You seem to be using a non-standard definition of an algorithm (programs are a superset of algorithms, the primary difference being that algorithms must terminate while programs may or may not).
That's not how it was taught to me. I interpret "algorithm" to mean a set of step-by-step instructions for carrying out some computation. There's no need for the instructions to be machine-understandable, as they are essentially mathematical entities. Programs use algorithms (often by composing more than one together) to solve particular tasks on particular datasets. Thus, quicksort is an algorithm (that happens to be typically characterized as a function call for ease of calling) but the fact that you could instruct it to sort a set of people by skin colour does not make quicksort itself defamatory - it just sorts things, any things - it's the use which you put it to which problematic. (Interestingly, neither is an algorithm to go from a skin colour to a score itself inherently defamatory, but it could be used by someone intent on mischief for defamatory purposes. But in that case the fault is not with the algorithm but rather the use of it.)
A subjective judgement as to wether the "garbage" output by a particular program is/isn't defamatory is outside the realm of computer science.
It might be possible (if horribly difficult) to construct a computerized semantic model of what is or isn't defamatory, and there is a field within CS that focusses on such things (OK, in practice they do more work on stuff like understanding biology, leading to things like bioinformatics). Given such a model, it would then be possible to work out whether the computations done by a particular algorithm are potentially defamatory given some particular dataset, assuming anyone gives any credence to the results of the algorithm at all.
FYI, it's entirely up to the ISP (or whoever is running the particular newsserver) which groups to carry. It always was. A lot of them block binaries groups, usually on the grounds that they're more trouble than they're worth. (If you've got a binary you want to distribute, put it on an FTP server or a website; those protocols are much better designed for bulk data transfer.)
It really depends on what you're doing with it. For example, if the program is recommending what hue of skin cream (or made-to-measure suit, or something else like that) will work best with your colouration, then that program that requests that info for such purposes can hardly be inherently defamatory. On the other hand, it is most certainly possible to use a program to defame someone: it's not that hard to conceive of ways to do it (e.g. by spamming libellous statements all over the place.) But all this is programs, not algorithms; I've no idea what a defamatory algorithm might look like, and I don't think it is possible to make mathematics work that way.
As an aside, I really doubt that skin colour is going to be expressible as a simple enumeration or integer, so you won't be able to switch on it...
If Linux and the GNU project had taken your attitude of "hey, I'm just a guy putting up my code," then the community would be in a very different position today wrt. Microsoft's patent aggression.
That's hard to say for sure; if they'd done that, then they'd also be running a real risk of having other companies doing the same back to them. It's perhaps more of a Mexican Standoff, where if any big player starts throwing their weight around, everyone loses (except the lawyers).
If I take BSD licensed code and make a change to it and then license this new group of code as GPL, I don't think there is any problem.
Actually, I think that's one of the very few ways of violating the BSD license.:-) One of the key requirements of BSD code is that the copyright and license of the source code files themselves are retained. On the other hand, you can aggregate those files with other source files that are GPLed for the purposes of redistribution, and you can build the code into sets of binaries and libraries pretty much any way you want (so function calls or #includes cause no problems). If you instead choose to commercialize, failing to distribute source to any of the BSD parts (even if modified by you) isn't a big deal (the GPL parts aren't the concern of the BSD licensed code).
The major incentive for the members of a BSD community to share are that if they don't, they run the real risk of the rest of the community making incompatible changes that make the keeping of the the non-sharer's local changes up to date into a support nightmare. In other words they really strongly encourage openness and sharing. They just don't feel that it is right to use the license to enforce the policy; they prefer social/community enforcement.
I think in the free software community [GPLv3] will get a lot of support from developers.
But the free software community is comprised of people who have already bought into the GPL; that they'll support the update is not surprising. (For the FSF to have created an update that largely alienated their own supporters would have been unexpected, especially given the years of consultation and socialization of the update that they've been doing.)
The more interesting cases are whether there are people in either the wider open software community or the non-open (and non-free) community who will be either attracted in or repelled (in the case of the non-open folks, repelled from either free or open licensed software) by the GPL update. I suspect that v3 probably won't bring many new people into the free community in itself - most of those who get excited over licensing have already nailed their colours to the mast - to get substantially more devs in the v3 space will require the creation of one or more new "must develop with" codebases using the new license.
[Declaration: I develop BSD software. I do so because it suits me philosophically, and because I like the community I'm part of. I know people are building commercial products on my code. I don't mind, since I know they're having to put lots of their own effort in to make it worthwhile; they've earned their crust.]
[An approach is to] indoctrinate school kids to believe that copyright infringement is a Great Evil on a par with Rape, Murder, Genocide, and Britney Spears.
Oh well, at least it isn't as bad as Celine Dion...
Heh. I've done that in the past. I'd got a machine into a state where I couldn't access any real devices - all I had was a ramdisk preloaded with not very much more than the core of DOS - and needed an executable in a particular location so that I could get the system to the point where I could boot a Linux install disk (I don't want to remember more details, other than the fact that this was in 1992 or 1993). It turns out that it is easier to write a COM file by hand than an EXE, but it's still possible...
It's a really interesting example of a web feature that deviated massively from its original purpose into something that the community of the site found useful and neat (well, you and me, anyway - I quite liked the way it used to work as well).
Rather than build on that they decided to tweak the system (for understandable reasons) so it started working more as it was originally intended - as a way to tag/classify stories at a high level.
Agreed. The best thing about the tags is that they were community generated, giving an efficient channel for finding out what people were thinking about a story. Right now, it just gives the info which I get from the icons anyway. When tags were "Web 2.0" they were good, but now they're much more like "Classical Semantic Web" and so suck donkey balls.
And what would you suggest instead? NEdit seems to be distinctly sub-emacs in features (though with different bindings) and Eclipse is massive (though good for a few things: notably Java and XSD/WSDL, all of which are impossibly officious without a fancy editor to help you out). Everyone knows that notepad is a terrible editor for real use, and ed is only for the real hard-core. (OK, I admit I like ed. But I wouldn't want to write code in it if at all possible, not these days.) If I've not mentioned what you think we should be using instead of vi or emacs, be prepared to say.
Taco changed the code; I'm guessing to disallow the stupid tags that got put on almost every story, like those you mentioned. Maybe to greylist those who kept tagging that way, too.
I think there's a list of tags that are permitted (blacklisting tags would be easier to route around by finding alternate things that mean the same thing) but as far as I can see, there's no downside to using a non-blessed tag; it just gets dropped on the floor.
I think it's a shame though; the old tagging system added a good bit of fun to the site, and the "joke" tags were sometimes very appropriate indeed. The new system is just boring crap that reproduces what is already in there from the article categories or a simple search of the part of the story on the front page; a search engine could do those tags, or even plain old grep, and so they add nothing of value. The old system was better because it provided a snapshot of what people thought about the story, despite being much more open to abuse.
No, but it does autonomously write and submit kernel patches.
Re:libgcc, libstdc++, and Bison
on
GPLv2 Vs. GPLv3
·
· Score: 1
But how do I know that they won't? OK, I believe that they won't, since the stink that it would raise would be quite amazingly bad for their cause, but have they given an enduring commitment that they will never remove things like license exemptions for libgcc? If they haven't, the business perspective is that there's something of a hostage to fortune there. (Now if there was such a commitment given somewhere and I've not seen it, I apologize for FUD-slinging. But my google-fu wasn't strong tonight.)
Re:libgcc, libstdc++, and Bison
on
GPLv2 Vs. GPLv3
·
· Score: 0, Troll
Other Slashdot users have expressed worry that the FSF might end [the libgcc] exception. But I see no basis for this worry.
On what grounds do have this tremendous outbreak of optimism? Scummy license tricks have occurred in the past with some programs; what guarantees that the FSF won't do so in the future (e.g. to solve a budget problem or to further some political agenda)?
Re:The GPL: Intellectual Theft
on
GPLv2 Vs. GPLv3
·
· Score: 2, Interesting
People who use BSD-like licences are giving away their work, usually because they want to maximise the amount of value others get from it.
It should be noted that people who do this do so in the hope that others will do the same, and the amount of respect you get in such a community relates very closely to the amount that you give. It's a gift economy, and it works pretty well when the cost of giving a copy is so small. (Of course, you actually get something that looks virtually the same with GPL licensed code, except the GPL people believe they shouldn't give back to the BSD community, which is rude.)
Re:Why we stayed clear of the GPL
on
GPLv2 Vs. GPLv3
·
· Score: 1
Another way of looking at it is that the BSDL has invisible strings attached that ensure that you will never be paid, not even in the abstract sense of knowing that you might be aided down the line some day by someone returning the favour. That's a pretty big price to pay; too big for me.
[Emphasis mine for clarity.]
The BSD license does not ensure that you never get (broad-sense) "paid". If it did, I would never have received credit for those things that I've written under the BSDL, and yet I most certainly have been compensated in kind by a great many people. QED. Given that, your paragraph above is at best hyperbole, and the first clause of the conclusion you draw is probably unsound; the price paid isn't high by any objective measure. On the other hand, it might just be that your threshold is ultra-low, so I can't dispute whether the price is too big for you or not (the second clause of your conclusion). But I would point out that if you ever get fed up of the GPL crew, most groups that use the BSDL will welcome you.
What would be considered "good stuff" on one site (or even by one moderator) would be considered ignorant drivel on another site (or by a different moderator).
You achieve all the same benefits without the problems just by having your own reputation/moderation system.
I suspect that there will be a lot of correlation between sites, as people who act like asses in one place are more likely to do so elsewhere. On the other hand, I also think that what will actually emerge is that the sites that correlate cluster in groups: if you have a good rep on site A, you're more likely to have a good rep on site B and a bad rep on site C, and you probably won't frequent D at all. Given all that, someone with a good search engine and a lot of cleverness will be able to start mapping out what these virtual communities actually look like and other sociological/anthropological stuff like that.
But will sharing reputation systems help sites? I think so, eventually, but not for many years yet. Until the reputation clusters have been found, sharing is as likely to introduce needless pollution of reputation systems as it is to enable reputations to be built up quickly. (Could there be a single reputation cluster? Maybe, but I suspect not; people are too inclined to divide the world into "us" and "them" for it to work out.)
One thing that might come out of reputation research is that it might become possible to use the reputation clusters to predict, from someone's interests and interactions, which sorts of sites they'd like to visit. OK, that does sound backwards, but it should guide people to where they won't want to make a total fool of themselves on a regular basis (yes, even the griefing pranksters; after all, when amongst the fools the foolish are sages and the wise foolish.) It may also eventually be possible to join the reputation clusters up, but using negative links (so reputations on sites for followers of Xenu who believe in ID and the supremacy of feng shui of placement of feeding bowls for their chihuahua will negatively reinforce reputations here) but I doubt that will help any time soon. There's a revolution waiting to happen here, but since it really involves lots of people, it'll take time to brew.
On the other hand, it is sensible to start working out what technological steps are required to enable specific bipartite reputation sharing, as well as looking at how to build sane single-site reputation systems. For example, slashdot's is pretty good in that it isn't easy to totally game the system while being mostly self-regulating, but can it be bettered without input of data from outside sites? If it can't be greatly improved, how difficult will it be to export the system to other sites? (It's late: I'm sure you can think of other aspects, but I can't right now.)
Just because the people who Eolas bought the patent from were the first to pose the problem, that still doesn't make the solution any less obvious.
Funnily enough, the actual inventor is also the CEO of Eolas (which was a spin-off technology transfer firm from the university where he worked as I understand it, a common enough occurrence). While I don't care for software patents for the most part and think that they were enforced in a way that sucked (thanks to odd guidance from SCOTUS) under the standards of obviousness of the time what they were doing was patentable. I remember the early web from around 1993; the whole plugin thing was definitely novel at the time when Eolas was busy inventing, even if it became thoroughly obvious several years later. (Arguably, the technology became obvious because of people having seen the tech that the Eolas people were hawking around.)
Would anyone grant such a step ahead of the current normal state of the art now under modern "obviousness" rules? I hope not; the system was seriously screwed at the time. On the other hand, would you, if you were a small inventor that offered a tech to Microsoft but had it turned down only to then have the 800-lb gorilla then use it in a flagship product, want MS to get away with it? (If you answer "yes" to that one, I have to ask whether you like throwing chairs and chanting "developers"...) I know it's fashionable among a certain clique to hate Eolas, but according to the facts (yes, the truth really is out there if you choose to look) they're within their rights to get their payout. (FWIW, the usual reason for not pursuing a payout - that the other party has a defensive patent portfolio to apply in retaliation - don't apply this time because Eolas changed the field they were working in. It happens.)
Of course, if you're only riled up over this because of the effect it has on your web apps in IE, you should switch to Firefox which isn't adversely affected.:-)
Pilots would be blackmailed into opening cockpit doors at the threat of killing everyone in the cabin.
I really doubt it these days. If I was a pilot and I got that sort of threat, I'd be thinking "everyone in there is dead whether I let those loons in here or not, what with the fact that the plane will be shot down rather than being allowed anywhere near a sensitive target, so I might as well keep myself alive".
I should have noted why I think that Ravioli Code is a bad thing (and hence that those who think it is good style are doing a disservice to their trade). The problem is that it tends to lead to functions (methods, etc.) without true coherence, and it often leaves the code to implement even something fairly simple scattered over a very large number of functions. Anyone having to maintain the code has to understand how all the calls between all the bits work, recreating almost all the badness of Spaghetti Code except with function calls instead of GOTO. It is far better to ensure that each function has a strong consistent description (e.g. "this function frobnicates the foobar", which you should attach to the function somehow - in C, by a comment because there's no stronger metadata scheme) rather than splitting it up into smaller pieces ("stage 1 of preparing to frobnicate the foo part of the foobar", etc.) with less coherence. The principal reason why this is better is precisely that it makes the code easier overall to understand.
This is not to argue against splitting functions where necessary; sometimes you need to split things in odd ways with tricky internal coherence to make other parts of the code much neater, and sometimes it improves separation of concerns (a good thing!) But splitting stuff into ultra-short functions for its own sake is missing the point, and those who do it are making big headaches for the maintainers of that code. I say this from a position of authority; I've had to maintain applications I wrote several years after believing them obsolete and setting them aside (yes, with a total hiatus in-between) and I know for sure that understanding the code is the biggest challenge of all for maintenance. People who deliberately split code up into ravioli, and especially those who advocate that others do so, are "dangerous idiots" precisely because they've lost sight of the fundamental need for comprehensibility and are encouraging others to also stray from The True Path.
Writing good code takes good taste, and any basic technique should be applied judiciously. It's the higher-level things (comprehensibility, separation of concerns, consistency) that are the true goals of the Good Programmer.
[Ye gods! This message is preachy. Serves me right for posting really late...]
Breaking all of those [5 or 6 line segments of functions] into independent functions leaves you with hundreds of 5 or 6 line functions, which is even harder to understand how they interact.
This is the essence of Ravioli Code. Some people claim that it is good style. Some people are dangerous idiots.
Slashdot Mirror
FYI, it's entirely up to the ISP (or whoever is running the particular newsserver) which groups to carry. It always was. A lot of them block binaries groups, usually on the grounds that they're more trouble than they're worth. (If you've got a binary you want to distribute, put it on an FTP server or a website; those protocols are much better designed for bulk data transfer.)
As an aside, I really doubt that skin colour is going to be expressible as a simple enumeration or integer, so you won't be able to switch on it...
The major incentive for the members of a BSD community to share are that if they don't, they run the real risk of the rest of the community making incompatible changes that make the keeping of the the non-sharer's local changes up to date into a support nightmare. In other words they really strongly encourage openness and sharing. They just don't feel that it is right to use the license to enforce the policy; they prefer social/community enforcement.
The more interesting cases are whether there are people in either the wider open software community or the non-open (and non-free) community who will be either attracted in or repelled (in the case of the non-open folks, repelled from either free or open licensed software) by the GPL update. I suspect that v3 probably won't bring many new people into the free community in itself - most of those who get excited over licensing have already nailed their colours to the mast - to get substantially more devs in the v3 space will require the creation of one or more new "must develop with" codebases using the new license.
[Declaration: I develop BSD software. I do so because it suits me philosophically, and because I like the community I'm part of. I know people are building commercial products on my code. I don't mind, since I know they're having to put lots of their own effort in to make it worthwhile; they've earned their crust.]
Heh. I've done that in the past. I'd got a machine into a state where I couldn't access any real devices - all I had was a ramdisk preloaded with not very much more than the core of DOS - and needed an executable in a particular location so that I could get the system to the point where I could boot a Linux install disk (I don't want to remember more details, other than the fact that this was in 1992 or 1993). It turns out that it is easier to write a COM file by hand than an EXE, but it's still possible...
Not that designing easy production tools is easy though, oh no...
I think it's a shame though; the old tagging system added a good bit of fun to the site, and the "joke" tags were sometimes very appropriate indeed. The new system is just boring crap that reproduces what is already in there from the article categories or a simple search of the part of the story on the front page; a search engine could do those tags, or even plain old grep, and so they add nothing of value. The old system was better because it provided a snapshot of what people thought about the story, despite being much more open to abuse.
Bring back the open tags! Please!
But how do I know that they won't? OK, I believe that they won't, since the stink that it would raise would be quite amazingly bad for their cause, but have they given an enduring commitment that they will never remove things like license exemptions for libgcc? If they haven't, the business perspective is that there's something of a hostage to fortune there. (Now if there was such a commitment given somewhere and I've not seen it, I apologize for FUD-slinging. But my google-fu wasn't strong tonight.)
The BSD license does not ensure that you never get (broad-sense) "paid". If it did, I would never have received credit for those things that I've written under the BSDL, and yet I most certainly have been compensated in kind by a great many people. QED. Given that, your paragraph above is at best hyperbole, and the first clause of the conclusion you draw is probably unsound; the price paid isn't high by any objective measure. On the other hand, it might just be that your threshold is ultra-low, so I can't dispute whether the price is too big for you or not (the second clause of your conclusion). But I would point out that if you ever get fed up of the GPL crew, most groups that use the BSDL will welcome you.
But will sharing reputation systems help sites? I think so, eventually, but not for many years yet. Until the reputation clusters have been found, sharing is as likely to introduce needless pollution of reputation systems as it is to enable reputations to be built up quickly. (Could there be a single reputation cluster? Maybe, but I suspect not; people are too inclined to divide the world into "us" and "them" for it to work out.)
One thing that might come out of reputation research is that it might become possible to use the reputation clusters to predict, from someone's interests and interactions, which sorts of sites they'd like to visit. OK, that does sound backwards, but it should guide people to where they won't want to make a total fool of themselves on a regular basis (yes, even the griefing pranksters; after all, when amongst the fools the foolish are sages and the wise foolish.) It may also eventually be possible to join the reputation clusters up, but using negative links (so reputations on sites for followers of Xenu who believe in ID and the supremacy of feng shui of placement of feeding bowls for their chihuahua will negatively reinforce reputations here) but I doubt that will help any time soon. There's a revolution waiting to happen here, but since it really involves lots of people, it'll take time to brew.
On the other hand, it is sensible to start working out what technological steps are required to enable specific bipartite reputation sharing, as well as looking at how to build sane single-site reputation systems. For example, slashdot's is pretty good in that it isn't easy to totally game the system while being mostly self-regulating, but can it be bettered without input of data from outside sites? If it can't be greatly improved, how difficult will it be to export the system to other sites? (It's late: I'm sure you can think of other aspects, but I can't right now.)
Would anyone grant such a step ahead of the current normal state of the art now under modern "obviousness" rules? I hope not; the system was seriously screwed at the time. On the other hand, would you, if you were a small inventor that offered a tech to Microsoft but had it turned down only to then have the 800-lb gorilla then use it in a flagship product, want MS to get away with it? (If you answer "yes" to that one, I have to ask whether you like throwing chairs and chanting "developers"...) I know it's fashionable among a certain clique to hate Eolas, but according to the facts (yes, the truth really is out there if you choose to look) they're within their rights to get their payout. (FWIW, the usual reason for not pursuing a payout - that the other party has a defensive patent portfolio to apply in retaliation - don't apply this time because Eolas changed the field they were working in. It happens.)
Of course, if you're only riled up over this because of the effect it has on your web apps in IE, you should switch to Firefox which isn't adversely affected.
I should have noted why I think that Ravioli Code is a bad thing (and hence that those who think it is good style are doing a disservice to their trade). The problem is that it tends to lead to functions (methods, etc.) without true coherence, and it often leaves the code to implement even something fairly simple scattered over a very large number of functions. Anyone having to maintain the code has to understand how all the calls between all the bits work, recreating almost all the badness of Spaghetti Code except with function calls instead of GOTO. It is far better to ensure that each function has a strong consistent description (e.g. "this function frobnicates the foobar", which you should attach to the function somehow - in C, by a comment because there's no stronger metadata scheme) rather than splitting it up into smaller pieces ("stage 1 of preparing to frobnicate the foo part of the foobar", etc.) with less coherence. The principal reason why this is better is precisely that it makes the code easier overall to understand.
This is not to argue against splitting functions where necessary; sometimes you need to split things in odd ways with tricky internal coherence to make other parts of the code much neater, and sometimes it improves separation of concerns (a good thing!) But splitting stuff into ultra-short functions for its own sake is missing the point, and those who do it are making big headaches for the maintainers of that code. I say this from a position of authority; I've had to maintain applications I wrote several years after believing them obsolete and setting them aside (yes, with a total hiatus in-between) and I know for sure that understanding the code is the biggest challenge of all for maintenance. People who deliberately split code up into ravioli, and especially those who advocate that others do so, are "dangerous idiots" precisely because they've lost sight of the fundamental need for comprehensibility and are encouraging others to also stray from The True Path.
Writing good code takes good taste, and any basic technique should be applied judiciously. It's the higher-level things (comprehensibility, separation of concerns, consistency) that are the true goals of the Good Programmer.
[Ye gods! This message is preachy. Serves me right for posting really late...]