[Hampshire] What do you think?
Fellow Lug members, I would welcome comments on the following. The Linux Application Developers Quandary or is it really a Nightmare Linux distributions such as Ubuntu are making great strides in removing the need to do even quite advanced configuration operations via the command line and utilities like ‘vi’ (and even ‘emacs’ for those so inclined). Some would like to banish the bash command terminal to the same prominence the DOS Command window has on Windows Systems. i.e. buried away in All Programs-Accessories along with Windows Explorer, Notepad and Calculator to name but a few. That is all fine and dandy for the majority of key/core applications that are already included in a distributions repository. In the case of someone starting out to develop a new application that needs both a daemon that uses one or more configuration files and an application controller(to edit the configuration files) do they:- 1) Develop a command line only controller for V1.00 2) Develop a GUI only controller for V1.00 3) Both of the above 4) Non of the above and rely on users being able to use vi/emacs etc With application complexity increasing and the number of configurable parameters or even command line switches and options the task facing anyone who wants to develop a viable front-end for the application is considerable and forever increasing. Consider the following two cases. Properties files, manual edits and CVS Properties files (or as the used to be called ‘ini files’) are in my opinion are real PITA. That said, they are a million times better than the Windows Registry. As everything in Linux/Unix is a file and the majority of these files are plain text there is a great temptation to edit them manually especially if you are remotely logged into the system over a slow connection and using the GUI is not practicable. Once you have done that there is a danger that the changes you make will not be picked up by the GUI application. This particularly applies to comments. Nice and helpful as they are, how many GUI’s distributed in a standard Linux Distro today can handle comments. It is good practice to comment any changes so that the next person who comes along to fix the problem you edit has just caused can know who did what, when & why to the file. Yep, the version history strikes back. How many GUI’s give you the opportunity to add a new bit oh version history to the file? Not many I’d be willing to guess. Then comes CVS (or something similar). We all know that it is good practice to use CVS/SVN/git or some commercial package to store those ultra critical files in so that when your system goes down in a heap of flames (it does happen) you can pull everything out of your Source Control System and deploy it on the new system knowing that it is the latest version. Some of these systems add comments into the file showing the checkin date/time & user. This is great for auditing purposes but we are back to the problem, how does the GUI handle comments. Again, the answer is not very well. Command line option applicability With some applications that have a plethora of command line options the is often some which will not work together or worse still, are ignored completely if they are placed after another option of the command line. How is the GUI Developer going to easily, reliably code up the rules for the GUI so that the application has a better then 50/50 chance of doing what the user wants when if gets kicked off? Estimating the number of test cases to ensure that the test coverage could be a daunting operation and without a decent tool to actually do the manual application of GUI operation it could be almost impossible. Note, I have not even considered the coding of the GUI at this stage. Just writing down the rules will probably show up actual inconsistencies in the documentation (assuming there is something more than a ‘man’ page) and how the application actually works. Adding an AI rules engine may be the only way to go for some complex applications. One company I work with has done this for one of their applications already so it is not just some crystal ball gazing. The costs of maintaining the GUP have since dropped by more than 50% and from that experience, they are considering doing it for more applications. Note, this is not anything you will find buried in dome Debian repository somewhere and will cost you more money than most LUG users will earn in a year. If we take the two cases outlined above it is not hard to see that many projects have made the decision (either consciously or not) to take the easy way out and not handle comments etc or dynamically edit the options presented on the GUI if they would make the execution of the command fail. Clearly this is not ideal practice and it is going to take a sea change in attitude by developers to achieve this even on a small percentage of key application in Linux but if the goal of doing away wi
Re: [Hampshire] What do you think?
Hi Stephen, On Sun, Jul 19, 2009 at 02:06:13PM +0100, Stephen Davies wrote: > As everything in Linux/Unix is a file and the majority of these files > are plain text there is a great temptation to edit them manually > especially if you are remotely logged into the system over a slow > connection and using the GUI is not practicable. If use of the GUI is not practical then I don't see the point of configuring it remotely, use a different tool altogether. I also don't agree that configuring a GUI application must be done with text files. If the application is a GUI then I think it should be configured with a GUI, preferably part of the same application itself. It might be fine to read a config file to change some of the more esoteric options, but I don't see why the majority of configuration can't be done in the GUI. It seems to work for Firefox, which is the largest GUI application I run. By the way, I tend to prefer non-GUI applications for most things. > Once you have done that there is a danger that the changes you make will > not be picked up by the GUI application. This particularly applies to > comments. Nice and helpful as they are, how many GUI’s distributed in a > standard Linux Distro today can handle comments. I don't know but it seems a trivial problem for the author of the GUI software to overcome. > It is good practice to comment any changes so that the next person who > comes along to fix the problem you edit has just caused can know who did > what, when & why to the file. Yep, the version history strikes back. How > many GUI’s give you the opportunity to add a new bit oh version history > to the file? Not many I’d be willing to guess. The configuration of client software is typically not versioned. Do you need it to be? It's a good question about how to maintain central configuration control for GUI desktop software. > Then comes CVS (or something similar). We all know that it is good > practice to use CVS/SVN/git or some commercial package to store those > ultra critical files in so that when your system goes down in a heap of > flames (it does happen) you can pull everything out of your Source > Control System and deploy it on the new system knowing that it is the > latest version. > Some of these systems add comments into the file showing the checkin > date/time & user. This is great for auditing purposes but we are back to > the problem, how does the GUI handle comments. Again, the answer is not > very well. I'm not aware of any SCCS which adds stuff into the files under control, unless you tell it to. And if your file format supports comments then this again seems trivial. > > Command line option applicability > > With some applications that have a plethora of command line options the > is often some which will not work together or worse still, are ignored > completely if they are placed after another option of the command line. > > How is the GUI Developer going to easily, reliably code up the rules for > the GUI so that the application has a better then 50/50 chance of doing > what the user wants when if gets kicked off? Config files are typically used when command-line configuration becomes too complex. > Estimating the number of test cases to ensure that the test coverage > could be a daunting operation and without a decent tool to actually do > the manual application of GUI operation it could be almost impossible. Testing definitely seems the hardest thing to me. As always. > One company I work with has done this for one of their applications > already so it is not just some crystal ball gazing. The costs of > maintaining the GUP have since dropped by more than 50% and from that > experience, they are considering doing it for more applications. Note, > this is not anything you will find buried in dome Debian repository > somewhere and will cost you more money than most LUG users will earn in > a year. Nice implicit suggestion that expensive closed source software is inherently better than FLOSS! Solaris used to cost a lot of money and Windows still does, but I think Linux is better than both of them. There countless examples of FLOSS that is the best in its class. I don't see the point of your "you won't find this in Debian" comment. > Clearly this is not ideal practice and it is going to take a sea change > in attitude by developers to achieve this even on a small percentage of > key application in Linux but if the goal of doing away with the command > line is to be achieved then I think that this change is essential and > long overdue. I don't really see that the standards of configurability for popular Linux GUI apps is any better or worse than those for Windows. I think this could be improved, but "doing away with the command-line" is not a goal I support and I think is orthogonal to making better GUI apps. GUI apps could be better. On Linux and Windows. > The ideal state would be that the GUI did the followin
Re: [Hampshire] What do you think?
Stephen Davies wrote: > > Conclusions. > > While the ambitions of those who want to relegate the command line to > history are very laudable, there are many cases where it is the only > place to get the job done and done with certainty. > In addition to that, until Linux does not use any shell scripts on > startup/shutdown the command line will be an essential for developers, > sysadmins and even users (at times). I don’t think that reliance upon > scripts will be removed anytime soon after all, we don’t want the mess > that is the Windows Registry re-invented do we? > > > I can't see my day to day job of sysadmin will move to a GUI only option. The reason why M$ have been forced to produce a "power shell" is because sysadmins insisted they need it to maintain both windows and Linux. The power of the command line is it can be scripted easily, quickly and very effectively. GUIs do not have the flexibility to cover all the different needs. Therefore the command line tools like ifconfig, ping, grep, vim, awk, perl, python, sed and others will be with us for a long time! Non sys admins might be able to just use GUIs for normal use, but I doubt they will be able to fault find without the command line in both windows and Linux. John. -- -- Discover Linux - Open Source Solutions to Business and Schools http://discoverlinux.co.uk -- -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
