AFAIK, aim-t isn't even an option at the jabber.com / jabber.org servers. There's not really anything that can be done to prevent an IP address ban. From what I understand, these are explicit bans against the major Jabber servers, and are not necessarily related to the amount of AIM logins.
Coming from AIM as my primary chat medium, that was ahuge hurdle to adopting Jabber personally.
Depending on how you feel about open standards (and I hope a lot of us feel strongly towards them here), I encourage you to put in a little bit more effort:) It is a darn shame Trillian doesn't support Jabber, otherwise I'd actually recommend the program. My advice to you is to use a Jabber client alongside Trillian. Yeah I know, using two clients sucks, but you were probably doing this before Trillian came around anyway. Start building your Jabber roster now. You're gonna have to do it eventually anyway, and starting early will speed up adoption.
I recommend this especially to Trillian users like you, who probably have other Trillian-using friends that could all easily begin using Jabber. I agree it is tougher to convert your AIM-using Grandma to Jabber, but you Trillian users are natural rebels, right? Rebel! And keep Trillian around for talking to Grandma.
Personally, I used to use ICQ for a long time, then I began using Jabber and the ICQ transport. Later, I decided to start using AIM and MSN transports also (I figured, hey, why not?). Bad move.. this brought me knee deep in proprietary IM. I strongly suggest NOT using IM services that you weren't already using. Ie, if you start using Trillian or Jabber, do the world a favor and please don't just start using every single service. This only promotes them.
So one day I decided to bite the bullet and unregistered from ALL the transports I was using. Now I use Jabber only. It was tough in the beginning (well, a lot less people bothered me on IM, hehe), but eventually I rebuilt my contact list. All my friends use Jabber now and so does my family. Right now I've got over 100 Jabber contacts, although I can't say I talk to a lot of them. I don't recommend this route for everyone, but it sure feels good to be free of AOL once and for all (and there was much rejoicing).
I use a SocketCom Bluetooth CF card, to communicate with my GPRS-capable Nokia 6310i, which drains barely anything from the Zaurus. I left the sucker online for hours (logged into Jabber) in my pocket at DefCon, and at the end of the day the battery life gauge on the Z hadn't even moved. Of course, that gauge is crap anyway, but you get the idea.
Obviously, this saves a lot of power on the Zaurus because it doesn't have to manage its own long range cell connection. I do have to say though, that with GPRS, even the phone spent very little battery life, since you only spend energy (and money, hehe) when you are transferring data. I'm sure it would be different if I were downloading huge files, but if I'm just sitting in away-mode on Jabber I get very good mileage. And cheap too!
the system actually just froze, which is pretty impressive, and shows how Microsoft has incoroporated some of Linux's features into their product line
I believe you're knocking XFree86 here, and not Linux. But you're right, as Linux user and I can attest that XFree86 sucks when it comes to driver stability.
I'll get back to you when XDirectFB can run KDE apps..
Re:A bit *too* nice about Qt
on
Qt vs MFC
·
· Score: 2
The article also seems to praise QString, which is yet another string class with a Big Bloated Interface(TM) (doh!) that thinks using only mutable strings is the way forward (double-doh!) and reference counting/copy-on-write of a mutable string is a Good Thing (double-plus-doh!). These are well-known design flaws with both approaches, relating to efficiency, thread safety, etc.
Can you explain these inefficiencies, or provide a URL to some analysis about them? Personally, I think the copy-on-write stuff is really cool. Not just QString, but even container classes like QValueList won't duplicate your objects unless needed. Native Unicode makes things simpler too...
Have a look at Animail. I personally haven't used it, but according to the website it looks to be like fetchmail, with optional anti-SPAM measures (which the docs say were inspired by TMDA).
I refuse to respond to any TMDA or other robot autoreply. You use it, and you're immediately added onto my blacklist and bitbucketed.. A blacklist of people who value other people so little that they should be ignored.. A blacklist that is public.
I think you're taking this a bit too seriously. Consider the Jabber IM protocol, which already has a presence authorization system (ie, whitelist), and a server-to-server "dialback" protocol for preventing server spoofs. No one would ever complain about those features.
So then, why complain about TMDA (or others like it)? IMO, there is nothing wrong with what TMDA does, it is just providing a service that Email really should have had built-in.
Your idea of a key phrase is good, but perhaps it is overkill?
First, I think it will be a long time before the whole world is using a whitelist-based protection mechanism. We'll probably have a better email protocol before spammers would even worry about circumventing whitelists.
It has been mentioned in quite a few threads already that a spammer would have to use a valid return-address in order to receive the confirmation email. I think this would be enough to stop them cold. Spammers rely on being able to spoof addresses.
A better circumvention measure would be for a spammer to spoof the address of someone in my whitelist (maybe this is what Outlook-addressbook viruses will do in the future).
Perhaps the ultimate SPAM-killer would be some combination of the two. Blacklists to prevent bandwidth loss, and whitelists to kill anything that slips through.
I assume it's pretty easy to chain MAPS before TMDA in my qmail setup, maybe I should look into it.
Yes! See my other post about TMDA in the comments. It does exactly this.
By the way, your potential abuse is not as bad as it sounds. The spammer would need to use a valid return address in order to receive the confirmation. This means they could be tracked and stopped, etc. The most serious problems with SPAM right now are how there are so many open-relays and that addresses can be spoofed.
(this is similar to a comment I posted to the other recent fax SPAM story. it has been expanded.) ------
I highly recommend using TMDA on your mail server to defeat SPAM. It works by maintaining a whitelist of valid senders. If someone emails you and they are not in the whitelist, then they receive a confirmation request email. They must reply to it in order to be added to the whitelist (at which point, TMDA will deliver their original message, and allow all new ones to pass through). No having to report SPAMs, no worry of maintaining a never ending blacklist. No blocking of entire domains, no having to "sort through the spam periodically". TMDA does it all for you, putting a minor inconvenience on first-time senders.
The end result is that I get no SPAM. Zero, zlich, nada, not one -- with no effort on my part.
I believe there are other packages out there similar to TMDA that you may want to try. Regardless, I'm convinced that a whitelist-centric strategy is the way to beat SPAM.
Note: You still must take into account mailinglists or other situations where you are going to receive mail from an unknown source that won't be able to process the confirm request (such as some online purchase confirmation), and this is where qmail aliases can come in handy. Ie, justin-linux, justin-sears, etc, and just throw them away if you ever get SPAM. TMDA even has some features to help with this, such as hash-generated addresses that self-destruct after a period of time.
Still, for all other purposes you can keep your normal address. No need for SPAM armoring ever again:)
I highly recommend using TMDA on your mail server to defeat SPAM. It works by maintaining a whitelist of valid senders. If someone emails you and they are not in the whitelist, then they receive a confirmation request email. They must reply to it in order to be added to the whitelist (at which point, TMDA will deliver their original message, and allow all new ones to pass through). No having to report SPAMs, no worry of maintaining a never ending blacklist. TMDA does it all for you, putting a minor inconvenience on first-time senders.
The end result is that I get no SPAM. Zero, zlich, nada, not one -- with no effort on my part.
I believe there are other packages out there similar to TMDA that you may want to try. Regardless, I'm convinced that a whitelist-centric strategy is the way to beat SPAM.
Perhaps it isn't that Linux isn't ready for the desktop, but rather people aren't ready for linux. I like Linux for the reasons that thus guy doesn't! I like compiling my own programs and I like editing my/etc/lilo.conf and my/etc/fstab. I like compiling my own kernel. It gives me a feeling of intimacy with the Operating System because I know exactly what is going on.
The thing is, even dedicated Linux users like you and I could still benefit from a properly detected CDRW drive. I agree it is a good thing to have power, but it is also good to have convenience (read: apt-get, emerge). All of Tony's points ring true even for me, though I won't be leaving Linux at all. I would like to see his wishes come true though.
As for his X server gripes, I don't have any of his problems. My fonts out of Redhat and Mandrake are fine, I've got 3-D on my Radeon out of the box and I can play Tux Racer, my 2-d is as fast as on my windows boxes.
While your XFree86 may have been auto-configured by Redhat or Mandrake, it is still the same awful font configuration deep-down. XFree86 is 99% the cause of Linux desktop crashes. Why must the graphical interface be run as root? Why does Tux Racer require X, when all it does is bypass the X protocol anyway? Sure, it all "works", but it could be better. DirectFB with an X layer sounds like the future solution we want.
In my experience, recompiling the kernel/running kudzu is MUCH faster than messing with drivers.
The problem is that even programs like kudzu and yast are not perfect, because they have to work around the quirks of X and Linux driver modules. Is there more to detection than just seeing if a driver fails? Can drivers be manipulated after being loaded? Is there a standard way to get information about a loaded module? (name, description, and other info?) If the answer is 'no' to any of these, then the Linux driver system could use some improvement.
As I said, I'm not leaving Linux. But these are problems I would seriously like to see tended to. His requests are not about making Linux something it is not, but rather making Linux better than it is. I think we can all agree with that.:)
It was not designed for security (for example, it sends passwords as clear text)
What?!?! Jabber sends the password as a hash and even has SSL support. Some clients do PGP end-to-end if you really that. Not to mention that the server-to-server protocol does "dialback" to prevent spoofing. Sorry, but you are terribly misinformed here. Jabber is the most secure of all IM systems (which unfortunately doesn't say much, since security is basically non-existent in ICQ, AIM, etc).
the model it uses is inherently vulnerable to DOS attacks
I'm not a server developer, so I'd like to hear about these DoS attack vulnerabilities (that aren't inherent to servers in general). Otherwise, I'll write this comment off as unfounded.
you'll never convince AOL to use it.
I'll give you this, at least. Fortunately, as an open project, Jabber will live on no matter what any company says or does. Unfortunately, without serious corporate backing, Jabber is likely to stay within the techie circle (like Linux).
According to Peter Saint-Andre (member of the Jabber Software Foundation, who was at this year's IETF meeting), SIMPLE is about two years away from defining the protocols, let alone implementations, for a full-featured IM system. Jabber only recently had an RFC written (earlier this year), as the focus before that has been on implementations. The difference is obvious: people are using Jabber right now, while SIMPLE is basically all talk.
This is fine, and should be expected. When the email standard became widely adopted, it's not like there were any sections in the RFC about being compatible with AOL mail. It should not be a requirement of a standard IM protocol to interface with AOL OSCAR. Rather, the requirement should be for AOL to support the standard protocol. This doesn't mean they have to ditch what they use now, it just means that they need to "talk Jabber" to the outside world (they already do this with email: SMTP on the outside, proprietary on the inside).
IMO, Jabber does what it does, and does it good. All the problems people have with it are all related to interfacing with proprietary networks, to which I just yawn.
Why do we need a standard IM protocol? The same reason we needed a standard email protocol. Interoperable email was solved by having each of the big boys (like Prodigy, Compuserve, and AOL) to agree on a standard. The answer was _not_ to use some all-in-one Prodigy+Compuserver+AOL mail application.
There are other problems with the Trillian approach. First, it is a "single-vendor-solution", which is not what you want with something as important as IM. Imagine if the only email client you could ever use was Outlook. What do you do about Linux? What about PDAs? Wait for Cerulean to develop clients for every situation? Not. The whole point of an open protocol is to allow anyone to develop a interoperable server or client.
Second, AOL (and Yahoo also, based on rumors) are not happy with these 3rd-party interoperability attempts. What happens when AOL decides to detect Trillian, and not allow it to use their network? Please, we don't need this kind of childish BS in instant messaging, especially as it becomes more prevalent in the corporate world.
My personal jabber server keeps on ticking no matter what AOL does. This is how IM should have been since the beginning.
IM interoperability is a serious problem. I'll agree with you that Trillian solves the problem, however in my opinion it is in a temporary way. The real solution is to standardize on a protocol. Here's to hoping Jabber takes over the world:)
I think the reason Japan has so much cooler stuff is that they are willing to take risks. In the USA, if a particular device or software/game is not going to "make millions" by attracting mainstream buyers, then there is little chance it would ever make it to the market. Publishers and manufacturers here want to take only the safest bets. Ever wonder why the USA is full of so many crappy movies, games, and me-too products? Why take a risk when you can copy something proven?
In Japan, they release just about anything that their minds and conjure up. Surely they have the same economic business sense as those in the USA, but perhaps their consumer market is much more willing to risk buying innovative stuff (this is basically what the article seems to conclude). Also, maybe because of Japan's small size, companies don't have to spend very much money on initial production runs?
Re:modules, and why Rusty is wrong:
on
Kernel Summit Wrapup
·
· Score: 4, Interesting
Well, y'see, there's this OS called Windows, made by this guy Gates... it might suit you better.
Somehow I knew I'd get a comment like that. I can't tell if you are a Windows user singing its praises, or some die-hard Linux user that wouldn't ever touch modprobe your life depended on it. Either way, your comment completely misses the point.
I find Linux to be a better OS in general, but it is not without flaws. What is the harm in fixing these flaws? I didn't say everyone needs to use a point-n-drool driver GUI. What I want is a better driver layer, so that stuff like that can exist if necessary. In the instance that you're a "die-hard Linux user", then continue to recompile your kernel or uncomment a modprobe line in your Slackware config whenever you want to install hardware. I just see a lot more potential with Linux driver configuration than that.
We ooh and ahh about "apt-get mozilla" or "emerge mozilla". Single commands that do all the hard work for you. Wouldn't it be great to have programs that could do the same kind of things for drivers also? The best part about Linux is that it is so flexible. You are not confined to a GUI or anything. A powerful underlying driver layer means more sane configuration, more powerful driver scripts, and the possibility of making easy-to-use configuration tools. And best of all, you can continue recompiling your kernel just as you may have always done. Yay! Everyone is happy.
My suggestion was to make Linux better, not to make it Windows. I hope you can see the difference.
Depending on the distribution (like, say, Redhat), that may be all you need to do in Linux also. However, I think the underlying system could be a lot better.
I have a mental list of about 5 things Linux needs to be really damn good. Better module support is one of them. Granted, I'm not a driver author, and I really haven't done much with compiling drivers since 2.2, so anyone please correct me if some of this stuff is already in place.
All drivers should be available as an add-on module. The idea here is to be able to load any driver when you need it, and to never have to recompile your kernel.
Binary compatibility between kernel versions. I mean, really, does it change _that_ much? I should be able to load a 2.4.0 driver on a 2.4.1 system. Why should VMWare need to have a bazillion drivers for various kernel versions? Maybe this is too late for older kernels, but how about considering backwards compatibility from this point on? Is it too much to ask that Linux 2.6 drivers should work in 2.8?
A very good interface for which modules can be interacted with (outside of the kernel). Currently there is insmod, which is able to specify additional parameters to a module via command line arguments. But what about errors? Are those returned as an insmod exit code or a standard text format? What about interacting with a module after it is already loaded? Is there a standard for probing whether or not hardware exists, other than simply seeing if the driver fails to load?
The end result is that I should be able to get a diskette from a hardware vendor that contains a nice driver.o file that I can load. If it comes with a driver.c file, then that's great, but I want a.o that I can just use right away.
Having a standard for probing and manipulating drivers is badly needed, so that someone can come along and make a decent Linux driver GUI. Yes, I know about Kudzu and Yast2, but something tells me they are doing a LOT of workarounds and/or "evil hacks" behind the scenes.
Solve this and we are well on our way to making Linux the best it can be. I really hope it is being addressed in 2.5
The problem is that a phone-centric combo device is probably going to be a bad PDA. I'm already convinced that PDA-centric combo devices (like the Nokia 9000 series) are bad phones. Thus, my opinion on combo devices is that they simply aren't as usable as separate, dedicated components would be.
While you say you'd rather not carry two devices, I think that is the optimal solution. 99% of the time, you only need your phone, but in the 1% instance you need a PDA, you want something good. I say take the cell phone with you all the time, and then choose to take the PDA with you depending on the necessity. Bluetooth completes this.
Me? I use the Nokia 6310i and the Sharp Zaurus. No compromises.
so far all of the "universal instant messenger" services that connect with anything that they can find display the same sort of problems that you would find in a Swiss Army Knife, i.e. they do everything "okay" or "pretty well", but overall don't do the job as well as a service or tool that is tailored to one specific job.
Maybe the users of these multi-IM programs are not interested in the extra service-specific features you speak of, otherwise these types of programs wouldn't be so popular. It is abundantly clear that the general public does _not_ like the segregated world of IM we live in.
Communications standards would not preclude an AIM-lover from using the official AIM client if they want the bonus features. Consider AOL internet services, which gives you all sorts of other things in addition to a TCP/IP connection. Consider AOL email, which uses a proprietary protocol internally, but talks SMTP to the rest of the world.
What we need is for AOL (and others) to agree on an IM standard, if only for the basics, so that we can tear this wall down exactly like what happened with email 10 years ago.
The Jabber protocol has achieved RFC status, and will likely be accepted by the IETF. There's our standard. Unfortunately, there are powerful market forces at work, so I won't place any bets on AOL running a Jabber server anytime soon. Too bad, really..
Doing it early just saves everyone a lot of money and bother.
And doing it later is almost near impossible.
Even though this article is actually about high-level wireless data layers, consider that even base celluar networks in the USA have yet to fully standardize. While it is true that the GSM standard is here to stay, especially considering that AT&T has embraced it, I still don't see Sprint or Verizon going anywhere. The USA market is going to be fragmented for a long time, I'm afraid..
Whenever I hear about "standardizing later", I think of instant messaging. How long has it been since ICQ started? 6 or 7 years? You'd think we'd have an IM standard by now, but instead we've gained 3 other HUGE proprietary networks (and then some). True, there is Jabber, but how long has it been available now? 2-3 years? AOL, Microsoft, and Yahoo, still have yet to embrace any sort of standard. I believe the IETF will be accepting Jabber as an RFC soon, but does anyone really think AOL will start using it?
Slashdot Mirror
Whatever happened to the aim-t probelms?
:) It is a darn shame Trillian doesn't support Jabber, otherwise I'd actually recommend the program. My advice to you is to use a Jabber client alongside Trillian. Yeah I know, using two clients sucks, but you were probably doing this before Trillian came around anyway. Start building your Jabber roster now. You're gonna have to do it eventually anyway, and starting early will speed up adoption.
AFAIK, aim-t isn't even an option at the jabber.com / jabber.org servers. There's not really anything that can be done to prevent an IP address ban. From what I understand, these are explicit bans against the major Jabber servers, and are not necessarily related to the amount of AIM logins.
Coming from AIM as my primary chat medium, that was ahuge hurdle to adopting Jabber personally.
Depending on how you feel about open standards (and I hope a lot of us feel strongly towards them here), I encourage you to put in a little bit more effort
I recommend this especially to Trillian users like you, who probably have other Trillian-using friends that could all easily begin using Jabber. I agree it is tougher to convert your AIM-using Grandma to Jabber, but you Trillian users are natural rebels, right? Rebel! And keep Trillian around for talking to Grandma.
Personally, I used to use ICQ for a long time, then I began using Jabber and the ICQ transport. Later, I decided to start using AIM and MSN transports also (I figured, hey, why not?). Bad move.. this brought me knee deep in proprietary IM. I strongly suggest NOT using IM services that you weren't already using. Ie, if you start using Trillian or Jabber, do the world a favor and please don't just start using every single service. This only promotes them.
So one day I decided to bite the bullet and unregistered from ALL the transports I was using. Now I use Jabber only. It was tough in the beginning (well, a lot less people bothered me on IM, hehe), but eventually I rebuilt my contact list. All my friends use Jabber now and so does my family. Right now I've got over 100 Jabber contacts, although I can't say I talk to a lot of them. I don't recommend this route for everyone, but it sure feels good to be free of AOL once and for all (and there was much rejoicing).
-Justin
I use a SocketCom Bluetooth CF card, to communicate with my GPRS-capable Nokia 6310i, which drains barely anything from the Zaurus. I left the sucker online for hours (logged into Jabber) in my pocket at DefCon, and at the end of the day the battery life gauge on the Z hadn't even moved. Of course, that gauge is crap anyway, but you get the idea.
Obviously, this saves a lot of power on the Zaurus because it doesn't have to manage its own long range cell connection. I do have to say though, that with GPRS, even the phone spent very little battery life, since you only spend energy (and money, hehe) when you are transferring data. I'm sure it would be different if I were downloading huge files, but if I'm just sitting in away-mode on Jabber I get very good mileage. And cheap too!
Who's making your coffee? I'm not keen on sweat
Who's drinking sweat? Or maybe you are talking about Gatorade.
the system actually just froze, which is pretty impressive, and shows how Microsoft has incoroporated some of Linux's features into their product line
I believe you're knocking XFree86 here, and not Linux. But you're right, as Linux user and I can attest that XFree86 sucks when it comes to driver stability.
I'll get back to you when XDirectFB can run KDE apps..
The article also seems to praise QString, which is yet another string class with a Big Bloated Interface(TM) (doh!) that thinks using only mutable strings is the way forward (double-doh!) and reference counting/copy-on-write of a mutable string is a Good Thing (double-plus-doh!). These are well-known design flaws with both approaches, relating to efficiency, thread safety, etc.
Can you explain these inefficiencies, or provide a URL to some analysis about them? Personally, I think the copy-on-write stuff is really cool. Not just QString, but even container classes like QValueList won't duplicate your objects unless needed. Native Unicode makes things simpler too...
Have a look at Animail. I personally haven't used it, but according to the website it looks to be like fetchmail, with optional anti-SPAM measures (which the docs say were inspired by TMDA).
I refuse to respond to any TMDA or other robot autoreply. You use it, and you're immediately added onto my blacklist and bitbucketed.. A blacklist of people who value other people so little that they should be ignored.. A blacklist that is public.
I think you're taking this a bit too seriously. Consider the Jabber IM protocol, which already has a presence authorization system (ie, whitelist), and a server-to-server "dialback" protocol for preventing server spoofs. No one would ever complain about those features.
So then, why complain about TMDA (or others like it)? IMO, there is nothing wrong with what TMDA does, it is just providing a service that Email really should have had built-in.
Your idea of a key phrase is good, but perhaps it is overkill?
First, I think it will be a long time before the whole world is using a whitelist-based protection mechanism. We'll probably have a better email protocol before spammers would even worry about circumventing whitelists.
It has been mentioned in quite a few threads already that a spammer would have to use a valid return-address in order to receive the confirmation email. I think this would be enough to stop them cold. Spammers rely on being able to spoof addresses.
A better circumvention measure would be for a spammer to spoof the address of someone in my whitelist (maybe this is what Outlook-addressbook viruses will do in the future).
Nice try. It all goes through the same filter. Have fun :)
And to do that they have to use a valid return address, thus ending their SPAM operation quickly (see other threads about this).
Good point.
Perhaps the ultimate SPAM-killer would be some combination of the two. Blacklists to prevent bandwidth loss, and whitelists to kill anything that slips through.
I assume it's pretty easy to chain MAPS before TMDA in my qmail setup, maybe I should look into it.
Yes, I noticed this too. I tend to check my mail very frequently, and not much is there these days. Maybe I should install a biff of sorts..
Still, it does feel good to be able to say, "I don't get SPAM, period." Oops there goes my ego.
Yes! See my other post about TMDA in the comments. It does exactly this.
By the way, your potential abuse is not as bad as it sounds. The spammer would need to use a valid return address in order to receive the confirmation. This means they could be tracked and stopped, etc. The most serious problems with SPAM right now are how there are so many open-relays and that addresses can be spoofed.
(this is similar to a comment I posted to the other recent fax SPAM story. it has been expanded.)
:)
------
I highly recommend using TMDA on your mail server to defeat SPAM. It works by maintaining a whitelist of valid senders. If someone emails you and they are not in the whitelist, then they receive a confirmation request email. They must reply to it in order to be added to the whitelist (at which point, TMDA will deliver their original message, and allow all new ones to pass through). No having to report SPAMs, no worry of maintaining a never ending blacklist. No blocking of entire domains, no having to "sort through the spam periodically". TMDA does it all for you, putting a minor inconvenience on first-time senders.
The end result is that I get no SPAM. Zero, zlich, nada, not one -- with no effort on my part.
I believe there are other packages out there similar to TMDA that you may want to try. Regardless, I'm convinced that a whitelist-centric strategy is the way to beat SPAM.
Note: You still must take into account mailinglists or other situations where you are going to receive mail from an unknown source that won't be able to process the confirm request (such as some online purchase confirmation), and this is where qmail aliases can come in handy. Ie, justin-linux, justin-sears, etc, and just throw them away if you ever get SPAM. TMDA even has some features to help with this, such as hash-generated addresses that self-destruct after a period of time.
Still, for all other purposes you can keep your normal address. No need for SPAM armoring ever again
-Justin
I highly recommend using TMDA on your mail server to defeat SPAM. It works by maintaining a whitelist of valid senders. If someone emails you and they are not in the whitelist, then they receive a confirmation request email. They must reply to it in order to be added to the whitelist (at which point, TMDA will deliver their original message, and allow all new ones to pass through). No having to report SPAMs, no worry of maintaining a never ending blacklist. TMDA does it all for you, putting a minor inconvenience on first-time senders.
The end result is that I get no SPAM. Zero, zlich, nada, not one -- with no effort on my part.
I believe there are other packages out there similar to TMDA that you may want to try. Regardless, I'm convinced that a whitelist-centric strategy is the way to beat SPAM.
Perhaps it isn't that Linux isn't ready for the desktop, but rather people aren't ready for linux. I like Linux for the reasons that thus guy doesn't! I like compiling my own programs and I like editing my /etc/lilo.conf and my /etc/fstab. I like compiling my own kernel. It gives me a feeling of intimacy with the Operating System because I know exactly what is going on.
:)
The thing is, even dedicated Linux users like you and I could still benefit from a properly detected CDRW drive. I agree it is a good thing to have power, but it is also good to have convenience (read: apt-get, emerge). All of Tony's points ring true even for me, though I won't be leaving Linux at all. I would like to see his wishes come true though.
As for his X server gripes, I don't have any of his problems. My fonts out of Redhat and Mandrake are fine, I've got 3-D on my Radeon out of the box and I can play Tux Racer, my 2-d is as fast as on my windows boxes.
While your XFree86 may have been auto-configured by Redhat or Mandrake, it is still the same awful font configuration deep-down. XFree86 is 99% the cause of Linux desktop crashes. Why must the graphical interface be run as root? Why does Tux Racer require X, when all it does is bypass the X protocol anyway? Sure, it all "works", but it could be better. DirectFB with an X layer sounds like the future solution we want.
In my experience, recompiling the kernel/running kudzu is MUCH faster than messing with drivers.
The problem is that even programs like kudzu and yast are not perfect, because they have to work around the quirks of X and Linux driver modules. Is there more to detection than just seeing if a driver fails? Can drivers be manipulated after being loaded? Is there a standard way to get information about a loaded module? (name, description, and other info?) If the answer is 'no' to any of these, then the Linux driver system could use some improvement.
As I said, I'm not leaving Linux. But these are problems I would seriously like to see tended to. His requests are not about making Linux something it is not, but rather making Linux better than it is. I think we can all agree with that.
It was not designed for security (for example, it sends passwords as clear text)
What?!?! Jabber sends the password as a hash and even has SSL support. Some clients do PGP end-to-end if you really that. Not to mention that the server-to-server protocol does "dialback" to prevent spoofing. Sorry, but you are terribly misinformed here. Jabber is the most secure of all IM systems (which unfortunately doesn't say much, since security is basically non-existent in ICQ, AIM, etc).
the model it uses is inherently vulnerable to DOS attacks
I'm not a server developer, so I'd like to hear about these DoS attack vulnerabilities (that aren't inherent to servers in general). Otherwise, I'll write this comment off as unfounded.
you'll never convince AOL to use it.
I'll give you this, at least. Fortunately, as an open project, Jabber will live on no matter what any company says or does. Unfortunately, without serious corporate backing, Jabber is likely to stay within the techie circle (like Linux).
According to Peter Saint-Andre (member of the Jabber Software Foundation, who was at this year's IETF meeting), SIMPLE is about two years away from defining the protocols, let alone implementations, for a full-featured IM system. Jabber only recently had an RFC written (earlier this year), as the focus before that has been on implementations. The difference is obvious: people are using Jabber right now, while SIMPLE is basically all talk.
but it only works for people using *jabber*
This is fine, and should be expected. When the email standard became widely adopted, it's not like there were any sections in the RFC about being compatible with AOL mail. It should not be a requirement of a standard IM protocol to interface with AOL OSCAR. Rather, the requirement should be for AOL to support the standard protocol. This doesn't mean they have to ditch what they use now, it just means that they need to "talk Jabber" to the outside world (they already do this with email: SMTP on the outside, proprietary on the inside).
IMO, Jabber does what it does, and does it good. All the problems people have with it are all related to interfacing with proprietary networks, to which I just yawn.
Why do we need a standard IM protocol? The same reason we needed a standard email protocol. Interoperable email was solved by having each of the big boys (like Prodigy, Compuserve, and AOL) to agree on a standard. The answer was _not_ to use some all-in-one Prodigy+Compuserver+AOL mail application.
:)
There are other problems with the Trillian approach. First, it is a "single-vendor-solution", which is not what you want with something as important as IM. Imagine if the only email client you could ever use was Outlook. What do you do about Linux? What about PDAs? Wait for Cerulean to develop clients for every situation? Not. The whole point of an open protocol is to allow anyone to develop a interoperable server or client.
Second, AOL (and Yahoo also, based on rumors) are not happy with these 3rd-party interoperability attempts. What happens when AOL decides to detect Trillian, and not allow it to use their network? Please, we don't need this kind of childish BS in instant messaging, especially as it becomes more prevalent in the corporate world.
My personal jabber server keeps on ticking no matter what AOL does. This is how IM should have been since the beginning.
IM interoperability is a serious problem. I'll agree with you that Trillian solves the problem, however in my opinion it is in a temporary way. The real solution is to standardize on a protocol. Here's to hoping Jabber takes over the world
I think the reason Japan has so much cooler stuff is that they are willing to take risks. In the USA, if a particular device or software/game is not going to "make millions" by attracting mainstream buyers, then there is little chance it would ever make it to the market. Publishers and manufacturers here want to take only the safest bets. Ever wonder why the USA is full of so many crappy movies, games, and me-too products? Why take a risk when you can copy something proven?
In Japan, they release just about anything that their minds and conjure up. Surely they have the same economic business sense as those in the USA, but perhaps their consumer market is much more willing to risk buying innovative stuff (this is basically what the article seems to conclude). Also, maybe because of Japan's small size, companies don't have to spend very much money on initial production runs?
Well, y'see, there's this OS called Windows, made by this guy Gates... it might suit you better.
Somehow I knew I'd get a comment like that. I can't tell if you are a Windows user singing its praises, or some die-hard Linux user that wouldn't ever touch modprobe your life depended on it. Either way, your comment completely misses the point.
I find Linux to be a better OS in general, but it is not without flaws. What is the harm in fixing these flaws? I didn't say everyone needs to use a point-n-drool driver GUI. What I want is a better driver layer, so that stuff like that can exist if necessary. In the instance that you're a "die-hard Linux user", then continue to recompile your kernel or uncomment a modprobe line in your Slackware config whenever you want to install hardware. I just see a lot more potential with Linux driver configuration than that.
We ooh and ahh about "apt-get mozilla" or "emerge mozilla". Single commands that do all the hard work for you. Wouldn't it be great to have programs that could do the same kind of things for drivers also? The best part about Linux is that it is so flexible. You are not confined to a GUI or anything. A powerful underlying driver layer means more sane configuration, more powerful driver scripts, and the possibility of making easy-to-use configuration tools. And best of all, you can continue recompiling your kernel just as you may have always done. Yay! Everyone is happy.
My suggestion was to make Linux better, not to make it Windows. I hope you can see the difference.
I have a mental list of about 5 things Linux needs to be really damn good. Better module support is one of them. Granted, I'm not a driver author, and I really haven't done much with compiling drivers since 2.2, so anyone please correct me if some of this stuff is already in place.
All drivers should be available as an add-on module. The idea here is to be able to load any driver when you need it, and to never have to recompile your kernel.
Binary compatibility between kernel versions. I mean, really, does it change _that_ much? I should be able to load a 2.4.0 driver on a 2.4.1 system. Why should VMWare need to have a bazillion drivers for various kernel versions? Maybe this is too late for older kernels, but how about considering backwards compatibility from this point on? Is it too much to ask that Linux 2.6 drivers should work in 2.8?
A very good interface for which modules can be interacted with (outside of the kernel). Currently there is insmod, which is able to specify additional parameters to a module via command line arguments. But what about errors? Are those returned as an insmod exit code or a standard text format? What about interacting with a module after it is already loaded? Is there a standard for probing whether or not hardware exists, other than simply seeing if the driver fails to load? .o that I can just use right away.
The end result is that I should be able to get a diskette from a hardware vendor that contains a nice driver.o file that I can load. If it comes with a driver.c file, then that's great, but I want a
Having a standard for probing and manipulating drivers is badly needed, so that someone can come along and make a decent Linux driver GUI. Yes, I know about Kudzu and Yast2, but something tells me they are doing a LOT of workarounds and/or "evil hacks" behind the scenes.
Solve this and we are well on our way to making Linux the best it can be. I really hope it is being addressed in 2.5
The problem is that a phone-centric combo device is probably going to be a bad PDA. I'm already convinced that PDA-centric combo devices (like the Nokia 9000 series) are bad phones. Thus, my opinion on combo devices is that they simply aren't as usable as separate, dedicated components would be.
While you say you'd rather not carry two devices, I think that is the optimal solution. 99% of the time, you only need your phone, but in the 1% instance you need a PDA, you want something good. I say take the cell phone with you all the time, and then choose to take the PDA with you depending on the necessity. Bluetooth completes this.
Me? I use the Nokia 6310i and the Sharp Zaurus. No compromises.
so far all of the "universal instant messenger" services that connect with anything that they can find display the same sort of problems that you would find in a Swiss Army Knife, i.e. they do everything "okay" or "pretty well", but overall don't do the job as well as a service or tool that is tailored to one specific job.
Maybe the users of these multi-IM programs are not interested in the extra service-specific features you speak of, otherwise these types of programs wouldn't be so popular. It is abundantly clear that the general public does _not_ like the segregated world of IM we live in.
Communications standards would not preclude an AIM-lover from using the official AIM client if they want the bonus features. Consider AOL internet services, which gives you all sorts of other things in addition to a TCP/IP connection. Consider AOL email, which uses a proprietary protocol internally, but talks SMTP to the rest of the world.
What we need is for AOL (and others) to agree on an IM standard, if only for the basics, so that we can tear this wall down exactly like what happened with email 10 years ago.
The Jabber protocol has achieved RFC status, and will likely be accepted by the IETF. There's our standard. Unfortunately, there are powerful market forces at work, so I won't place any bets on AOL running a Jabber server anytime soon. Too bad, really..
Doing it early just saves everyone a lot of money and bother.
And doing it later is almost near impossible.
Even though this article is actually about high-level wireless data layers, consider that even base celluar networks in the USA have yet to fully standardize. While it is true that the GSM standard is here to stay, especially considering that AT&T has embraced it, I still don't see Sprint or Verizon going anywhere. The USA market is going to be fragmented for a long time, I'm afraid..
Whenever I hear about "standardizing later", I think of instant messaging. How long has it been since ICQ started? 6 or 7 years? You'd think we'd have an IM standard by now, but instead we've gained 3 other HUGE proprietary networks (and then some). True, there is Jabber, but how long has it been available now? 2-3 years? AOL, Microsoft, and Yahoo, still have yet to embrace any sort of standard. I believe the IETF will be accepting Jabber as an RFC soon, but does anyone really think AOL will start using it?