You apparently didn't even read the message that I was responding to. It wasn't about the EFF; it was about the next lawsuits we'll read about:
I was wondering if someone will do a cartoon about the lawsuit. And then get sued. Ands then counter-sue. And then someone else does a cartoon about that lawsuit. And they get sued...
Not at all unlikely. And one effect of this sort of thing is to put money into the lawyers' pockets.
I'd agree that the EFF are the good guys here.
What I really want to know is when the JibJab guys will put the rest of their oevre online. I saw a few of their other efforts before their server was flooded, and they have a lot of funny stuff. I hope this really helps their reputation and they can profit from it. Of course, for parodists and satirists, this sort of publicity is often the best thing that can happen to them.
We should probably also note the nice irony that the original version of "This Land is Your Land" was a strongly anti-private-property song, and we now have people trying to block a parody that Woodie Guthrie would have loved by claiming that the song is their own private property.
Of course, several of Woodie's original verses are very rarely heard these days, as people try hard to pervert it into a feel-good patriotic dittie. This is aided by the propensity of most people to learn only the first and sometimes second verses of songs.
Now we will segue into another long thread on the meaning of the term "irony"...
Don't you mean "should not be doing QA on their own code.".... ?
In actual practice, he got it right by forgetting the "not".;-)
I usually present the QA folks with lots of test code. This makes them my friends, since they are usually under pressure to get the product out the door and don't have time to think up all the tests themselves. I don't either, of course, and I can't ever give them something complete. And I have the usual developer's problem of not being permitted any contact with actual users, so I can't guess at their misconceptions when they try using the software without having read any of the documentation that I also included.
Quite often, I get a bit of flak from management for being too friendly with the QA people. They usually have this silly "clean-room" concept for how it should be done. And the tests should test all possible paths. Yeah, as if they have the millenia that that would take on the fastest cpus...
One serious problem is that the QA testers always have to modify my tests for their test setup. I have my own collection of (mostly perl and tcl) testing tools, but of course that's totally different that what the QA people are using. And there isn't time for us to teach each other to use all the tools.
It's all a long way from an ideal setup. But that's The Market for you.
Older geeks will remember all the stories back in the 70's about people who paid big bucks for some fantastic new feature in IBM's cpus, and watched the IBM guy come over and "install" it by clipping a jumper wire or two on a board.
We're probably going to be hearing a lot more of those stories in the future as a result of this development. Except that the IBM guy won't have to actually come over and clip anything. They'll be able to do it across the Net by asking you to download an Install program, which will execute the commands to burn out the appropriate piece of the cpu chip, which turned out to send a "disable" signal to the circuitry that you just paid for.
And, of course, among the many classifications you'll find in the many classification systems over the years have been classes such as "unrestricted", "public", and "press release".
One of the standard political propaganda tools has been to publicly charge someone with release of classified documents without mentioning that the classification was one of these classes.
I've seen documents classified as "time sensitive" as a way of warning that they would lose their value if they weren't sent to the recipients (press, government agency, etc.) within a short time.
Saying something is "classified" without stating the classification is either very sloppy or intentionally misleading.
We can assume that either their opinion cannot be expressed by the ballot or that they don't care enough about it to do anything with it.
It's fairly easy to come up with other possibilities.
"My boys will be watching the polling places; if they see you anywhere near one, you'll be very sorry." Voter intimidation happens all over the place.
Some people are "on call" as part of their job; a work emergency could well take precedence in their mind, especially if the election's outcome is a foregone conclusion.
They could have voted, but the votes were "lost". If you watched recent American votes closely, you may have noticed several cases where groups of ballots, sometimes tens of thousands of them, were "discovered" misplaced somewhere some time after the election. The voting officials are very apologetic, of course. We don't know how many cases of this weren't discovered. This could explain the apparent low voter turnout.
And a vote-related possibility: It's a common belief that if you vote for X and X wins, you are at least partly responsible for X's actions in office. A voter might refuse to vote simply because they don't want to be blamed for the outcome. If you vote for the lesser evil and that one wins, you could find yourself full of remorse for the evil that you voted for. If you don't vote, then you can say "Don't blame me; I didn't vote for the turkey."
There are many reasons someone might decide not to vote.
Actually, I've always sorta liked the idea (used in some places) that non-votes are counted, and to win, a candidate must win a majority of the registered voters' votes, not just a majority of the actual votes. Then a non-vote truly is a vote to block all the candidates from winning. This could make parties a lot more responsive to voters' desires. I'm not aware that this has ever been done in the US, though.
If this had been used in the 2000 elections, neither Bush nor Gore would have become president, and they'd have had to do the elections over again until one party came up with a candidate that 50% of the adult population was willing to vote for.
Also, if you look closely at COBOL, you'll quickly see that it is only superficially English-like. It uses English words as keywords, but those words usually have a very different meaning than the English words.
One of the conventional example is "OR", which in English (as in most human languages) is normally exclusive-or, while in Cobol (as in most programming languages) it's inclusive-or.
Another instructive example is "IF", which in COBOL is an imperative verb, not a conjunction. As in most programming language, it means to perform an action (evaluate an expression and branch depending on the true/false value). This is a subtlety, but it's one of a long list of ways that COBOL isn't English at all. It just uses keywords spelled the same as vaguely-related English words.
This is significant, because of the problem of reading the code as if it were English. This leads to all sorts of mistaken interpretations of the code. Reading COBOL requires constant awareness that it is not English.
When you don't vote you're written off as apathetic or ignorant.
Yeah, but note that it's not the non-voter who's doing the writing off. It's the people who insist on wilfully misinterpreting the meaning of a non-vote.
If someone hasn't told you their opinion, you have no right whatsoever to claim that they believe some specific thing.
This is illogic that's just as bad as the election winner by 50.5% of the 23% who voted, who then claims a "mandate from the voters" for any and all of his/her campaign policies.
Of course, such illogic is the norm in most politics.
If you must assume an opinion of someone who hasn't voted, the only reasonable thing to assume is "none of the above". But even that's not very good logic. The correct conclusion is that you don't know their opinion.
... and eventually we'll learn that, like the Tablet PC, it was for sale running linux in Asia a year before it came to market in the US. But it won't be sold with linux in the US, because that was a requirement for the license to sell it with Windows in the US. Americans will have to pay the MS tax and install linux themselves if that's what they want.
Anyone know how it's being sold in Asia? I wouldn't be surprised to hear that it's available there with a number of different OSs, for different markets. You can probably get it with iTron, too, but not in the US.
Re: "Free as in speech, not free as in beer."
on
Making Open Source Pay
·
· Score: 2, Insightful
Quite possibly the best quote I've ever read on/.
Heh; I'll be happy to take credit for it. Actually, I've seen very similar comments from other people. But feel free to spread the meme:
Trusting software vendors is no smarter than trusting auto dealers.
And you can easily follow this with the explanation that open-source software means that you don't have to trust the software vendor. You can (hire people to) take a look at the source, fix bugs, and add features. And, most importantly, you (or your people) can look for things that shouldn't be in there, and remove them.
Re: "Free as in speech, not free as in beer."
on
Making Open Source Pay
·
· Score: 4, Insightful
Yeah, but that doesn't usually have much impact on your typical business manager. If you try to sell them something, and start talking about free speech and/or free beer, they'll just think you're bizarre. What does that have to with running a business?
A better simile, I've found, is to compare their computers to a delivery fleet. It's fairly obvious to even a PHB that a fleet of vehicles needs maintenance. And, while they might not want to get their hands dirty working on the innards of their vehicles, they know enough to hire mechanics for that. And those mechanics need the shop manuals for all the vehicles.
Tell them that "closed source" software is a lot like a vehicle without a shop manual. If something goes wrong with such a vehicle, all you can do is report it back to the auto company that you bought the vehicle from. They'll fix it when they get around to it. Or maybe they won't bother fixing it, figuring that they can get you to buy a new vehicle if they drag it out long enough or say it's not repairable.
Similarly, you tell them, things are going to go wrong inside their computers. You need "shop manuals" for all your software. With software, that's called "source code". If your computer support group doesn't have the source code, then they'll be stuck with just reporting problems back to the software vendor. And that vendor will be just about as interested in fixing your problems as the truck manufacturerer is interested in keeping your fleet running. More likely they'll try to sell you more (New! Improved!) software.
But if your people have the source code (for software) or shop manuals (for vehicles), they can dig in, figure out what's wrong, and fix it.
Yeah, studying the source isn't easy. But have you ever leafed through a shop manual? There are people who can understand those things. And, as with mechanics, the software people have friends and colleagues that share information about problems. With software, this is mostly done via the Internet, and you really want your IT people to know how to use it to find information.
Most managerial types are smart enough to understand all this. We just have to get across to them that trusting software vendors is no smarter than trusting auto dealers. You need your own people to do the job, your people need the information required to do the job, and they also need to communicate with their cohorts in other organizations to find information fast when something's failing. But without the source code, there's often nothing your people can do, and you're stuck with begging the dealer for help.
Hey, that's wonderful! Totally useless to most of the world, of course. But I'll bet you get lots of praise from the small crowd that's interested in the history of Central America.
One suggestion: In the News list, you should include the long-count date along with the Gregorian date. Maybe both in Arabic numbers and in glyphs. Putting the glyphs in stela form to the left of the news would be very cool.
Several years ago, I added a gimmick to my personal web site that simply converts Arabic numbers to Mayan numbers. No need to link to it, I suppose; anyone interested probably knows where it is. I like to describe it as "my entry in the ongoing competition for most useless web page".
I think I'll add your link to my page.... There; it's done.
I wonder if anyone has yet put up a page that does such conversions for a long list of number and calendar systems? If so, I'm not guessing the right keywords to feed google. There is a site that does Roman-system conversion, a Hebrew-to-Gregorian date converter, and a Chinese-to-Gregorian converter. I don't seem to see any site that does more than one.
There's a conceptually similar site out there, which takes measurements in any of a long list of units and converts them to any of the other units. One of my favorite is the conversion between fluid ounces and cubic attoparsecs. These differ only in the third decimal place, of course, which is one of the more amusing coincidences in the insanity of measurement systems.
It's hard to imagine corporate support for any of these things.
Why is it that every successful Open Source project, that is also targeted to the End-User market (and not the server/developer market) is backed directly by a company with money to spare?
This isn't quite true; there are a number of significant open-source projects that have no corporate backing.
One very successful such effort that I've been involved in can be found by googling for "ABC music notation". Only musicians would find this useful, but it's a good counter-example here. All the prime movers are musicians who happen to be programmers. There are a few commercial music packages that can now input (and sometimes output) ABC notation. But this doesn't include monetary support. There are a number of excellent end-user open-source tools for this notation, and none of them has any corporate support that I am aware of. There are also some closed-source "shareware" tools, and they all seem to have come from one person using their own resources.
This isn't surprising. Commercial music interests tend to be rather narrow, catering to only Western Pop or Western Classical styles. They aim for complex, click-and-point GUI packages that try to do everything for a very narrow range of music. They usually run on only one platform, usually Windows. The ABC gang consists of a motley collection of musician-programmers that are involved in musical styles that you've probably never heard of. And they've developed software that runs on all the common computer platforms with more compatibility than you'd ever expect from a gaggle of musicians. (Talk about herding cats...)
I expect that others involved with the 80,000+ SourceForge projects will chime in with more open-source end-user projects that don't have corporate support.
Of course, such support is usually welcome. It's just not always forthcoming, until after a package develops a user population and looks like it might have marketing possibilities.
(The ABC crowd is generally wary of corporate attention. As musicians, they have good historical grounds for this. Some here might have read about the growing use of copyright to limit musical innovation.;-)
." There's a BIG difference between "nobody" and "hardly anybody".
Heh; yeah, and it's often the difference between proprietary and open source.
I've also contributed code to a number of open-source projects. And in many cases, my work was triggered by reading a complaint from a user. I'd have the response "Hey, that's bothered me, too, and it looks like I'm not the only one. I wonder how hard it would be to fix?..."
Then, usually far too many hours later, I announce that I've got a patch that fixes the problem, and people should try it out. Or if it's simple enough, I just send in the patch in, it gets included in the next alpha/beta release, and I can reply to the original users complain saying that there's a fix in the archive for them to try.
With closed software, I couldn't have done this. If the code maintainers aren't following the same lists and groups as I am, they probably never notice the complaints. Or they are under pressure from their management to implement only the changes requested by Sales.
It isn't important that everyone hack the source code. What's important is that open source allows a significantly-larger crowd of programmers to hack the code. And it usually turns out that those programmers are users of the code themselves. This often makes them more responsive to user complaints than commercial developers, who usually only answer to their superiors (and are often intentionally kept out of direct contact with users).
And if the code's maintainers aren't responsive enough, open source allows you to do a fork. I've been involved in this, too. With closed source, it's only possible with permission of the original group. With open source, you sometimes (though rarely) get a fork that's more useful than the original. Or, more often, it's useful to a set of users that wouldn't have ever become users of the original.
"Say someone comes to you and asks you a question today, and they find you annoying," says Bent. "Maybe the next time, they'll ask someone else. Soon people stop coming to you and asking you things, and you end up without a job."
My experience has been the opposite. In several jobs, I've become known as the guru who listened sympathetically and actually answered questions. The result? I got written up in my reviews as spending too much time helping others with their tasks, to the detriment of my own. In most companies, this is not a good thing to have on your record.
And, in my experience, people who are good at "help desk" tasks are never the ones who are well paid or promoted. They're stuck in a dead-end help-desk job until they wise up and find a better job elsewhere.
Actually, Jedi programming tricks aren't even necessary. I've worked on any number of projects where I've included a lot of debug hooks. These are generally written in a way that including them is optional, because many of them slow the code down noticeably. No secret process here; it's something that lots of programmers do as a matter of course.
The in-house products can then end up smaller and faster than a 3rd-party program simply because the commercial link libraries have a lot of these debug hooks enabled, while the vendor's apps are linked to libraries with fewer of the debug hooks compiled in.
There is a long-standing debate about the wisdom of stripping out such hooks. The best metaphor I've seen is the question: If you're working on becoming a licensed pilot, would you wear your parachute in ground school and then take it off when you go into the air? Of course not.
Similarly, the argument goes, when you deliver your new apps to paying customers and something goes wrong, that's when you really need those debug hooks. Then you can tell them "Just type this command and run it again, and tell me what it says....?
But marketing never understands this. They always demand that the delivered products have "all that debug junk" stripped out so the apps are smaller and faster. They don't care much about the speed of the delivered link libraries, since that affects only customers' software and not their own. So the delivered libraries can have the debug junk left in, at least as much as you reasonably think the customers' programmers can use.
The result of this is that the vendors software runs faster than exactly the same code would if compiled and linked at a customer site. And it isn't even because of some nefarious plot to hurt independent software developers; it's because your own management doesn't understand why you might want to deliver software that a few percent larger and slower than it needs to be.
Myself, I like to downplay the fact of these debug hooks, so that management won't order it stripped out in deliverables. I've too often found myself trying to help some hapless customer, and found that the "v[erbose]" setting is nonfunctional. "It doesn't work, and it doesn't tell me what's wrong." Not a nice situation to be in when you put that stuff in there for exactly the situation that you're facing and you're on the spot to help a customer get it working.
Why won't it work for Microsoft? Because someone on Slashdot arbitrarily said so?
Nah; it's mostly because, with some justification, many people will fear that access to MS source is dangerous. Once you've seen the source to any of MS's products, you are forever after in danger of being sued for stealing the code and incorporating it into something else. This is what the SCO fiasco is all about, and you'd have to be fairly naive to not suspect that this is part of what MS is planning.
Now, if they would let us developers look at the source without signing anything that makes us forever beholden to them, it might be different. But as far as I can tell, you do have to sign something. And that signature effectively gives them he right to raid your computers (or those of any future employers) any time they like and examine everything for signs of theft of MS source.
This isn't just because of some paranoia of mine. I've looked at the source to several vendors' source in the past, including IBM and Sun, and I wasn't particularly worried about either of them using this to take over my life. But in those cases, the code was offered to me by (representatives of) the company, and I didn't have to sign away any rights. It was done for the simple expedient of making it clear to me as a developer just what was going on inside the vendor's software, so I could make my apps work.
This sort of problem has happened with unix vendors in the past. I worked on several projects at Digital where there were discussions of why DEC never sold a commercial Sys/V-based system, although they had it running in-house. The general explanation was that DEC's lawyers kept warning that the AT&T license for Sys/V could possibly give AT&T either ownership of any software that used the AT&T libraries, or at least gave AT&T the right to demand access to everything you had to verify that you weren't stealing any AT&T IP. AT&T never convinced the lawyers that this wasn't a rational worry, and Sys/V lost out pretty badly in a lot of places as a result.
Much of the success of the BSD branch came from the elimination of requirements to sign away legal rights before seeing the code. BSD code was available to students and developers without a contract, so it was fairly safe to look at it while developing your own code.
Microsoft has a history of some rather heavy-handed tactics against developers of apps that run on DOS and Windows. Netscape is just the most notorious case. And MS's support of SCO is another that provides good grounds to worry.
If you value your professional life or future income, you'd be a fool to sign anything like the contracts that MS uses to control access to their "shared source".
Re:Have to be careful here with music tastes
on
IT's Musical Habits
·
· Score: 2, Insightful
, yet would a hip-hop fan sit down and listen to an album of Hank Williams Sr.? Or Patsy Cline?
Well, by some chance, I happen to know that my wife's current collection of CDs in her car for the drives to/from work include Eminem and Patsy Cline. No Hank Williams Sr or Jr at the moment, but they are in the collection.
She has mentioned humming some of Eminem's songs (which often do have real melodies, unlike most rap) at meetings, and enjoying the grins of the few people who recognize them. This is in a medical IT environment, FWIW.
[A]ll the gurus I know don't restrict themselves to one kind of music.
Hmmm... I must be some sort of guru then.;-)
My main reaction to this is that they completely ignored the possibility that people might have a mix of really different stuff.
Next to my linux workstation there's a Mac PowerBook. I checked the "Recently Played" list and found:
Grateful Dead "Playing in the Band" Andy Statman "Midnight Zhok" Ad Vielle Que Pourra "Micro-Polka", "Valse Minette" Vienna Teng "Green Island Serenade" Peter Hedlund "Iste Kornbodsmarsch" Phillipe Bruneau "Valse-Clog des Pyrénées" Linda Ronstadt "Long, Long Time" Cowboy Junkies (several songs) Beatles (White Album) Chieftains/Sting "Long Black Veil" Dorothée Hogan "Marche de Mont-St-Louis" Silly Wizard (Live Wizardry) Café Accordion Orchestra "Surullinen Tango"...
I wonder how many of us just don't fit into any musical pigeonhole?
But I suppose "IT people show few consistent patterns in musical taste" wouldn't make for much of a story.
Slashdot Mirror
You apparently didn't even read the message that I was responding to. It wasn't about the EFF; it was about the next lawsuits we'll read about:
I was wondering if someone will do a cartoon about the lawsuit. And then get sued. Ands then counter-sue. And then someone else does a cartoon about that lawsuit. And they get sued...
Not at all unlikely. And one effect of this sort of thing is to put money into the lawyers' pockets.
I'd agree that the EFF are the good guys here.
What I really want to know is when the JibJab guys will put the rest of their oevre online. I saw a few of their other efforts before their server was flooded, and they have a lot of funny stuff. I hope this really helps their reputation and they can profit from it. Of course, for parodists and satirists, this sort of publicity is often the best thing that can happen to them.
Yeah, this could be a real money maker for the lawyers.
...
Even if the JibJab guys win, I wonder what percent of the settlement will end up in their pockets
This song is our song,
It is not your song.
You did not write it,
and we can sing it.
My daddy wrote it,
He gave it to us all to sing.
This song was made for you and me.
We should probably also note the nice irony that the original version of "This Land is Your Land" was a strongly anti-private-property song, and we now have people trying to block a parody that Woodie Guthrie would have loved by claiming that the song is their own private property.
...
Of course, several of Woodie's original verses are very rarely heard these days, as people try hard to pervert it into a feel-good patriotic dittie. This is aided by the propensity of most people to learn only the first and sometimes second verses of songs.
Now we will segue into another long thread on the meaning of the term "irony"
Don't you mean "should not be doing QA on their own code.".... ?
;-)
...
In actual practice, he got it right by forgetting the "not".
I usually present the QA folks with lots of test code. This makes them my friends, since they are usually under pressure to get the product out the door and don't have time to think up all the tests themselves. I don't either, of course, and I can't ever give them something complete. And I have the usual developer's problem of not being permitted any contact with actual users, so I can't guess at their misconceptions when they try using the software without having read any of the documentation that I also included.
Quite often, I get a bit of flak from management for being too friendly with the QA people. They usually have this silly "clean-room" concept for how it should be done. And the tests should test all possible paths. Yeah, as if they have the millenia that that would take on the fastest cpus
One serious problem is that the QA testers always have to modify my tests for their test setup. I have my own collection of (mostly perl and tcl) testing tools, but of course that's totally different that what the QA people are using. And there isn't time for us to teach each other to use all the tools.
It's all a long way from an ideal setup. But that's The Market for you.
Older geeks will remember all the stories back in the 70's about people who paid big bucks for some fantastic new feature in IBM's cpus, and watched the IBM guy come over and "install" it by clipping a jumper wire or two on a board.
We're probably going to be hearing a lot more of those stories in the future as a result of this development. Except that the IBM guy won't have to actually come over and clip anything. They'll be able to do it across the Net by asking you to download an Install program, which will execute the commands to burn out the appropriate piece of the cpu chip, which turned out to send a "disable" signal to the circuitry that you just paid for.
What I want to know is: Do I lose my geek creds if the one I got wrong was thinking that a legit letter was a fraud?
(I automatically checked "fraud" for any that had a link to verify the info.)
And, of course, among the many classifications you'll find in the many classification systems over the years have been classes such as "unrestricted", "public", and "press release".
One of the standard political propaganda tools has been to publicly charge someone with release of classified documents without mentioning that the classification was one of these classes.
I've seen documents classified as "time sensitive" as a way of warning that they would lose their value if they weren't sent to the recipients (press, government agency, etc.) within a short time.
Saying something is "classified" without stating the classification is either very sloppy or intentionally misleading.
We can assume that either their opinion cannot be expressed by the ballot or that they don't care enough about it to do anything with it.
It's fairly easy to come up with other possibilities.
"My boys will be watching the polling places; if they see you anywhere near one, you'll be very sorry." Voter intimidation happens all over the place.
Some people are "on call" as part of their job; a work emergency could well take precedence in their mind, especially if the election's outcome is a foregone conclusion.
They could have voted, but the votes were "lost". If you watched recent American votes closely, you may have noticed several cases where groups of ballots, sometimes tens of thousands of them, were "discovered" misplaced somewhere some time after the election. The voting officials are very apologetic, of course. We don't know how many cases of this weren't discovered. This could explain the apparent low voter turnout.
And a vote-related possibility: It's a common belief that if you vote for X and X wins, you are at least partly responsible for X's actions in office. A voter might refuse to vote simply because they don't want to be blamed for the outcome. If you vote for the lesser evil and that one wins, you could find yourself full of remorse for the evil that you voted for. If you don't vote, then you can say "Don't blame me; I didn't vote for the turkey."
There are many reasons someone might decide not to vote.
Actually, I've always sorta liked the idea (used in some places) that non-votes are counted, and to win, a candidate must win a majority of the registered voters' votes, not just a majority of the actual votes. Then a non-vote truly is a vote to block all the candidates from winning. This could make parties a lot more responsive to voters' desires. I'm not aware that this has ever been done in the US, though.
If this had been used in the 2000 elections, neither Bush nor Gore would have become president, and they'd have had to do the elections over again until one party came up with a candidate that 50% of the adult population was willing to vote for.
Also, if you look closely at COBOL, you'll quickly see that it is only superficially English-like. It uses English words as keywords, but those words usually have a very different meaning than the English words.
One of the conventional example is "OR", which in English (as in most human languages) is normally exclusive-or, while in Cobol (as in most programming languages) it's inclusive-or.
Another instructive example is "IF", which in COBOL is an imperative verb, not a conjunction. As in most programming language, it means to perform an action (evaluate an expression and branch depending on the true/false value). This is a subtlety, but it's one of a long list of ways that COBOL isn't English at all. It just uses keywords spelled the same as vaguely-related English words.
This is significant, because of the problem of reading the code as if it were English. This leads to all sorts of mistaken interpretations of the code. Reading COBOL requires constant awareness that it is not English.
... militaristic, plutocratic Yale graduate.
;-)
You should add "member of Skull and Bones" to both lists.
When you don't vote you're written off as apathetic or ignorant.
Yeah, but note that it's not the non-voter who's doing the writing off. It's the people who insist on wilfully misinterpreting the meaning of a non-vote.
If someone hasn't told you their opinion, you have no right whatsoever to claim that they believe some specific thing.
This is illogic that's just as bad as the election winner by 50.5% of the 23% who voted, who then claims a "mandate from the voters" for any and all of his/her campaign policies.
Of course, such illogic is the norm in most politics.
If you must assume an opinion of someone who hasn't voted, the only reasonable thing to assume is "none of the above". But even that's not very good logic. The correct conclusion is that you don't know their opinion.
... and eventually we'll learn that, like the Tablet PC, it was for sale running linux in Asia a year before it came to market in the US. But it won't be sold with linux in the US, because that was a requirement for the license to sell it with Windows in the US. Americans will have to pay the MS tax and install linux themselves if that's what they want.
Anyone know how it's being sold in Asia? I wouldn't be surprised to hear that it's available there with a number of different OSs, for different markets. You can probably get it with iTron, too, but not in the US.
Quite possibly the best quote I've ever read on /.
Heh; I'll be happy to take credit for it. Actually, I've seen very similar comments from other people. But feel free to spread the meme:
Trusting software vendors is no smarter than trusting auto dealers.
And you can easily follow this with the explanation that open-source software means that you don't have to trust the software vendor. You can (hire people to) take a look at the source, fix bugs, and add features. And, most importantly, you (or your people) can look for things that shouldn't be in there, and remove them.
Yeah, but that doesn't usually have much impact on your typical business manager. If you try to sell them something, and start talking about free speech and/or free beer, they'll just think you're bizarre. What does that have to with running a business?
A better simile, I've found, is to compare their computers to a delivery fleet. It's fairly obvious to even a PHB that a fleet of vehicles needs maintenance. And, while they might not want to get their hands dirty working on the innards of their vehicles, they know enough to hire mechanics for that. And those mechanics need the shop manuals for all the vehicles.
Tell them that "closed source" software is a lot like a vehicle without a shop manual. If something goes wrong with such a vehicle, all you can do is report it back to the auto company that you bought the vehicle from. They'll fix it when they get around to it. Or maybe they won't bother fixing it, figuring that they can get you to buy a new vehicle if they drag it out long enough or say it's not repairable.
Similarly, you tell them, things are going to go wrong inside their computers. You need "shop manuals" for all your software. With software, that's called "source code". If your computer support group doesn't have the source code, then they'll be stuck with just reporting problems back to the software vendor. And that vendor will be just about as interested in fixing your problems as the truck manufacturerer is interested in keeping your fleet running. More likely they'll try to sell you more (New! Improved!) software.
But if your people have the source code (for software) or shop manuals (for vehicles), they can dig in, figure out what's wrong, and fix it.
Yeah, studying the source isn't easy. But have you ever leafed through a shop manual? There are people who can understand those things. And, as with mechanics, the software people have friends and colleagues that share information about problems. With software, this is mostly done via the Internet, and you really want your IT people to know how to use it to find information.
Most managerial types are smart enough to understand all this. We just have to get across to them that trusting software vendors is no smarter than trusting auto dealers. You need your own people to do the job, your people need the information required to do the job, and they also need to communicate with their cohorts in other organizations to find information fast when something's failing. But without the source code, there's often nothing your people can do, and you're stuck with begging the dealer for help.
My particular itch has nothing to do with programming.
... There; it's done.
Hey, that's wonderful! Totally useless to most of the world, of course. But I'll bet you get lots of praise from the small crowd that's interested in the history of Central America.
One suggestion: In the News list, you should include the long-count date along with the Gregorian date. Maybe both in Arabic numbers and in glyphs. Putting the glyphs in stela form to the left of the news would be very cool.
Several years ago, I added a gimmick to my personal web site that simply converts Arabic numbers to Mayan numbers. No need to link to it, I suppose; anyone interested probably knows where it is. I like to describe it as "my entry in the ongoing competition for most useless web page".
I think I'll add your link to my page.
I wonder if anyone has yet put up a page that does such conversions for a long list of number and calendar systems? If so, I'm not guessing the right keywords to feed google. There is a site that does Roman-system conversion, a Hebrew-to-Gregorian date converter, and a Chinese-to-Gregorian converter. I don't seem to see any site that does more than one.
There's a conceptually similar site out there, which takes measurements in any of a long list of units and converts them to any of the other units. One of my favorite is the conversion between fluid ounces and cubic attoparsecs. These differ only in the third decimal place, of course, which is one of the more amusing coincidences in the insanity of measurement systems.
It's hard to imagine corporate support for any of these things.
Why is it that every successful Open Source project, that is also targeted to the End-User market (and not the server/developer market) is backed directly by a company with money to spare?
...)
;-)
This isn't quite true; there are a number of significant open-source projects that have no corporate backing.
One very successful such effort that I've been involved in can be found by googling for "ABC music notation". Only musicians would find this useful, but it's a good counter-example here. All the prime movers are musicians who happen to be programmers. There are a few commercial music packages that can now input (and sometimes output) ABC notation. But this doesn't include monetary support. There are a number of excellent end-user open-source tools for this notation, and none of them has any corporate support that I am aware of. There are also some closed-source "shareware" tools, and they all seem to have come from one person using their own resources.
This isn't surprising. Commercial music interests tend to be rather narrow, catering to only Western Pop or Western Classical styles. They aim for complex, click-and-point GUI packages that try to do everything for a very narrow range of music. They usually run on only one platform, usually Windows. The ABC gang consists of a motley collection of musician-programmers that are involved in musical styles that you've probably never heard of. And they've developed software that runs on all the common computer platforms with more compatibility than you'd ever expect from a gaggle of musicians. (Talk about herding cats
I expect that others involved with the 80,000+ SourceForge projects will chime in with more open-source end-user projects that don't have corporate support.
Of course, such support is usually welcome. It's just not always forthcoming, until after a package develops a user population and looks like it might have marketing possibilities.
(The ABC crowd is generally wary of corporate attention. As musicians, they have good historical grounds for this. Some here might have read about the growing use of copyright to limit musical innovation.
." There's a BIG difference between "nobody" and "hardly anybody".
..."
Heh; yeah, and it's often the difference between proprietary and open source.
I've also contributed code to a number of open-source projects. And in many cases, my work was triggered by reading a complaint from a user. I'd have the response "Hey, that's bothered me, too, and it looks like I'm not the only one. I wonder how hard it would be to fix?
Then, usually far too many hours later, I announce that I've got a patch that fixes the problem, and people should try it out. Or if it's simple enough, I just send in the patch in, it gets included in the next alpha/beta release, and I can reply to the original users complain saying that there's a fix in the archive for them to try.
With closed software, I couldn't have done this. If the code maintainers aren't following the same lists and groups as I am, they probably never notice the complaints. Or they are under pressure from their management to implement only the changes requested by Sales.
It isn't important that everyone hack the source code. What's important is that open source allows a significantly-larger crowd of programmers to hack the code. And it usually turns out that those programmers are users of the code themselves. This often makes them more responsive to user complaints than commercial developers, who usually only answer to their superiors (and are often intentionally kept out of direct contact with users).
And if the code's maintainers aren't responsive enough, open source allows you to do a fork. I've been involved in this, too. With closed source, it's only possible with permission of the original group. With open source, you sometimes (though rarely) get a fork that's more useful than the original. Or, more often, it's useful to a set of users that wouldn't have ever become users of the original.
Well, I found the oddest part was the paragraph:
"Say someone comes to you and asks you a question today, and they find you annoying," says Bent. "Maybe the next time, they'll ask someone else. Soon people stop coming to you and asking you things, and you end up without a job."
My experience has been the opposite. In several jobs, I've become known as the guru who listened sympathetically and actually answered questions. The result? I got written up in my reviews as spending too much time helping others with their tasks, to the detriment of my own. In most companies, this is not a good thing to have on your record.
And, in my experience, people who are good at "help desk" tasks are never the ones who are well paid or promoted. They're stuck in a dead-end help-desk job until they wise up and find a better job elsewhere.
We can meet over beers
;-)
Hey, man; you're really gonna get trounced by the wine afficionados!
(Typed on my Mac here on my patio in the 'burbs, with a Margarita on the side table.
Actually, Jedi programming tricks aren't even necessary. I've worked on any number of projects where I've included a lot of debug hooks. These are generally written in a way that including them is optional, because many of them slow the code down noticeably. No secret process here; it's something that lots of programmers do as a matter of course.
....?
The in-house products can then end up smaller and faster than a 3rd-party program simply because the commercial link libraries have a lot of these debug hooks enabled, while the vendor's apps are linked to libraries with fewer of the debug hooks compiled in.
There is a long-standing debate about the wisdom of stripping out such hooks. The best metaphor I've seen is the question: If you're working on becoming a licensed pilot, would you wear your parachute in ground school and then take it off when you go into the air? Of course not.
Similarly, the argument goes, when you deliver your new apps to paying customers and something goes wrong, that's when you really need those debug hooks. Then you can tell them "Just type this command and run it again, and tell me what it says
But marketing never understands this. They always demand that the delivered products have "all that debug junk" stripped out so the apps are smaller and faster. They don't care much about the speed of the delivered link libraries, since that affects only customers' software and not their own. So the delivered libraries can have the debug junk left in, at least as much as you reasonably think the customers' programmers can use.
The result of this is that the vendors software runs faster than exactly the same code would if compiled and linked at a customer site. And it isn't even because of some nefarious plot to hurt independent software developers; it's because your own management doesn't understand why you might want to deliver software that a few percent larger and slower than it needs to be.
Myself, I like to downplay the fact of these debug hooks, so that management won't order it stripped out in deliverables. I've too often found myself trying to help some hapless customer, and found that the "v[erbose]" setting is nonfunctional. "It doesn't work, and it doesn't tell me what's wrong." Not a nice situation to be in when you put that stuff in there for exactly the situation that you're facing and you're on the spot to help a customer get it working.
Why won't it work for Microsoft? Because someone on Slashdot arbitrarily said so?
Nah; it's mostly because, with some justification, many people will fear that access to MS source is dangerous. Once you've seen the source to any of MS's products, you are forever after in danger of being sued for stealing the code and incorporating it into something else. This is what the SCO fiasco is all about, and you'd have to be fairly naive to not suspect that this is part of what MS is planning.
Now, if they would let us developers look at the source without signing anything that makes us forever beholden to them, it might be different. But as far as I can tell, you do have to sign something. And that signature effectively gives them he right to raid your computers (or those of any future employers) any time they like and examine everything for signs of theft of MS source.
This isn't just because of some paranoia of mine. I've looked at the source to several vendors' source in the past, including IBM and Sun, and I wasn't particularly worried about either of them using this to take over my life. But in those cases, the code was offered to me by (representatives of) the company, and I didn't have to sign away any rights. It was done for the simple expedient of making it clear to me as a developer just what was going on inside the vendor's software, so I could make my apps work.
This sort of problem has happened with unix vendors in the past. I worked on several projects at Digital where there were discussions of why DEC never sold a commercial Sys/V-based system, although they had it running in-house. The general explanation was that DEC's lawyers kept warning that the AT&T license for Sys/V could possibly give AT&T either ownership of any software that used the AT&T libraries, or at least gave AT&T the right to demand access to everything you had to verify that you weren't stealing any AT&T IP. AT&T never convinced the lawyers that this wasn't a rational worry, and Sys/V lost out pretty badly in a lot of places as a result.
Much of the success of the BSD branch came from the elimination of requirements to sign away legal rights before seeing the code. BSD code was available to students and developers without a contract, so it was fairly safe to look at it while developing your own code.
Microsoft has a history of some rather heavy-handed tactics against developers of apps that run on DOS and Windows. Netscape is just the most notorious case. And MS's support of SCO is another that provides good grounds to worry.
If you value your professional life or future income, you'd be a fool to sign anything like the contracts that MS uses to control access to their "shared source".
, yet would a hip-hop fan sit down and listen to an album of Hank Williams Sr.? Or Patsy Cline?
Well, by some chance, I happen to know that my wife's current collection of CDs in her car for the drives to/from work include Eminem and Patsy Cline. No Hank Williams Sr or Jr at the moment, but they are in the collection.
She has mentioned humming some of Eminem's songs (which often do have real melodies, unlike most rap) at meetings, and enjoying the grins of the few people who recognize them. This is in a medical IT environment, FWIW.
Does it count if trad Irish music interferes with work because you keep picking up whatever instrument is handy and playing along?
[A]ll the gurus I know don't restrict themselves to one kind of music.
... I must be some sort of guru then. ;-)
...
Hmmm
My main reaction to this is that they completely ignored the possibility that people might have a mix of really different stuff.
Next to my linux workstation there's a Mac PowerBook. I checked the "Recently Played" list and found:
Grateful Dead "Playing in the Band"
Andy Statman "Midnight Zhok"
Ad Vielle Que Pourra "Micro-Polka", "Valse Minette"
Vienna Teng "Green Island Serenade"
Peter Hedlund "Iste Kornbodsmarsch"
Phillipe Bruneau "Valse-Clog des Pyrénées"
Linda Ronstadt "Long, Long Time"
Cowboy Junkies (several songs)
Beatles (White Album)
Chieftains/Sting "Long Black Veil"
Dorothée Hogan "Marche de Mont-St-Louis"
Silly Wizard (Live Wizardry)
Café Accordion Orchestra "Surullinen Tango"
I wonder how many of us just don't fit into any musical pigeonhole?
But I suppose "IT people show few consistent patterns in musical taste" wouldn't make for much of a story.