What I also want to see is the death of X-Windows. It's served it's term, but it isn't getting any better. I want to see DirectFB [directfb.org] succeed, but it needs to be multi-platform.
People not understanding what the X Window System is just try to reinvent it with a different name and incompatible API.
Hint: if you don't like the Xlib API, well, you should realize that the X Window System is mainly a protocol specification. Xlib is just that, a library that speaks X protocol, and it happens to be the one that comes with every X implementation, but for God's sake nothing prevents to implement another one. If Sam Lantinga (SDL main author) wanted, he could extend SDL just to speak direcly X protocol, without using Xlib at all (but that would be stupid, since Xlib isn't that ugly).
Now, projects like DirectFB have their place for special applications (embedded devices), but for everyone else, <whatever>-on-X (<whatever> being Display PostScript, Display PDF, GTK+, Qt, Motif, SDL, Berlin, etc.) is the only reasonable answer, at least for the large range of supported hardware (don't limit yourself to XFree86, but think also of all the UNIX and OpenVMS systems out there having their own implementation of the X Window System).
Admittedly, you're giving up portability but Java is nice, or at least interesting, for many other reasons.
I wonder if this commitment to Gnome from Sun could also be considered some sort of admission that Swing, despite years of research and development, is not (yet?) that adeguate to make a desktop environment.
But then, Sun people probably just didn't want to reinvent the wheel.
If I use any gpl'ed code in my software, I HAVE to distribute the sources with the binaries.
Accepting the GPL is not required, but accepting the GPL is the easiest way to obtain th e right to redistribute other's GPL work.
If you don't accept the GPL, well, you could always obtain that rights by other means (i.e. asking the authors, perhaphs paying them).
But in the end, if you don't obtain the rights (by accepting the GPL or by other means), you can't redistribute. If you do so anyway, it's copyright infringiment.
Re:Make that "old skool BSD license"
on
Ghost for Unix
·
· Score: 2
Addenda: to furtherly demonstrate how silly that clause is, I'd also want to point out that while Mr. Huber Freyer requires his acknowledgement to be displayed in all advertising material, he is not displaying anywhere in his page the required acknowledgement (as the NetBSD license still requires) regarding the University of California, but simply tells his software is based on NetBSD.
Now: is he giving due credit? Yes. Is he doing it in the form required by the NetBSD license? No. Is that clause silly? Yes.
Re:Make that "old skool BSD license"
on
Ghost for Unix
·
· Score: 2
This ain't a troll or funny. Its fucking sarcasm.
If the FreeBSD team didn't decide to change licencing, every single advertisement (including banners, for example) of FreeBSD would have to exhaustively elencate all of the contributors, thus making any sort of advertisement pratically impossibile.
Mr. Huber Freyer can get away advertising his work without much hassle exactly because he doesn't have also to list all FreeBSD contributors (since they changed their mind).
Requiring due credit is fine. Pretending to have your name to be written even on your distributor's underwear is definitively too much, and this is what the old advertising clause basically asks for.
Wow. That's so easy! I can see why OS X is the number one selling Unix
<sarcasm> Of course: if something doesn't work out of the box in OS X, you have nothing to do but wait for the next release (and buy it)...
</sarcasm>
And of course, everything has to work out of the box on MacOS X, since it would pretty lame for a company that gets to decide what hardware has to be put inside its machines.
And of course, everything works out of the box on a Linux distribution if you stick to the supported hardware, which is what you should do in the first place like when you bought an Apple with OS X.
The point on MacOS X is that you can't choose non-Apple-sanctioned hardware and expect the clicky-pointy things to work.
Do you remember the times of the non-Apple clones? (i.e. Umax ones). Remember how MacOS wasn't guaranteed to run very well on these?
Uhm, perhaps there could be subtle issues on how various JVM implementations handle floating point math, despite of the Java specifications? I'd say that when you're doing distributed computing, you don't want to end comparing apples and oranges.
Have you ever actually tried to decode a binary file without the data definition?
Yes, in fact I said it would be easier (even for Microsoft) to
handle an XML-based format instead of a binary-only format.
But then, let's look on how Microsoft Word exports HTML: in order
to avoid loosing information in the conversion process (so you can
open your exported HTML with Word and have exactly your document
again), the generated HTML is full of special comments and
Word-only CSS properties expressing the information from the
original document that can't be directly mapped into HTML.
So, as of today, good or bad, here we already have a purely textual
representation of a Microsoft Word document with well-defined data
boundaries. It is still easier to reverse engineer than the pure
binary format, but IMHO still leaves several obscure points behind.
What I'm arguing is that the XML representation Microsoft is going
to adopt, given the precedents of that company, wouldn't be that
much better than this "rich HTML" WRT precisely understanding its
meaning, and that Microsoft isn't really interested in gaining real
interoperability as much as throwing buzzwords at the audience.
But then, if this XML-based format is not going to be the default,
I agree that this whole discussion is pointless.
WTF!? XML shouldn't need to be documented. The whole point is to
create a human readable file that is parseble by computer. If MS Word
delivers an XML file that I can't figure out, it's not XML.
Uhm, it is also the point of source files in the programming language of
your choice, I'd say... and still, you need good comments.
I'm guessing their XML document format will be just as hard to decyper and the current office formats.
There are 2 problems with the current format of Microsoft Office file:
Give the correct interpretation to the bytes representing the
document content, in order to import the Office document in some
other office suite using a different representation.
This is mostly solved (thanks to years of trials and errors).
Give the correct interpretation to the bytes representing the
document itself AND all the extra cruft having nothing to
do with the document contents that the Microsoft Office suite puts
in, in order to generate documents readable by the various
versions of the Office suite.
This is definitively more difficult, as nobody knows Office
internals and how they expect such additional data to
be. StarOffice guys managed to make an acceptable job, at the
price of years of trials and errors. It's like watching at a dump
of your computer's memory, guesssing what's code, what's data,
what's padding and the meaning of every byte...
Now, do an XML format simplifies things? Well, yes, just as an RTF
text is easier to manage than a pure binary format, but nothing
prevents putting extra cruft in an XML document, so it's just that
instead of having to use a hex editor, you now may use a text
editor, but giving a correct interpretation of tags and attributes
is something that only Microsoft can do, unless it publishes the
full specifications (present and future: after all, XML is
eXtendible, right?)
Personally, I think that:
Microsoft is realizing that the current Office formats are getting
out of control, so it wants to get rid of them, because mantaining
backwards compatibility is becoming too much painful.
An XML-based format may be the right answer for Microsoft, in that all
the subtles of parsing binary data simply disappear, while it may
still make difficult to everyone else to understand what's the
real meaning of data. Let's say <obscuretag_42 foobarizer="xyzzy"/>
Microsoft was not giving out the specifications of the formats of
its Office suite before: should we now suppose it's giving out the
DTD/Schema AND a good explanation of how to interpret it? I'd hope the
answer is yes, but giving the company's precedents...
Well, the fact it supports Windows and MacOS doesn't necessarily mean it won't work on Linux.
Being a CD-RW, it probably just talks SCSI over USB when writing,
and probably shows up itself as a SCSI-over-USB cd reader (or as a
Mass Storage unit) when reading. IIRC, there is good support for both
on Linux (unless the firmware is broken). OTOH, IEEE1394 would have
been a better choice than USB2.0, IMHO (at least, IEEE1394 has been
out for more time).
The 2D prepress industry is probably many times larger than 3D... Why don't we have better software?
Probably because there a lot more programmers and itches to be scratched in the 3D industry than in the 2D industry? After all, it was the 3D industry to put together Film Gimp (The Gimp modified to handle 16 bits per channel).
In order to have good programs, well, you also need programmers with a good experience in the field (something that I'd believe is quite rare in the 2D prepress industry, regardless of the huge userbase).
don't you think Linux is concise and catchy? Why can't RMS be content
Beware of the non-GNU/Linux systems that will come (and they
will come, sooner or later).
RMS (and the FSF) has a goal, which is to promote Free Software and
to avoid further confusion about its nature (the adoption of the word
"free" has already been an endless source of confusion). As of now,
you can take a Linux distribution at random and be quite sure it uses
the GNU tools. But what about tomorrow? It will still be "Linux", but
not necessarily "GNU".
If Stallman was really smart, he would try using some diplomacy to
convince people rather than alienating everyone and causing a flame
war to erupt every time he opens his mouth.
ESR tried to do this to promote CML2, to the point of describing
himself as a "social hacker", and failed miserabily precisely for that
reason.
OTOH, I'm believing that Stallman is really smarter than it
looks at playing such games... he simply doesn't care too much
about his personal reputation as someone else does.
He knows that with just a couple
of hard statements from time to time, he can touch the sensibility
of a lot of people at once and bring attention to an issue, no matter
if half of them considers him gone nuts.
A Patent should last for twice the length of time it would take an
'expert' to perform research that would produce the same effect.
And how would you determine how much it would take for an expert to
come up with the same results?
Since the object of the patent has to be, by definition, nonobvious
and without prior art, how could one esteem how long it would take
to an "expert" to perform a research which would lead to equivalent
results? Esteems are based on previous experience...
And how much resources (read: money, which can greatly speed up
things) should be available to the "expert" to perform such ideal
research and accomplish equivalent results?
Hint: the only way is to ask the patent applicant himself, and
trust him.
The "ego factor" is the same reason we have 5 different office products all working on seperate import / export filters for MS Office, when the effort should be combined.
To be honest, that's the wrong example: if there was just one codebase for this, it would be too easy for Microsoft to break it hard, i.e. by changing their formats in a way that requires a complete redesign from scratch of the code of the filter. Past experience proves that Microsoft is expecially good at breaking hard other's designs.
OTOH, by having multiple implementations, there is a chance that at least one of them fits well within the new scheme, and can be easily expanded to handle the new format, thus plugging the hole while other implementations catch up.
To some degree, this is applicable even to the Gnome/KDE, Emacs/Vi(m), GNU Emacs/XEmacs etc. situations: if something is discovered which greatly improves their usability, there is a chance that at least in one of them it is easy to implement, so it may seem the light, and others will start to catch up. Lots of features were added to projects just because the "other implementations" had them and it seemed a good idea...
Would Mozilla have tabbed browsing, mouse gestures and several other useful things if the only other browser out there was IE (instead of Opera and Galeon)? I'd dare to say yes, but not here and now.
Briefly said, "monocoltures" are not always a good idea.
...and a dozen or so of language-specific programming modes (with syntax highlinghting, auto-indentation, etc.).
Plus, creating your own elisp code to do whatever you want (not just silly keyboard macros) is quite simple, and there are already tons of useful snippets and code examples out there. This can hardly be said for other editors, except for Vim and JEdit (which I personally consider on par with Emacs, except it requires more resources to run).
I can't speak for Vim, since I use it just occasionally, but I'm confident that it provides equivalent functionalities.
Slashdot Mirror
As has been stated several times, the name is X Window System, and as you can easily read doing a man X:
If the people call it X-Windows or XWindows anyways, that's not a problem of the X Consortium.
BTW, the (unofficial) term X Windows appears everywhere in the GNU documentation (problems using trademarks in GNU documents?)
People not understanding what the X Window System is just try to reinvent it with a different name and incompatible API.
Hint: if you don't like the Xlib API, well, you should realize that the X Window System is mainly a protocol specification. Xlib is just that, a library that speaks X protocol, and it happens to be the one that comes with every X implementation, but for God's sake nothing prevents to implement another one. If Sam Lantinga (SDL main author) wanted, he could extend SDL just to speak direcly X protocol, without using Xlib at all (but that would be stupid, since Xlib isn't that ugly).
Now, projects like DirectFB have their place for special applications (embedded devices), but for everyone else, <whatever>-on-X (<whatever> being Display PostScript, Display PDF, GTK+, Qt, Motif, SDL, Berlin, etc.) is the only reasonable answer, at least for the large range of supported hardware (don't limit yourself to XFree86, but think also of all the UNIX and OpenVMS systems out there having their own implementation of the X Window System).
No, that would be just too intrusive. Instead, I'm guessing that we'll see more of
Just like ads in magazines, or commercials on TV.
...ad banners CHASE your mouse pointer!
I wonder if this commitment to Gnome from Sun could also be considered some sort of admission that Swing, despite years of research and development, is not (yet?) that adeguate to make a desktop environment.
But then, Sun people probably just didn't want to reinvent the wheel.
Moderators, moderate parent post up. He's got it right.
Accepting the GPL is not required, but accepting the GPL is the easiest way to obtain th e right to redistribute other's GPL work.
If you don't accept the GPL, well, you could always obtain that rights by other means (i.e. asking the authors, perhaphs paying them).
But in the end, if you don't obtain the rights (by accepting the GPL or by other means), you can't redistribute. If you do so anyway, it's copyright infringiment.
handles also SVG.
Basically, little hope.
Addenda: to furtherly demonstrate how silly that clause is, I'd also want to point out that while Mr. Huber Freyer requires his acknowledgement to be displayed in all advertising material, he is not displaying anywhere in his page the required acknowledgement (as the NetBSD license still requires) regarding the University of California, but simply tells his software is based on NetBSD.
Now: is he giving due credit? Yes. Is he doing it in the form required by the NetBSD license? No. Is that clause silly? Yes.
If the FreeBSD team didn't decide to change licencing, every single advertisement (including banners, for example) of FreeBSD would have to exhaustively elencate all of the contributors, thus making any sort of advertisement pratically impossibile.
Mr. Huber Freyer can get away advertising his work without much hassle exactly because he doesn't have also to list all FreeBSD contributors (since they changed their mind).
Requiring due credit is fine. Pretending to have your name to be written even on your distributor's underwear is definitively too much, and this is what the old advertising clause basically asks for.
<sarcasm>
Of course: if something doesn't work out of the box in OS X, you have nothing to do but wait for the next release (and buy it)...
</sarcasm>
And of course, everything has to work out of the box on MacOS X, since it would pretty lame for a company that gets to decide what hardware has to be put inside its machines.
And of course, everything works out of the box on a Linux distribution if you stick to the supported hardware, which is what you should do in the first place like when you bought an Apple with OS X.
The point on MacOS X is that you can't choose non-Apple-sanctioned hardware and expect the clicky-pointy things to work.
Do you remember the times of the non-Apple clones? (i.e. Umax ones). Remember how MacOS wasn't guaranteed to run very well on these?
Uhm, perhaps there could be subtle issues on how various JVM implementations handle floating point math, despite of the Java specifications? I'd say that when you're doing distributed computing, you don't want to end comparing apples and oranges.
A quick search on Google comes up with something interesting on the subject (which of course may be true or not).
Well, to be honest, you should include also:
These can't be deduced by looking at the hardware.
Yes, in fact I said it would be easier (even for Microsoft) to handle an XML-based format instead of a binary-only format.
But then, let's look on how Microsoft Word exports HTML: in order to avoid loosing information in the conversion process (so you can open your exported HTML with Word and have exactly your document again), the generated HTML is full of special comments and Word-only CSS properties expressing the information from the original document that can't be directly mapped into HTML.
So, as of today, good or bad, here we already have a purely textual representation of a Microsoft Word document with well-defined data boundaries. It is still easier to reverse engineer than the pure binary format, but IMHO still leaves several obscure points behind.
What I'm arguing is that the XML representation Microsoft is going to adopt, given the precedents of that company, wouldn't be that much better than this "rich HTML" WRT precisely understanding its meaning, and that Microsoft isn't really interested in gaining real interoperability as much as throwing buzzwords at the audience.
But then, if this XML-based format is not going to be the default, I agree that this whole discussion is pointless.
Uhm, it is also the point of source files in the programming language of your choice, I'd say... and still, you need good comments.
XML is like Lisp, but with sharp parenthesis.
There are 2 problems with the current format of Microsoft Office file:
This is mostly solved (thanks to years of trials and errors).
This is definitively more difficult, as nobody knows Office internals and how they expect such additional data to be. StarOffice guys managed to make an acceptable job, at the price of years of trials and errors. It's like watching at a dump of your computer's memory, guesssing what's code, what's data, what's padding and the meaning of every byte...
Now, do an XML format simplifies things? Well, yes, just as an RTF text is easier to manage than a pure binary format, but nothing prevents putting extra cruft in an XML document, so it's just that instead of having to use a hex editor, you now may use a text editor, but giving a correct interpretation of tags and attributes is something that only Microsoft can do, unless it publishes the full specifications (present and future: after all, XML is eXtendible, right?)
Personally, I think that:
Well, the fact it supports Windows and MacOS doesn't necessarily mean it won't work on Linux.
Being a CD-RW, it probably just talks SCSI over USB when writing, and probably shows up itself as a SCSI-over-USB cd reader (or as a Mass Storage unit) when reading. IIRC, there is good support for both on Linux (unless the firmware is broken). OTOH, IEEE1394 would have been a better choice than USB2.0, IMHO (at least, IEEE1394 has been out for more time).
Probably because there a lot more programmers and itches to be scratched in the 3D industry than in the 2D industry? After all, it was the 3D industry to put together Film Gimp (The Gimp modified to handle 16 bits per channel).
In order to have good programs, well, you also need programmers with a good experience in the field (something that I'd believe is quite rare in the 2D prepress industry, regardless of the huge userbase).
Beware of the non-GNU/Linux systems that will come (and they will come, sooner or later).
RMS (and the FSF) has a goal, which is to promote Free Software and to avoid further confusion about its nature (the adoption of the word "free" has already been an endless source of confusion). As of now, you can take a Linux distribution at random and be quite sure it uses the GNU tools. But what about tomorrow? It will still be "Linux", but not necessarily "GNU".
ESR tried to do this to promote CML2, to the point of describing himself as a "social hacker", and failed miserabily precisely for that reason.
OTOH, I'm believing that Stallman is really smarter than it looks at playing such games... he simply doesn't care too much about his personal reputation as someone else does. He knows that with just a couple of hard statements from time to time, he can touch the sensibility of a lot of people at once and bring attention to an issue, no matter if half of them considers him gone nuts.
And how would you determine how much it would take for an expert to come up with the same results?
Since the object of the patent has to be, by definition, nonobvious and without prior art, how could one esteem how long it would take to an "expert" to perform a research which would lead to equivalent results? Esteems are based on previous experience...
And how much resources (read: money, which can greatly speed up things) should be available to the "expert" to perform such ideal research and accomplish equivalent results?
Hint: the only way is to ask the patent applicant himself, and trust him.
Briefly said, it is The Gimp modified to handle 16 bit per channel.
To be honest, that's the wrong example: if there was just one codebase for this, it would be too easy for Microsoft to break it hard, i.e. by changing their formats in a way that requires a complete redesign from scratch of the code of the filter. Past experience proves that Microsoft is expecially good at breaking hard other's designs.
OTOH, by having multiple implementations, there is a chance that at least one of them fits well within the new scheme, and can be easily expanded to handle the new format, thus plugging the hole while other implementations catch up.
To some degree, this is applicable even to the Gnome/KDE, Emacs/Vi(m), GNU Emacs/XEmacs etc. situations: if something is discovered which greatly improves their usability, there is a chance that at least in one of them it is easy to implement, so it may seem the light, and others will start to catch up. Lots of features were added to projects just because the "other implementations" had them and it seemed a good idea...
Would Mozilla have tabbed browsing, mouse gestures and several other useful things if the only other browser out there was IE (instead of Opera and Galeon)? I'd dare to say yes, but not here and now.
Briefly said, "monocoltures" are not always a good idea.
It has already been done, at least for Emacs. Have a look at the OO-Browser and JDEE, plus all that comes with GNU Emacs like:
Plus, creating your own elisp code to do whatever you want (not just silly keyboard macros) is quite simple, and there are already tons of useful snippets and code examples out there. This can hardly be said for other editors, except for Vim and JEdit (which I personally consider on par with Emacs, except it requires more resources to run).
I can't speak for Vim, since I use it just occasionally, but I'm confident that it provides equivalent functionalities.