Sounds good. I don't see any major problems with that design. You should suggest it (or submit a patch) to the Pidgin guys - maybe they'll implement it.
Sorry, no. If it breaks, you can keep both pieces. If you want more from me than that then I'll be happy to quote you my hourly rate. Especially if you just downloaded some software that I openly shared on my website.
Yea, and the earth can't be round because then the people in Australia would fall off.
Did it occur to you that free software activists might have considered that issue? Did you go to any effort to find out what their responses to it might be?
You know its funny that you say that because I often think that people don't realize how close Open Source is to communism.
It's no more communism than the academic model of publishing research is communism. The economic game that is open source software is like a version of prisoner's dilemma when cooperation obviously dominates betrayal.
That's exactly the sort of compromise that sounds like a great solution but results in weird bug reports in practice. ("All I can see is the input box - I can't see the conversation at all. What's wrong?" "Apparently you resized your input box and are stuck in manual-size mode. Delete your config directory to get back normal behavior.")
And everyone I've talked to thinks the new behavior is great and much easier to use than futzing with trying to resize panes. Sizeable panes / frames have always been an annoying UI element, and getting rid of them is frequently the right choice.
Then the only options that get into the project are A.) options that everyone agrees on and B.) options that were worth forking over. Sounds good to me.
Every option means doubling the number of possible configurations - which makes proper testing of the application twice as hard. It also provides twice as many weird ways that the developers can have their apps configured that will prevent them from noticing issues as they personally develop.
There are some applications and configuration options where this isn't true - for example, a text editor for programmers would be less useful if you couldn't configure how many spaces are in a tab - but for simple end-user facing applications like Pidgin and the mechanism for resizing the text input box making a choice arbitrarily (or optimizing for UI simplicity) among the usable possibilities is probably the correct design decision.
There is always going to be a vocal minority who really wants to be able to configure every last little thing about their software. For free software, they can simply be pointed to the source code and told to have fun. As a usability compromise, features like Mozilla's "about:config" are good - as long as the user is told that weird configurations won't be supported. But in this particular case the best solution really seems to be for the Pidgin guys to just tell the forkers to "have fun" and then proceed to ignore them because the feature they're offering is silly and pointless.
And then some cat lover comes along, deletes "cats vs dogs as pets" as a "POV fork" of the Dogs article, and then alters Dogs to say "dogs are crappy pets compared to cats".
Firefox is barely hanging on with 10-12% web browser marketshare, and it's avalible on all computers past and present, including those with windows. Apple hovers between 3-7%. I'm reasonably sure that linux is less than 1% of the desktop market.
I'm not sure where you got your numbers, but my psychic powers (which are unquestionably accurate) told me that NetBSD has 60% of the desktop market and OS/2 has 35%... so your numbers must be wrong.
Of course, with truly open source drivers users have to go through the extra hassle of *compiling* the driver prior to installation.
Huh?
The last time I had to manually compile a driver for Linux was in like 2002, and that was because I had decided to compile a custom kernel (for no good reason).
A driver being open source has *absolutely* no negative impact on the end user experience.
20 bucks is non-trivial if you're shipping a hundred thousand machines that retail at $300 each.
But the real thing here is simply flexibility. Dell isn't going to stop selling Windows any time soon. Lenovo hasn't even started selling Linux. But having the option to push Linux on any product line at any time is huge for these vendors.
The biggest cost is the installation and configuration of the OS.
That's... false. Getting disk images onto hard drives is a solved problem, and making the disk image is a one time thing.
Are you a time traveler from like 6 years ago or something?
The industry norm today is to provide open drivers and/or open specs. There are no types of common hardware components for which there isn't already a player on the market who is doing that - anyone who is screwing around with new proprietary Linux drivers in 2008 has missed the bus and is basically just wasting their resources for no good reason.
The time for screwing around with closed drivers is over. There are a few holdovers: Nvidia and Broadcom are the only ones that matter. It will probably make sense to sell Nvidia cards for another six months while the RadeonHD drivers mature. Aside from that, companies that fail to release open source drivers and/or open specs are simply at a competitive disadvantage - and this article indicates that that disadvantage includes selling components to major vendors right now.
OpenPGP software allows you to easily self-generate valid keys. Doing the same with S/MIME (self-signing certificates) is really obnoxious. Further, OpenPGP clients tend to support a web-of-trust introduction model which is strictly better for actual security than the centralized commercial PKI model that S/MIME software tries to force on users.
For sending secure messages within a medium to large sized organization there is some argument for S/MIME using a local CA, but even then simply emulating the same effect with a organization PGP key signer and key server is probably cleaner.
Most people haven't even evaluated anything other than the latest version of what they were using last year.
You could come to some interesting conclusions if you looked at the choice of people who had evaluated the various options - but neither of us have any useful data on that.
The comparison of proprietary software (at least software with a strong network effect like MS Windows and MS Office) to addictive drugs is actually pretty accurate. People who use proprietary software think it's necessary, refuse to admit they have a problem, and try to push the stuff on other people. The vendors love to give out free samples so they can charge a ton of money once the victims are hooked.
I'm absolutely not claiming that the harmful effects of these products on individual users are similar, but the similarities in business model and user reaction to criticism are worthy of comment.
Conceptually, the strategy of having a vocal "mainstream media" that labels anyone outside of a narrow political range as a "crazy extremist" can be even more powerful as an indoctrination tool than an "iron curtain". In the USSR, everyone knew that the news was all government propaganda. In the USA today, most people believe in the "free press".
you're treating closed source licensing as a trump card rather than as a factor.
If you have clear visibility into your app's future
Seeing into the future is *really hard*. Given a choice between a proprietary platform with potential future licensing woes and a high quality free platform, selecting the free platform simply due to licensing is a good first approximation at the right choice.
Intel doesn't fabricate quad-core chips. The quad core processors that they sell are multi-chip modules (MCM) - two dual core chips stuck together in the same package. This is why AMD keeps going on about how their processors are "true quad core".
From an engineering perspective, Intel's approach is both more and less elegant than AMD's approach. Intel saved a bunch of design time, came to market earlier, and wastes less silicon when they have fabrication errors. AMD's processor cores can communicate more quickly, but for various reasons this doesn't mean they do better on real-world benchmarks.
In conclusion, Intel's not going to be releasing 3 core processors any time soon because they don't have a fabrication setup that tends to produce chips with 3 working cores the way AMD does.
Since I'm not a Linux zealot, I just care that it does what I want it to do.
Not caring about licensing questions probably means that you've failed to consider them in depth. That probably seems like a very reasonable choice - if you wanted to worry about legal issues you would have gone to law school - but it's also very short sighted.
"Freedom" seems abstract and irrelevant until you find out that the elegant technical solution you want to implement is disallowed by the license of some component you're using. This rarely happens immediately, because you wouldn't have picked a tool if it didn't let you do what you initially wanted, but it comes up pretty frequently when you try to do something that you didn't initially consider.
Examples:
- You design your application using Oracle as the database. $20,000 a server seems fine - until you realize that the whole design would be more elegant if you moved a bunch of logic into the database and replicated it a bunch of times (say... at each client site). But $20,000 * 100 sites isn't in the budget, so you're forced to scrap the best technical solution for legal reasons.
- You design a data entry interface in Flash. The project expands, and it turns out that it'd be more effective if the users used tablets rather than PCs to do their data entry. So you bring on a hardware team, and they tell you that ARM tablets cost 1/3rd what x86 tablets would cost. Sadly, there's no flash player on ARM - and with your budget it would have been a simple port, too.
Far from being irrelevant and abstract, the issue of licensing is directly relevant to anyone selecting software to build anything important (software or any business process). Proprietary licensing means usage constraints - both explicit constraints like the limited set of Flash platforms and economic constraints like the per-server Oracle license fee. Developing on proprietary stuff is like working in a mine field - sometimes you have to do it, but it's sure as hell something you want to avoid.
Slashdot Mirror
Sounds good. I don't see any major problems with that design. You should suggest it (or submit a patch) to the Pidgin guys - maybe they'll implement it.
Sorry, no. If it breaks, you can keep both pieces. If you want more from me than that then I'll be happy to quote you my hourly rate. Especially if you just downloaded some software that I openly shared on my website.
Never, ever, ever. Not even a little bit.
Yea, and the earth can't be round because then the people in Australia would fall off.
Did it occur to you that free software activists might have considered that issue? Did you go to any effort to find out what their responses to it might be?
It's no more communism than the academic model of publishing research is communism. The economic game that is open source software is like a version of prisoner's dilemma when cooperation obviously dominates betrayal.
That's exactly the sort of compromise that sounds like a great solution but results in weird bug reports in practice. ("All I can see is the input box - I can't see the conversation at all. What's wrong?" "Apparently you resized your input box and are stuck in manual-size mode. Delete your config directory to get back normal behavior.")
And everyone I've talked to thinks the new behavior is great and much easier to use than futzing with trying to resize panes. Sizeable panes / frames have always been an annoying UI element, and getting rid of them is frequently the right choice.
Then the only options that get into the project are A.) options that everyone agrees on and B.) options that were worth forking over. Sounds good to me.
Options suck.
Every option means doubling the number of possible configurations - which makes proper testing of the application twice as hard. It also provides twice as many weird ways that the developers can have their apps configured that will prevent them from noticing issues as they personally develop.
There are some applications and configuration options where this isn't true - for example, a text editor for programmers would be less useful if you couldn't configure how many spaces are in a tab - but for simple end-user facing applications like Pidgin and the mechanism for resizing the text input box making a choice arbitrarily (or optimizing for UI simplicity) among the usable possibilities is probably the correct design decision.
There is always going to be a vocal minority who really wants to be able to configure every last little thing about their software. For free software, they can simply be pointed to the source code and told to have fun. As a usability compromise, features like Mozilla's "about:config" are good - as long as the user is told that weird configurations won't be supported. But in this particular case the best solution really seems to be for the Pidgin guys to just tell the forkers to "have fun" and then proceed to ignore them because the feature they're offering is silly and pointless.
And then some cat lover comes along, deletes "cats vs dogs as pets" as a "POV fork" of the Dogs article, and then alters Dogs to say "dogs are crappy pets compared to cats".
Somehow I don't see SAS RAID cards as being in quite the same league of "common hardware" as graphics or wireless cards are.
I'm not sure where you got your numbers, but my psychic powers (which are unquestionably accurate) told me that NetBSD has 60% of the desktop market and OS/2 has 35%... so your numbers must be wrong.
Huh?
The last time I had to manually compile a driver for Linux was in like 2002, and that was because I had decided to compile a custom kernel (for no good reason).
A driver being open source has *absolutely* no negative impact on the end user experience.
20 bucks is non-trivial if you're shipping a hundred thousand machines that retail at $300 each.
But the real thing here is simply flexibility. Dell isn't going to stop selling Windows any time soon. Lenovo hasn't even started selling Linux. But having the option to push Linux on any product line at any time is huge for these vendors.
That's... false. Getting disk images onto hard drives is a solved problem, and making the disk image is a one time thing.
Are you a time traveler from like 6 years ago or something?
The industry norm today is to provide open drivers and/or open specs. There are no types of common hardware components for which there isn't already a player on the market who is doing that - anyone who is screwing around with new proprietary Linux drivers in 2008 has missed the bus and is basically just wasting their resources for no good reason.
The time for screwing around with closed drivers is over. There are a few holdovers: Nvidia and Broadcom are the only ones that matter. It will probably make sense to sell Nvidia cards for another six months while the RadeonHD drivers mature. Aside from that, companies that fail to release open source drivers and/or open specs are simply at a competitive disadvantage - and this article indicates that that disadvantage includes selling components to major vendors right now.
Good job. Now
So... if your actions have any effect at all, it will be to delay the development of software that effectively uses SSDs.
OpenPGP software allows you to easily self-generate valid keys. Doing the same with S/MIME (self-signing certificates) is really obnoxious. Further, OpenPGP clients tend to support a web-of-trust introduction model which is strictly better for actual security than the centralized commercial PKI model that S/MIME software tries to force on users.
For sending secure messages within a medium to large sized organization there is some argument for S/MIME using a local CA, but even then simply emulating the same effect with a organization PGP key signer and key server is probably cleaner.
Most people haven't even evaluated anything other than the latest version of what they were using last year.
You could come to some interesting conclusions if you looked at the choice of people who had evaluated the various options - but neither of us have any useful data on that.
The comparison of proprietary software (at least software with a strong network effect like MS Windows and MS Office) to addictive drugs is actually pretty accurate. People who use proprietary software think it's necessary, refuse to admit they have a problem, and try to push the stuff on other people. The vendors love to give out free samples so they can charge a ton of money once the victims are hooked.
I'm absolutely not claiming that the harmful effects of these products on individual users are similar, but the similarities in business model and user reaction to criticism are worthy of comment.
Surely you wouldn't rather than some poor kid in Africa had no medicine relative to a couple pounds of Heroin?
And the title itself has an even stronger bias in the other direction (the Slashdot editor "ethical thought is stupid" bias).
Conceptually, the strategy of having a vocal "mainstream media" that labels anyone outside of a narrow political range as a "crazy extremist" can be even more powerful as an indoctrination tool than an "iron curtain". In the USSR, everyone knew that the news was all government propaganda. In the USA today, most people believe in the "free press".
Seeing into the future is *really hard*. Given a choice between a proprietary platform with potential future licensing woes and a high quality free platform, selecting the free platform simply due to licensing is a good first approximation at the right choice.
Intel doesn't fabricate quad-core chips. The quad core processors that they sell are multi-chip modules (MCM) - two dual core chips stuck together in the same package. This is why AMD keeps going on about how their processors are "true quad core".
From an engineering perspective, Intel's approach is both more and less elegant than AMD's approach. Intel saved a bunch of design time, came to market earlier, and wastes less silicon when they have fabrication errors. AMD's processor cores can communicate more quickly, but for various reasons this doesn't mean they do better on real-world benchmarks.
In conclusion, Intel's not going to be releasing 3 core processors any time soon because they don't have a fabrication setup that tends to produce chips with 3 working cores the way AMD does.
Not caring about licensing questions probably means that you've failed to consider them in depth. That probably seems like a very reasonable choice - if you wanted to worry about legal issues you would have gone to law school - but it's also very short sighted.
"Freedom" seems abstract and irrelevant until you find out that the elegant technical solution you want to implement is disallowed by the license of some component you're using. This rarely happens immediately, because you wouldn't have picked a tool if it didn't let you do what you initially wanted, but it comes up pretty frequently when you try to do something that you didn't initially consider.
Examples:
- You design your application using Oracle as the database. $20,000 a server seems fine - until you realize that the whole design would be more elegant if you moved a bunch of logic into the database and replicated it a bunch of times (say... at each client site). But $20,000 * 100 sites isn't in the budget, so you're forced to scrap the best technical solution for legal reasons.
- You design a data entry interface in Flash. The project expands, and it turns out that it'd be more effective if the users used tablets rather than PCs to do their data entry. So you bring on a hardware team, and they tell you that ARM tablets cost 1/3rd what x86 tablets would cost. Sadly, there's no flash player on ARM - and with your budget it would have been a simple port, too.
Far from being irrelevant and abstract, the issue of licensing is directly relevant to anyone selecting software to build anything important (software or any business process). Proprietary licensing means usage constraints - both explicit constraints like the limited set of Flash platforms and economic constraints like the per-server Oracle license fee. Developing on proprietary stuff is like working in a mine field - sometimes you have to do it, but it's sure as hell something you want to avoid.