Slashdot Mirror
What's Missing from Free Software?
dan.hunt asks: "Klaus Knopper was interviewed here and the interviewer, technobeast, asked: 'If you were asking the questions, what would be the 1st one you would ask?' Klaus answered in part 'What are you missing in the available Free Software, and how would you like to change that?'"
Source distribution should be optional
!@!@@!"$$!$!$!@!$@!$@!$@
Source distribution is optional, as long as you distribute it for cost if requested. Theres tons of OSS which is one downloadable file. Mozilla, for example, or even rpm's and debs.
KDE is not a window manager. It is a desktop environment comprising several libraries, utilities applets, office applications and the KWM window manager.
1. I agree that "names that mean something" is a good idea, but your suggestion that Microsoft's names "mean something" is ridiculous. Instead of "Internet Explorer", lets try "Browser" or "Web Browser"
/bin. The reason for all that cruft was to put things on the correct disks, but that can be solved today with symbolic links (and could be solved even better with Plan9 union mounts, or by having things that search paths instead search a fixed directory and all subdirectories and have symbolic links handle "~" and "$foo" expansions so system links can be user-specific.
2. Unless you consider the registry editor "graphical" I don't think you can do everything in Windows "graphically". But we do need the a solution that is superior to the typical Windows gui. One HUGE advantage of text files is that they can have comments and you can easily cut & paste items to duplicate and then modify them, and you can comment out lines. Also useful is the ability in many cases to insert "if" statements. It is unclear what the solution is, but it is obvious that the most complex computer control (writing programs) even the mighty Microsoft has not come up with anything better than ASCII files. But people do like IDE's that manage those files and react nicely to the edits you do and quickly jump to the right places in them based on outside influences, so maybe some work should be done similar to that.
3. People who say "Linux can do that and did it long before Windows" are missing the point I think. I also set this up, but it was a pain and required much searching through Google and editing files and I'm quite uncertain if I did it right. Really, if I put in two network cards, why not have this turn on automatically? Why else would I have two cards? (ps Linux detected them both so it is not a hardware or driver problem) It can be done with ZERO wizards, I was all prepared to swap the network cables if it didn't work, or perhaps it could detect which end had a DHCP server. Now I don't know much about networks, but some automatic sensible setup would be nice.
4. NTFS is undocumented and Microsoft is using this as a way to stop Linux adoption. However I have heard that NTFS write is kind of working, so this may happen. A better approach would be to add some code to Windows to read Linux partitions. Then it can be balanced: each system can copy from the other but neither can damage the other with any mistake. Such code could be installed with a Windows auto-run program on a Linux installation disk.
5. I don't get this. Huge numbers of machines where I work are "installed" by inserting a HDD. This is done for Windows, Linux, and dual-boot machines, and works exactly like you suggest.
6. Actually it may be a good idea to have abstract one-syllable names like "bin" and "etc". They can be communicated in speech unambiguously. However I would eliminate all the unnecessary hierarchy and revert back to the original Linux setup where the locations were in the root. "/usr/bin" and "/usr/local/bin" and so on would be eliminated and everything dumped in
7. Last I checked it has been quite awhile since 2.4, and the next version is 2.6. I suspect if you check the developers inside Microsoft you will find they use a lot of numbers to describe each version of Windows as well. Unless they really don't recompile it except when they sell a new version...
This is a very bad idea. And I say that as someone who uses XML daily, and is generally very fond of it.
A telling example: XML-based configuration files have made my working with XML quite a lot harder. As you might know, XML systems - and SGML systems before them - can use so-called "catalogs" that map public identifiers or URIs to local files, so that when you reference the official location of, say, the DocBook DTD in a file, you don't have to download it every time. In the old SGML days, that was done with a line-oriented catalog file that would contain something like
PUBLIC "-//OASIS//DTD DocBook V4.1//EN" "/usr/local/share/sgml/docbook/4.1/docbook.dtd"
Unfortunatly, in their great wisdom people (namely OASIS, the organization also responsible for the DocBook and lots of other, usually quite good, standards) decided that line-oriented formats are no good, and developed an XML format that looks something like this:
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog "> o okx.dtd"/>
<public publicId="-//OASIS//DTD DocBook XML V4.2//EN" uri="file:///usr/local/share/xml/docbook/4.2/docb
</catalog>
The problem: Try installing a new DTD. It will hopefully have it's own catalog file, that you only have to register with one of the catalogs already known.
For the old variant, all you have to do is "echo CATALOG new_catalog_file >> /some/existing/catalog". Removing it again is easily done with grep -v or sed. Try something like that with the XML format, and it will end up unparsable. You either have to edit it by hand, or use a special program that knows about XML and XML-based catalogs.
In other words, the main effect of the new format is that you cannot use the traditional Unix tools anymore. Manipulating the config files now requires specialized programs, making things like portable install scripts very hard. And I really, really doubt that any GUI or other tool benefits from the XML format - SGML catalogs, and most config files, are damn easy to parse, the hard part is getting the semantics right - what values are legal, what options exist, how to present them to the user in a visually pleasing and intuitive way etc. XML doesn't help you one bit with that.
XML is cool for complex structured documents. Config files are neither documents, nor are they supposed to be complex.
Programming can be fun again. Film at 11.