I was initially disturbed by the fact that GTK and Qt don't use Xresources, until I really started using them. These days I avoid dealing with resource files like the plague.
The resource files were good for developers, but for end-users, I think they're a mistake. They're too complicated to understand and modify. In my experience, every Motif program had a slightly different search algorithm for its resource files, which was a major hassle. Then you had to understand the bizarre syntax, as you've already conceded.
The bottom line is, GUI programs should provide GUI interfaces to customize themselves. How that info is stored is irrelevant to most people.
Tom's hatred of the Caps-Lock is a result of his vi zealotry. In vi, forgetting to unlock your caps can be fairly deadly. This is just one of the reasons why I became an emacs zealot.
And don't get me started on Sun's keyboards. Perhaps switching the caps-lock and control was a good idea, but it sure sucked having to switch back and forth. And why can't they decide whether Escape belongs in the base setup or next to the never-used function keys? Worse still, please put the backslash and pipe key combination below the backspace! It's not too fun accidentally pressing enter when you meant for a pipe!
Seriously, Tom makes a good point about software/hardware that is neophyte-friendly at the expense of being expert friendly. I tend to prefer the software that's primarily expert-friendly, but allows experts to make it neophyte friendly (emacs is a great example, I might add).
I allow him the poetic license to use some exaggerated analogies, but this was a bit too long...
I disagree. GNU autoconf, automake and libtool are excellent tools. It supports an incredible number of different systems and allows programmers to add their own checks and configuration options quite easily.
Yes configure generated from autoconf is great, but only for someone compiling the program! I'm talking about commercial binary apps here. If some smart company decides to implement InstallMaster for Linux they could make some serious bucks! But they'll probably never be able to fully support all the different distros.
Why are people arguing as if this is seriously encouraging programmers to behave like this? None of the items are things programmers gain any efficiency from.
Seriously, how many programmers have had to deal with some lame-ass coding standards designed by a committee that obviously hadn't done any real coding in years? My personal favorite is to avoid the use of any and all loop jumps, like break or continue. How is it easier to read 8 levels of nesting, with all sorts of redundant comparisons and operations, when the whole thing could be fixed with a simple return? This is the type of thing that kills big projects. Ever had a code review, where nobody has time to look at the actual content and purpose of the code, so they just start rigorously enforcing these arbitrary coding conventions? Inevitably, the code gets completely rewritten for a bug fix (with no code review) and the standards go out the window.
A lot of people have commented about changing requirements causing redesigns. My complaint is that too many people (managers) refuse to see beyond the current requirements. Sometimes, you just know that the customer is going to want something eventually, so you want to spend a little extra time up-front preparing for it. But unfortunately you get forced in to doing things the quickest way, and then it's too expensive to add the features that would really be useful.
It sucks, but usually you need to be first to win the market. But if you look at most products that were first to market, they sell well for a while, but eventually the competitors overtake them. It's usually because they didn't plan ahead in the original implementation, and are now left with unmaintainable code that needs to be completely rewritten. There are too many examples to cite..
The article was very well written and insiteful but didn't convince me that forking isn't really a threat. It also minimized the impact on productivity that forking has caused.
Today, the different Linux distros can cause a headache for people dealing with product installation issues, usually with scripts. This isn't so bad because most UNIX people are already used to that. But it does scare off software companies. Think about it, for Windows, you just buy InstallShield or Wise and most of the problems of OS differences are taken care of. Not true for Linux today.
It gets worse at the API level. If the Linux kernel forks and the APIs contain minor annoying incompatibilities, it will be just as bad as the UNIX days of old.
I'm a strong advocate of Linux mainly because it is Open Source. I feel the advantage of this is huge, but mainly for developers. Developers need to be able to trust that the APIs they are using a) work as advertised, b) can be fixed quickly when they don't and c) aren't subject to the whims of a particular profit driven organization. Open Source, and in particular GPL'ed code guarantees those things. Nothing else does.
These benefits aren't immediately visible to the consumers (ie. the non-programmers who just use a computer to get something done). But the benefits do trickle down, when the code they use can be made more reliable and can safely incorporate innovations. The time spent reinventing the wheel for minor variations of operating systems could be spent doing useful innovations.
Realistically, freeware will never replace commercial applications, and I don't want it to. What I want to see is new products with genuinely new features, and I'm willing to pay for them, with or without source. Those new products will come a lot faster if there is a common API to work with. There will always be competing versions of products, but at some point there will be features we come to expect of all of them, and the advantages to the different versions of the products become trivial. At that point, it makes more sense to standardize on a freeware version, and forget all the others. I believe at this point in time, there are not enough technical advantages to the competing operating systems to warrant their existence. It is a detriment to everyone's productivity. Therefore, it's time for an Open Source OS to move to the forefront, and Linux is the closest of any to doing that.
Right now there is one major fork in the Linux world, and that's GNOME vs. KDE. This is particularly nasty, because there really is no way to develop software that supports both. (I mean totally supports both, not just using some common subset of features) This is a long-term threat to the viability of the OS for commercial development. Let's get real, they both are trying to accomplish mostly the same goals: a common look and feel for graphical applications. As long as they both fight for mindshare, that won't happen! I really hope at some point in time, one or the other surrenders, and concentrates their efforts on taking the useful innovations they have and putting them into the other, so we can all get on with things.
If you really want Linux to replace Windows, stop arguing over petty differences and work together to build an OS that truly offers all the advantages that Windows currently offers.
There is a fundamental difference between jumping on the NT bandwagon and jumping on the Linux bandwagon: a steering wheel! With MS you have no control, no influence, you're just a pawn in the developer control game. With Linux you're part of the solution.
After re-reading my comments, I'm embarassed by how bad they actually sound. I don't want to advocate dropping any alternative development of any kind. I do feel that a lot of time is wasted bickering over petty differences between projects. I feel that Linux stands the best chance of actually improving the lives of software developers and users, mostly because of the hype. So, I feel my effort is best spent there. I'm sure others will disagree, but I feel that at this point and time there's an opportunity to cement OpenSource software in the mainstream, and we could blow it by squabbles like this.
OK, although I think that there's always merit in discussion and debate, I think we all need to take a breath and look at what the situation is here. The industry needs commonality, because we don't all have time to learn the nuances of 5 subtly different platforms. The successful vendors have been the ones to get others to follow their bandwagon, or jump on the strongest one and somehow influence it.
Although the BSD systems have many strengths and the cross-pollination that occurs is useful, keep in mind that BSD is partially responsible for the splintering of UN*X that has ultimately lead to the dominance of other platforms. At one time even Microsoft acknowledged the superiority of UNIX (remember XENIX?). No matter how good BSD is the most successful platform will be the one with the buzz, and without question Linux has got the buzz now.
Developing software is too time-consuming to repeat n times for n platforms. Instead of arguing the merits of one platform vs. another, we should all be arguing over how best to provide a common platform for software development, that allows for multiple implementations to exist transparently. Users are gaining a common user interface with efforts like GNOME and KDE, but programmers need more commonality at the API to develop these applications.
It seems to me that it's time to consider merging BSD with Linux. This would lead to even more rapid development of Linux and more of that mythical buzz. It's time for the non-UNIX to become the ONE UNIX.
Slashdot Mirror
I was initially disturbed by the fact that GTK and Qt don't use Xresources, until I really started using them. These days I avoid dealing with resource files like the plague.
The resource files were good for developers, but for end-users, I think they're a mistake. They're too complicated to understand and modify. In my experience, every Motif program had a slightly different search algorithm for its resource files, which was a major hassle. Then you had to understand the bizarre syntax, as you've already conceded.
The bottom line is, GUI programs should provide GUI interfaces to customize themselves. How that info is stored is irrelevant to most people.
Tom's hatred of the Caps-Lock is a result of his vi zealotry. In vi, forgetting to unlock your caps can be fairly deadly. This is just one of the reasons why I became an emacs zealot.
And don't get me started on Sun's keyboards. Perhaps switching the caps-lock and control was a good idea, but it sure sucked having to switch back and forth. And why can't they decide whether Escape belongs in the base setup or next to the never-used function keys? Worse still, please put the backslash and pipe key combination below the backspace! It's not too fun accidentally pressing enter when you meant for a pipe!
Seriously, Tom makes a good point about software/hardware that is neophyte-friendly at the expense of being expert friendly. I tend to prefer the software that's primarily expert-friendly, but allows experts to make it neophyte friendly (emacs is a great example, I might add).
I allow him the poetic license to use some exaggerated analogies, but this was a bit too long...
Yes configure generated from autoconf is great, but only for someone compiling the program! I'm talking about commercial binary apps here. If some smart company decides to implement InstallMaster for Linux they could make some serious bucks! But they'll probably never be able to fully support all the different distros.
Seriously, how many programmers have had to deal with some lame-ass coding standards designed by a committee that obviously hadn't done any real coding in years? My personal favorite is to avoid the use of any and all loop jumps, like break or continue. How is it easier to read 8 levels of nesting, with all sorts of redundant comparisons and operations, when the whole thing could be fixed with a simple return? This is the type of thing that kills big projects. Ever had a code review, where nobody has time to look at the actual content and purpose of the code, so they just start rigorously enforcing these arbitrary coding conventions? Inevitably, the code gets completely rewritten for a bug fix (with no code review) and the standards go out the window.
A lot of people have commented about changing requirements causing redesigns. My complaint is that too many people (managers) refuse to see beyond the current requirements. Sometimes, you just know that the customer is going to want something eventually, so you want to spend a little extra time up-front preparing for it. But unfortunately you get forced in to doing things the quickest way, and then it's too expensive to add the features that would really be useful.
It sucks, but usually you need to be first to win the market. But if you look at most products that were first to market, they sell well for a while, but eventually the competitors overtake them. It's usually because they didn't plan ahead in the original implementation, and are now left with unmaintainable code that needs to be completely rewritten. There are too many examples to cite..
The article was very well written and insiteful but didn't convince me that forking isn't really a threat. It also minimized the impact on productivity that forking has caused.
Today, the different Linux distros can cause a headache for people dealing with product installation issues, usually with scripts. This isn't so bad because most UNIX people are already used to that. But it does scare off software companies. Think about it, for Windows, you just buy InstallShield or Wise and most of the problems of OS differences are taken care of. Not true for Linux today.
It gets worse at the API level. If the Linux kernel forks and the APIs contain minor annoying incompatibilities, it will be just as bad as the UNIX days of old.
I'm a strong advocate of Linux mainly because it is Open Source. I feel the advantage of this is huge, but mainly for developers. Developers need to be able to trust that the APIs they are using a) work as advertised, b) can be fixed quickly when they don't and c) aren't subject to the whims of a particular profit driven organization. Open Source, and in particular GPL'ed code guarantees those things. Nothing else does.
These benefits aren't immediately visible to the consumers (ie. the non-programmers who just use a computer to get something done). But the benefits do trickle down, when the code they use can be made more reliable and can safely incorporate innovations. The time spent reinventing the wheel for minor variations of operating systems could be spent doing useful innovations.
Realistically, freeware will never replace commercial applications, and I don't want it to. What I want to see is new products with genuinely new features, and I'm willing to pay for them, with or without source. Those new products will come a lot faster if there is a common API to work with. There will always be competing versions of products, but at some point there will be features we come to expect of all of them, and the advantages to the different versions of the products become trivial. At that point, it makes more sense to standardize on a freeware version, and forget all the others. I believe at this point in time, there are not enough technical advantages to the competing operating systems to warrant their existence. It is a detriment to everyone's productivity. Therefore, it's time for an Open Source OS to move to the forefront, and Linux is the closest of any to doing that.
Right now there is one major fork in the Linux world, and that's GNOME vs. KDE. This is particularly nasty, because there really is no way to develop software that supports both. (I mean totally supports both, not just using some common subset of features) This is a long-term threat to the viability of the OS for commercial development. Let's get real, they both are trying to accomplish mostly the same goals: a common look and feel for graphical applications. As long as they both fight for mindshare, that won't happen! I really hope at some point in time, one or the other surrenders, and concentrates their efforts on taking the useful innovations they have and putting them into the other, so we can all get on with things.
If you really want Linux to replace Windows, stop arguing over petty differences and work together to build an OS that truly offers all the advantages that Windows currently offers.
There is a fundamental difference between jumping on the NT bandwagon and jumping on the Linux bandwagon: a steering wheel! With MS you have no control, no influence, you're just a pawn in the developer control game. With Linux you're part of the solution.
After re-reading my comments, I'm embarassed by how bad they actually sound. I don't want to advocate dropping any alternative development of any kind. I do feel that a lot of time is wasted bickering over petty differences between projects. I feel that Linux stands the best chance of actually improving the lives of software developers and users, mostly because of the hype. So, I feel my effort is best spent there. I'm sure others will disagree, but I feel that at this point and time there's an opportunity to cement OpenSource software in the mainstream, and we could blow it by squabbles like this.
OK, although I think that there's always merit in discussion and debate, I think we all need to take a breath and look at what the situation is here. The industry needs commonality, because we don't all have time to learn the nuances of 5 subtly different platforms. The successful vendors have been the ones to get others to follow their bandwagon, or jump on the strongest one and somehow influence it.
Although the BSD systems have many strengths and the cross-pollination that occurs is useful, keep in mind that BSD is partially responsible for the splintering of UN*X that has ultimately lead to the dominance of other platforms. At one time even Microsoft acknowledged the superiority of UNIX (remember XENIX?). No matter how good BSD is the most successful platform will be the one with the buzz, and without question Linux has got the buzz now.
Developing software is too time-consuming to repeat n times for n platforms. Instead of arguing the merits of one platform vs. another, we should all be arguing over how best to provide a common platform for software development, that allows for multiple implementations to exist transparently. Users are gaining a common user interface with efforts like GNOME and KDE, but programmers need more commonality at the API to develop these applications.
It seems to me that it's time to consider merging BSD with Linux. This would lead to even more rapid development of Linux and more of that mythical buzz. It's time for the non-UNIX to become the ONE UNIX.