Erm, last I read that was VP of 'Novell Ximian Services'.
I'm sorry Nat, but while I don't know if this story is true or not, I don't think a comment from you is likely to help. You said a lot when the SuSE Novell merger started which turned out to be rubbish so how can anyone trust you to do more than push your own position now?
I think that the ease and speed with which a cid2spf converter has been written is good illustration of the advantages of an XML based format. I wonder how long it would take to write a converter that goes the other way for comparison.
Actually in most configurations this could be detected by looking at the returned packets. The firewall protecting the network would generally block all the ports except those involved in the 'knocking' so these would return nothing (assuming a drop rule is in place), the closed ports could then be detected by observing the RST packet sent when they are probed. This could be trivially done with nmap. The other likely configuration is that firewall shows all unused ports as closed, in this case you can detect which ones were closed by the firewall and which ones were closed by the machine behind it by the difference in the TTL field of the returned packet.
The one situation where this technique could work is where a host is directly on the network and has no firewall. A very bad idea.
This comment is so ass-backwards as to be virtually buried in it's own behind. KDE used an existing toolkit -Qt, while Gnome decided try to make a new one based on the custom widgets used by a single app (Gimp). KDE is build on a component model where everything is a KPart and most apps result from combining them. Very few Gnome apps are Bonobo enabled. Why do people persist in making such fundamental mistakes? I would suggest it is because they haven't actually bothered to do anything as 'complicated' as build the systems and try them.
If people on slashdot want to be taken seriously they really ought to make use of the freedom they are given and actually use some of the source code we donate.
You've misunderstood the integration work. The effect is in fact the total opposite. The work means they can use KDE for most things and cherry pick any apps they want from Ximian and they will integrate nicely into the desktop. That said, we (KDE) aren't standing still, so the number of apps they choose to do this for is likely to me small.
You're the second person so suggest that, I haven't had a chance to look at it yet. For now the doxygen solution works nicely and has the advantage of understanding signals and slots.
1. The kjsembed library provides access to the existing objects with no (repeat *no*) need for the host app to write any extra code. ie. it can extend apps that were not intended to support this stuff (though obviously it is better if they are).
2. A huge proportion of kde apps already link kjs via either khtml or via kdeinit. This adds no extra overhead (rather than a large python interpreter).
3. We would have huge version skew problems because the distros (and users) would immediately rip out the chosen version of python and link the code against their default installed one. This would lead to impossible to track down bugs.
4. Most of the stuff that people use from the python libs is already available from the kde libs. By providing bindings to those we get better integration with things like cookies, cache handling etc. as well as a very low overhead in terms of type conversions.
I do a similar thing. I've developed a tool that uses doxygen to generate XML descriptions of the code, then xslt to create a binding to JS. This isn't 100% automated yet, but I was able to bind a fairly complex class (QDir) in about 20 minutes. This includes all the enumerations and default argument support.
I've been working on a system for embedding JS in KDE apps (amongst other reasons it is a about 1/10 the size of a python interpreter). You can find lots of information at http://xmelegance.org/kjsembed. The interpreter in KDE has no dependency on KDE/Qt or anything else so you might find it usable in your app.
I don't really accept this argument because there is no reason why you could not use the same stream to transmit multiple documents. You are correct that you can only have one root node per document but I'm not aware of anything in the XML specs that even discusses the transmition medium beyond discussing the encoding.
For the record - I think XML is a good choice, but I think Jabber throws away many of the advantages that you can gain by using it.
Yes, but a well designed XML-based protocol wouldn't need you to mess about like that. You can work around these things, but there's no reason why should have to. Using SAX is still a problem if you use a validating parser (it's true you can use it if you disable validation).
One of the problems with Jabber is that it isn't really a very good protocol. The fact that it doesn't close the outer tags until the end of a session makes it impossible to implement efficiently using the standard XML tools (the memory requirements are ridiculous).
If you want to make a standard XML format for chat, then first thing to do is look at where Jabber went wrong and start again.
I find Linus' comment about visual basic very interesting. We're dealing with the issue of how to make it easy for people to put together the same kind of bespoke application with tools like kjsembed. This lets you write applications using Javascript - you have access to things like KDE's DB support, XMLGUI facilities and UIs created with Qt Designer. Maybe after a couple more release cycles that could become a 'killer app' for linux.
I can make my Apache instance respond with anything, for e.g. "saqib webserver ver. 9.0"
Unfortunately I can then come along and run hmap to detect what it really is using finger printing techniques. Concealing server names and versions gives only a very small increase in security and can make management of multiple servers harder (as it's more difficult to check you patched everything).
Rich.
> the Mozilla project always intended to release a full application suite including web browser, email client and web page editor
Even implementing all 3, I think the same argument holds.
> Maybe, but Mozilla needed a toolkit anyway for web forms/content since existing toolkits didn't support the stylability required by the W3C standards.
We've implemented the stylability in Qt. I don't see that doing so in other toolkits would be a problem.
The key word in your comment is 'browser' that is what the mozilla project seemed to set out to write. I suspect that if the project had reused existing toolkits etc. it could have got there much more quickly.
I don't see that I'm forgetting that - I'm saying that I think if they'd focussed on the core aim of the project (a browser) they could have achieved it better, quicker and at far less cost.
I don't agree that much needs to be spent on marketing. Mozilla will have a large public profile for a long time to come. I however can't see that it can really be a serious contender to MSIE on windows though for the forseable future unless MS drop the ball and a DR-DOS style resurrection is possible. The trouble is that for now, the door there is closed for a few years at least.
Err, and we also made kmail, quanta, kdelibs... your examples just seem to me to be a list of exactly where the mozilla project went wrong.
If the mozilla project had written gecko then written nice wrapper UIs for each platform then they would have had a chance to succeed. I think they lost focus and as a result shot themselves in the foot.
I have to say, I find it rather surprising that Mozilla should need 2 million dollars to write a brower, and even more surprising that they're asking for people to donate even more. The mozilla project has had more full time developers than we've ever had working on KDE, yet konqueror is not far behind (oh, and we did write a desktop too...).
If the mozilla foundantion would like to sponser the forthcoming KDE conference (eg. to discuss how we could make use of any reusable parts of their code base) I'm sure they'd be most welcome.
> On good example is konqueror and its > identification of file type through filename's > suffix.
All this example shows is that you don't know what you're talking about. Konqueror uses magic based system with the extensiong only being used if no other information is available.
Just a note Qt/Embedded is GPL too, this is why you'll find a (fully compatible) branch of it on sourceforge developed by some guys who wanted to add some new features of their own.
Just to clarify, I'm not saying we won't release 3.2. Just that as per coolo's comment (for those who read the article) it may be 4.0 if we find we need to break compatibility to do the job properly. There are a lot of pretty cool things to be discussed at the forthcoming developer's conference and if we decide they should be in the next release (possible but not probable) this may be a good idea. Either way - it got you to read the article, didn't it!
Slashdot Mirror
Nat Friedman
Novell/SUSE Linux Desktop Lead
Erm, last I read that was VP of 'Novell Ximian Services'.
I'm sorry Nat, but while I don't know if this story is true or not, I don't think a comment from you is likely to help. You said a lot when the SuSE Novell merger started which turned out to be rubbish so how can anyone trust you to do more than push your own position now?
Rich.
Two things:
1. Most distros patch holes in existing versions but do not change the version numbers.
2. The OpenSSL holes recently were a null pointer dereferrence and a DoS - neither would lead to a compromise.
If there are 2 of these boxes, then a spoofed attack that sets them against each would kill both. I suspect the drawing board needs revisiting.
I think that the ease and speed with which a cid2spf converter has been written is good illustration of the advantages of an XML based format. I wonder how long it would take to write a converter that goes the other way for comparison.
Actually in most configurations this could be detected by looking at the returned packets. The firewall protecting the network would generally block all the ports except those involved in the 'knocking' so these would return nothing (assuming a drop rule is in place), the closed ports could then be detected by observing the RST packet sent when they are probed. This could be trivially done with nmap. The other likely configuration is that firewall shows all unused ports as closed, in this case you can detect which ones were closed by the firewall and which ones were closed by the machine behind it by the difference in the TTL field of the returned packet.
The one situation where this technique could work is where a host is directly on the network and has no firewall. A very bad idea.
This comment is so ass-backwards as to be virtually buried in it's own behind. KDE used an existing toolkit -Qt, while Gnome decided try to make a new one based on the custom widgets used by a single app (Gimp). KDE is build on a component model where everything is a KPart and most apps result from combining them. Very few Gnome apps are Bonobo enabled. Why do people persist in making such fundamental mistakes? I would suggest it is because they haven't actually bothered to do anything as 'complicated' as build the systems and try them.
If people on slashdot want to be taken seriously they really ought to make use of the freedom they are given and actually use some of the source code we donate.
You've misunderstood the integration work. The effect is in fact the total opposite. The work means they can use KDE for most things and cherry pick any apps they want from Ximian and they will integrate nicely into the desktop. That said, we (KDE) aren't standing still, so the number of apps they choose to do this for is likely to me small.
You're the second person so suggest that, I haven't had a chance to look at it yet. For now the doxygen solution works nicely and has the advantage of understanding signals and slots.
Rich.
There are a number of problems with that:
1. The kjsembed library provides access to the existing objects with no (repeat *no*) need for the host app to write any extra code. ie. it can extend apps that were not intended to support this stuff (though obviously it is better if they are).
2. A huge proportion of kde apps already link kjs via either khtml or via kdeinit. This adds no extra overhead (rather than a large python interpreter).
3. We would have huge version skew problems because the distros (and users) would immediately rip out the chosen version of python and link the code against their default installed one. This would lead to impossible to track down bugs.
4. Most of the stuff that people use from the python libs is already available from the kde libs. By providing bindings to those we get better integration with things like cookies, cache handling etc. as well as a very low overhead in terms of type conversions.
Cheers
Rich.
I do a similar thing. I've developed a tool that uses doxygen to generate XML descriptions of the code, then xslt to create a binding to JS. This isn't 100% automated yet, but I was able to bind a fairly complex class (QDir) in about 20 minutes. This includes all the enumerations and default argument support.
Rich.
I've been working on a system for embedding JS in KDE apps (amongst other reasons it is a about 1/10 the size of a python interpreter). You can find lots of information at http://xmelegance.org/kjsembed. The interpreter in KDE has no dependency on KDE/Qt or anything else so you might find it usable in your app.
I don't really accept this argument because there is no reason why you could not use the same stream to transmit multiple documents. You are correct that you can only have one root node per document but I'm not aware of anything in the XML specs that even discusses the transmition medium beyond discussing the encoding.
For the record - I think XML is a good choice, but I think Jabber throws away many of the advantages that you can gain by using it.
Yes, but a well designed XML-based protocol wouldn't need you to mess about like that. You can work around these things, but there's no reason why should have to. Using SAX is still a problem if you use a validating parser (it's true you can use it if you disable validation).
Rich.
One of the problems with Jabber is that it isn't really a very good protocol. The fact that it doesn't close the outer tags until the end of a session makes it impossible to implement efficiently using the standard XML tools (the memory requirements are ridiculous).
If you want to make a standard XML format for chat, then first thing to do is look at where Jabber went wrong and start again.
I find Linus' comment about visual basic very interesting. We're dealing with the issue of how to make it easy for people to put together the same kind of bespoke application with tools like kjsembed. This lets you write applications using Javascript - you have access to things like KDE's DB support, XMLGUI facilities and UIs created with Qt Designer. Maybe after a couple more release cycles that could become a 'killer app' for linux.
Unfortunately I can then come along and run hmap to detect what it really is using finger printing techniques. Concealing server names and versions gives only a very small increase in security and can make management of multiple servers harder (as it's more difficult to check you patched everything). Rich.
I'm genuinely interested in why you think it is a problem to do this with the proprietary toolkits. What do you see as the issues?
Rich.
> the Mozilla project always intended to release a full application suite including web browser, email client and web page editor
Even implementing all 3, I think the same argument holds.
> Maybe, but Mozilla needed a toolkit anyway for web forms/content since existing toolkits didn't support the stylability required by the W3C standards.
We've implemented the stylability in Qt. I don't see that doing so in other toolkits would be a problem.
Rich.
The key word in your comment is 'browser' that is what the mozilla project seemed to set out to write. I suspect that if the project had reused existing toolkits etc. it could have got there much more quickly.
Rich.
I don't see that I'm forgetting that - I'm saying that I think if they'd focussed on the core aim of the project (a browser) they could have achieved it better, quicker and at far less cost.
I don't agree that much needs to be spent on marketing. Mozilla will have a large public profile for a long time to come. I however can't see that it can really be a serious contender to MSIE on windows though for the forseable future unless MS drop the ball and a DR-DOS style resurrection is possible. The trouble is that for now, the door there is closed for a few years at least.
Rich.
Err, and we also made kmail, quanta, kdelibs... your examples just seem to me to be a list of exactly where the mozilla project went wrong.
If the mozilla project had written gecko then written nice wrapper UIs for each platform then they would have had a chance to succeed. I think they lost focus and as a result shot themselves in the foot.
Rich.
I have to say, I find it rather surprising that Mozilla should need 2 million dollars to write a brower, and even more surprising that they're asking for people to donate even more. The mozilla project has had more full time developers than we've ever had working on KDE, yet konqueror is not far behind (oh, and we did write a desktop too...).
If the mozilla foundantion would like to sponser the forthcoming KDE conference (eg. to discuss how we could make use of any reusable parts of their code base) I'm sure they'd be most welcome.
Rich.
> On good example is konqueror and its
> identification of file type through filename's > suffix.
All this example shows is that you don't know what you're talking about. Konqueror uses magic based system with the extensiong only being used if no other information is available.
Rich.
Just a note Qt/Embedded is GPL too, this is why you'll find a (fully compatible) branch of it on sourceforge developed by some guys who wanted to add some new features of their own.
Rich.
Just to clarify, I'm not saying we won't release 3.2. Just that as per coolo's comment (for those who read the article) it may be 4.0 if we find we need to break compatibility to do the job properly. There are a lot of pretty cool things to be discussed at the forthcoming developer's conference and if we decide they should be in the next release (possible but not probable) this may be a good idea. Either way - it got you to read the article, didn't it!
Rich.