JDK 1.2 was Java2 v1.2.
JDK 1.5 is now Java2 v5.0.
Big difference, there. Take a look on the site if you don't believe that it is still "Java2". Personally I thought it was time for Java3, since the language has changed so damn much between 1.4 and 1.5.:-)
You can take the money because what are the parents going to do? "Umm... I tried to bribe the teacher, and he took my money." As if! They're going to shut up, and stew over it. I say take the damn cash. You get the money, the parents get a lesson they may never forget. Everyone wins!;-)
One reason that comes to mind is that no one (IOW not enough to matter) really cares about "plays more formats." How many people do you know that play anything other than CD, DVD and MP3?
Well, I know dozens of people personally who play DIVX and XVID, since they always have that sort of file shared at lans.
And there are thousands more who seem to use it too. Either that, or those torrent downloads which say "200 leechers" are lying to me.
The point about supporting more codecs is that with the containers these days, you don't know in advance which codec is being used in a file. Having support for more is like insurance against files not working.
Yeah, the codec support of XBMC is much more extensive than any manufacturer will ever provide in the short term, thanks entirely to the installation of MPlayer which is built-in.
What gets me thinking about this whole Mplayer GUI business is that you could build a little embedded Linux system with a swish GUI, Mplayer, Samba and whatever else pre-installed, and effectively get the same kind of functionality you can get with XBMC. Then you could sell this hardware package to the public, as the default configuration. The adverts would all say "plays more formats than everything else on the market", and they would be right.
Yet, nobody has done this yet as far as I know (I mean, surely Slashdot would be all over that kind of press release like maggots on a shit sandwich.)
Maybe it's that MPlayer's status as GPL is scaring off companies from developing a pretty GUI around it, since redistributing MPlayer would mean having to redistribute the code for their entire GUI. I don't know... what I do know is that if I was sitting on enough money to begin a scheme like this, I would be planning it already.:-(
Indeed. Actually even if they did remove the English localisation, it would be possible to install the English bundle if you had your hands on a copy of the full Windows XP.
Either way, it's good to see Microsoft are realising the true value of their product, even though it's only in a couple of regions of the world. >:-/
I'm not entirely convinced that I want the price to go down here though... if it did, more people might buy it, instead of using Linux.:-)
And oh yeah. Never mind that every OS I can think of already ships with an FTP client which works. And if you are too stupid to click on a hyperlink then you are too stupid to deserve life.:-)
Oh please. I see you're specifically picking on a throwaway which I didn't even use as a workaround. If you had actually read my comments properly instead of just looking for the parts which are open to attack, you would see that I mentioned that yes, various clients do display XHTML messages, which includes images.
And... teaching your boss to download an FTP client? What the fuck? If he doesn't know how to download and install software, how the fuck did he even get the Jabber client you're allegedly already talking to him on? Did you install it via an RPC exploit? If that's the case, then install the FTP client the same way. Duh.
But when you use those new features on an old client, unexpected results happen equating in some cases of basically breaking the older browesers. Look when HTML 4.0 came out...or CSS...or any of the IE/Netscape/W3C differences.
But documents written and passed between users of the old HTML or CSS, will still work. Yahoo blocked even users of the old client connecting to each other.
As for Jabber, the protocol gets improved fairly often and not once have I had to download a client. Perhaps this is because XML-based protocols are easier to keep backwards compatible (you just ignore the elements you don't understand.)
This is the best solution, although I'm guessing a lot of ISPs would grumble at the idea of supporting yet another service, when there is no preexisting demand for it. Most ISPs have their hands full with just the basic services, and if anything would like to eliminate or outsource services. (NNTP, for example, is often a favorite service to try to outsource.)
Yep, agreed. Outsourcing would be okay, it would still mean we would have ISPs offering Jabber accounts to users, which is good in two ways. First, the user is likely to ask "What is Jabber?" and then that's one more person who knows about it. Second, having the Jabber server at the ISP is the second more efficient place to put it... the most efficient being running the server from your own house.:-)
Virtual hosting can even be done with jabberd which is nice for this sort of setup. Although the administration interfaces for virtual hosting could be better. Perhaps ejabberd does better at this, but I have no idea since I haven't had time to play with it yet.
However, I bet we could make Jabber a little sweeter by putting together an easy-to-install, easy-to-maintain, minimal-effort jabberd package.
We had this much at one point, the jabberd-quickstart. It was for jabberd 1.4.x though, and hasn't been modernised for jabberd 2.0.
Such a package could be managed from a web interface, as well as provide a web interface for domain owners to manage their users. Simple integration with existing authentication schemes (UNIX passwd, LDAP, RADIUS, etc.) would be helpful, too. If such a package was trivially easy to install, had a near-zero maintenance burden, and offered a useful value-add service that the ISP could advertise, some just might go for it.
I 100% support someone writing a Webmin module for jabberd2. That would be completely awesome.:-)
But if a full virtual hosting service came up, then you would need a publically-accessible web interface for that. You could sign up as a domain owner to get virtual domains, then add users on your own domain. It would almost be like an email forwards interface.
I don't think that just developing a Jabber client that can launch a teleconferencing program is good enough, though. Jabber client authors should agree on which teleconferencing standards to use, so users don't have to think about which specific client the other person is using.
Well, if all the teleconferencing programs would actually standardise their goddamned protocols like Jabber has its, it might be a bit easier.:-)
Anyway voice and video is going through the motions at the moment in Jabber. You can obviously already open an arbitrary stream from one party to the other because that's how file transfer works. All that is needed then is for the two parties to agree on what the stream contains. Presumably someone is already most of the way through this since it's such an emotional issue when someone comes around who actually does want the feature.:-)
The multimedia/teleconferencing components could be written as reusable components, which could be both embedded in the Jabber client and present as a standalone application, for the best of both worlds.
That might indeed be the way to go. But the important thing here is that the teleconferencing components often open sockets themselves and have their own mechanism of directly connecting. After all, you wouldn't want to embed an H323 library without being able to support connecting directly to h323:// URLs, right? And you would want people who don't use Jabber to still be able to call you on your client. So you would presumably need to integrate all this into the Jabber client, rather than just putting in a video window.
But who knows. If Jabber takes off well enough, then perhaps its stream initiation protocols will exceed the usefulness of all the other protocols. At that point hey, let's throw away H323 and the like, and go with something else.:-)
Well the Java clients are still arbitrary code. They can use exactly the same protocol as the real client, so I'm not sure what makes this any easier if they simply update their Java clients in line with their native ones.
And HTML clients require screen scraping, which is almost more horrible.
It would be nice if some independent party kept a repository of the current news on IM companies fucking over their userbase, including a queryable database where you can ask "has anything broken recently?" for use in clients.
That way Jabber server admins could make use of it too, by being on a mailing list for such issues or doing the queries every day, hour, or whenever. Once we have this notice, we can send it to all users of the transport.
Or better yet, they could deliver this sort of news via Jabber, so it gets to us faster.
Then once we know it's broken, we need subscription to the various providers of the transports for them to send information on when it's going to be fixed. Once we have this information, we can fix the issue and send the good news to all users of the transport.
Nice and streamlined, and doesn't assume that everyone uses clients to connect directly.:-)
Perhaps the people complaining haven't used it for a year or two and just think it's awful that a commercial company would break compatibility for an upgrade? It happens all the time in the open source world
Hell yeah, people were furious the last time the HTTP protocol changed and broke all web browsers. Oh wait...:-)
First off, Jabber.org's list of public servers and their capabilities is a PITA to read. (Why do you have to go to the website in the first place? Shouldn't the list be maintained in such a way that you can access it from Jabber clients?)
Of course, even though it exists, that doesn't mean that people like you will even notice.:-)
Anyway as to the issue of servers being unreliable, you could always take somewhere like this as a hint of which servers are more stable than others.
But in keeping the list inline with the users' experiences, you need the users to actually complain! One of the only problems we have on our server (jabber.zim.net.au) is that when a user has an issue, they don't even ask customer support. If customer support aren't told that a user has a problem, then how do they know there is even a problem? We didn't find out about Yahoo being down until about 20 hours after Yahoo fucked over all their users.
No shit. Even SFTP is easy for Windows users. You send the person a link to download WinSCP, which has its own installer which just works. Then you pass them an sftp://user@host URL and tell them the password, they click on it and it pops up a window which looks almost exactly like an Explorer window.
But these people who bitch about the lack of file transfer in something which isn't a file transfer client, are the same sort of people who ask why there are no wheels on sneakers... "but my rollerblades have them... why don't these sneakers have them?"
Many clients have had that feature since the dark ages. My guess is you haven't actually used Jabber for 2-3 years.
In addition to this the client I use, Psi, added this feature recently in version 0.92, in the form which complies with the JEPs.
Oh yeah, and there are other ways to transfer files. You may not have heard of FTP, SFTP, email, and so forth. Hope this helps.
Ok, how about video and audio conversation?
Neos can do this. Although IMO video and audio conversation are not instant messaging, and as such should be done in other clients. Sure, integrate with the other client... but don't implement it in a goddamned instant messenger because it isn't instant messaging.
Display pictures?
What, is your web browser not good enough? Seriously...
Anyway if you want them inline, there are several clients which can read and write XHTML messages, which includes images, yes.
Custom emoticons?
Not only custom emoticons, but custom roster icons too.
When you think about it for a couple of seconds, sites like this couldn't exist without such a feature.
Oh yeah, and because Jabber's iconset format is/will be standardised, there is a good chance that an iconset from one client will work on another client. Is this extremely basic feature in any of the others yet? Didn't think so. Moving on.
And don't get me started on the need on transports to connect to other services...
I agree, these should be built into the core server as it would make compiling and configuring the server much simpler. Although anyone with a Gentoo distribution and half (actually, probably 20% of) a brain can compile the server and all four transports with a single command.
You certainly wouldn't want to put support for Yahoo and the like in the client. Why? Well, the protocol just changed. You'll have to upgrade. The point is to avoid upgrading, therefore it is done on the server. In this way, for every 1000 people using the service, only 1 actually has to update the software.
Jabber is great for simple text messaging and nothing else
I see your comment is in the following form:
say something sucks;
demand a bunch of features which already exist in some form or another;
use the assumption that such features don't exist to conclude something which is false.
I hereby classify your comment as: Troll. Thanks for playing spot the loser.:-)
Slashdot Mirror
JDK 1.2 was Java2 v1.2.
JDK 1.5 is now Java2 v5.0.
Big difference, there. Take a look on the site if you don't believe that it is still "Java2". Personally I thought it was time for Java3, since the language has changed so damn much between 1.4 and 1.5. :-)
Because d00d, nothing is as fast as Gentoo Linux. :-)
But the question is, what is "Troll AND Offtopic" equal to?
I'd take the $5k and still fail the dumba$$
That actually sounds fairly sensible.
You can take the money because what are the parents going to do? "Umm... I tried to bribe the teacher, and he took my money." As if! They're going to shut up, and stew over it. I say take the damn cash. You get the money, the parents get a lesson they may never forget. Everyone wins! ;-)
What about video? :-/
One reason that comes to mind is that no one (IOW not enough to matter) really cares about "plays more formats." How many people do you know that play anything other than CD, DVD and MP3?
Well, I know dozens of people personally who play DIVX and XVID, since they always have that sort of file shared at lans.
And there are thousands more who seem to use it too. Either that, or those torrent downloads which say "200 leechers" are lying to me.
The point about supporting more codecs is that with the containers these days, you don't know in advance which codec is being used in a file. Having support for more is like insurance against files not working.
Yeah, the codec support of XBMC is much more extensive than any manufacturer will ever provide in the short term, thanks entirely to the installation of MPlayer which is built-in.
What gets me thinking about this whole Mplayer GUI business is that you could build a little embedded Linux system with a swish GUI, Mplayer, Samba and whatever else pre-installed, and effectively get the same kind of functionality you can get with XBMC. Then you could sell this hardware package to the public, as the default configuration. The adverts would all say "plays more formats than everything else on the market", and they would be right.
Yet, nobody has done this yet as far as I know (I mean, surely Slashdot would be all over that kind of press release like maggots on a shit sandwich.)
Maybe it's that MPlayer's status as GPL is scaring off companies from developing a pretty GUI around it, since redistributing MPlayer would mean having to redistribute the code for their entire GUI. I don't know... what I do know is that if I was sitting on enough money to begin a scheme like this, I would be planning it already. :-(
What will happen when low-cost labor in China is combined with Microsoft technologies?
Isn't the Xbox already made in China?
Indeed. Actually even if they did remove the English localisation, it would be possible to install the English bundle if you had your hands on a copy of the full Windows XP.
Either way, it's good to see Microsoft are realising the true value of their product, even though it's only in a couple of regions of the world. >:-/
I'm not entirely convinced that I want the price to go down here though... if it did, more people might buy it, instead of using Linux. :-)
Wait... are you saying that the red Swingline stapler is proof of the US's warmongering? Oh dear... :-/
Even if there weren't, I imagine that a Thai-only copy of Windows with no English language bundle would be of quite limited usefulness.
And oh yeah. Never mind that every OS I can think of already ships with an FTP client which works. And if you are too stupid to click on a hyperlink then you are too stupid to deserve life. :-)
Oh please. I see you're specifically picking on a throwaway which I didn't even use as a workaround. If you had actually read my comments properly instead of just looking for the parts which are open to attack, you would see that I mentioned that yes, various clients do display XHTML messages, which includes images.
And... teaching your boss to download an FTP client? What the fuck? If he doesn't know how to download and install software, how the fuck did he even get the Jabber client you're allegedly already talking to him on? Did you install it via an RPC exploit? If that's the case, then install the FTP client the same way. Duh.
But when you use those new features on an old client, unexpected results happen equating in some cases of basically breaking the older browesers. Look when HTML 4.0 came out...or CSS...or any of the IE/Netscape/W3C differences.
But documents written and passed between users of the old HTML or CSS, will still work. Yahoo blocked even users of the old client connecting to each other.
As for Jabber, the protocol gets improved fairly often and not once have I had to download a client. Perhaps this is because XML-based protocols are easier to keep backwards compatible (you just ignore the elements you don't understand.)
Are you sure it works fine? Or is everyone you can see on your list also using the same quick fix?
This is the best solution, although I'm guessing a lot of ISPs would grumble at the idea of supporting yet another service, when there is no preexisting demand for it. Most ISPs have their hands full with just the basic services, and if anything would like to eliminate or outsource services. (NNTP, for example, is often a favorite service to try to outsource.)
Yep, agreed. Outsourcing would be okay, it would still mean we would have ISPs offering Jabber accounts to users, which is good in two ways. First, the user is likely to ask "What is Jabber?" and then that's one more person who knows about it. Second, having the Jabber server at the ISP is the second more efficient place to put it... the most efficient being running the server from your own house. :-)
Virtual hosting can even be done with jabberd which is nice for this sort of setup. Although the administration interfaces for virtual hosting could be better. Perhaps ejabberd does better at this, but I have no idea since I haven't had time to play with it yet.
However, I bet we could make Jabber a little sweeter by putting together an easy-to-install, easy-to-maintain, minimal-effort jabberd package.
We had this much at one point, the jabberd-quickstart. It was for jabberd 1.4.x though, and hasn't been modernised for jabberd 2.0.
Such a package could be managed from a web interface, as well as provide a web interface for domain owners to manage their users. Simple integration with existing authentication schemes (UNIX passwd, LDAP, RADIUS, etc.) would be helpful, too. If such a package was trivially easy to install, had a near-zero maintenance burden, and offered a useful value-add service that the ISP could advertise, some just might go for it.
I 100% support someone writing a Webmin module for jabberd2. That would be completely awesome. :-)
But if a full virtual hosting service came up, then you would need a publically-accessible web interface for that. You could sign up as a domain owner to get virtual domains, then add users on your own domain. It would almost be like an email forwards interface.
I don't think that just developing a Jabber client that can launch a teleconferencing program is good enough, though. Jabber client authors should agree on which teleconferencing standards to use, so users don't have to think about which specific client the other person is using.
Well, if all the teleconferencing programs would actually standardise their goddamned protocols like Jabber has its, it might be a bit easier. :-)
Anyway voice and video is going through the motions at the moment in Jabber. You can obviously already open an arbitrary stream from one party to the other because that's how file transfer works. All that is needed then is for the two parties to agree on what the stream contains. Presumably someone is already most of the way through this since it's such an emotional issue when someone comes around who actually does want the feature. :-)
The multimedia/teleconferencing components could be written as reusable components, which could be both embedded in the Jabber client and present as a standalone application, for the best of both worlds.
That might indeed be the way to go. But the important thing here is that the teleconferencing components often open sockets themselves and have their own mechanism of directly connecting. After all, you wouldn't want to embed an H323 library without being able to support connecting directly to h323:// URLs, right? And you would want people who don't use Jabber to still be able to call you on your client. So you would presumably need to integrate all this into the Jabber client, rather than just putting in a video window.
But who knows. If Jabber takes off well enough, then perhaps its stream initiation protocols will exceed the usefulness of all the other protocols. At that point hey, let's throw away H323 and the like, and go with something else. :-)
It's broken on our server and several other server admins have noted the same trouble. :-/
Well the Java clients are still arbitrary code. They can use exactly the same protocol as the real client, so I'm not sure what makes this any easier if they simply update their Java clients in line with their native ones.
And HTML clients require screen scraping, which is almost more horrible.
I would have sent feedback, but their feedback form didn't have anywhere to enter "Jabber Yahoo Transport" as my client. :-(
It would be nice if some independent party kept a repository of the current news on IM companies fucking over their userbase, including a queryable database where you can ask "has anything broken recently?" for use in clients.
That way Jabber server admins could make use of it too, by being on a mailing list for such issues or doing the queries every day, hour, or whenever. Once we have this notice, we can send it to all users of the transport.
Or better yet, they could deliver this sort of news via Jabber, so it gets to us faster.
Then once we know it's broken, we need subscription to the various providers of the transports for them to send information on when it's going to be fixed. Once we have this information, we can fix the issue and send the good news to all users of the transport.
Nice and streamlined, and doesn't assume that everyone uses clients to connect directly. :-)
Perhaps the people complaining haven't used it for a year or two and just think it's awful that a commercial company would break compatibility for an upgrade? It happens all the time in the open source world
Hell yeah, people were furious the last time the HTTP protocol changed and broke all web browsers. Oh wait... :-)
First off, Jabber.org's list of public servers and their capabilities is a PITA to read. (Why do you have to go to the website in the first place? Shouldn't the list be maintained in such a way that you can access it from Jabber clients?)
There is.
Of course, even though it exists, that doesn't mean that people like you will even notice. :-)
Anyway as to the issue of servers being unreliable, you could always take somewhere like this as a hint of which servers are more stable than others.
But in keeping the list inline with the users' experiences, you need the users to actually complain! One of the only problems we have on our server (jabber.zim.net.au) is that when a user has an issue, they don't even ask customer support. If customer support aren't told that a user has a problem, then how do they know there is even a problem? We didn't find out about Yahoo being down until about 20 hours after Yahoo fucked over all their users.
No shit. Even SFTP is easy for Windows users. You send the person a link to download WinSCP, which has its own installer which just works. Then you pass them an sftp://user@host URL and tell them the password, they click on it and it pops up a window which looks almost exactly like an Explorer window.
But these people who bitch about the lack of file transfer in something which isn't a file transfer client, are the same sort of people who ask why there are no wheels on sneakers... "but my rollerblades have them... why don't these sneakers have them?"
I am sorry but jabber sucks.
Zero content found. Statement ignored. :-)
Do they at least have file transfer now?
Many clients have had that feature since the dark ages. My guess is you haven't actually used Jabber for 2-3 years.
In addition to this the client I use, Psi, added this feature recently in version 0.92, in the form which complies with the JEPs.
Oh yeah, and there are other ways to transfer files. You may not have heard of FTP, SFTP, email, and so forth. Hope this helps.
Ok, how about video and audio conversation?
Neos can do this. Although IMO video and audio conversation are not instant messaging, and as such should be done in other clients. Sure, integrate with the other client... but don't implement it in a goddamned instant messenger because it isn't instant messaging.
Display pictures?
What, is your web browser not good enough? Seriously...
Anyway if you want them inline, there are several clients which can read and write XHTML messages, which includes images, yes.
Custom emoticons?
Not only custom emoticons, but custom roster icons too.
When you think about it for a couple of seconds, sites like this couldn't exist without such a feature.
Oh yeah, and because Jabber's iconset format is/will be standardised, there is a good chance that an iconset from one client will work on another client. Is this extremely basic feature in any of the others yet? Didn't think so. Moving on.
And don't get me started on the need on transports to connect to other services...
I agree, these should be built into the core server as it would make compiling and configuring the server much simpler. Although anyone with a Gentoo distribution and half (actually, probably 20% of) a brain can compile the server and all four transports with a single command.
You certainly wouldn't want to put support for Yahoo and the like in the client. Why? Well, the protocol just changed. You'll have to upgrade. The point is to avoid upgrading, therefore it is done on the server. In this way, for every 1000 people using the service, only 1 actually has to update the software.
Jabber is great for simple text messaging and nothing else
I see your comment is in the following form:
I hereby classify your comment as: Troll. Thanks for playing spot the loser. :-)