I wonder if this will be a truly open technology, open source, and give us the ability to actually know what it is doing when it runs. And Windows only? Perhaps that will change, that wouldnt be a friendly policy to ignore users of other OSs. Microsoft isnt the entirity of the computing world.
I hope this app just isnt a commercial marketing type thing but is an open protocol, open source technology.
Yes, I certianly agree. We should try to make Unix-type systems more avialable to everyone and that means some good GUI configuration tools.
The big problem with Linux, BSD, etc, is few are being paid to develop for these platforms, thus we dont have a lot of people who can work full time to improve things. We need to find a way to pay developers of open source projects so they can work full time on these projects. With that I think we would see an increase in quality including lots of nice GUI tools for non-techie users.
I think furthermore techie and non-techie users can both share the same system and techies can have full control and low level access to the system well non-techies can have the easy to use GUIs at the same time. GUI configurators can be made to automatically produce the human readable config files, thus we can have both config files, GUI tools, and a rich command line environment.
As far as Unix itself, I think overall the system is very good and no changes should to the core concepts should be made, the directory layout is good, the basic concepts are good, X WIndows is good. I have heard people say that the X Windows API is prehistoric. Nonsense, its just a low level API and its designers didnt make the mistake of just offering a bunch of high level widgets but created an API providing graphical primitives high level widgets can be created with. X API is designed for widget construction, not for direct use by applications.
Basically what is needed is more full time developers, including for the GUI tools.
I certianly agree, that FireFox gaining popularity is a great thing and especially if its getting people off of IE and proprietary protocols and languages, its a very a good thing. Its also great to hear that people find that it fits thier needs so well.
So I certianly do think that Firefox is a good thing and that its getting so much attention and popularity. Since Mozilla and FireFox share the same engine as well, no matter which you use you should get the same rendering, protocol and language support. I am very impressed by Geckos supports for standards, and hopefully it will be continued to be improved, support for things like SVG, CSS 1-3, HTML, XHTML, SMIL, MNG, PNG, Javascript and W3C DOM standards. These standards are essential and allow users the freedom to choose their browser while being able to still view web pages, and make designers lives easier by not having them support 10 different incompatible browsers.
I dont really understand what FireFox is so much better than Mozilla, and why its such a big deal. How is it an improvement over Mozilla? Ive heard from others it has fewer features and options, and a more dumbed down UI. Dumbed down UI != ease of use. I think the less customisability software has the harder it becomes to use, for newbies and experienced users alike. It becomes more difficult for the user to customise the software for their preferences and usage pattern, and more difficult to accomplish certian tasks. The trick with useability is not to remove customisbility, but rather make software as customisable as possible but simply design a good configuration user interface that places more commonly used options more prominantly than advanced one, such as through placing the more advanced options on advanced options screens or other such techniques, thus keeping the more advanced options from confusing newbies but allowing people to gradually begin using them and discover them (and making it easy to discover them by making them all avialable through a good UI) as they become familiar with software. People often start out using software by using a subset of its features and then gradually add to their knowledge of the software and use a more complete set of its features, and different users have different needs and will use different features sets. This is why software should be as customisable as possible and not try to restrict features and functionality, but rather allow the user to customise the software to their tastes. One feature that seems useless to one person is likely essential to someone else.
I do think that if done properly, making KDE and other applications work on Windows could actually help Free Software, that is, and actually *ease* the transition over to Linux. That is, if its done properly.
Why not instead of spending huge effort to port millions of OSS Unix programs to Windows, just instead compile Unix applications on Windows using Cygwin, and improve Cygwin to be an accurate implementation of Unix source compatability standards? Cygwin could be improved so that nearly all OSS Unix programs could compile on it with few modications. This would save huge effort porting applications. The same goes for Mac OS X, and every other OS.
If porting KDE to Windows APIs requires a lot of extra work, maintainence and effort, then it will hurt free software since it will be a case of re-inventing the wheel, extra work ends up being done making the same software work on Windows proprietary, non standard APIs, this increases the work being done to maintian the same software and takes away resources from making new software or adding new features, instead of going on to design new things people will be tied up re-engineering the same things to run on different OSs. This is how non-standard core OS APIs, like C libraries and kernel interfaces, hinder free software, software reuseability, promote OS lock-in and restrict OS freedom and OS choice, and how standards like POSIX which promote standards which assure source compatability (the ability to compile software on any OS without modification), assures OS choice, since it makes sure that people can take the same software with them to whatever OS they choose with only a recompile.
The solution, to avoid duplication of effort maintaining ports for Windows and other OSs, and allowing software that implements POSIX compatability on Windows and thus allows Unix programs to compile on Windows without modification, thus there is no extra effort needed to port the software to Windows, instead of having to port a gazillion OSS applications to Windows we can just need some POSIX libraries for Windows and all Unix programs will work on Windows without porting. This saves developer effort and prevents OSS developer resources from having to be spent porting existing software to Windows and instead work on new software.
And, Cygwin already exists which is a very good start at creating a POSIX/Unix standards compliant environment on Windows. There is still more work to be done on it, but instead of investing huge resources in porting a gazillion Unix apps to Windows, why not just make sure Cygwin is an accurate implementation of a Unix environment and those gazillion applications will work on Windows with little or no porting? Cygwin is nearly that already, with X windows, most Unix utilities, lots of libraries, but there still are some glitches. One big one that needs to be fixed is the lack of case sensitivity on filenames. This could be fixed simply by creating a hidden file in each directory with a table to map between case sensitive names and the real name used on the underlying filesysem, or on NTFS try to use NTFSs case sensitivity support if possible.
The fact that AOL is using the IE engine is not convincing proof that AOL is supporting open source projects like Mozilla. Mozilla, most of all, is the rendering engine, Gecko, this is the core of Mozilla and one of its most important and central parts. It would be I believe be deceptive to call software "Mozilla" if it doesnt even use the engine developed by the Mozilla project. It would be nothing more than IE masquerading in a Mozilla skin. It seems if AOL was really serious about supporting Mozilla and supporting an alternative to IE that was free of Microsoft licences, they would be supporting work to improve the Mozilla code so it does as good of a job as IE, and using Mozilla in all of their own products and not relying on IE at all. It seems this would be good for AOL since they would not be relying on proprietary software from another company and would be able to see all of the source code.
A feature that seems worthless to one person might be essential to another. Just because something seems to have no use to you does not mean that someone else doesnt have a use for it.
I believe that object oriented programming, in a very large program, makes things much, much eisier, when it is properly done, which is quite easy to do. I believe one reason it tends to make programs more maintainable, more understandable, and easier to get familiarised with, when we instead of creating one big monolithic software program and instead create modules each which has a particular purpose, is it keeps the code in the module smaller, shorter, simpler, and eisier to understand. Good documentation is also important to describe what the module does and its interface. I have done OO programming and done right it makes things simpler, makes less code, keeps the code reuseable, ans breaks up a big program into smaller parts which are eisier to understand.
I believe strong typing should be available in a language, but not forced on programmers since in many cases it just makes things more complex. I have used weak typed languages and it rarely is a problem. Although, I do think types can be useful, and I know Perl 6 will have types avialable if you want to use them.
The issues regarding seperating different areas of program design can be easily addressed at the software level, and have been with object oriented languages, like Java, Perl (my preferred language), C++, among others. It is possible to place program logic in methods in one object and call those from some a seperate UI component. Object oriented environments which provide seperate spaces for the objects are widely avialable and easily done in software. Putting such things in the CPU would certianly not make them any eisier or more likely to be used, and I dont think that the CPU is the right place for an object oriented programming environment:-). The CPU cant easily be changed or reprogrammed if there is a bug which is why we dont build operating systems and complex software programs into them but instead put those things into software levels, which works well.
I have found Perl to be a very useable program language that allows programs to be written in a clear and easy to understand manner. I believe the notion that it encourages obfuscated programming is a myth. I have read some pretty obfuscated and awful code written in C++ and Java , and obfuscation is possible in any somewhat useable programming language. What we need is good programming habits. If we dont use good programming habits and keep readability in mind we can make a mess of things in any language.
Certianly, I believe people should be able to use the language that fits them best and what they are most comfortable with. If you like Java, then It is fine with me if you want to use it. I prefer Perl since that somehow fits my needs and is eisier for me to understand and use, and write good code in. For other people it might be Java. I believe people should use what fits them best.
I have found that Perl allowed me to get to writing good readable maintainable code faster than most other languages.
A programmer if they do not have practice in programming can mess things up in any language. Different people have different needs and different thought patterns, and different languages fit different peoples tastes better. What might be great for one person is not so useable to another. A feature that is essential to one person may have no use for another. Just because one person thinks a feature has no use does not mean the feature does not have merit and should not be there, because there is likely someone who does need it.
I thought that I heard that James Webb telescope is primarily infrared. If so, its not at all the same thing as Hubble, although it has virtues of its own, it doesnt give us the same visible light capabilities as Hubble. I heard Webb does have some visible capability but it doesnt sound like it has as much as Hubble. It has an infrared viewer, which is quite different and will allow us to see through clouds of dust to say the centers of galaxies better, but it may not provide the same quality visible light photographs we are used to with Hubble. It seems like something like Hubble and Webb would compliment each other, since they each photograph different parts of the spectrum better.
I should correct myself, binary interfaces are ussually outside the scope of POSIX and other source compatability standards. Such things can be done via Linux Standards Base or whatever if desired.
There are a few exceptions, such as with X Window Systems and NFS, where of course binary compatability is needed in the protocols, and perhaps file formats like TAR.
Unix OSs can if their is some new feature offered by the OS to the application programmers, and the feature does not yet have an API defined for it, create a new API for the feature. However, as this feature becomes more broadly used across different operating systems, a standard needs to be defined to assure that applications which use the feature can run on different Unix OSs. One such area presently that may need to be addressed for instance is scalable kernel event notification facilities such as Kqueue/Epoll interfaces, each OS seems to have a different API for the same feature.
Furthermore, with POSIX application APIs, their is ussually no need to change what has already been defined, and certianly this should be avoided. Agian the application APIs do not dictate the underlying kernel design. Ussually only the binary interfaces may have an significant impact on kernel design, and these interfaces can be changed without disrupting source compatability. Ussually what we see with Unix standards is new capability being added beyond what is already there.
The binary interfaces and things like low level filesystem design are smartly out of the scope of Unix standards.
Unix specifications have evolved to meet the needs of modern operating systems, they are not antique as you imply, but as improvements and innovations have occured in OS features, these things have been included into the API. For instance POSIX threads. Also, I do not consider Unix API to be a legacy API, it has a pretty clean design and the model is in fact followed to quite an extant by Linux and most OSs. POSIX defined a lot of very basic things like standard C functions and libraries, and command line utilties, with the aim of assuring source compatability. POSIX does not attempt to provide binary compatability, this would be quite a mistake, so POSIX does not define kernel binary interfaces and such, which can be heavily tied down to the underlying kernel architecture, since this would constrain system design . C library functions and command line utilities are easily abstracted or seperated from underlying kernel architecture and thus are easily supported without having to clutter up or constrain kernel architecture. In fact, many innovative kernel designs have been implemented on Unix-type systems, like microkernel and multi-server kernels, the C library function interface or command line utitility selection really doesnt interfere with that. POSIX tends to focus on the environment the programmer sees, hence giving the programmer common tools on all OSs, rather than the underlying system architecture.
This, source compatability specifications, allows new kernel designs to be tried and so on and OSs to choose their own internal kernel designs while being able to share the same application base with other OSs. Its a win-win situation.
The user/programmer level interfaces, such as C libraries, when properly designed, as Unix/POSIX is, are not a significant constraint on kernel design or performance.
It is unfortunate that things are this way. However, Open/Free OSs can still support the standards even if they dont do the certification. This certianly helps software to be re-used and easily ported across OSs and could save a lot of time by avoiding having to do extensive porting of an app to each OS.
Linux should follow Unix standards, and this is rather important since the Unix standards tend to be designed to assure source compatability, that the base libraries, kernel, and environment follow the same standards so that software and application libraries can compile on any Unix-compliant OS with no modification. This is essential to having true OS choice because if you want to switch OSs its nice to be able to take your applications with you. Furthermore, since it allows the same software to be compiled on different OSs, all Unix OSs can co-exist and benefit from the software written for each other, so each OS doesnt have to have a set of applications rewritten for it, which wastes time. Linux shouldnt have the "take over the world" mentality and realise that people do deserve OS choice and thus support standards to allow people to move freely between Linux and other Unix OSs.
I certianly agree that it would be a much better idea to provide some sort of standard API that could be implement in a compatability library that would allow an application standard interfaces to Gnome, KDE, etc, for things like registering icons and putting itself on the menus so developers dont have to write special code for each environment. I dont however think that a single piece of software, window manager, or environment should be forced on everyone. Furthermore, if you run KDE that doesnt mean you cant run Gnome apps, you can! It is frustrating to hear people say things like, "I run KDE but I miss Mozilla" , or "I run Gnome but I miss Konqueror". I've run Konqueror under Gnome just fine, and Mozilla under KDE fine.
Furthermore, although Linux claims to be all about "freedom" and "choice", it seems most window managers and desktop environment seem intent on forcing their idea of what is right and useful on you and forcing you to do things a certian way. We fail to realise that different people have particular and unique tastes and a look and feel that seems perfect to one might seem unuseable to another person. It is disturbing to see how many people seem to believe that any feature that they see as "unnecessary" should be thrown away and no one should be allowed to use them becuase it doesnt fit their idea of what is the right way. They forget that a feature that is useless to one person is essential to another. Instead of throwing away features and creating stripped down "fischer price" GUIs, the key is making it configurable, so the user can configure it however they want and decide for themselves what features to include. Desktops can come with a default configuration but it should be completely customisable by the user. Every WM I have tried forces a very rigid set of limitations on me and gives me little choice on making the desktop my own. On KDE, I wanted to float the panel, so i could move it around the screen and so it wouldnt stick to the side of the screen, I wanted to be able to configure Konqueror to require a double click on an icon, yet none of these things could be done. Rigid and inflexible. I think if we want to make Linux GUIs more user friendly we need to make everrything configurable via a GUI interface, the less used options can be put in "experts options" tabs so they dont necessarily have to bewilder the main options screens. Many people dont have enough time to learn another document language just to require double clicks on icons.
I should add, that the compatability layer, which would perhaps consist of a userland process, and a or a wrapper module, as needed, could support every past version of the kernel driver ABI and ABI, so that old drivers would continue to work without bogging down the kernel itself with cruft. The cruft would be in this compatability layer which would be seperate from the kernel, and in fact would be an optional part of the system, since users who dont need to use old driver binaries could use modules compiled for thier native kernel version.
I think it would also be a great idea to include something like this for program binaries as well, if not supported already, so old program binaries can also run on newer kernel while compatability being an optional module or add-on. This probably already exists in fact, i am sure.
I do think its important to encourage open source, but I also dont think things shouldnt be made more difficult to users to encourage open source.
It seems like we see too opposite extremes here, one that there should be no stable ABI and the other that there the ABI should remain the same. However, I think that there is a compromise that can be reached here, while allowing the kernel to change its ABI all it wants, while also giving us a stable ABI. Two ABIs. One built into the kernel, and one implemented in a compatability layer, which would probably be a user space process which may have to emulate some aspects of the kernel. Of course the drivers running on the ABI implemented in the compatability layer will be slower. But hopefully the kernel API and wrapper API will be compatable so the driver can be compiled for either. If the API does have to be chnaged in the kernel, the compatability layer could provide support for the new APIs as well as the old ones, but if there would be a break in compatability drivers which have not been updated for the new API would only be able to run under the compatability layer, obviously this should be avoided.
At least this would allow people who need the convienience of easy to acquire drivers the ease of use they need but also give the Linux experts the ability to compile their modules to run on the native kernel ABI.
I haven't seen this idea suggested very much, but I think, it is a good solution to give all sides the features they need.
I should further emphasize that I find Perl perfect for my own needs, tastes, and it is eisiest for me to understand and use. However, I think people should choose which language suits them best. Perl might be perfect for me but for others Ruby might be preferred. If I wanted a language that did things like Ruby, i'd use Ruby. Its a good things that every language isnt the same and that each one does things differently, this provides you choice in what kind of language to use. If every language were the same, you wouldnt have much choice. I emphasise, Perl should be Perl and Ruby should be Ruby, Perl shouldnt try to be Ruby or vice versa, and people should choose which one based on their needs and preference. This is why I dont think its very good to expect every language to work in the same way.
Feel free to use Ruby, I dont complain about or insult other languages because they are different, in fact I like the fact there are other languages that do things differently, its different from Perl and people have different needs, and in fact I am sure its a pretty good language. I just prefer Perl as it fits me best. I have found Perl to be highly functional for me.
I have used CPAN extensively. I have found it to be a valuable and comprehensive resource. I see having a choice between modules as a benefit. Whats wrong with having a choice? I really dont understand why some seem so opposed to choice and seem intent on forcing everyone to do things one way, thier way, rather than allowing people to have a choice between several different methods and alternatives, even though I have found that when I have a choice between different methods or features, I actually spend less time implementing what I want to do since I am able to choose the feature that best fits my needs, rather than having to cope with features that are awkward and clumsy for what I need to use it for, and ussually it just takes a minute or two of reading the handy documentation to see if a module or feature does what I need it to do. You can ussually see in a few minutes whether or not a module will suite your needs by simply looking at the documentation that comes with the module. Ussually it is sufficient. I simply havent seen the problems that you have described, especially not to a greater extent than other languages.
Most of the Perl modules I have been carefully tested and a lot of work was put into them. There are some that could use more functionality. However, its important that people contribute their modules, even if they do not contain every last feature, since, believe me, it ussually much eisier to extend an existing module than trying to write one from scratch. I have extended and enhanced many modules myself, and I have found the Perl language to be just as readable and maintainable than other languages, despite what some have said. In fact, I have saved a lot of time by simply expanding on someone elses module rather than having to write one from the ground up. So i do think CPAN is doing the right thing by not restricting chioce and letting people decide what features best suite their needs rather than forcing people to use a restricted set of features or into a single methodology that some people prefer but not others.
Furthermore, the Perl OO system is more than adequate, and I have found that creating and using modules is as easy and simple, and straightforward on Perl as it is on other languages, yet it gives you an incredible amount of flexibility and power, which I have found only makes the maintainanence and production of perl code eisier, since I am not forced to use a highly restricted set of features for what I need to do, some of which may be awkward for a particular purpose. Perl doesnt force OO on you either, obviously in many short simple programs OO is likely to be overkill. Its main advantages come when you are using modules and you want to keep namespaces seperate. I have found that for instance, having to use OO for something as simple as a print to STDOUT to be highly unnatural and require more typing and verbosity than necessary. Perl allows you to reserve the OO features for when they do provide a benefit, ussually in a larger program or a more complex constructs. Perl doesnt force this on you, although you could have that way if you wanted I am sure.
I use Perl every day and it has been one of the eisiest to learn and use language that I have found. The syntax to me, seems pretty clear, concise and easy to read, for instance, for a GUI example: use Tk; $win=MainWindow->new; $label=$win->Label(tex t=>'Hello World'); $label->pack;
. The syntax actually is very clean and rather simple and easy to use. In my extensive use of Perl I have found the syntax to be very clean, clear, and easy to understand. I think Perl does things a little differently than other languages, and immediately when people see something that is different to them, it seems many think that there is something wrong with it. If you look at another language for the first time it might seem unusual and strange to you. I have looked at PHP, Python, C++ and Java, those languages seem difficult and strange to me when I first look at them, but thats probably because I hadn't used them enough. It shouldn't be wrong to be different. Perl does things differently but that doesnt make it bad or worse than other languages.
As far as OO goes, Perls OOs is not "bolted on". It is elegantly, carefully designed and integrated with the language. The process of creating and using a Perl module is simple and straightforward, I have done it many times, and just as easy as other programming languages. For example: use Module; $module=Module->new; $module->method(); seems pretty simple and clear to me, in fact, more elegant than some other OO languages that I have seen, in my opinion. I have used C++ and Java, and actually do prefer the design of Perls OO over other languages, it actually takes me less time to use it and code for it than it does on other languages, but thats my personal preference. I have found that with Perl OO and Perl syntax in general it is easy to write clear, good, concise code in less space than many other languages. Perl, to me anyway, requires less language verbage than say C++ or Java does, but is clear and concise.
People have different needs and tastes, and if people should use the programming tools that best suites them. Perl best suites my needs and works in a way that is natural and easy to me. It took me less time to learn Perl than it has other languages.
As far as the GUI libraries, Perl has interfaces to a wide range of GUI libraries, from GTK, QT, OpenGL, Tk, FLTK, etc. Take your pick. Tk is most often distributed with Perl, including with ActiveState Perl on Windows. I have used TK on many occassions and found it to have a very elegant and well designed, yet powerful API.
Perl modules to me seem to be very portable, I have used ones on many different OSs and programs, with no problem. There is nothing inherit in the module system that makes it unportable.
I really havent seen any of the issues that you have mentioned in my extensive use of the Perl programming language.
Not quite true. Compared to what? Most complex programs and libraries written in most languages do rely on other libraries to provide additional facilities. Most GUI programs ussually rely on a graphics library of some sort, because it would be a expensive allocation of time and effort to try to build these things directly when it saves time and resources to instread use another library that provides these things rather than reinvent the wheel. This is the whole idea of libraries and re-use, to avoid re-inventing the wheel. If you use your Linux distributions package installer it will ussually automatically install required libraries. This will happen for almost any GUI program, no matter what language. Many common Linux C/C++ programs use dozens of seperate libraries that need to be installed. If the Linux distro is properly designed it should also install Perl modules required for a Perl program to run. Perl programs are no different than programs written in other languages in their use of external libraries. If you are concerned about end-users bieng inconvenienced by downloading modules, then you can provide a distribution of your program that includes all of the modules that it requires. Of course you should consider allowing advanced users to install the modules themselves.
Furthermore, I have found that manually installing Perl modules is ussually always a very simple and easy process, just as easy or eisier as installing a C library. It is made especially eisier because we have CPAN where you can easily find Perl modules you need from one central location, and it saves you time, you spend less time looking for a library.
Yes, I certianly agree. Perls operator set, is not confusing to me at all and it is easy to learn them. The way the chart is laid out makes it look overly confusing but any good book or good documentation will show that it is very easy to grasp. I really dont see Perls features as causing bad code or making it hard to read. I really believe that can just as easily happen in many other languages. Perl provides a lot more freedom than other languages, but I believe this does not mean that it is eisier to write bad code. For me, Perl is actually much eisier to understand, read and write than say C++. This honestly partly might be because I dont use C++, so I am not as used to it. People, when they see a language which is different from what they arent used to, suddenly think that it must be bad. Note that I said, 'for me', people are often different and have different tastes. Perl is different but that does not make it bad. Its operator set is really ideal at least to me and it is easy for me to learn and use. The idea that you for instance use eq for string comparison and == for numeric comparison is easy to grasp. As far as typing, I dont think perls loose typing really creates problems even in large projects, I havent seen it. Really, good coding style guidelines is what is needed in any language. Personally, generally I think Perls freedom and the choices it gives for how to do things make it eisier to read and write rather than more difficult. If people want a language that is highly restrictive, there are many other ones out there to do that. Please use them if thats what you want. Just because a language is different and doesnt fit my taste doesnt mean I demand that those langauges be changed to how I think they should be, I am glad that their are people who like using them. And I am glad I am able to use Perl, becuase it is most useable for me. I think we should continue to have our Perl as a language of freedom and choice, as it is, as those who appreciate it have come to benefit from the freedom, choice, and useability that it is gives, and the people who want restrictive languages should be able to have their other languages that do that.
Slashdot Mirror
I wonder if this will be a truly open technology, open source, and give us the ability to actually know what it is doing when it runs. And Windows only? Perhaps that will change, that wouldnt be a friendly policy to ignore users of other OSs. Microsoft isnt the entirity of the computing world.
I hope this app just isnt a commercial marketing type thing but is an open protocol, open source technology.
Yes, I certianly agree. We should try to make Unix-type systems more avialable to everyone and that means some good GUI configuration tools.
The big problem with Linux, BSD, etc, is few are being paid to develop for these platforms, thus we dont have a lot of people who can work full time to improve things. We need to find a way to pay developers of open source projects so they can work full time on these projects. With that I think we would see an increase in quality including lots of nice GUI tools for non-techie users.
I think furthermore techie and non-techie users can both share the same system and techies can have full control and low level access to the system well non-techies can have the easy to use GUIs at the same time. GUI configurators can be made to automatically produce the human readable config files, thus we can have both config files, GUI tools, and a rich command line environment.
As far as Unix itself, I think overall the system is very good and no changes should to the core concepts should be made, the directory layout is good, the basic concepts are good, X WIndows is good. I have heard people say that the X Windows API is prehistoric. Nonsense, its just a low level API and its designers didnt make the mistake of just offering a bunch of high level widgets but created an API providing graphical primitives high level widgets can be created with. X API is designed for widget construction, not for direct use by applications.
Basically what is needed is more full time developers, including for the GUI tools.
I certianly agree, that FireFox gaining popularity is a great thing and especially if its getting people off of IE and proprietary protocols and languages, its a very a good thing. Its also great to hear that people find that it fits thier needs so well.
So I certianly do think that Firefox is a good thing and that its getting so much attention and popularity. Since Mozilla and FireFox share the same engine as well, no matter which you use you should get the same rendering, protocol and language support. I am very impressed by Geckos supports for standards, and hopefully it will be continued to be improved, support for things like SVG, CSS 1-3, HTML, XHTML, SMIL, MNG, PNG, Javascript and W3C DOM standards. These standards are essential and allow users the freedom to choose their browser while being able to still view web pages, and make designers lives easier by not having them support 10 different incompatible browsers.
I dont really understand what FireFox is so much better than Mozilla, and why its such a big deal. How is it an improvement over Mozilla? Ive heard from others it has fewer features and options, and a more dumbed down UI. Dumbed down UI != ease of use. I think the less customisability software has the harder it becomes to use, for newbies and experienced users alike. It becomes more difficult for the user to customise the software for their preferences and usage pattern, and more difficult to accomplish certian tasks. The trick with useability is not to remove customisbility, but rather make software as customisable as possible but simply design a good configuration user interface that places more commonly used options more prominantly than advanced one, such as through placing the more advanced options on advanced options screens or other such techniques, thus keeping the more advanced options from confusing newbies but allowing people to gradually begin using them and discover them (and making it easy to discover them by making them all avialable through a good UI) as they become familiar with software. People often start out using software by using a subset of its features and then gradually add to their knowledge of the software and use a more complete set of its features, and different users have different needs and will use different features sets. This is why software should be as customisable as possible and not try to restrict features and functionality, but rather allow the user to customise the software to their tastes. One feature that seems useless to one person is likely essential to someone else.
I do think that if done properly, making KDE and other applications work on Windows could actually help Free Software, that is, and actually *ease* the transition over to Linux. That is, if its done properly.
Why not instead of spending huge effort to port millions of OSS Unix programs to Windows, just instead compile Unix applications on Windows using Cygwin, and improve Cygwin to be an accurate implementation of Unix source compatability standards? Cygwin could be improved so that nearly all OSS Unix programs could compile on it with few modications. This would save huge effort porting applications. The same goes for Mac OS X, and every other OS.
If porting KDE to Windows APIs requires a lot of extra work, maintainence and effort, then it will hurt free software since it will be a case of re-inventing the wheel, extra work ends up being done making the same software work on Windows proprietary, non standard APIs, this increases the work being done to maintian the same software and takes away resources from making new software or adding new features, instead of going on to design new things people will be tied up re-engineering the same things to run on different OSs. This is how non-standard core OS APIs, like C libraries and kernel interfaces, hinder free software, software reuseability, promote OS lock-in and restrict OS freedom and OS choice, and how standards like POSIX which promote standards which assure source compatability (the ability to compile software on any OS without modification), assures OS choice, since it makes sure that people can take the same software with them to whatever OS they choose with only a recompile.
The solution, to avoid duplication of effort maintaining ports for Windows and other OSs, and allowing software that implements POSIX compatability on Windows and thus allows Unix programs to compile on Windows without modification, thus there is no extra effort needed to port the software to Windows, instead of having to port a gazillion OSS applications to Windows we can just need some POSIX libraries for Windows and all Unix programs will work on Windows without porting. This saves developer effort and prevents OSS developer resources from having to be spent porting existing software to Windows and instead work on new software.
And, Cygwin already exists which is a very good start at creating a POSIX/Unix standards compliant environment on Windows. There is still more work to be done on it, but instead of investing huge resources in porting a gazillion Unix apps to Windows, why not just make sure Cygwin is an accurate implementation of a Unix environment and those gazillion applications will work on Windows with little or no porting? Cygwin is nearly that already, with X windows, most Unix utilities, lots of libraries, but there still are some glitches. One big one that needs to be fixed is the lack of case sensitivity on filenames. This could be fixed simply by creating a hidden file in each directory with a table to map between case sensitive names and the real name used on the underlying filesysem, or on NTFS try to use NTFSs case sensitivity support if possible.
The fact that AOL is using the IE engine is not convincing proof that AOL is supporting open source projects like Mozilla. Mozilla, most of all, is the rendering engine, Gecko, this is the core of Mozilla and one of its most important and central parts. It would be I believe be deceptive to call software "Mozilla" if it doesnt even use the engine developed by the Mozilla project. It would be nothing more than IE masquerading in a Mozilla skin. It seems if AOL was really serious about supporting Mozilla and supporting an alternative to IE that was free of Microsoft licences, they would be supporting work to improve the Mozilla code so it does as good of a job as IE, and using Mozilla in all of their own products and not relying on IE at all. It seems this would be good for AOL since they would not be relying on proprietary software from another company and would be able to see all of the source code.
One of my favourite sayings:
A feature that seems worthless to one person might be essential to another. Just because something seems to have no use to you does not mean that someone else doesnt have a use for it.
I believe that object oriented programming, in a very large program, makes things much, much eisier, when it is properly done, which is quite easy to do. I believe one reason it tends to make programs more maintainable, more understandable, and easier to get familiarised with, when we instead of creating one big monolithic software program and instead create modules each which has a particular purpose, is it keeps the code in the module smaller, shorter, simpler, and eisier to understand. Good documentation is also important to describe what the module does and its interface. I have done OO programming and done right it makes things simpler, makes less code, keeps the code reuseable, ans breaks up a big program into smaller parts which are eisier to understand.
I believe strong typing should be available in a language, but not forced on programmers since in many cases it just makes things more complex. I have used weak typed languages and it rarely is a problem. Although, I do think types can be useful, and I know Perl 6 will have types avialable if you want to use them.
The issues regarding seperating different areas of program design can be easily addressed at the software level, and have been with object oriented languages, like Java, Perl (my preferred language), C++, among others. It is possible to place program logic in methods in one object and call those from some a seperate UI component. Object oriented environments which provide seperate spaces for the objects are widely avialable and easily done in software. Putting such things in the CPU would certianly not make them any eisier or more likely to be used, and I dont think that the CPU is the right place for an object oriented programming environment :-). The CPU cant easily be changed or reprogrammed if there is a bug which is why we dont build operating systems and complex software programs into them but instead put those things into software levels, which works well.
I have found Perl to be a very useable program language that allows programs to be written in a clear and easy to understand manner. I believe the notion that it encourages obfuscated programming is a myth. I have read some pretty obfuscated and awful code written in C++ and Java , and obfuscation is possible in any somewhat useable programming language. What we need is good programming habits. If we dont use good programming habits and keep readability in mind we can make a mess of things in any language.
Certianly, I believe people should be able to use the language that fits them best and what they are most comfortable with. If you like Java, then It is fine with me if you want to use it. I prefer Perl since that somehow fits my needs and is eisier for me to understand and use, and write good code in. For other people it might be Java. I believe people should use what fits them best.
I have found that Perl allowed me to get to writing good readable maintainable code faster than most other languages.
A programmer if they do not have practice in programming can mess things up in any language. Different people have different needs and different thought patterns, and different languages fit different peoples tastes better. What might be great for one person is not so useable to another. A feature that is essential to one person may have no use for another. Just because one person thinks a feature has no use does not mean the feature does not have merit and should not be there, because there is likely someone who does need it.
I thought that I heard that James Webb telescope is primarily infrared. If so, its not at all the same thing as Hubble, although it has virtues of its own, it doesnt give us the same visible light capabilities as Hubble. I heard Webb does have some visible capability but it doesnt sound like it has as much as Hubble. It has an infrared viewer, which is quite different and will allow us to see through clouds of dust to say the centers of galaxies better, but it may not provide the same quality visible light photographs we are used to with Hubble. It seems like something like Hubble and Webb would compliment each other, since they each photograph different parts of the spectrum better.
I should correct myself, binary interfaces are ussually outside the scope of POSIX and other source compatability standards. Such things can be done via Linux Standards Base or whatever if desired.
There are a few exceptions, such as with X Window Systems and NFS, where of course binary compatability is needed in the protocols, and perhaps file formats like TAR.
Unix OSs can if their is some new feature offered by the OS to the application programmers, and the feature does not yet have an API defined for it, create a new API for the feature. However, as this feature becomes more broadly used across different operating systems, a standard needs to be defined to assure that applications which use the feature can run on different Unix OSs. One such area presently that may need to be addressed for instance is scalable kernel event notification facilities such as Kqueue/Epoll interfaces, each OS seems to have a different API for the same feature.
Furthermore, with POSIX application APIs, their is ussually no need to change what has already been defined, and certianly this should be avoided. Agian the application APIs do not dictate the underlying kernel design. Ussually only the binary interfaces may have an significant impact on kernel design, and these interfaces can be changed without disrupting source compatability. Ussually what we see with Unix standards is new capability being added beyond what is already there.
The binary interfaces and things like low level filesystem design are smartly out of the scope of Unix standards.
Unix specifications have evolved to meet the needs of modern operating systems, they are not antique as you imply, but as improvements and innovations have occured in OS features, these things have been included into the API. For instance POSIX threads. Also, I do not consider Unix API to be a legacy API, it has a pretty clean design and the model is in fact followed to quite an extant by Linux and most OSs. POSIX defined a lot of very basic things like standard C functions and libraries, and command line utilties, with the aim of assuring source compatability. POSIX does not attempt to provide binary compatability, this would be quite a mistake, so POSIX does not define kernel binary interfaces and such, which can be heavily tied down to the underlying kernel architecture, since this would constrain system design . C library functions and command line utilities are easily abstracted or seperated from underlying kernel architecture and thus are easily supported without having to clutter up or constrain kernel architecture. In fact, many innovative kernel designs have been implemented on Unix-type systems, like microkernel and multi-server kernels, the C library function interface or command line utitility selection really doesnt interfere with that. POSIX tends to focus on the environment the programmer sees, hence giving the programmer common tools on all OSs, rather than the underlying system architecture.
This, source compatability specifications, allows new kernel designs to be tried and so on and OSs to choose their own internal kernel designs while being able to share the same application base with other OSs. Its a win-win situation.
The user/programmer level interfaces, such as C libraries, when properly designed, as Unix/POSIX is, are not a significant constraint on kernel design or performance.
It is unfortunate that things are this way. However, Open/Free OSs can still support the standards even if they dont do the certification. This certianly helps software to be re-used and easily ported across OSs and could save a lot of time by avoiding having to do extensive porting of an app to each OS.
Linux should follow Unix standards, and this is rather important since the Unix standards tend to be designed to assure source compatability, that the base libraries, kernel, and environment follow the same standards so that software and application libraries can compile on any Unix-compliant OS with no modification. This is essential to having true OS choice because if you want to switch OSs its nice to be able to take your applications with you. Furthermore, since it allows the same software to be compiled on different OSs, all Unix OSs can co-exist and benefit from the software written for each other, so each OS doesnt have to have a set of applications rewritten for it, which wastes time. Linux shouldnt have the "take over the world" mentality and realise that people do deserve OS choice and thus support standards to allow people to move freely between Linux and other Unix OSs.
I certianly agree that it would be a much better idea to provide some sort of standard API that could be implement in a compatability library that would allow an application standard interfaces to Gnome, KDE, etc, for things like registering icons and putting itself on the menus so developers dont have to write special code for each environment. I dont however think that a single piece of software, window manager, or environment should be forced on everyone. Furthermore, if you run KDE that doesnt mean you cant run Gnome apps, you can! It is frustrating to hear people say things like, "I run KDE but I miss Mozilla" , or "I run Gnome but I miss Konqueror". I've run Konqueror under Gnome just fine, and Mozilla under KDE fine.
Furthermore, although Linux claims to be all about "freedom" and "choice", it seems most window managers and desktop environment seem intent on forcing their idea of what is right and useful on you and forcing you to do things a certian way. We fail to realise that different people have particular and unique tastes and a look and feel that seems perfect to one might seem unuseable to another person. It is disturbing to see how many people seem to believe that any feature that they see as "unnecessary" should be thrown away and no one should be allowed to use them becuase it doesnt fit their idea of what is the right way. They forget that a feature that is useless to one person is essential to another. Instead of throwing away features and creating stripped down "fischer price" GUIs, the key is making it configurable, so the user can configure it however they want and decide for themselves what features to include. Desktops can come with a default configuration but it should be completely customisable by the user. Every WM I have tried forces a very rigid set of limitations on me and gives me little choice on making the desktop my own. On KDE, I wanted to float the panel, so i could move it around the screen and so it wouldnt stick to the side of the screen, I wanted to be able to configure Konqueror to require a double click on an icon, yet none of these things could be done. Rigid and inflexible. I think if we want to make Linux GUIs more user friendly we need to make everrything configurable via a GUI interface, the less used options can be put in "experts options" tabs so they dont necessarily have to bewilder the main options screens. Many people dont have enough time to learn another document language just to
require double clicks on icons.
I should add, that the compatability layer, which would perhaps consist of a userland process, and a or a wrapper module, as needed, could support every past version of the kernel driver ABI and ABI, so that old drivers would continue to work without bogging down the kernel itself with cruft. The cruft would be in this compatability layer which would be seperate from the kernel, and in fact would be an optional part of the system, since users who dont need to use old driver binaries could use modules compiled for thier native kernel version.
I think it would also be a great idea to include something like this for program binaries as well, if not supported already, so old program binaries can also run on newer kernel while compatability being an optional module or add-on. This probably already exists in fact, i am sure.
I do think its important to encourage open source, but I also dont think things shouldnt be made more difficult to users to encourage open source.
It seems like we see too opposite extremes here, one that there should be no stable ABI and the other that there the ABI should remain the same. However, I think that there is a compromise that can be reached here, while allowing the kernel to change its ABI all it wants, while also giving us a stable ABI. Two ABIs. One built into the kernel, and one implemented in a compatability layer, which would probably be a user space process which may have to emulate some aspects of the kernel. Of course the drivers running on the ABI implemented in the compatability layer will be slower. But hopefully the kernel API and wrapper API will be compatable so the driver can be compiled for either. If the API does have to be chnaged in the kernel, the compatability layer could provide support for the new APIs as well as the old ones, but if there would be a break in compatability drivers which have not been updated for the new API would only be able to run under the compatability layer, obviously this should be avoided.
At least this would allow people who need the convienience of easy to acquire drivers the ease of use they need but also give the Linux experts the ability to compile their modules to run on the native kernel ABI.
I haven't seen this idea suggested very much, but I think, it is a good solution to give all sides the features they need.
I should further emphasize that I find Perl perfect for my own needs, tastes, and it is eisiest for me to understand and use. However, I think people should choose which language suits them best. Perl might be perfect for me but for others Ruby might be preferred. If I wanted a language that did things like Ruby, i'd use Ruby. Its a good things that every language isnt the same and that each one does things differently, this provides you choice in what kind of language to use. If every language were the same, you wouldnt have much choice. I emphasise, Perl should be Perl and Ruby should be Ruby, Perl shouldnt try to be Ruby or vice versa, and people should choose which one based on their needs and preference. This is why I dont think its very good to expect every language to work in the same way.
Feel free to use Ruby, I dont complain about or insult other languages because they are different, in fact I like the fact there are other languages that do things differently, its different from Perl and people have different needs, and in fact I am sure its a pretty good language. I just prefer Perl as it fits me best. I have found Perl to be highly functional for me.
Peace,
Eravnrekaree
I have used CPAN extensively. I have found it to be a valuable and comprehensive resource. I see having a choice between modules as a benefit. Whats wrong with having a choice? I really dont understand why some seem so opposed to choice and seem intent on forcing everyone to do things one way, thier way, rather than allowing people to have a choice between several different methods and alternatives, even though I have found that when I have a choice between different methods or features, I actually spend less time implementing what I want to do since I am able to choose the feature that best fits my needs, rather than having to cope with features that are awkward and clumsy for what I need to use it for, and ussually it just takes a minute or two of reading the handy documentation to see if a module or feature does what I need it to do. You can ussually see in a few minutes whether or not a module will suite your needs by simply looking at the documentation that comes with the module. Ussually it is sufficient. I simply havent seen the problems that you have described, especially not to a greater extent than other languages.
Most of the Perl modules I have been carefully tested and a lot of work was put into them. There are some that could use more functionality. However, its important that people contribute their modules, even if they do not contain every last feature, since, believe me, it ussually much eisier to extend an existing module than trying to write one from scratch. I have extended and enhanced many modules myself, and I have found the Perl language to be just as readable and maintainable than other languages, despite what some have said. In fact, I have saved a lot of time by simply expanding on someone elses module rather than having to write one from the ground up. So i do think CPAN is doing the right thing by not restricting chioce and letting people decide what features best suite their needs rather than forcing people to use a restricted set of features or into a single methodology that some people prefer but not others.
Furthermore, the Perl OO system is more than adequate, and I have found that creating and using modules is as easy and simple, and straightforward on Perl as it is on other languages, yet it gives you an incredible amount of flexibility and power, which I have found only makes the maintainanence and production of perl code eisier, since I am not forced to use a highly restricted set of features for what I need to do, some of which may be awkward for a particular purpose. Perl doesnt force OO on you either, obviously in many short simple programs OO is likely to be overkill. Its main advantages come when you are using modules and you want to keep namespaces seperate. I have found that for instance, having to use OO for something as simple as a print to STDOUT to be highly unnatural and require more typing and verbosity than necessary. Perl allows you to reserve the OO features for when they do provide a benefit, ussually in a larger program or a more complex constructs. Perl doesnt force this on you, although you could have that way if you wanted I am sure.
I use Perl every day and it has been one of the eisiest to learn and use language that I have found. The syntax to me, seems pretty clear, concise and easy to read, for instance, for a GUI example:x t=>'Hello World');
use Tk;
$win=MainWindow->new;
$label=$win->Label(te
$label->pack;
. The syntax actually is very clean and rather simple and easy to use. In my extensive use of Perl I have found the syntax to be very clean, clear, and easy to understand. I think Perl does things a little differently than other languages, and immediately when people see something that is different to them, it seems many think that there is something wrong with it. If you look at another language for the first time it might seem unusual and strange to you. I have looked at PHP, Python, C++ and Java, those languages seem difficult and strange to me when I first look at them, but thats probably because I hadn't used them enough. It shouldn't be wrong to be different. Perl does things differently but that doesnt make it bad or worse than other languages.
As far as OO goes, Perls OOs is not "bolted on". It is elegantly, carefully designed and integrated with the language. The process of creating and using a Perl module is simple and straightforward, I have done it many times, and just as easy as other programming languages. For example: use Module; $module=Module->new; $module->method(); seems pretty simple and clear to me, in fact, more elegant than some other OO languages that I have seen, in my opinion. I have used C++ and Java, and actually do prefer the design of Perls OO over other languages, it actually takes me less time to use it and code for it than it does on other languages, but thats my personal preference. I have found that with Perl OO and Perl syntax in general it is easy to write clear, good, concise code in less space than many other languages. Perl, to me anyway, requires less language verbage than say C++ or Java does, but is clear and concise.
People have different needs and tastes, and if people should use the programming tools that best suites them. Perl best suites my needs and works in a way that is natural and easy to me. It took me less time to learn Perl than it has other languages.
As far as the GUI libraries, Perl has interfaces to a wide range of GUI libraries, from GTK, QT, OpenGL, Tk, FLTK, etc. Take your pick. Tk is most often distributed with Perl, including with ActiveState Perl on Windows. I have used TK on many occassions and found it to have a very elegant and well designed, yet powerful API.
Perl modules to me seem to be very portable, I have used ones on many different OSs and programs, with no problem. There is nothing inherit in the module system that makes it unportable.
I really havent seen any of the issues that you have mentioned in my extensive use of the Perl programming language.
Not quite true. Compared to what? Most complex programs and libraries written in most languages do rely on other libraries to provide additional facilities. Most GUI programs ussually rely on a graphics library of some sort, because it would be a expensive allocation of time and effort to try to build these things directly when it saves time and resources to instread use another library that provides these things rather than reinvent the wheel. This is the whole idea of libraries and re-use, to avoid re-inventing the wheel. If you use your Linux distributions package installer it will ussually automatically install required libraries. This will happen for almost any GUI program, no matter what language. Many common Linux C/C++ programs use dozens of seperate libraries that need to be installed. If the Linux distro is properly designed it should also install Perl modules required for a Perl program to run. Perl programs are no different than programs written in other languages in their use of external libraries. If you are concerned about end-users bieng inconvenienced by downloading modules, then you can provide a distribution of your program that includes all of the modules that it requires. Of course you should consider allowing advanced users to install the modules themselves.
Furthermore, I have found that manually installing Perl modules is ussually always a very simple and easy process, just as easy or eisier as installing a C library. It is made especially eisier because we have CPAN where you can easily find Perl modules you need from one central location, and it saves you time, you spend less time looking for a library.
Yes, I certianly agree. Perls operator set, is not confusing to me at all and it is easy to learn them. The way the chart is laid out makes it look overly confusing but any good book or good documentation will show that it is very easy to grasp. I really dont see Perls features as causing bad code or making it hard to read. I really believe that can just as easily happen in many other languages. Perl provides a lot more freedom than other languages, but I believe this does not mean that it is eisier to write bad code. For me, Perl is actually much eisier to understand, read and write than say C++. This honestly partly might be because I dont use C++, so I am not as used to it. People, when they see a language which is different from what they arent used to, suddenly think that it must be bad. Note that I said, 'for me',
people are often different and have different tastes. Perl is different but that does not make it bad. Its operator set is really ideal at least to me and it is easy for me to learn and use. The idea that you for instance use eq for string comparison and == for numeric comparison is easy to grasp. As far as typing, I dont think perls loose typing really creates problems even in large projects, I havent seen it. Really, good coding style guidelines is what is needed in any language. Personally, generally I think Perls freedom and the choices it gives for how to do things make it eisier to read and write rather than more difficult. If people want a language that is highly restrictive, there are many other ones out there to do that. Please use them if thats what you want. Just because a language is different and doesnt fit my taste doesnt mean I demand that those langauges be changed to how I think they should be, I am glad that their are people who like using them. And I am glad I am able to use Perl, becuase it is most useable for me. I think we should continue to have our Perl as a language of freedom and choice, as it is, as those who appreciate it have come to benefit from the freedom, choice, and useability that it is gives, and the people who want restrictive languages should be able to have their other languages that do that.