Jabbers groupchat implementation is far less scalable than IRC. Ever seen a jabber chatroom with > 2000 People?
This is because no one uses XMPP/Jabber, not because of any sort of protocol deficiency.
The main difference between Jabber and IRC architecture-wise is that Jabber does not split a room across servers. However, with the way Jabber is designed, you have a lot more servers. IRC has segregated network clusters, while Jabber simply operates by domain over the open internet. With IRC, you have 10000 rooms hosted over 20 servers. With Jabber, you have 1000 Jabber servers, each with 10 rooms. This is a lot more scalable. In addition, "channel takeovers" are less effective under this model, as the rooms are centrally managed at the given domain. An admin could simply shutdown the room until a problem is remedied.
Not to mention that Jabber is also a more advanced system in general. There is no need for a DCC2, as the Jabber file transfer is already very good. There is no need to change your nickname to "Foobar|Away", as in Jabber there is actually an away status. What a concept!
That said, most implementations of XMPP/Jabber are not as mature as existing IRC implementations, so we're a ways off from world domination.
And if many different companies ran IM servers that were all part of the same system, how long before SPIM became rampant?
With XMPP/Jabber, packets are not domain spoofable like in SMTP. This means that XMPP is already as effective on spam as a basic email challenge/response system like TMDA, but without any of the drawbacks since it is built-in.
And with clients like gaim and trillian, why does this matter to anyone except the competitors?
Since AOL's AIM network has no server-to-server bridge, the only way to talk to AIM users is to actually log in as a client to the AIM network, using an AIM account, which is ridiculous. Logging into multiple services from the same client does not change this. It gives a false sense of bridging between networks. In the meantime, you have to worry that these companies might try to break your IM client.
Also, I don't think "competitors" is the right term. Sure, there might be businesses that want to compete against AOL in the IM space, but I think the majority of those that would run IM servers are _users_. I run a personal Jabber server at andbit.net for about 10 people. Universities and businesses are gradually switching to XMPP/Jabber. We are all users of IM, and we simply want interconnectivity.
The server-side is more important than the client-side. This move to allow IMAP access to AOL subscribers is nice, but since I'm not an AOL subscriber, it makes no difference to me. The move that did matter is when AOL started using SMTP, some 10 years ago.
The same should go for AIM. All we need is for AOL to open up their server-side to XMPP. This way non-AIM/AOL subscribers would be able to talk to AIM/AOL subscribers, as life should be. Being able to use alternate clients to connect to AIM is a completely different matter, and is much less important. Let them keep using OSCAR for clients, just as they used a proprietary email client for so long.
- The number of spams your system has sent in response to forged "From" addresses?
This is unfortunate, but it is also expected behavior of a C/R system, so it is unfair to say that sending these mails constitutes not working well. I've received emails from mailing list software about my subscription status, due to a spammer sending a forged email to a list server. Does this mean we should disable all automated systems? What if I want to reply to the spammer to tell him to quit emailing me, and instead this reply goes to some innocent individual who had his address forged? I say the innocent individual just needs to get some filters too.
- The number of real emails you've missed, because the sender doesn't feel like jumping through the hoops you've put in place?
When I installed TMDA, I watched the "pending" folder for 6 months, to ensure that everybody confirmed their mail. And they do. Authentication is to be expected these days. You have to confirm mailing list subscriptions. You have to be granted authorization on IM (Jabber). Why should email between individuals be any different?
Re:the first one makes it difficult
on
A Taste of Qt 4
·
· Score: 1
If a developer got a Qt/Win commercial license, can he/shethen compile an open source program and distribute the binary? I checked the license agreement for Qt/Win and didn't find anything about that...
Yes, this is allowed. Back when Qt/Mac was still non-free, I found a commercial user on the qt-interest mailinglist to maintain my Mac port. Just ensure that the person doing the compiling has the necessary rights to do so. For GPL projects, this generally means amending the license to allow linking to the commercial edition of Qt (see this question in the GPL FAQ for more information).
Re:the first one makes it difficult
on
A Taste of Qt 4
·
· Score: 3, Insightful
Yes, this is an unfortunate problem. The main reason there is no GPL version for Windows is that 99% of all software developed is in-house, and the GPL would allow in-house development without needing a commercial license (this would seriously eat into Trolltech's income). The company has tried in the past to release a "non-commercial" edition, which was closed source, but free to use, provided it was not for commercial purposes. Unfortunately this was abused by organizations who used it for commercial purposes anyway.
I should mention that the Psi project receives Qt/Windows for free. Trolltech gave us several commercial licenses, including endless support and upgrades, provided that we only use it for open source work. I'm not sure how practical it is for all free cross-platform projects to establish a trusting relationship with Trolltech in order to use Qt/Windows, but it might be a solution...
Re:Yeah, BUT....
on
A Taste of Qt 4
·
· Score: 4, Insightful
1) No GPL version for the Windows platform. As much as people in the Open Source community might hate MS, many (most) Open Source packages are cross-platform where Windows is a platform.
A port of the GPL'd Qt/X11 to Windows can be found here. Remember, there was a time when Gtk didn't run anywhere but X11 either, yet hobbyists managed to port it. Qt is arguably much easier to port, as it was designed this way, and Trolltech has already proven it with their own proprietary version.
2) A non GPL version of the library costs an outrageous sum of money. Sure Trolltech wants to make money, but lower the costs a bit.
Honestly, I'm not sure how Trolltech can afford to pay all of their programmers a decent wage by simply selling a developer tool (which by definition is a bit of a niche market), even at such a high price. They must sell a heap of licenses... I'm no business major, but I think that Qt has to be expensive if we want Trolltech in business (and we do, Linux on the desktop wouldn't be where it is today without 'em).
3) Why compete against Java? Somebody who uses Java is not going to switch to Qt as Java is still simpler. To me C++ != Java, and I am not saying one is better or worse than the other.
Ahh, but maybe Qt can keep a C++ user from switching to Java? I learned Qt before I learned Java, and during my study of the latter I kept thinking how much it was like Qt. At this stage, if something cool is possible in Java, I'd like to see it also possible in Qt/C++ (assuming such a feature would make sense in that context).
Qt is almost a like a language
on
A Taste of Qt 4
·
· Score: 5, Informative
In the Linux world, Qt is often thought of as just a GUI toolkit. After all, there is no look-and-feel standard in the X11 environment, and by default Qt and Gtk look much different. Therefore, most look-and-feel decisions on the X11 platform amount to selecting between the toolkits. Consider PyQt, which provides GUI support to python via Qt, but nothing more.
What people don't realize is that Qt is actually a massive foundational library, similar in nature to Java's, for C++. It is a very large API, with threading, network, XML, objects, container classes, string handling, unicode, etc. The 'moc' tool even brings extra features to C++ that normally don't exist. It's almost as if Qt/C++ is a language of its own. GUI is a very small portion of Qt. In fact, of all the Qt code I've ever written, most of it has nothing to do with the GUI. Qt makes C++ actually fun.
I'm very much looking forward to Qt 4. With the plans for advanced threading support and GUI/non-GUI split (similar to how glib and gtk are separated), I can see Qt being very useful for writing cross-platform server applications, a market mostly ruled by Java. The great thing about Qt is that it gives us natively compiled code.
You are correct. However, it should be said that CMDA vs GSM is an apples and oranges comparison. CDMA is a radio protocol. GSM is a full mobile phone standard of which a radio protocol is just one component. GSM is based on TDMA radio technology, which is outdated by now. The positive point of GSM is that it defines the featureset, including voice (with all the trimmings), data/fax, and sms, as well as concepts like the SIM chip (keeps identity and phone separated), and even the audio codec! This ambitious featureset and level of compatibility is what allowed GSM to dominate most of the world. Of course, like most standards, GSM hasn't really changed in the last 10 years (although lately there have been some add-ons, like GPRS).
Even so, GSM has withstood the test of time. Some companies in the USA tried to build their own competing systems (using the same radio protocol, TDMA), but they paled in comparison to GSM. Even many CDMA implementations (ie, Sprint, Verizon) have lagged seriously behind GSM's featureset, despite being based on a better radio protocol. Today, CDMA implementations have surpassed GSM capabilities in many areas (wireless data throughput comes to mind), but until I see Verizon using SIM chips, it is safe to say that GSM isn't going anywhere.
The next generation of mobile technology will simply be improvements to GSM concepts. We'll hopefully continue the trend of network standardization with a solid featureset and a SIM-like identity mechanism, but with an upgraded (CDMA-based) radio protocol.
For general purpose programmming, C++ is often overlooked because it suffers from the same problem as C in this scenario, which is that there isn't really much in the standard library to draw from. C#, Java, Perl, Python, etc, all have lots of "foundation" underneath which allow you to build applications quickly.
However, this is not so much an issue of language as it is of API, and C++ has the language features necessary to build a good API. All that is needed is a good library then, such as the Qt C++ library. With Qt, you get nearly the same foundational API as Java, but with natively compiled code. C++ may not be the end-all be-all of languages (no language can claim this), but it is much more capable than many people think. If you wouldn't touch C/C++ with a 10 foot pole, you haven't tried Qt. You can have your cake (large, well constructed API) and eat it too (native code).
Qt may not be a language, but it does provide some language extensions via the Meta Object Compiler, which brings some nice things to C++. Also, Qt is not just a GUI library, but actually a whole Java-like foundation for C++. It's good stuff.
I'm not necessarily disagreeing with you, I'm just elaborating on what Qt is. It's closer to Java in nature than you might think, and with the upcoming Qt4 I can imagine it becoming quite a competitor.
KDE has been the killer app for Linux on the desktop since forever. It was, and still is, the default desktop environment on the majority of Linux distributions. When you read all these reviews about Linux distros, for the most part they are really reviewing KDE. It's what you see on the screen. To most people, KDE is Linux. Calling it a killer app is an understatement.
One of the tough aspects of popularizing XMPP/Jabber is that no large company has stepped forward to fully deliver it to the end-user. Ideally, AOL, Microsoft, and Yahoo would try to migrate their IM protocols to the standard, but somehow this seems unlikely. If a large company could provide a consumer-level IM client, plus dedicated server, plus whitepages, etc (the whole nine yards), and compete against the other gorillas, maybe this will work.
I'd really like to see this, because the Jabber world really needs it. If we can't convince any of the existing major IM players to adopt Jabber, then we need a new company to enter the ring. But is Google large enough to take them on?
Oh, in that case, I know this one: it's the users' fault for not constantly monitoring the problems discovered in every software package they use and failing to update their systems, right?
I never said anything about users. A little cranky this morning?;-)
Security holes are the fault of the developer. However, more often than not, software has security holes that are fixed in later revisions, and the user will need to update. This need to update cannot be blamed on the user, it is just an unfortunate consequence of typical software development. The solution, of course, lies in the hands of the developers to not release code with holes. This is actually more realistic than you might think, just look at qmail.
Just to clarify, this article is about a problem in Nokia's implementation of Bluetooth, not necessarily a problem in the actual Bluetooth protocol/specification. As an analogy, we hear about security holes in IIS, Apache, OpenSSL, etc, but these do not necessarily indicate problems in the relevant RFC documents. At least, we can hope so...
That sounds about right to me. Obviously, the actual Commercial license text has a lot more to it than two lines, including what I described in my previous post. In any case, this URL doesn't say that you can't sell software developed by the Free edition.
I think you were looking for this page, which states: "The Free Edition licenses do not allow the development or distribution of commercial software." This sounds confusing, but I think it is because the entire Trolltech website seems to confuse Commercial with Closed-source. What I believe they mean is that you can't use the Free edition for Closed-source software, which makes sense and is consistent with the actual license of the Free edition.
It's not the policy of my series to publish proprietary software on the accompanying CD. But there is some Borland stuff and a copy of Windows Qt on the CD. This is due to a mis-communication with my publisher.
This is interesting, because I know that a lot of the book's popularity is due to the fact that it has Qt/Windows 3.2 bundled with it. This is _huge_ for the many developers that want to port modern free Qt programs to Windows. We've been waiting nearly 3 years for this day.
Got a URL? If it really does say that on their website, then there must be some miscommunication with the website developers.
The Free edition is GPL, no strings attached. You can read the included license files.
However, they do have some trickery going on with the Commercial editions. The license for these state that you cannot use them for working on code previously developed with the Free edition. I think the intent here is to prevent a company from developing a large project with the Free edition, and then buying one commercial license to build the final closed-source product.
I have no direct experience with either of these toolkits, but I can draw many comparisons between software that's developed by professionals and software developed by college students wherein the college students made the better product.
I totally agree with you, as I'm a college student and I think I put out some pretty good software;-), but I think in this case the professionals have the better product. As noted in the parent post: if Gtk were technically better than Qt, we'd all be using Gtk and no one would be complainining about the GPL.
To quote the review, it seems that people prefer Qt because they 'like' it. They like the system, the API, the docs, or what have you. Developers that prefer Gtk seem to choose it based either that it is native C ("I don't need no skinking C++!"), or that the license is LGPL. Personally, I don't consider the language argument to be very strong. I used to be a C guy myself, but because of Qt I use C++.
Re:Jabber.org=buggy ... jabber.com=overpriced
on
Enterprise IM?
·
· Score: 1
Just a nitpick:
'Jabber.org' is not buggy, unless you are referring to the website having bugs.:)
You're probably thinking of the 'jabberd' server software, but this is not a product of jabber.org, and it is not the only server software available. Saying "the free Jabber" would make about as much sense as saying "the free HTTP". Remember, Jabber is an open protocol, and anyone is free to implement it. Just as with any other standard protocol, such as email, there are many software solutions (free, commercial, etc) available.
It may be a great idea if a mother is tracking her child. It's not such a great idea if a stalker is doing the same.
People tracking people is a much different matter than providers & callers tracking people. I think you're right about mother vs stalker, but both cases are possible without "GPS in phones". You can already buy GSM/GPS tracking devices, and it would be relatively easy to make one too (Nokia 9290 + Earthmate).
I suppose this technology might make tracking devices for stalkers more accessible, particularly if the phones can be programmed to automatically do their magic (send data to the stalker) without having to connect the phone to an external device. And a phone looks less threatening than a mysterious black box ("hey it's just a phone"). I don't have a counter answer to this, other than that maybe we all just need to get used to it. We already have this problem with software (spyware!), so having it with hardware should not be surprising. As technology advances and devices become more capable, complex, and smaller, we need to be aware of what these things can do when we see them.
I think GPS in phones is a great idea. Aside from the fact that it would make emergency calls much more efficient, it would be handy when using it with a PDA (you'd get both GPS and Network in one peripheral). Having a two-in-one would also simplify tracking-device projects. Don't you think it would be totally nerdy cool to be able to enter an AT command to your phone and get GPS coordinates, or throw it into a NMEA mode?
The issue of providers tracking you is a completely separate problem. As long as the user remains in control (ie, I can choose to allow my phone to transmit GPS information to my provider or caller), then we're fine. Personally I'd have it always set to never allow another party to get my (x,y) unless I was using an emergency call. The rest of the time I'd be using the GPS capability with a local device for my own needs. We just need to ensure that phones don't go "DRM-style", where they are doing things against your will.
Actually, the whole Non-Commercial version was an experiment in making Qt/Windows more accessable to free software developers. It was not intended as a bait-and-switch. Trolltech was very hesitant about releasing their flagship product for free on Windows (probably their biggest source of income), so in mid-2001, around the time Qt 3.0 was in the beta phase, they released a non-commercial version of Qt 2.x for Windows. The plan was that if their sales started to drop (implying that companies were freeloading off of the non-commercial version instead of buying licenses like they were supposed to), then in a few months they would release Qt 3.0, thus obsoleting the non-commercial version. In other words, by timing the release around that of Qt 3.0, they had an 'easy out' to prevent much harm if the move was a mistake.
Well, guess what? It was a mistake. The sales data came in, and indeed they lost a bunch of money. Qt/Non-commercial was effectively dead later that year. I'd say the fact that they were even letting people download it through 2003 was just to be nice. There is very little reason for them to continue hosting a file they never update. Someone else can take over that job now.:)
Slashdot Mirror
Jabbers groupchat implementation is far less scalable than IRC. Ever seen a jabber chatroom with > 2000 People?
This is because no one uses XMPP/Jabber, not because of any sort of protocol deficiency.
The main difference between Jabber and IRC architecture-wise is that Jabber does not split a room across servers. However, with the way Jabber is designed, you have a lot more servers. IRC has segregated network clusters, while Jabber simply operates by domain over the open internet. With IRC, you have 10000 rooms hosted over 20 servers. With Jabber, you have 1000 Jabber servers, each with 10 rooms. This is a lot more scalable. In addition, "channel takeovers" are less effective under this model, as the rooms are centrally managed at the given domain. An admin could simply shutdown the room until a problem is remedied.
Not to mention that Jabber is also a more advanced system in general. There is no need for a DCC2, as the Jabber file transfer is already very good. There is no need to change your nickname to "Foobar|Away", as in Jabber there is actually an away status. What a concept!
That said, most implementations of XMPP/Jabber are not as mature as existing IRC implementations, so we're a ways off from world domination.
And if many different companies ran IM servers that were all part of the same system, how long before SPIM became rampant?
With XMPP/Jabber, packets are not domain spoofable like in SMTP. This means that XMPP is already as effective on spam as a basic email challenge/response system like TMDA, but without any of the drawbacks since it is built-in.
And with clients like gaim and trillian, why does this matter to anyone except the competitors?
Since AOL's AIM network has no server-to-server bridge, the only way to talk to AIM users is to actually log in as a client to the AIM network, using an AIM account, which is ridiculous. Logging into multiple services from the same client does not change this. It gives a false sense of bridging between networks. In the meantime, you have to worry that these companies might try to break your IM client.
Also, I don't think "competitors" is the right term. Sure, there might be businesses that want to compete against AOL in the IM space, but I think the majority of those that would run IM servers are _users_. I run a personal Jabber server at andbit.net for about 10 people. Universities and businesses are gradually switching to XMPP/Jabber. We are all users of IM, and we simply want interconnectivity.
The server-side is more important than the client-side. This move to allow IMAP access to AOL subscribers is nice, but since I'm not an AOL subscriber, it makes no difference to me. The move that did matter is when AOL started using SMTP, some 10 years ago.
The same should go for AIM. All we need is for AOL to open up their server-side to XMPP. This way non-AIM/AOL subscribers would be able to talk to AIM/AOL subscribers, as life should be. Being able to use alternate clients to connect to AIM is a completely different matter, and is much less important. Let them keep using OSCAR for clients, just as they used a proprietary email client for so long.
- The number of spams your system has sent in response to forged "From" addresses?
This is unfortunate, but it is also expected behavior of a C/R system, so it is unfair to say that sending these mails constitutes not working well. I've received emails from mailing list software about my subscription status, due to a spammer sending a forged email to a list server. Does this mean we should disable all automated systems? What if I want to reply to the spammer to tell him to quit emailing me, and instead this reply goes to some innocent individual who had his address forged? I say the innocent individual just needs to get some filters too.
- The number of real emails you've missed, because the sender doesn't feel like jumping through the hoops you've put in place?
When I installed TMDA, I watched the "pending" folder for 6 months, to ensure that everybody confirmed their mail. And they do. Authentication is to be expected these days. You have to confirm mailing list subscriptions. You have to be granted authorization on IM (Jabber). Why should email between individuals be any different?
If a developer got a Qt/Win commercial license, can he/shethen compile an open source program and distribute the binary? I checked the license agreement for Qt/Win and didn't find anything about that...
Yes, this is allowed. Back when Qt/Mac was still non-free, I found a commercial user on the qt-interest mailinglist to maintain my Mac port. Just ensure that the person doing the compiling has the necessary rights to do so. For GPL projects, this generally means amending the license to allow linking to the commercial edition of Qt (see this question in the GPL FAQ for more information).
Yes, this is an unfortunate problem. The main reason there is no GPL version for Windows is that 99% of all software developed is in-house, and the GPL would allow in-house development without needing a commercial license (this would seriously eat into Trolltech's income). The company has tried in the past to release a "non-commercial" edition, which was closed source, but free to use, provided it was not for commercial purposes. Unfortunately this was abused by organizations who used it for commercial purposes anyway.
I should mention that the Psi project receives Qt/Windows for free. Trolltech gave us several commercial licenses, including endless support and upgrades, provided that we only use it for open source work. I'm not sure how practical it is for all free cross-platform projects to establish a trusting relationship with Trolltech in order to use Qt/Windows, but it might be a solution...
1) No GPL version for the Windows platform. As much as people in the Open Source community might hate MS, many (most) Open Source packages are cross-platform where Windows is a platform.
A port of the GPL'd Qt/X11 to Windows can be found here. Remember, there was a time when Gtk didn't run anywhere but X11 either, yet hobbyists managed to port it. Qt is arguably much easier to port, as it was designed this way, and Trolltech has already proven it with their own proprietary version.
2) A non GPL version of the library costs an outrageous sum of money. Sure Trolltech wants to make money, but lower the costs a bit.
Honestly, I'm not sure how Trolltech can afford to pay all of their programmers a decent wage by simply selling a developer tool (which by definition is a bit of a niche market), even at such a high price. They must sell a heap of licenses... I'm no business major, but I think that Qt has to be expensive if we want Trolltech in business (and we do, Linux on the desktop wouldn't be where it is today without 'em).
3) Why compete against Java? Somebody who uses Java is not going to switch to Qt as Java is still simpler. To me C++ != Java, and I am not saying one is better or worse than the other.
Ahh, but maybe Qt can keep a C++ user from switching to Java? I learned Qt before I learned Java, and during my study of the latter I kept thinking how much it was like Qt. At this stage, if something cool is possible in Java, I'd like to see it also possible in Qt/C++ (assuming such a feature would make sense in that context).
In the Linux world, Qt is often thought of as just a GUI toolkit. After all, there is no look-and-feel standard in the X11 environment, and by default Qt and Gtk look much different. Therefore, most look-and-feel decisions on the X11 platform amount to selecting between the toolkits. Consider PyQt, which provides GUI support to python via Qt, but nothing more.
What people don't realize is that Qt is actually a massive foundational library, similar in nature to Java's, for C++. It is a very large API, with threading, network, XML, objects, container classes, string handling, unicode, etc. The 'moc' tool even brings extra features to C++ that normally don't exist. It's almost as if Qt/C++ is a language of its own. GUI is a very small portion of Qt. In fact, of all the Qt code I've ever written, most of it has nothing to do with the GUI. Qt makes C++ actually fun.
I'm very much looking forward to Qt 4. With the plans for advanced threading support and GUI/non-GUI split (similar to how glib and gtk are separated), I can see Qt being very useful for writing cross-platform server applications, a market mostly ruled by Java. The great thing about Qt is that it gives us natively compiled code.
You are correct. However, it should be said that CMDA vs GSM is an apples and oranges comparison. CDMA is a radio protocol. GSM is a full mobile phone standard of which a radio protocol is just one component. GSM is based on TDMA radio technology, which is outdated by now. The positive point of GSM is that it defines the featureset, including voice (with all the trimmings), data/fax, and sms, as well as concepts like the SIM chip (keeps identity and phone separated), and even the audio codec! This ambitious featureset and level of compatibility is what allowed GSM to dominate most of the world. Of course, like most standards, GSM hasn't really changed in the last 10 years (although lately there have been some add-ons, like GPRS).
Even so, GSM has withstood the test of time. Some companies in the USA tried to build their own competing systems (using the same radio protocol, TDMA), but they paled in comparison to GSM. Even many CDMA implementations (ie, Sprint, Verizon) have lagged seriously behind GSM's featureset, despite being based on a better radio protocol. Today, CDMA implementations have surpassed GSM capabilities in many areas (wireless data throughput comes to mind), but until I see Verizon using SIM chips, it is safe to say that GSM isn't going anywhere.
The next generation of mobile technology will simply be improvements to GSM concepts. We'll hopefully continue the trend of network standardization with a solid featureset and a SIM-like identity mechanism, but with an upgraded (CDMA-based) radio protocol.
The closest thing to that besides C is C++.
For general purpose programmming, C++ is often overlooked because it suffers from the same problem as C in this scenario, which is that there isn't really much in the standard library to draw from. C#, Java, Perl, Python, etc, all have lots of "foundation" underneath which allow you to build applications quickly.
However, this is not so much an issue of language as it is of API, and C++ has the language features necessary to build a good API. All that is needed is a good library then, such as the Qt C++ library. With Qt, you get nearly the same foundational API as Java, but with natively compiled code. C++ may not be the end-all be-all of languages (no language can claim this), but it is much more capable than many people think. If you wouldn't touch C/C++ with a 10 foot pole, you haven't tried Qt. You can have your cake (large, well constructed API) and eat it too (native code).
Qt may not be a language, but it does provide some language extensions via the Meta Object Compiler, which brings some nice things to C++. Also, Qt is not just a GUI library, but actually a whole Java-like foundation for C++. It's good stuff.
I'm not necessarily disagreeing with you, I'm just elaborating on what Qt is. It's closer to Java in nature than you might think, and with the upcoming Qt4 I can imagine it becoming quite a competitor.
KDE has been the killer app for Linux on the desktop since forever. It was, and still is, the default desktop environment on the majority of Linux distributions. When you read all these reviews about Linux distros, for the most part they are really reviewing KDE. It's what you see on the screen. To most people, KDE is Linux. Calling it a killer app is an understatement.
One of the tough aspects of popularizing XMPP/Jabber is that no large company has stepped forward to fully deliver it to the end-user. Ideally, AOL, Microsoft, and Yahoo would try to migrate their IM protocols to the standard, but somehow this seems unlikely. If a large company could provide a consumer-level IM client, plus dedicated server, plus whitepages, etc (the whole nine yards), and compete against the other gorillas, maybe this will work.
I'd really like to see this, because the Jabber world really needs it. If we can't convince any of the existing major IM players to adopt Jabber, then we need a new company to enter the ring. But is Google large enough to take them on?
Oh, in that case, I know this one: it's the users' fault for not constantly monitoring the problems discovered in every software package they use and failing to update their systems, right?
;-)
I never said anything about users. A little cranky this morning?
Security holes are the fault of the developer. However, more often than not, software has security holes that are fixed in later revisions, and the user will need to update. This need to update cannot be blamed on the user, it is just an unfortunate consequence of typical software development. The solution, of course, lies in the hands of the developers to not release code with holes. This is actually more realistic than you might think, just look at qmail.
Just to clarify, this article is about a problem in Nokia's implementation of Bluetooth, not necessarily a problem in the actual Bluetooth protocol/specification. As an analogy, we hear about security holes in IIS, Apache, OpenSSL, etc, but these do not necessarily indicate problems in the relevant RFC documents. At least, we can hope so ...
That sounds about right to me. Obviously, the actual Commercial license text has a lot more to it than two lines, including what I described in my previous post. In any case, this URL doesn't say that you can't sell software developed by the Free edition.
I think you were looking for this page, which states: "The Free Edition licenses do not allow the development or distribution of commercial software." This sounds confusing, but I think it is because the entire Trolltech website seems to confuse Commercial with Closed-source. What I believe they mean is that you can't use the Free edition for Closed-source software, which makes sense and is consistent with the actual license of the Free edition.
It's not the policy of my series to publish proprietary software on the accompanying CD. But there is some Borland stuff and a copy of Windows Qt on the CD. This is due to a mis-communication with my publisher.
This is interesting, because I know that a lot of the book's popularity is due to the fact that it has Qt/Windows 3.2 bundled with it. This is _huge_ for the many developers that want to port modern free Qt programs to Windows. We've been waiting nearly 3 years for this day.
Got a URL? If it really does say that on their website, then there must be some miscommunication with the website developers.
The Free edition is GPL, no strings attached. You can read the included license files.
However, they do have some trickery going on with the Commercial editions. The license for these state that you cannot use them for working on code previously developed with the Free edition. I think the intent here is to prevent a company from developing a large project with the Free edition, and then buying one commercial license to build the final closed-source product.
I have no direct experience with either of these toolkits, but I can draw many comparisons between software that's developed by professionals and software developed by college students wherein the college students made the better product.
;-), but I think in this case the professionals have the better product. As noted in the parent post: if Gtk were technically better than Qt, we'd all be using Gtk and no one would be complainining about the GPL.
I totally agree with you, as I'm a college student and I think I put out some pretty good software
To quote the review, it seems that people prefer Qt because they 'like' it. They like the system, the API, the docs, or what have you. Developers that prefer Gtk seem to choose it based either that it is native C ("I don't need no skinking C++!"), or that the license is LGPL. Personally, I don't consider the language argument to be very strong. I used to be a C guy myself, but because of Qt I use C++.
Just a nitpick:
:)
:)
'Jabber.org' is not buggy, unless you are referring to the website having bugs.
You're probably thinking of the 'jabberd' server software, but this is not a product of jabber.org, and it is not the only server software available. Saying "the free Jabber" would make about as much sense as saying "the free HTTP". Remember, Jabber is an open protocol, and anyone is free to implement it. Just as with any other standard protocol, such as email, there are many software solutions (free, commercial, etc) available.
Just FYI.
Huh? Qt/Windows apps look just like native apps, even with the XP theme and everything. Have you ever used one? See my sig.
It may be a great idea if a mother is tracking her child. It's not such a great idea if a stalker is doing the same.
People tracking people is a much different matter than providers & callers tracking people. I think you're right about mother vs stalker, but both cases are possible without "GPS in phones". You can already buy GSM/GPS tracking devices, and it would be relatively easy to make one too (Nokia 9290 + Earthmate).
I suppose this technology might make tracking devices for stalkers more accessible, particularly if the phones can be programmed to automatically do their magic (send data to the stalker) without having to connect the phone to an external device. And a phone looks less threatening than a mysterious black box ("hey it's just a phone"). I don't have a counter answer to this, other than that maybe we all just need to get used to it. We already have this problem with software (spyware!), so having it with hardware should not be surprising. As technology advances and devices become more capable, complex, and smaller, we need to be aware of what these things can do when we see them.
I think GPS in phones is a great idea. Aside from the fact that it would make emergency calls much more efficient, it would be handy when using it with a PDA (you'd get both GPS and Network in one peripheral). Having a two-in-one would also simplify tracking-device projects. Don't you think it would be totally nerdy cool to be able to enter an AT command to your phone and get GPS coordinates, or throw it into a NMEA mode?
The issue of providers tracking you is a completely separate problem. As long as the user remains in control (ie, I can choose to allow my phone to transmit GPS information to my provider or caller), then we're fine. Personally I'd have it always set to never allow another party to get my (x,y) unless I was using an emergency call. The rest of the time I'd be using the GPS capability with a local device for my own needs. We just need to ensure that phones don't go "DRM-style", where they are doing things against your will.
Don't forget about AIM and ICQ. Many geeks may hate AOL, but they still use their IM network.
Actually, the whole Non-Commercial version was an experiment in making Qt/Windows more accessable to free software developers. It was not intended as a bait-and-switch. Trolltech was very hesitant about releasing their flagship product for free on Windows (probably their biggest source of income), so in mid-2001, around the time Qt 3.0 was in the beta phase, they released a non-commercial version of Qt 2.x for Windows. The plan was that if their sales started to drop (implying that companies were freeloading off of the non-commercial version instead of buying licenses like they were supposed to), then in a few months they would release Qt 3.0, thus obsoleting the non-commercial version. In other words, by timing the release around that of Qt 3.0, they had an 'easy out' to prevent much harm if the move was a mistake.
:)
Well, guess what? It was a mistake. The sales data came in, and indeed they lost a bunch of money. Qt/Non-commercial was effectively dead later that year. I'd say the fact that they were even letting people download it through 2003 was just to be nice. There is very little reason for them to continue hosting a file they never update. Someone else can take over that job now.