I'd like to see configuration of everything move to an XML standard, and this should be coupled with flexible visual tools.
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:
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.
Re:Former perl, python, java geek gone to Ruby
on
Ruby 1.8.0 Released
·
· Score: 1
I have to disagree about the clean syntax. For example, a method call is not simply object.method arg1, arg2,..., it can also be object.method(arg1, arg2,...), blocks can be do... end or {... }. You mention the syntactic sugar yourself - I can't see how that can be separated from the "basic syntax". All in all, Rubys syntax looks quite eclectic to me. Of course, it's still better than a lot of other languages.
Mind you, I don't have any problem with alternative ways to write stuff, or with shortcuts. I just don't like it when a language designer decides which ones he personally likes and includes them, without a possibility for users to create their own. A language syntax should either be consistent or extensible (or both).
Re:Former perl, python, java geek gone to Ruby
on
Ruby 1.8.0 Released
·
· Score: 1
The major improvement in Ruby over Python and C++ and most OO languages (but not Smalltalk) is the inclusion of code blocks that may be passed in as a parameter to a method
From what I understand, code blocks are basically anonymous functions that the method they are passed to can only invoke with yield, right? Or is it possible to treat them as any other parameter, i.e. store them, pass them further around, take more than one etc?
When I looked at Ruby (not in much detail yet), I thought that code blocks were a pretty lame excuse for proper functions-as-data, so I'm a little bit surprised to see them mentioned as a great feature. Did I miss something?
Is there any OS vendor other than Microsoft (and SCO) that isn't using open source software in some way?
Microsoft is using open source software. They even sell GPLed programs, as part of their Windows Services for Unix package, including GNU tools like gcc.
Perhaps more interesting, there are frequent rumors that their developers use lots of internal tools written in Perl. And, of course, they used some network components from BSD, but I don't know if there are any left.
Sparc systems have one important advantage over AMD64: They exist. I wouldn't expect anyone to run mission-critical apps on a 128-CPU AMD64 server any time soon.
And you know how linux is making leaps and bounds ? take a look at some of the more recent code that has been put into the kernel, and in userland. Sun is a major contributor.
Not only the Linux kernel. Sun is who came up with NFS and PAM, they are major contributors in the Gnome project, they open-sourced Star/OpenOffice, they are an important part of the DocBook community, they invented the Morphic GUI now used in Squeak for the Self language, employ several hacker legends like Richard Gabriel, Guy Steele or Bill Joy (well, if you want to call that employment) etc, etc.
I mean, this is slashdot. We should not forget that, all objective topics aside, Sun is just one heck of a cool company! If only they would get rid of that annoying Scott McNealy...
GNU is an operating system. It's a replacement of the proprietary unix operating system.
Wrong tense. Gnu will be a replacement for unix when it's done. There just isn't a stable release for it yet, but they only had something like 19 years so far...
GNU was meant to be a system, Linux was not. Linux is a kernel, which needs an operating system to live.
Linux was meant to be a complete system as well, until people decided that it would be pointless to recreate lots of little userland utilities when Gnu has them already.
Basically, GNU/Linux can be seen as the symbiosis of two incomplete attempts to produce an operating system. That way, the name even makes sense.
BTW, your definition of "operating system" seems funny. An OS is made up by ls, cat, true and sh, but doesn't include a kernel?
At this point, testing with normal browsers has become impossible, since there are multiple versions of IE, both Mac and PC, on the streets, all of them rendering CSS differently, Mozilla has split yet again, Safari is trying to gain market share, and Opera is still causing web developers to pull their hair out.
And now you want an accessability standard?
"Accessible" also means accessible for people with different browsers. If you follow the WAI guidelines, your site will work OK in all of them, not only in voice browsers und other weird stuff, but also Opera, IE and Konqueror.
The whole WAI idea can basically be summarized in two rules: "Provide as much information as possible - it will help someone, even if most will ignore it" and "Don't rely on bugs in specific implementations, code to the specs". It's just about being sane.
Give me any AA site, and I'm pretty sure that I'll be able to use it with weird browsers the author might not even know about. It might look different, but it's usable. If you need print layout, you know where to find it, just accept that HTML isn't for you.
And as for w3c "standards" these are not plug-ins and are not called standards because they are supported by everything.. hell, they don't even call 'em standards, they call them recomendations.
These are layed out so that people creating the browsers of tomorrow can work together to prevent any more messed-up-browser-detection-required-scripting-shi t that happend during the browser wars and is a fact of life still today for most web developers.
Unfortunatly, no. That was how the W3C got big, and it was really good at it: Being an independent gremium where best practices from competing vendors were consolidated for the sake of interoperability.
But that is not what they are doing today. They silently switched from standardization to specification, developing "standards" out of the blue - and they suck at it!
The worst example is probably W3C XML Schema - the classical example of design by committe, hard to use, theoretically unsound, with lots of stuff bolted on without real integration late in the process (like the gHorribleKludge date/time types). And now they force it in into every other spec. They are seriously alienating huge parts of the community - take XPath2/XSLT2 for example, there have been quite some implementors stating that they don't plan to support it, ever (for example the ones of 4XSLT (Python) and libxslt (C)) - their user base doesn't need it (and yes, the userbase itself said so), and it makes the implementation way more complex than it has to be for XSLT1.
I certainly don't want the browser wars back, but I miss the old, working W3C.
Considering the superb support for advanced concepts like accesskey, tabindex (which have been in HTML for years), XML "standards" like XLink, XPointer or client-side XSL (-T and -FO), or sane IMT handling in current client and server software, I'd expect it to change the way things ought to be done but aren't, and nothing else until a military superpower finds a way to connect bad markup practice with terrorism.
Interviewer: "What do you think will be the biggest problem in computing in the 90s?" Paul Boutin: "There are only 17,000 three-letter acronyms."
OK, so XForms is not really a TLA (and there are of course more than 17,000 of them, more like 17,576 assuming the basic 26-letter latin alphabet). But it's also not the 90s anymore, so get over it.
DOS is still useful now, for a limited problem domain, but that's not the point.
Software development as an art/craft/science/whatever you think it is has evolved rapidly. There are "fashions" in code - try reading 20 year old C code: the language itself hasn't really changed much, but you will immediatly notice the differerence. People have tried things that failed, and have found interesting solutions that are now forgotten. This will all be lost.
What would literature be like if we hadn't accesss to the classics? Or architecture? There is a lot of knowledge that is worth being preserved.
And, of course, digging in old software is way cool.
I think it's not really about static typing only. "Corporate" doesn't like too much power and flexibility, probably thinking that it makes it harder to maintain the code once they fired the incompetent code monkey that wrote it.
It is really interesting to read some of the early Java papers. It was explicitly designed as a language for huge teams of mediocre programmers, while languages like Lisp expect programmers to know what they are doing (for example, like in Python, it will make it visible if you access a function you are not supposed to, but will not prevent you from doing so).
Re:LSB or POSIX, it really doesn't matter, because
on
LSB & Posix Conflicts
·
· Score: 1
Because it has to demonstrate the GNU way of programming. The GNU way of implementing traditional UNIX programs is adding lots of questionable options to it (so that people get tricked into writing code that won't work on any other system), and not implementing the standard ones completly (so that standard-conforming code won't neccessarily run on a GNU system). A stategy otherwise known as "embrace and extend".
Of course, bloat is another important quality. You might note that your program therefore doesn't qualify as a part of the GNU system - it doesn't even use gettext! Even their version of/bin/true uses gettext, and supports several command line arguments, but only depending on the POSIXLY_CORRECT env variable (and hence it is much more code than your hello version, and thus obviously better).
San Francisco, CA - January 30 2002- The Open Group announced today completion of the joint revision to POSIX® and the Single UNIX® Specification. The new standard is now available at http://www.UNIX-systems.org/version3/ in keeping with The Open Group's policy of open and free access to its standards.
As far as I can see, all that is required is a free registration. Am I missing something?
Won't happen, ever. There are reasons for the differences. For example, OpenBSD stores config files of third-party apps in/etc, FreeBSD in/usr/local/etc - there are good arguments for both ways (basically "all config files should be in one location where you can easily find them all" vs. "there should be a clear distinction between the base system and arbitrary third-party stuff").
Another problem is non-free software where you don't really have a choice where to put stuff, especially when the author(s) insist on a really weird interpretation of the Unix file system hierarchy. This can badly mess up your carefully organized system. Qmail and other D.J. Bernstein software is the prime example.
Even if not, GNU has helpfully published a version of "Hello, World!" that uses autoconf, so it's quite easy to work around incompatibilities if the GPL isn't a problem for your project. It doesn't seem to be actively maintained at the moment, however, the current version 2.1.1 is over a year old.
Doesn't matter a bit. If anything, issue a warning if someone uses a potentially dangerous function (like FreeBSD does for stuff like mktemp, the linker will print "Warning: Potentially unsafe use of mktemp, consider using mkstemp instead" or some such), but don't break apps that adhere to the standard. It has "portable" in its name for a reason.
Even the bash approach where you have to explicitly ask for POSIX-conforming behaviour is better than nothing, even if I think that it should be the default.
There are only two sane ways to deal with POSIX brain-damage: Fix POSIX, or don't use that stuff in your programs. OSes that are "mostly" POSIX-compatible are worse for portability that those who just say that they don't implement POSIX at all.
Several of the BSDs (though I'm not sure which, FreeBSD and NetBSD maybe) have ancestries which can be traced back to real unix.
All of the BSDs. FreeBSD and NetBSD share common roots (and obviously OpenBSD too, scince it's a fork of NetBSD), but parted early, in the early eighties or early nineties, depending on how you count. Both derive from the original Berkeley Software Distribution assembled by Bill Joy in 1977, which was a tape containing the original Unix plus some extensions, like a pascal compiler and the ex editor. The second edition featured vi (also written by Joy) and termcap. Here's a nice history of BSD, and here's a Unix timeline.
However, officially no contemporary BSD contains a single line of original Unix code - at least that's the official outcome of a former lawsuit rather similar to todays SCO issue. Incidentally, this lawsuite happened in the early days of the FreeBSD project, which also lost its prime developer some time earlier. It took about a year for them to get back to a usable system with all offending code removed. It was also in the time of the beginning of the rise of Linux (early to mid nineties) - some BSD old-timers still like to muse about whether BSD would be dominant today rather than Linux if this legal battle hadn't happened.
The last question would be, of what benefit would it bring to FreeBSD when there is already and adequate solution, UFS2, sitting there ready to be used.
Even if it isn't used for production systems, being able to read and write ReiserFS partitions would be useful for FreeBSD. Just like supporting NTFS is useful, without anybody using it for the root partition.
I don't really see the licensing problem, however. It doesn't really have to be part of the default FreeBSD kernel. Someone could just write a ko (i.e. a loadable kernel module) and give it a good home in the ports tree. There is already a port for pf, the OpenBSD packet filter, that works that way, and I doubt that adding a filesystem dynamically would be that much harder.
But right now, there are already people doing service and support. There are also people developing shrinkwrap software. The only way that the second group could be absorbed by the first would be if all software would really, really suck, so that people need lots of support;-)
If more work will be done without direct compensation, less people will receive direct compensation for their work. It really is that simple.
Slashdot Mirror
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.
Mind you, I don't have any problem with alternative ways to write stuff, or with shortcuts. I just don't like it when a language designer decides which ones he personally likes and includes them, without a possibility for users to create their own. A language syntax should either be consistent or extensible (or both).
When I looked at Ruby (not in much detail yet), I thought that code blocks were a pretty lame excuse for proper functions-as-data, so I'm a little bit surprised to see them mentioned as a great feature. Did I miss something?
Perhaps more interesting, there are frequent rumors that their developers use lots of internal tools written in Perl. And, of course, they used some network components from BSD, but I don't know if there are any left.
Sparc systems have one important advantage over AMD64: They exist. I wouldn't expect anyone to run mission-critical apps on a 128-CPU AMD64 server any time soon.
I mean, this is slashdot. We should not forget that, all objective topics aside, Sun is just one heck of a cool company! If only they would get rid of that annoying Scott McNealy...
Linux was meant to be a complete system as well, until people decided that it would be pointless to recreate lots of little userland utilities when Gnu has them already.
Basically, GNU/Linux can be seen as the symbiosis of two incomplete attempts to produce an operating system. That way, the name even makes sense.
BTW, your definition of "operating system" seems funny. An OS is made up by ls, cat, true and sh, but doesn't include a kernel?
The whole WAI idea can basically be summarized in two rules: "Provide as much information as possible - it will help someone, even if most will ignore it" and "Don't rely on bugs in specific implementations, code to the specs". It's just about being sane.
Give me any AA site, and I'm pretty sure that I'll be able to use it with weird browsers the author might not even know about. It might look different, but it's usable. If you need print layout, you know where to find it, just accept that HTML isn't for you.
But that is not what they are doing today. They silently switched from standardization to specification, developing "standards" out of the blue - and they suck at it!
The worst example is probably W3C XML Schema - the classical example of design by committe, hard to use, theoretically unsound, with lots of stuff bolted on without real integration late in the process (like the gHorribleKludge date/time types). And now they force it in into every other spec. They are seriously alienating huge parts of the community - take XPath2/XSLT2 for example, there have been quite some implementors stating that they don't plan to support it, ever (for example the ones of 4XSLT (Python) and libxslt (C)) - their user base doesn't need it (and yes, the userbase itself said so), and it makes the implementation way more complex than it has to be for XSLT1.
I certainly don't want the browser wars back, but I miss the old, working W3C.
Considering the superb support for advanced concepts like accesskey, tabindex (which have been in HTML for years), XML "standards" like XLink, XPointer or client-side XSL (-T and -FO), or sane IMT handling in current client and server software, I'd expect it to change the way things ought to be done but aren't, and nothing else until a military superpower finds a way to connect bad markup practice with terrorism.
Paul Boutin: "There are only 17,000 three-letter acronyms."
OK, so XForms is not really a TLA (and there are of course more than 17,000 of them, more like 17,576 assuming the basic 26-letter latin alphabet). But it's also not the 90s anymore, so get over it.
Software development as an art/craft/science/whatever you think it is has evolved rapidly. There are "fashions" in code - try reading 20 year old C code: the language itself hasn't really changed much, but you will immediatly notice the differerence. People have tried things that failed, and have found interesting solutions that are now forgotten. This will all be lost.
What would literature be like if we hadn't accesss to the classics? Or architecture? There is a lot of knowledge that is worth being preserved.
And, of course, digging in old software is way cool.
It is really interesting to read some of the early Java papers. It was explicitly designed as a language for huge teams of mediocre programmers, while languages like Lisp expect programmers to know what they are doing (for example, like in Python, it will make it visible if you access a function you are not supposed to, but will not prevent you from doing so).
Of course, bloat is another important quality. You might note that your program therefore doesn't qualify as a part of the GNU system - it doesn't even use gettext! Even their version of /bin/true uses gettext, and supports several command line arguments, but only depending on the POSIXLY_CORRECT env variable (and hence it is much more code than your hello version, and thus obviously better).
GNU's Not Unix, indeed.
Another problem is non-free software where you don't really have a choice where to put stuff, especially when the author(s) insist on a really weird interpretation of the Unix file system hierarchy. This can badly mess up your carefully organized system. Qmail and other D.J. Bernstein software is the prime example.
Even if not, GNU has helpfully published a version of "Hello, World!" that uses autoconf, so it's quite easy to work around incompatibilities if the GPL isn't a problem for your project. It doesn't seem to be actively maintained at the moment, however, the current version 2.1.1 is over a year old.
Even the bash approach where you have to explicitly ask for POSIX-conforming behaviour is better than nothing, even if I think that it should be the default.
There are only two sane ways to deal with POSIX brain-damage: Fix POSIX, or don't use that stuff in your programs. OSes that are "mostly" POSIX-compatible are worse for portability that those who just say that they don't implement POSIX at all.
However, officially no contemporary BSD contains a single line of original Unix code - at least that's the official outcome of a former lawsuit rather similar to todays SCO issue. Incidentally, this lawsuite happened in the early days of the FreeBSD project, which also lost its prime developer some time earlier. It took about a year for them to get back to a usable system with all offending code removed. It was also in the time of the beginning of the rise of Linux (early to mid nineties) - some BSD old-timers still like to muse about whether BSD would be dominant today rather than Linux if this legal battle hadn't happened.
I don't really see the licensing problem, however. It doesn't really have to be part of the default FreeBSD kernel. Someone could just write a ko (i.e. a loadable kernel module) and give it a good home in the ports tree. There is already a port for pf, the OpenBSD packet filter, that works that way, and I doubt that adding a filesystem dynamically would be that much harder.
If more work will be done without direct compensation, less people will receive direct compensation for their work. It really is that simple.