I agree, and I question whether there is any advantage to these things.
If the benefit is supposed to be diagnosing swing flaws -- then this is like using a CAT scan to diagnose a common cold. Hint: your slice is cased by a weak grip, coming over the top, or both. It is relatively easy to diagnose swing flaws: You don't need a $50K monitor, you need a $500 camcorder and some photos of a "model" swing like those that appear in golf digest every month. The hard part is to break your bad habit and ingrain a good habit.
Oh, and don't tell VJ Singh that all that time he spends on the range is now an obsolete practice method.
Because the product has been around long enough to be a lot less unfinished.
What are you basing that on? You own opinion of how long it "should" take to create a new language? Please provide your evidence/reasoning to justify this. I recall using mozilla a couple years in and it sucked pretty bad. Now firefox is awesome. I recall the same chorus of "why are you taking so long, why do you have so many bugs?". In fact, I think that kind of impatience only happens to projects that will be great. It's only if people are excited by the positives that they bother complaining about the things that prevent them from using the innovations.
In addition to "release early, release often", another principle of open source is "it will ship when it's ready". If you think they are taking too long then either a) pitch in and help or b) try back later. Whining doesn't benefit anybody.
From what I've seen, Groovy's a half-baked programming language and unfinished product. See this criticism for a start.
Groovy does not claim to be a finished product. Does anyone suggest otherwise? Why do so many people need to make long winded disections of exactly how it is unfinished? This critique provides a set of likes and dislikes. Unfortuantely, the section of dislikes is an example of the kind of unhelpful impatience that many people seem to be hurling at groovy now. Every single one of the criticisms can be summaries as "groovy is still a work in progress", which is something that you don't need to read a review to know.
Open source project should "release early, release often", not so that people can tell them "you released early, damn you" but so that people who want the project to succeed can see what needs to be done and help. This is a good thing, and people who bash it are wrong.
Groovy offers significant advantages over jython and jruby because it was designed specifically to run in the JVM. In particular: a) groovy's class library is the java class library -- you do not subject development teams to two competing sets of class libraries, b) groovy compiles to bytecode which means its interoperability with java is seamless c) groovy can and does actually add syntax and functionality to existing java classes via the GDK.
The problem with groovy is that it is young. It is just starting into the release candidate phase. Some people have written articles bashing groovy for missing expected features like good parsing error feedback. These articles are unfair since they are evaluating a product that is unfinished. I do not recommend groovy for any production purpose yet, it's simply not ready.
That's a really interesting bit of history from the 2002-2003 period regarding Red Hat 8.0, an older version of a distro that no longer exists and whose successor (Fedora) is just about to do it's 5th major release. I really don't see what the state of rpm in 2003 can tell us about the state of rpm in 2006.
For the record, I've never had rpm db corruption, probably because I follow the advice in this bug and never kill -9 rpm when it is actually doing something (duh!). But if for some reason you do get db corruption, you can always follow the advice of the bug and do rpm --rebuilddb and clear the stale locks with rm -f/var/lib/rpm/__db*.
Google "competes" with MS in a sense because they are seeking to change the nature of computing from hardware/software based competition to network/information based competition. The problem I see with Google's strategy is that I don't see how anything they do locks customers in.
IBM is trying to change it to a services/problem solving based competition. IBM is spending lots of money trying to commoditize software because it is a complement to their services.
Of the three plans, I actually think IBM's is the most viable long term.
Has the previous hype of Java and J2EE moved on to Ruby (on Rails) and Python?
Ruby (on Rails) -- yes Python -- no (sorry)
And the hype will come back to java in about a year or two when people realize groovy has all the benefits of ruby but with a bigger set of production quality libraries (all those from java) and that it can be compiled too.
This is actually the most exciting time for java in a long time: a) scripting - groovy (JSR 241) & beanshell (JSR 274) & bindings eg for PHP (JSR 223) & BSF b) New lightweight frameworks are blossoming (eg spring, hibernate, webwork, EJB3) c) Aspect Orient Programming is blossoming in java (AspectJ, spring, JBoss) d) Tools growth -- Eclipse plugins, Ant tasks, JUnit extensions, velocity & xdoclet, XML utilities
When groovy hits 1.0 and the people who left for Ruby start realizing they miss all the java libraries, the hype will come back. RoR is popular for two reasons -- Ruby has a very efficient syntax and Rails innovated with the "convention over configuration" idea. Groovy solves the first problem and the second one will be adopted where appropriate by the framework wonks.
Ruby's downsides are it's a raw young language (weird errors, its slow, small set of libraries, and poor tools support). In the end these negatives and the innovative things happening in java will win out.
This is correct, sort of. Copyright gives copyright holders certain exclusive rights. Among these rights are the exclusive right to authorize the creation copies and the exclusive right to authorize the creation of derivitive works. A "license" is an expression that such things are actually so authorized.
A computer program is copied onto a hard drive when it is installed and it is copied again into memory when it executes, though this copy isn't exactly a perfect copy, since the program state changes as the program's variables get values, etc... . This is a peculiar feature of software that Congress adopted 17 USC 117 (which this case concerns) to address. Accordingly, when you buy a copy of the software, by statute, you do not need a second license to install the program or a third licence for the in-memory copy to run it.
This exception applies to "a" machine, so you need to purchase one copy per machine you run it on --OR-- the copyright owner must authorize (aka license) you to make any additional copies. This is how network licenses work. You pay money and you can make more than the single copy the law gives you by default.
The concept of "software is licensed, not sold" comes from a bad (and I believe intentional) misinterpretation of this and traces it's origins to Microsoft (surprise). OEM computer makers used to received images of the operating system that they would copy to harddrives as part of the production process. Since they were making copies on more than one system, they needed a license. The particular terms of **ONE** such license had microsoft actually retaining ownership of the master copy from which the OEM's made their copies. MS could reclaim the master at any time, because it was their property and was "on loan", so to speak. So this master copy was, in fact, not sold and the creation of multiple copies from it was licensed. There was a court case (Microsoft v Harmony) where Harmony was this kind of OEM. The result of the case was Harmony lost becasue they were borrowing MS's master copy and MS really did have the right to take it back.
If you are not an OEM operating under a similar agreement, then the conclusion of MS v Harmony doesn't apply to you. Under the law, once a copy is made it is a normal "good" and it is property in the ordinary sense. The first sale doctrine says the copy owner, not the copyright owner, controls the sale of this tangibile asset. This is true because copyright only concerns authorizing the creation of new copies, not control of the property after they are created.
This case in TFA is significant, because it upholds the idea that you can actually change the software to add functionality beyond what was there originally in order to make it work on the single machine you use it on. This is exactly what the statute says in 17 USC 117, but because a couple courts have fallen prey to the "software is licensed, not sold" trap and wrongly applied it in a different context than what MS v Harmony actually applies to. Other courts have gotten it right, and so we are left with a big mess where the law conflicts. Sooner or later the Supreme Court will have to fix the mess.
Actually, "work for hire" status is not simply a matter of agreement between an independent contractor and their client. There are some very limited circumstances where an independent contractor's work can be considered a "work for hire". Within these circumstances, an explicit agreement to "work for hire" status is always necessary, but it is nowhere close to sufficient. See this article. In fact, for a software contractor, it can almost never be acheived.
What the parties can do is agree to "assign" copyright ownership for the material in question to the client. This is different in that it does not absolve the contractor of certain kinds of liability the same way "work for hire" does.
You said it correctly: "work for hire" applies to material created by an employee during his or her term of employment. An independent contractor is NOT an "employee". There are a few very narrow cases where an independent contractor's work may be a "work for hire". All involve an explicit agreement to this effect, but even this is not sufficient to guarantee it legally. See this article for more info.
Normally, stuff you creates when not on the job is yours even if you are an "employee". The only time this isn't the case is if your employment contract specifically contains terms stating otherwise. It's never the case that you lose rights to work you create "off the clock" involunatarily. You must agree explicitly. Courts almost always resolve contract ambiguity in favor of the author.
For those that care, the case to read is CCNV v Reid, where the Supreme Court ruled in favor of a sculptor who created a statue for a non-profit organization when determining who owned the copyright. This opinion spells out everything and is the definitive precedent for all of this.
I read the opinion. He was an independent contractor. By default, independent contractors own the copyrights to stuff they create. The idea is that the terms of their contract should spell out explicitly the full extent of the transfer of ownership, and that which is not given up is retained. If you are a regular employee stuff you create for work is owned by your employer because you are a part of them legally. This is the same idea that protects true employees from being sued by third parties, but does not protect contractors. These principles define what happens in the absense of explicit contract agreements.
Walmart want the poor to stay poor since they will be unable to afford to shop anywhere else.
That is the most moronic thing that I have ever seen moderated +5 Insightful. Stores generally sell more stuff when their customers are doing well economicaly -- Duh.
Walmart and the "worker hating right" want workers to get more stuff for their money. Walmart lowers the cost of living for everyone and thereby increases the size of the middleclass.
The truth is the left wants the poor to stay poor by having to pay more to get less. "Mom and pop" is this false image they create to distract from the fact they take food and clothes out of the walmart shopping bags of the very workers they claim to care so much about.
What is so utterly rediculous is that the left doesn't give a damn about small business owners (the real mom and pop). These people vote conservative by overwhelming margins. They want the governement to reduce needless regulation, streamline their tax burden, and reduce their exposure to wild litigation.
If you want to help "mom and pop" -- why don't you ask them what they want and implement it? They aren't complaining about walmart or competition -- they are complaining about government.
The funny thing about the vi/emacs flame wars is I tend to agree with both sides -- I hate both Emacs and vi. Both of them are symptomatic of the core problem with a lot of open source software: they both suck from a usability point of view. I simply refuse to use a program that requires me to learn arcane key bindings.
Having said that, I also hate most IDE's. The suck for the opposite problem -- they dumb down the noble task of programming. Saving me from key bindings is good, making me clueless about my code is bad.
Is there anyone out there like me?
If you are, I recommend jEdit. It is a nice GUI editor with a lot of power programmer features. It's open source with a very good plugin architecture. One of the plugins allows you to run a console, and once you get used to this, you realize that when you are coding it is better to run your shell in your editor than your editor in your shell.
It can edit over sftp and this defeats the standard "what if I need to remote in" argument that defenders of vi and emacs always use to say why they can't switch. We all know the real reason is they are just set in their ways.
I am surprised that it has not yet happened that a disgruntled IT worker has not launched such an attack targetted at a specific company. I still think it is a matter of time until a company suffers such a severe attack that it is forced under.
No, Ant is a substantially better way to build large projects than make for three reasons: 1) Easily extended with reusable tasks 2) Easier integration with editors & IDE's 3) Cross platform
All three of these leverage the XML syntax for a more constrained syntax.
I see no evidence that ant is getting harder to use as time goes by. If anything, I see custom ant tasks popping up to do more heavy lifting at build time with no real increase in use complexity, since it is trivial to document how to invoke an ant task in a very concise way.
There are some enormous projects building with ant, so I don't think there is much else for it to prove.
Most FOSS is not that innovative and just clones existing applications.
While this may be true the way you stated it, you can say exactly the same thing of proprietary software. If you look in a large arena, most things are not going to be innovative. The question that should be asked is: given that innovation is rare, where is most innovation occuring?
I would say 60% of the innovative new ideas in software over the last 7-8 years are coming from the open source java arena. Examples are Spring, Ant, JUnit, Hibernate, Maven, Struts, AspectJ, Cocoon. It's hard to point to any of these and claim it is a knockoff of something else.
Other recent innovative things from the open source realm outside of Java include Ruby on Rails, Subversion, BitTorrent.
I really can't think of a whole lot of innovation that is occuring OUTSIDE of the open source arena. I guess there is a fair amount of innovation occuring in the standards making processes, though it's hard to give credit to a software team as being "inovative" if all they do is implement a standard. Useful, certainly, but I wouldn't say innovative.
First off, there's no downside: - It costs nothing - It risks nothing, as there is no marketability - The licence clearly states no warantee, no support
It's "fair" and good for "the community" - You use open source, so you should "give back" - Others may benefit from it, appreciate you - If everyone takes cost free steps for mutual benefit, everyone will be better off
The upside is all positive: - You may get help finding & fixing bugs - You may get help enhancing it
It highlights publicly good work that your company has done - Releasing code is comparable to publishing in a trade journal, and is valuable for the same reasons - Associates your company, department, and you specifically with an area of expertise - May place your company in higher esteem among the IT community, which helps hiring - Generally, networking with others with similar business problems is good experience
Actually, I would argue that the best design document is a NON-existent one. Documentation is a non value added task unless it actually results in the final product being produced more quickly with fewer bugs. I see no reason why I cannot go from something like use case documents to unit tests, API documentation (like javadocs), and a physical data model.
The people who are wasting their time making documents that won't be maintained and therefore will be guaranteed to be wrong, should just be coding tests, classes, and DDL scripts.
If you view the design doc as an end in itself, then it should provide traceability from every "what" enumerated in the requirements documents to the corresponding "how". This could be done with class models, physical database models, data flow diagrams, and sequence diagrams, along with a big matrix cross referencing these artifacts to the enumaration of the requirements.
I contend that requirements are never stable enough for this traceability to have any real value. All it does is add cycle time to feature changes and make you less agile and produce fewer features per year. Even if all requirements were known and set in stone, the "best" way to implement them changes over time as new technoligies and standards (including your organization's internal ones) change. So design documents hamper refactoring. I content refactoring and agility are more important that auditability to the bottom line of your enterprise.
How does the exectution of a proxy bidding algorithm whose workings are fully disclosed ahead of time constitutue an "interest". You only can have a conflict of interest when you are exercising discretion in some way and a simultenous duty to use your discretion to benefit different goals. If you have no discretion, the whole question is moot. At every step, all bidders and the seller can rely on ebay behaving in the pre-ordained way.
Your statement is sort of like saying the rules of chess have a conflict of interest between the white pieces and the black pieces.
What nobody is talking about is that there are two aspects to the proxy bidding system: the maximum bid and the timestamp associated with that bid. Each named bidder is only allowed one such pair to control their bidding.
The plaintiff here wants to get out of this one "max/timestamp pair" situation with the best of both worlds -- they want to use the later and larger max, but they also want to keep their earlier timestamp, which allows them a non full increment bid.
Think of it this way: you told it to max you out at 100.09. Somebody else bid it up to 100.00. What makes you think you have the right to increase that by.09 cents, less than the next increment? It is the timestamp of your proxy bid. But when you change the value of your proxy, you changed the timestamp.
The kicker here is that the priviledge of winning by less than the bid increment comes with a definite disadvantage -- your auction opponent looks out and sees his bid of 100.00 beat by your bid of 100.09. He should fairly be able to ask "why is that jerk not required to bid up to the increment". The only fair answer is if he can rely on the fact that your 100.09 top bid reveals that you are maxed out and that he surpass your proxy max by bidding 101.09. If you are allowed to raise your proxy max without raising your current bid, he should be able to bid 101.09 and force you to bid 102.09. Instead, your new proxy max and timestamp puts you with the high current bid of 101.00 and forces your opponent to bid 102.00, which gives you an advantage towards winning the item since this is higher than the alternative where they could bid 101.09. This may be enough of an advantage to cause you to win. In short -- there was NO GUARANTEE you would have won with your original 100.09, since you are not able to decide for your opponent what his course of action would have been.
The reason the plaintiff will lose this case is that 1) the rules were clear ahead of time 2) raising your proxy max invalidates your old proxy timestamp which is what permitted the non-increment raise 3) there is no guarantee your original high bid would have won (and thus no proof of harm) 4) You cannot prove that you didn't actually pay LESS because of this system.
A) you were less vulnerable to sniping because your opponents could no longer infer that your current bid was your proxy max, and
B) your opponents would have had to raise two full increments above their previous bid to test you.
I happen to know Dr. Bernstein because I went to grad school with him. It's completely odd to me that people are up in arms over an assignment like this that wasn't achievable. It sounds like these students learned a hell of a lot. Who cares if the initial assignment was unrealistically hard. I think that's actually good -- it makes people try to stretch. In fact, I doubt we would have 44 security vulnerabilities if the goal had been to find 2 each.
I seriously doubt Dr. Bernstein is going to fail all these students. He should give them the grades he thinks they deserve with one letter grade lower for whiners. People who lose sight of the importance of the subject matter because they are obsessed with grades rather disgust me.
What percent of software bugs do you think can be trapped by a "do you want to submit an error report" dialogue? And without steps to duplicate being submitted, most of those error reports are useless anyway. Error reports can only catch certain crasher type bugs. A quick look in bugzilla showed 200 of the 5712 known firefox bugs involve a crash.
And right there is everything that is wrong with what how you are suggesting things should work. A user shouldn't have to know what a "buffer overflow" is.
I don't expect them to be able to contribute at all to solving such a bug. But like it or not buffer overflows exist and most are **never** found by any ordinary use. Which means no "do you want to..." dialouge ever appears. Who types in 10000 characters to the text box in the diologue buried four levels deep?
Slashdot Mirror
I agree, and I question whether there is any advantage to these things.
If the benefit is supposed to be diagnosing swing flaws -- then this is like using a CAT scan to diagnose a common cold. Hint: your slice is cased by a weak grip, coming over the top, or both. It is relatively easy to diagnose swing flaws: You don't need a $50K monitor, you need a $500 camcorder and some photos of a "model" swing like those that appear in golf digest every month. The hard part is to break your bad habit and ingrain a good habit.
Oh, and don't tell VJ Singh that all that time he spends on the range is now an obsolete practice method.
Because the product has been around long enough to be a lot less unfinished.
What are you basing that on? You own opinion of how long it "should" take to create a new language? Please provide your evidence/reasoning to justify this. I recall using mozilla a couple years in and it sucked pretty bad. Now firefox is awesome. I recall the same chorus of "why are you taking so long, why do you have so many bugs?". In fact, I think that kind of impatience only happens to projects that will be great. It's only if people are excited by the positives that they bother complaining about the things that prevent them from using the innovations.
In addition to "release early, release often", another principle of open source is "it will ship when it's ready". If you think they are taking too long then either a) pitch in and help or b) try back later. Whining doesn't benefit anybody.
From what I've seen, Groovy's a half-baked programming language and unfinished product. See this criticism for a start.
Groovy does not claim to be a finished product. Does anyone suggest otherwise? Why do so many people need to make long winded disections of exactly how it is unfinished? This critique provides a set of likes and dislikes. Unfortuantely, the section of dislikes is an example of the kind of unhelpful impatience that many people seem to be hurling at groovy now. Every single one of the criticisms can be summaries as "groovy is still a work in progress", which is something that you don't need to read a review to know.
Open source project should "release early, release often", not so that people can tell them "you released early, damn you" but so that people who want the project to succeed can see what needs to be done and help. This is a good thing, and people who bash it are wrong.
Groovy offers significant advantages over jython and jruby because it was designed specifically to run in the JVM. In particular: a) groovy's class library is the java class library -- you do not subject development teams to two competing sets of class libraries, b) groovy compiles to bytecode which means its interoperability with java is seamless c) groovy can and does actually add syntax and functionality to existing java classes via the GDK.
The problem with groovy is that it is young. It is just starting into the release candidate phase. Some people have written articles bashing groovy for missing expected features like good parsing error feedback. These articles are unfair since they are evaluating a product that is unfinished. I do not recommend groovy for any production purpose yet, it's simply not ready.
That's a really interesting bit of history from the 2002-2003 period regarding Red Hat 8.0, an older version of a distro that no longer exists and whose successor (Fedora) is just about to do it's 5th major release. I really don't see what the state of rpm in 2003 can tell us about the state of rpm in 2006.
/var/lib/rpm/__db*.
For the record, I've never had rpm db corruption, probably because I follow the advice in this bug and never kill -9 rpm when it is actually doing something (duh!). But if for some reason you do get db corruption, you can always follow the advice of the bug and do rpm --rebuilddb and clear the stale locks with rm -f
Funny you say that, because Hibernate uses Velocity.
Google "competes" with MS in a sense because they are seeking to change the nature of computing from hardware/software based competition to network/information based competition. The problem I see with Google's strategy is that I don't see how anything they do locks customers in.
IBM is trying to change it to a services/problem solving based competition. IBM is spending lots of money trying to commoditize software because it is a complement to their services.
Of the three plans, I actually think IBM's is the most viable long term.
I think he's using it in a "F*cked Up Drivel" sense rather than the legacy "Fear, Uncertainty, and Doubt" sense.
Has the previous hype of Java and J2EE moved on to Ruby (on Rails) and Python?
Ruby (on Rails) -- yes
Python -- no (sorry)
And the hype will come back to java in about a year or two when people realize groovy has all the benefits of ruby but with a bigger set of production quality libraries (all those from java) and that it can be compiled too.
This is actually the most exciting time for java in a long time:
a) scripting - groovy (JSR 241) & beanshell (JSR 274) & bindings eg for PHP (JSR 223) & BSF
b) New lightweight frameworks are blossoming (eg spring, hibernate, webwork, EJB3)
c) Aspect Orient Programming is blossoming in java (AspectJ, spring, JBoss)
d) Tools growth -- Eclipse plugins, Ant tasks, JUnit extensions, velocity & xdoclet, XML utilities
When groovy hits 1.0 and the people who left for Ruby start realizing they miss all the java libraries, the hype will come back. RoR is popular for two reasons -- Ruby has a very efficient syntax and Rails innovated with the "convention over configuration" idea. Groovy solves the first problem and the second one will be adopted where appropriate by the framework wonks.
Ruby's downsides are it's a raw young language (weird errors, its slow, small set of libraries, and poor tools support). In the end these negatives and the innovative things happening in java will win out.
This is correct, sort of. Copyright gives copyright holders certain exclusive rights. Among these rights are the exclusive right to authorize the creation copies and the exclusive right to authorize the creation of derivitive works. A "license" is an expression that such things are actually so authorized.
A computer program is copied onto a hard drive when it is installed and it is copied again into memory when it executes, though this copy isn't exactly a perfect copy, since the program state changes as the program's variables get values, etc... . This is a peculiar feature of software that Congress adopted 17 USC 117 (which this case concerns) to address. Accordingly, when you buy a copy of the software, by statute, you do not need a second license to install the program or a third licence for the in-memory copy to run it.
This exception applies to "a" machine, so you need to purchase one copy per machine you run it on --OR-- the copyright owner must authorize (aka license) you to make any additional copies. This is how network licenses work. You pay money and you can make more than the single copy the law gives you by default.
The concept of "software is licensed, not sold" comes from a bad (and I believe intentional) misinterpretation of this and traces it's origins to Microsoft (surprise). OEM computer makers used to received images of the operating system that they would copy to harddrives as part of the production process. Since they were making copies on more than one system, they needed a license. The particular terms of **ONE** such license had microsoft actually retaining ownership of the master copy from which the OEM's made their copies. MS could reclaim the master at any time, because it was their property and was "on loan", so to speak. So this master copy was, in fact, not sold and the creation of multiple copies from it was licensed. There was a court case (Microsoft v Harmony) where Harmony was this kind of OEM. The result of the case was Harmony lost becasue they were borrowing MS's master copy and MS really did have the right to take it back.
If you are not an OEM operating under a similar agreement, then the conclusion of MS v Harmony doesn't apply to you. Under the law, once a copy is made it is a normal "good" and it is property in the ordinary sense. The first sale doctrine says the copy owner, not the copyright owner, controls the sale of this tangibile asset. This is true because copyright only concerns authorizing the creation of new copies, not control of the property after they are created.
This case in TFA is significant, because it upholds the idea that you can actually change the software to add functionality beyond what was there originally in order to make it work on the single machine you use it on. This is exactly what the statute says in 17 USC 117, but because a couple courts have fallen prey to the "software is licensed, not sold" trap and wrongly applied it in a different context than what MS v Harmony actually applies to. Other courts have gotten it right, and so we are left with a big mess where the law conflicts. Sooner or later the Supreme Court will have to fix the mess.
Actually, "work for hire" status is not simply a matter of agreement between an independent contractor and their client. There are some very limited circumstances where an independent contractor's work can be considered a "work for hire". Within these circumstances, an explicit agreement to "work for hire" status is always necessary, but it is nowhere close to sufficient. See this article. In fact, for a software contractor, it can almost never be acheived.
What the parties can do is agree to "assign" copyright ownership for the material in question to the client. This is different in that it does not absolve the contractor of certain kinds of liability the same way "work for hire" does.
You said it correctly: "work for hire" applies to material created by an employee during his or her term of employment. An independent contractor is NOT an "employee". There are a few very narrow cases where an independent contractor's work may be a "work for hire". All involve an explicit agreement to this effect, but even this is not sufficient to guarantee it legally. See this article for more info.
Normally, stuff you creates when not on the job is yours even if you are an "employee". The only time this isn't the case is if your employment contract specifically contains terms stating otherwise. It's never the case that you lose rights to work you create "off the clock" involunatarily. You must agree explicitly. Courts almost always resolve contract ambiguity in favor of the author.
For those that care, the case to read is CCNV v Reid, where the Supreme Court ruled in favor of a sculptor who created a statue for a non-profit organization when determining who owned the copyright. This opinion spells out everything and is the definitive precedent for all of this.
I read the opinion. He was an independent contractor. By default, independent contractors own the copyrights to stuff they create. The idea is that the terms of their contract should spell out explicitly the full extent of the transfer of ownership, and that which is not given up is retained. If you are a regular employee stuff you create for work is owned by your employer because you are a part of them legally. This is the same idea that protects true employees from being sued by third parties, but does not protect contractors. These principles define what happens in the absense of explicit contract agreements.
Walmart want the poor to stay poor since they will be unable to afford to shop anywhere else.
That is the most moronic thing that I have ever seen moderated +5 Insightful. Stores generally sell more stuff when their customers are doing well economicaly -- Duh.
Walmart and the "worker hating right" want workers to get more stuff for their money. Walmart lowers the cost of living for everyone and thereby increases the size of the middleclass.
The truth is the left wants the poor to stay poor by having to pay more to get less. "Mom and pop" is this false image they create to distract from the fact they take food and clothes out of the walmart shopping bags of the very workers they claim to care so much about.
What is so utterly rediculous is that the left doesn't give a damn about small business owners (the real mom and pop). These people vote conservative by overwhelming margins. They want the governement to reduce needless regulation, streamline their tax burden, and reduce their exposure to wild litigation.
If you want to help "mom and pop" -- why don't you ask them what they want and implement it? They aren't complaining about walmart or competition -- they are complaining about government.
The funny thing about the vi/emacs flame wars is I tend to agree with both sides -- I hate both Emacs and vi. Both of them are symptomatic of the core problem with a lot of open source software: they both suck from a usability point of view. I simply refuse to use a program that requires me to learn arcane key bindings.
Having said that, I also hate most IDE's. The suck for the opposite problem -- they dumb down the noble task of programming. Saving me from key bindings is good, making me clueless about my code is bad.
Is there anyone out there like me?
If you are, I recommend jEdit. It is a nice GUI editor with a lot of power programmer features. It's open source with a very good plugin architecture. One of the plugins allows you to run a console, and once you get used to this, you realize that when you are coding it is better to run your shell in your editor than your editor in your shell.
It can edit over sftp and this defeats the standard "what if I need to remote in" argument that defenders of vi and emacs always use to say why they can't switch. We all know the real reason is they are just set in their ways.
I am surprised that it has not yet happened that a disgruntled IT worker has not launched such an attack targetted at a specific company. I still think it is a matter of time until a company suffers such a severe attack that it is forced under.
No, Ant is a substantially better way to build large projects than make for three reasons:
1) Easily extended with reusable tasks
2) Easier integration with editors & IDE's
3) Cross platform
All three of these leverage the XML syntax for a more constrained syntax.
I see no evidence that ant is getting harder to use as time goes by. If anything, I see custom ant tasks popping up to do more heavy lifting at build time with no real increase in use complexity, since it is trivial to document how to invoke an ant task in a very concise way.
There are some enormous projects building with ant, so I don't think there is much else for it to prove.
Most FOSS is not that innovative and just clones existing applications.
While this may be true the way you stated it, you can say exactly the same thing of proprietary software. If you look in a large arena, most things are not going to be innovative. The question that should be asked is: given that innovation is rare, where is most innovation occuring?
I would say 60% of the innovative new ideas in software over the last 7-8 years are coming from the open source java arena. Examples are Spring, Ant, JUnit, Hibernate, Maven, Struts, AspectJ, Cocoon. It's hard to point to any of these and claim it is a knockoff of something else.
Other recent innovative things from the open source realm outside of Java include Ruby on Rails, Subversion, BitTorrent.
I really can't think of a whole lot of innovation that is occuring OUTSIDE of the open source arena. I guess there is a fair amount of innovation occuring in the standards making processes, though it's hard to give credit to a software team as being "inovative" if all they do is implement a standard. Useful, certainly, but I wouldn't say innovative.
First off, there's no downside:
- It costs nothing
- It risks nothing, as there is no marketability
- The licence clearly states no warantee, no support
It's "fair" and good for "the community"
- You use open source, so you should "give back"
- Others may benefit from it, appreciate you
- If everyone takes cost free steps for mutual benefit, everyone will be better off
The upside is all positive:
- You may get help finding & fixing bugs
- You may get help enhancing it
It highlights publicly good work that your company has done
- Releasing code is comparable to publishing in a trade journal, and is valuable for the same reasons
- Associates your company, department, and you specifically with an area of expertise
- May place your company in higher esteem among the IT community, which helps hiring
- Generally, networking with others with similar business problems is good experience
Actually, I would argue that the best design document is a NON-existent one. Documentation is a non value added task unless it actually results in the final product being produced more quickly with fewer bugs. I see no reason why I cannot go from something like use case documents to unit tests, API documentation (like javadocs), and a physical data model.
The people who are wasting their time making documents that won't be maintained and therefore will be guaranteed to be wrong, should just be coding tests, classes, and DDL scripts.
If you view the design doc as an end in itself, then it should provide traceability from every "what" enumerated in the requirements documents to the corresponding "how". This could be done with class models, physical database models, data flow diagrams, and sequence diagrams, along with a big matrix cross referencing these artifacts to the enumaration of the requirements.
I contend that requirements are never stable enough for this traceability to have any real value. All it does is add cycle time to feature changes and make you less agile and produce fewer features per year. Even if all requirements were known and set in stone, the "best" way to implement them changes over time as new technoligies and standards (including your organization's internal ones) change. So design documents hamper refactoring. I content refactoring and agility are more important that auditability to the bottom line of your enterprise.
Conflict of interest.
How does the exectution of a proxy bidding algorithm whose workings are fully disclosed ahead of time constitutue an "interest". You only can have a conflict of interest when you are exercising discretion in some way and a simultenous duty to use your discretion to benefit different goals. If you have no discretion, the whole question is moot. At every step, all bidders and the seller can rely on ebay behaving in the pre-ordained way.
Your statement is sort of like saying the rules of chess have a conflict of interest between the white pieces and the black pieces.
What nobody is talking about is that there are two aspects to the proxy bidding system: the maximum bid and the timestamp associated with that bid. Each named bidder is only allowed one such pair to control their bidding.
.09 cents, less than the next increment? It is the timestamp of your proxy bid. But when you change the value of your proxy, you changed the timestamp.
The plaintiff here wants to get out of this one "max/timestamp pair" situation with the best of both worlds -- they want to use the later and larger max, but they also want to keep their earlier timestamp, which allows them a non full increment bid.
Think of it this way: you told it to max you out at 100.09. Somebody else bid it up to 100.00. What makes you think you have the right to increase that by
The kicker here is that the priviledge of winning by less than the bid increment comes with a definite disadvantage -- your auction opponent looks out and sees his bid of 100.00 beat by your bid of 100.09. He should fairly be able to ask "why is that jerk not required to bid up to the increment". The only fair answer is if he can rely on the fact that your 100.09 top bid reveals that you are maxed out and that he surpass your proxy max by bidding 101.09. If you are allowed to raise your proxy max without raising your current bid, he should be able to bid 101.09 and force you to bid 102.09. Instead, your new proxy max and timestamp puts you with the high current bid of 101.00 and forces your opponent to bid 102.00, which gives you an advantage towards winning the item since this is higher than the alternative where they could bid 101.09. This may be enough of an advantage to cause you to win. In short -- there was NO GUARANTEE you would have won with your original 100.09, since you are not able to decide for your opponent what his course of action would have been.
The reason the plaintiff will lose this case is that
1) the rules were clear ahead of time
2) raising your proxy max invalidates your old proxy timestamp which is what permitted the non-increment raise
3) there is no guarantee your original high bid would have won (and thus no proof of harm)
4) You cannot prove that you didn't actually pay LESS because of this system.
A) you were less vulnerable to sniping because your opponents could no longer infer that your current bid was your proxy max, and
B) your opponents would have had to raise two full increments above their previous bid to test you.
So you admit you're the weird one.
I happen to know Dr. Bernstein because I went to grad school with him. It's completely odd to me that people are up in arms over an assignment like this that wasn't achievable. It sounds like these students learned a hell of a lot. Who cares if the initial assignment was unrealistically hard. I think that's actually good -- it makes people try to stretch. In fact, I doubt we would have 44 security vulnerabilities if the goal had been to find 2 each.
I seriously doubt Dr. Bernstein is going to fail all these students. He should give them the grades he thinks they deserve with one letter grade lower for whiners. People who lose sight of the importance of the subject matter because they are obsessed with grades rather disgust me.
What percent of software bugs do you think can be trapped by a "do you want to submit an error report" dialogue? And without steps to duplicate being submitted, most of those error reports are useless anyway. Error reports can only catch certain crasher type bugs. A quick look in bugzilla showed 200 of the 5712 known firefox bugs involve a crash.
And right there is everything that is wrong with what how you are suggesting things should work. A user shouldn't have to know what a "buffer overflow" is.
I don't expect them to be able to contribute at all to solving such a bug. But like it or not buffer overflows exist and most are **never** found by any ordinary use. Which means no "do you want to..." dialouge ever appears. Who types in 10000 characters to the text box in the diologue buried four levels deep?