Yes, this is strange. Maybe your previous message was moderated down because it was a bit more provocative than mine. Or maybe some moderator thought that there was no reason to post anonymously and gave a -1 because of this.
I do not understand why mine was moderated up to +5, though. Something like +3 or +4 would have been more appropriate. But then someone gave it a -1 Flamebait, which I cannot understand either. I would have understood -1 Overrated (or maybe even Redundant, compared with the previous message that I had not seen), but -1 Flamebait is strange because I did not intend to be offensive.
Anyway, it is sometimes very difficult to understand why some messages are moderated up or down. Sometimes, the meta-moderation helps and reduces the influence of some unfair moderators, but we all know that the Slashdot moderation system is not perfect.
Oh, and moderating this comment as off-topic would be appropriate, by the way...
Thanks for confirming this. Unfortunately, the way you confirmed it is very dangerous.
Your message contains:
no date
no precise reference to the report that you are confirming
So from now one, your "confirmation" can be used by anybody who wants to claim that some
random report of theirs is "confirmed by a debian
developer". Until you revoke your own key, of course. That's a pity.
Although the official development kits are available for Windows, you can easily develop Symbian applications with the Linux tools provided by the GnuPoc project. So you will not only be able to build the Java applications (J2ME or MIDP), but also the native C++ applications using Linux.
So you can have a 100% Linux-based development environment for Symbian. Considering that the official Symbian SDK for Windows uses perl and gcc, so it is no surprise that most of the tools can work with Linux. It was probably a business decision to distribute the SDK for Windows only (it makes sense, because this is what most developers will be using anyway) but the Linux developers are not excluded.
Even the Symbian installer (the makesis utility) was released as open source by Symbian a few months ago. You can probably google for it.
No, these plug-ins will not restore support for MNG in Mozilla. They will only add a different way to include MNG using the EMBED tag. This is different from native support using the standard IMG tag.
Have a look at these two pages, providing support for Mozilla and Firebird:
The second page contains a test image using IMG, EMBED and OBJECT. With version 1.4 of Mozilla, I can see all three versions of the animation. With the plug-ins that you are linking to, you will probably not be able see the first one (which is the one that most web designers should be using). I haven't tried Mozilla 1.5 yet and I doubt that I will upgrade because of these MNG problems, but expect that none of the animations will be displayed with 1.5.
With version 1.4 of Mozilla, I can also see all the images on the Opossum demo page, showing how JNG compresses better than GIF and provides a much better quality (full color and true transparency instead of 1-bit "all or nothing" transparency). I can also see variousothertest cases for MNG without any problems. I suppose that Mozilla 1.5 will fail these tests.
This means that all those who thought that they could replace the animated GIFs on their pages with the patent-free MNG format will have to go back to GIF or Flash.
Note that MS Internet Explorer does not support MNG either, and Mozilla has a small market share in comparison to MSIE. But on the other hand, it is true that the removal of MNG is bad news for those who intended to use it inside their company, if their company uses Mozilla or other browsers derived from it.
I think that is is possible to restore a part of the MNG support by installing an XPI file for Mozilla. This is not a perfect solution because it requires every user to download a separate package for MNG support, but this could be a partial workaround for companies wanting to use MNG in their intranet.
Heh! The links to Mozilla from Slashdot are disabled. So if you want to take a look at this bug, you have to copy this URL and paste it into a separate browser window (or tell your browser or proxy to drop the Referer header, if you can do that): http://bugzilla.mozilla.org/show_bug.cgi?id=18574
Please do not add a new comment to that bug report. Voting for it is probably equally useless, because this bug report has far more bugs than any other bug report in Bugzilla, but still nobody wants to apply the required patches that would revert the removal of MNG support. Instead, spend your votes on related bugs, such as bug #196670 or bug #204520.
And why would anyone include their email address on a credit card application in the first place? And why would they bother fishing it out of the garbage?
This article is only two paragraphs long (no link to another article) but it looks like you haven't taken the time to read it. The second paragraph says: "We've managed to track down a copy of the form she had filled out, and in the signature area is a big 'N/A'." So if they managed to get a copy of the form, then it must have been fished out of the garbage.
Regarding the e-mail spam, I don't think that the author of the story or his wife have much to complain about. 20 per day is a relatively low amount, and the e-mail address could have been found via other sources than the credit card application. On the other hand, I can easily understand their frustration about the telemarketers and the junk mail (the dead tree version). It is a well-known fact that many companies (such as the credit card issuer in this case) sell their lists of addresses to other companies. So although the e-mail spam could have been caused by something else, I can easily believe that the junk mail and the annoying telemarketers could be traced back to that credit card application.
You are raising some interesting issues. Some of them are well-know, but some others (e.g. middle point for sliders) haven't been reported earlier, as far as I know.
Please try to report them in Bugzilla. This is the best way to make sure that the GIMP developers do not forget about these problems. Some of them already have their own bug report and there is no need to submit a duplicate bug report, but you can add some comments to the existing one if you think that you could give a better description of how some problems could be solved.
You can use bugzilla.gnome.org to report GIMP bugs or search for existing ones.
Or you can use the friendly interface from bugs.gimp.org if the default interface to Bugzilla scares you.
Re:What does this mean for Sodipodi?
on
GIMP goes SVG
·
· Score: 1
Was that staged?
Errr... No, honestly.
But I will think about it and prepare some nice dialogues for the next time the GIMP is mentioned on/. ;-)
Well, there is at least one significant difference between the "vital" features that you are requesting from the developers and the recently added support for SVG (which is used much more than you think, especially in GNOME and KDE): the SVG support is based on the excellent work that Simon did on the path tool (adding limited but very useful vector support to the GIMP) and on existing pieces of code borrowed from librsvg and the associated GIMP plug-in. So several pieces of the puzzle were ready to be used, some of them written by GIMP developers (the path tool) and some others written by external contributors (the SVG library and plug-in). Adding SVG support to the GIMP required some effort, but most of the pieces were already available.
This is different for the features that you are requesting: so far, there have been very few contributions to the development of these features. I agree that they are important and they would be very useful. But they will only be available in the GIMP when someone finds the time to implement them. So the best way for you to get them into the GIMP is to find someone who can write the code and submit it to the developers. I do not expect that many users have the programming skills required for implementing these features by themselves, but there are many other ways to contribute, including finding someone else who does the programming for you and then submits the results to the developers. Or you could try to help with the documentation, help files, translations to foreign languages, web site and many other things that would save some time for the current GIMP developers and allow them to spend more of their spare time implementing these nice features.
A part of this should already be handled by your X server (see Xcms, xcmsdb and related tools). For the other part, see the next item.
4. L*a*b color space
Also planned for a future release, when GEGL is integrated into the GIMP. Look at the GEGL Task List and scroll down to the item "Additional ColorSpaces and ColorModels". You will see that L*a*b is mentioned there.
For all of these, the GIMP and GEGL developers would be more than happy to accept any contributions from users of developers. Providing a patch implementing the missing feature is of course the best way to contribute, but paying someone for doing it may also work in some cases. Bribing some developer with money, food, books, movies or any geeky stuff may also help.;-)
That is a UI flaw. Drawing straight lines is a common thing that users do. Including it as a non-apparent feature (which makes the user hunt down the documentation) is just plain stupid.
You are right: this is a UI flaw. The problem is known and this will eventually be solved. You can have a look at the following bug reports. The second one deals more specifically with the issue that you mentioned (as a coincidence, I forked it off the main bug report today).
Re:I don't mean to gripe but....
on
GIMP goes SVG
·
· Score: 1
I am really surprised that the gimp team doesn't have some pro PhotoShop users on board to give feedback on -really important- missing features. At least they could pick up some good books on PS photo retouching (probably what 90% of the users would like to do with Gimp, honestly, does anybody think more than 1-2% would use this SVG thing?) and read up on it...
If you use PhotoShop on a regular basis (you do not have to be a pro) and you think that you could describe some interesting features in a better way than what has been reported so far, then please add some comments to these bug reports or join the gimp-user or gimp-developer mailing lists and post your suggestions there. We frequently get some requests saying "I want this" without describing what "this" is in a way that can be understood by those who are not familiar with the program implementing "this". If you think that you can help, please contribute.
Regarding buying some good books on PS, that would be an option, but remember that all GIMP developers are doing this in their spare time and are already busy enough implementing the features that have been planned a long time ago. Also, the goal is certainly not to copy PS or any other program. So instead of trying to copy some features exactly and being accused of plagiarism (which would be a risk if the developers would start reading PS books), it is better to have a clean room implementation, in which some user describes the desired features (but not the details of how it should be implemented) and some other developer starts from this description for implementing something that fits the GIMP way of thinking.
You may not see it immediately, but we also made
some extra efforts to make the site look nicer in
lynx and other text-based browsers. This is a nice
side-effect of having cleaner XHTML code and using
some CSS features for hiding some contents depending
on what the browser supports. There are still some
issues with the old Netscape4, but overall the new
site should be more accessible than the old one.
Hmmm... It looks like you posted your question twice, in reply to two different comments. I have already replied to the other comment, so I will simply add a link to my previous reply.
Re:The GIMP New Web Site
on
GIMP goes SVG
·
· Score: 1
Well, I can tell you from a reliable source that the software used for maintaining the web site is a combination of CVS for storing all source files (module gimp-web in gnomecvs), good old hand-written XHTML for the contents of a pages, and a custom set of Python scripts for wrapping the page contents into the templates (header, footer, menu bar). Until a few weeks ago, the last part was done using Apache SSI, but now the pages are pre-processed by the scripts instead of requiring the web server to do all the work for every request.
If you want to know who worked on what part of
the new GIMP web site, have a look at the team page or simply look at the ChangeLog after checking out the gimp-web module.
Re:What does this mean for Sodipodi?
on
GIMP goes SVG
·
· Score: 1
Thanks for the correction, Sven. Indeed, the
ability to work on the paths derived from the SVG file (as I mentioned in my second point) is one of the main points of the new SVG support.
Re:What does this mean for Sodipodi?
on
GIMP goes SVG
·
· Score: 4, Informative
One of the goals of adding SVG support in the GIMP was to allow better cooperation between the GIMP and Sodipodi or other vector-based applications.
Until recently, if you were using Sodipodi, you had to convert your SVG file to a bitmap format (such as PNG) before being able to load it in the GIMP. Now it is possible to import the SVG file directly into the GIMP and make some minor adjustments before creating the final image. You can also convert some parts of the SVG (imported as paths in the GIMP) to selections and apply more complex effects that what SVG would allow.
Note that the SVG support in the GIMP is only due to the integration of the SVG plug-in that had been available since a while as part of libsvg. So it's nothing really new, although including it as part of the default GIMP distribution seems to make a significant difference.
MDI interface for the GIMP
on
GIMP goes SVG
·
· Score: 2, Informative
Offering some kind of MDI interface for the GIMP has been suggested several years ago. This may be a good solution, as long as it is optional because some people prefer the current interface.
You can find some discussion about that in bug report #7379. The feature may be implemented in GIMP 3.0, or earlier if I find enough spare time to implement it or (more likely) if someone else takes the job and implements this feature.
Note that version 1.3.x and the upcoming version 2.0 offer the option of displaying a menu bar in the image windows, if this is what you are interested in. But if you want a shared menu bar on top of a big container window and a shared status bar at the bottom of that window, then you will have to wait until someone implements a real MDI solution.
Having a programming contest in which only OO languages are permitted is like having a cabinet-making contest in which all work must be done with screwdrivers.
I agree. That's why I posted the previous comment and suggested some scripting languages. I am not too familiar with ML, OCAML or Haskell, but there are some problems for which I would use Erlang. It's a pity that this fine language does not get the attention that it deserves.
A good programmer, just like a good physician or a good carpenter, becomes fluent in the tools of the trade and selects them according to the problem domain.
And the tools of the trade include not only the languages, but also the toolkits and libraries available for those languages. Although I have done it a number of times for specific tasks that required highly optimized code, I would not implement the sockets code for a client-server or some sorting algorithms, etc. Instead, I would install the appropriate libraries and use them. There is no need to re-invent the wheel every time.
<rant>And now a minor rant: my original comment was moderated twice as redundant (down to -1) only because I posted it just a bit after a similar comment that got modded up to +5. A bit more than one minute made the difference. Maybe I should not use to preview button and fix the typos? Or maybe I should not take care of formatting my message in HTML for better readability? The interesting thing is that several other redundant messages that have been posted one hour later did not get moderated down. So the conclusion is that one has to post very fast or post late. But posting just a bit too late (e.g., spending one minute previewing and correcting the comment) can kill a comment that would otherwise be as good (or bad) as another one that gets moderated up very quickly. Ah well, this is Slashdot, after all...</rant>;-)
The submitter has stated that "any programming language" can be used. The announcement on O'Reilly Developer News says: [...] and you can use the programming languages of your choice to solve the problems thrown at you.
But the Overview page for the competition contains the following paragraph:
Use Java, C++, C# or VB.NET. Pick any of these programming languages to code your solutions. All are acceptable and none is given an advantage.
This is far from "the programming languages of your choice". My choice would be plain old C for some tasks (using object-oriented paradigms if necessary, such as in glib and gtk+) and scripting languages such as Perl or Python for other tasks. I hope that they still accept C in the C++ category, but it looks like no other languages are allowed. Sigh!
You can also have a look at this new page on the ISC site, which describes the feature (same paragraph as the one quoted in my previous message) and provides links to the patched versions and the corresponding announcements.
It also mentions that the new "delegation-only" option is meant to be used in the following way (in named.conf):
zone "foo" {
type delegation-only;
};
Obviously, you would replace "foo" by "com" and "net". Easy! Problem gone.
Although the news are not on the BIND page yet, patches for the current versions 9.2.2 and 9.1.3 are already available. Only 9.2.3rc2 is currently listed on the page (as of this writing).
You can get the details from the bind-announce list archives:
All versions were released a few hours ago. Here is the common paragraph at the top of these three messages:
In response to high demand from our users, ISC is releasing a patch for BIND
to support the declaration of "delegation-only" zones in caching/recursive
name servers. Briefly, a zone which has been declared "delegation-only" will
be effectively limited to containing NS RRs for subdomains, but no actual
data outside its apex (for example, its SOA RR and apex NS RRset). This can
be used to filter out "wildcard" or "synthesized" data from NAT boxes or from
authoritative name servers whose undelegated (in-zone) data is of no interest.
I actually have a 6 CD set from Yggdrasilof the 'Linux Internet Archives Winter 1996'.
I still have single CD labeled "Yggdrasil GNU/Linux/X11 Fall '93". This is the oldest CD-based distribution that I have at home. Before that, I used the SLS floppies but I have recycled these floppies in the meantime.
Saying that all Linux distributions had some rough edges in 1993 would be an understatement, but I was able to play with them on my old 486/33 with a mere 20 MB of disk space. The Yggdrasil CD had a nice option to install only the basic system on the hard disk and use the CD for the parts that didn't fit. Running X11 and emacs from the CD was painfully slow, but it worked. I could even do some real work on that crazy old stuff!
Slashdot Mirror
There is no need for any "Phone Home" software or anything sending the CPUID to AOL. The story is much simpler than that and rather low-tech:
Nothing exceptional here. The FBI does not need any strange hooks into AOL. They only need stupid thieves. Case closed.
Yes, this is strange. Maybe your previous message was moderated down because it was a bit more provocative than mine. Or maybe some moderator thought that there was no reason to post anonymously and gave a -1 because of this.
I do not understand why mine was moderated up to +5, though. Something like +3 or +4 would have been more appropriate. But then someone gave it a -1 Flamebait, which I cannot understand either. I would have understood -1 Overrated (or maybe even Redundant, compared with the previous message that I had not seen), but -1 Flamebait is strange because I did not intend to be offensive.
Anyway, it is sometimes very difficult to understand why some messages are moderated up or down. Sometimes, the meta-moderation helps and reduces the influence of some unfair moderators, but we all know that the Slashdot moderation system is not perfect.
Oh, and moderating this comment as off-topic would be appropriate, by the way...
s/from now one/from now on/g
...and I did use the Preview button. Sigh!
Thanks for confirming this. Unfortunately, the way you confirmed it is very dangerous.
Your message contains:
So from now one, your "confirmation" can be used by anybody who wants to claim that some random report of theirs is "confirmed by a debian developer". Until you revoke your own key, of course. That's a pity.
Although the official development kits are available for Windows, you can easily develop Symbian applications with the Linux tools provided by the GnuPoc project. So you will not only be able to build the Java applications (J2ME or MIDP), but also the native C++ applications using Linux.
So you can have a 100% Linux-based development environment for Symbian. Considering that the official Symbian SDK for Windows uses perl and gcc, so it is no surprise that most of the tools can work with Linux. It was probably a business decision to distribute the SDK for Windows only (it makes sense, because this is what most developers will be using anyway) but the Linux developers are not excluded.
Even the Symbian installer (the makesis utility) was released as open source by Symbian a few months ago. You can probably google for it.
No, these plug-ins will not restore support for MNG in Mozilla. They will only add a different way to include MNG using the EMBED tag. This is different from native support using the standard IMG tag.
Have a look at these two pages, providing support for Mozilla and Firebird:
The second page contains a test image using IMG, EMBED and OBJECT. With version 1.4 of Mozilla, I can see all three versions of the animation. With the plug-ins that you are linking to, you will probably not be able see the first one (which is the one that most web designers should be using). I haven't tried Mozilla 1.5 yet and I doubt that I will upgrade because of these MNG problems, but expect that none of the animations will be displayed with 1.5.
With version 1.4 of Mozilla, I can also see all the images on the Opossum demo page, showing how JNG compresses better than GIF and provides a much better quality (full color and true transparency instead of 1-bit "all or nothing" transparency). I can also see various other test cases for MNG without any problems. I suppose that Mozilla 1.5 will fail these tests.
Note that MS Internet Explorer does not support MNG either, and Mozilla has a small market share in comparison to MSIE. But on the other hand, it is true that the removal of MNG is bad news for those who intended to use it inside their company, if their company uses Mozilla or other browsers derived from it.
I think that is is possible to restore a part of the MNG support by installing an XPI file for Mozilla. This is not a perfect solution because it requires every user to download a separate package for MNG support, but this could be a partial workaround for companies wanting to use MNG in their intranet.
Heh! The links to Mozilla from Slashdot are disabled. So if you want to take a look at this bug, you have to copy this URL and paste it into a separate browser window (or tell your browser or proxy to drop the Referer header, if you can do that):
http://bugzilla.mozilla.org/show_bug.cgi?id=18574
Please do not add a new comment to that bug report. Voting for it is probably equally useless, because this bug report has far more bugs than any other bug report in Bugzilla, but still nobody wants to apply the required patches that would revert the removal of MNG support. Instead, spend your votes on related bugs, such as bug #196670 or bug #204520.
This article is only two paragraphs long (no link to another article) but it looks like you haven't taken the time to read it. The second paragraph says: "We've managed to track down a copy of the form she had filled out, and in the signature area is a big 'N/A'." So if they managed to get a copy of the form, then it must have been fished out of the garbage.
Regarding the e-mail spam, I don't think that the author of the story or his wife have much to complain about. 20 per day is a relatively low amount, and the e-mail address could have been found via other sources than the credit card application. On the other hand, I can easily understand their frustration about the telemarketers and the junk mail (the dead tree version). It is a well-known fact that many companies (such as the credit card issuer in this case) sell their lists of addresses to other companies. So although the e-mail spam could have been caused by something else, I can easily believe that the junk mail and the annoying telemarketers could be traced back to that credit card application.
You are raising some interesting issues. Some of them are well-know, but some others (e.g. middle point for sliders) haven't been reported earlier, as far as I know.
Please try to report them in Bugzilla. This is the best way to make sure that the GIMP developers do not forget about these problems. Some of them already have their own bug report and there is no need to submit a duplicate bug report, but you can add some comments to the existing one if you think that you could give a better description of how some problems could be solved.
You can use bugzilla.gnome.org to report GIMP bugs or search for existing ones. Or you can use the friendly interface from bugs.gimp.org if the default interface to Bugzilla scares you.
Errr... No, honestly.
But I will think about it and prepare some nice dialogues for the next time the GIMP is mentioned on /. ;-)
Well, there is at least one significant difference between the "vital" features that you are requesting from the developers and the recently added support for SVG (which is used much more than you think, especially in GNOME and KDE): the SVG support is based on the excellent work that Simon did on the path tool (adding limited but very useful vector support to the GIMP) and on existing pieces of code borrowed from librsvg and the associated GIMP plug-in. So several pieces of the puzzle were ready to be used, some of them written by GIMP developers (the path tool) and some others written by external contributors (the SVG library and plug-in). Adding SVG support to the GIMP required some effort, but most of the pieces were already available.
This is different for the features that you are requesting: so far, there have been very few contributions to the development of these features. I agree that they are important and they would be very useful. But they will only be available in the GIMP when someone finds the time to implement them. So the best way for you to get them into the GIMP is to find someone who can write the code and submit it to the developers. I do not expect that many users have the programming skills required for implementing these features by themselves, but there are many other ways to contribute, including finding someone else who does the programming for you and then submits the results to the developers. Or you could try to help with the documentation, help files, translations to foreign languages, web site and many other things that would save some time for the current GIMP developers and allow them to spend more of their spare time implementing these nice features.
Planned for a future release. Contributions are welcome.
Planned for a future release. Again, contributions are welcome.
A part of this should already be handled by your X server (see Xcms, xcmsdb and related tools). For the other part, see the next item.
Also planned for a future release, when GEGL is integrated into the GIMP. Look at the GEGL Task List and scroll down to the item "Additional ColorSpaces and ColorModels". You will see that L*a*b is mentioned there.
For all of these, the GIMP and GEGL developers would be more than happy to accept any contributions from users of developers. Providing a patch implementing the missing feature is of course the best way to contribute, but paying someone for doing it may also work in some cases. Bribing some developer with money, food, books, movies or any geeky stuff may also help. ;-)
You are right: this is a UI flaw. The problem is known and this will eventually be solved. You can have a look at the following bug reports. The second one deals more specifically with the issue that you mentioned (as a coincidence, I forked it off the main bug report today).
http://bugzilla.gnome.org/show_bug.cgi?id=51108
http://bugzilla.gnome.org/show_bug.cgi?id=124040
If you use PhotoShop on a regular basis (you do not have to be a pro) and you think that you could describe some interesting features in a better way than what has been reported so far, then please add some comments to these bug reports or join the gimp-user or gimp-developer mailing lists and post your suggestions there. We frequently get some requests saying "I want this" without describing what "this" is in a way that can be understood by those who are not familiar with the program implementing "this". If you think that you can help, please contribute.
Regarding buying some good books on PS, that would be an option, but remember that all GIMP developers are doing this in their spare time and are already busy enough implementing the features that have been planned a long time ago. Also, the goal is certainly not to copy PS or any other program. So instead of trying to copy some features exactly and being accused of plagiarism (which would be a risk if the developers would start reading PS books), it is better to have a clean room implementation, in which some user describes the desired features (but not the details of how it should be implemented) and some other developer starts from this description for implementing something that fits the GIMP way of thinking.
You may not see it immediately, but we also made some extra efforts to make the site look nicer in lynx and other text-based browsers. This is a nice side-effect of having cleaner XHTML code and using some CSS features for hiding some contents depending on what the browser supports. There are still some issues with the old Netscape4, but overall the new site should be more accessible than the old one.
Hmmm... It looks like you posted your question twice, in reply to two different comments. I have already replied to the other comment, so I will simply add a link to my previous reply.
Well, I can tell you from a reliable source that the software used for maintaining the web site is a combination of CVS for storing all source files (module gimp-web in gnomecvs), good old hand-written XHTML for the contents of a pages, and a custom set of Python scripts for wrapping the page contents into the templates (header, footer, menu bar). Until a few weeks ago, the last part was done using Apache SSI, but now the pages are pre-processed by the scripts instead of requiring the web server to do all the work for every request.
If you want to know who worked on what part of the new GIMP web site, have a look at the team page or simply look at the ChangeLog after checking out the gimp-web module.
Thanks for the correction, Sven. Indeed, the ability to work on the paths derived from the SVG file (as I mentioned in my second point) is one of the main points of the new SVG support.
One of the goals of adding SVG support in the GIMP was to allow better cooperation between the GIMP and Sodipodi or other vector-based applications.
Until recently, if you were using Sodipodi, you had to convert your SVG file to a bitmap format (such as PNG) before being able to load it in the GIMP. Now it is possible to import the SVG file directly into the GIMP and make some minor adjustments before creating the final image. You can also convert some parts of the SVG (imported as paths in the GIMP) to selections and apply more complex effects that what SVG would allow.
Note that the SVG support in the GIMP is only due to the integration of the SVG plug-in that had been available since a while as part of libsvg. So it's nothing really new, although including it as part of the default GIMP distribution seems to make a significant difference.
Offering some kind of MDI interface for the GIMP has been suggested several years ago. This may be a good solution, as long as it is optional because some people prefer the current interface.
You can find some discussion about that in bug report #7379. The feature may be implemented in GIMP 3.0, or earlier if I find enough spare time to implement it or (more likely) if someone else takes the job and implements this feature.
Note that version 1.3.x and the upcoming version 2.0 offer the option of displaying a menu bar in the image windows, if this is what you are interested in. But if you want a shared menu bar on top of a big container window and a shared status bar at the bottom of that window, then you will have to wait until someone implements a real MDI solution.
I agree. That's why I posted the previous comment and suggested some scripting languages. I am not too familiar with ML, OCAML or Haskell, but there are some problems for which I would use Erlang. It's a pity that this fine language does not get the attention that it deserves.
And the tools of the trade include not only the languages, but also the toolkits and libraries available for those languages. Although I have done it a number of times for specific tasks that required highly optimized code, I would not implement the sockets code for a client-server or some sorting algorithms, etc. Instead, I would install the appropriate libraries and use them. There is no need to re-invent the wheel every time.
<rant>And now a minor rant: my original comment was moderated twice as redundant (down to -1) only because I posted it just a bit after a similar comment that got modded up to +5. A bit more than one minute made the difference. Maybe I should not use to preview button and fix the typos? Or maybe I should not take care of formatting my message in HTML for better readability? The interesting thing is that several other redundant messages that have been posted one hour later did not get moderated down. So the conclusion is that one has to post very fast or post late. But posting just a bit too late (e.g., spending one minute previewing and correcting the comment) can kill a comment that would otherwise be as good (or bad) as another one that gets moderated up very quickly. Ah well, this is Slashdot, after all...</rant> ;-)
The submitter has stated that "any programming language" can be used. The announcement on O'Reilly Developer News says: [...] and you can use the programming languages of your choice to solve the problems thrown at you.
But the Overview page for the competition contains the following paragraph:
This is far from "the programming languages of your choice". My choice would be plain old C for some tasks (using object-oriented paradigms if necessary, such as in glib and gtk+) and scripting languages such as Perl or Python for other tasks. I hope that they still accept C in the C++ category, but it looks like no other languages are allowed. Sigh!
You can also have a look at this new page on the ISC site, which describes the feature (same paragraph as the one quoted in my previous message) and provides links to the patched versions and the corresponding announcements.
It also mentions that the new "delegation-only" option is meant to be used in the following way (in named.conf):
zone "foo" {
type delegation-only;
};
Obviously, you would replace "foo" by "com" and "net". Easy! Problem gone.
Although the news are not on the BIND page yet, patches for the current versions 9.2.2 and 9.1.3 are already available. Only 9.2.3rc2 is currently listed on the page (as of this writing).
You can get the details from the bind-announce list archives:
All versions were released a few hours ago. Here is the common paragraph at the top of these three messages:
Have fun downloading and installing!
I still have single CD labeled "Yggdrasil GNU/Linux/X11 Fall '93". This is the oldest CD-based distribution that I have at home. Before that, I used the SLS floppies but I have recycled these floppies in the meantime.
Saying that all Linux distributions had some rough edges in 1993 would be an understatement, but I was able to play with them on my old 486/33 with a mere 20 MB of disk space. The Yggdrasil CD had a nice option to install only the basic system on the hard disk and use the CD for the parts that didn't fit. Running X11 and emacs from the CD was painfully slow, but it worked. I could even do some real work on that crazy old stuff!