Pretty sure this has been done, and is called UseNet. I seem to remember having done something like this back in... 1988. Oh, and I have a news reader now! That's where the first spam that I ever saw happened - good old canter&siegel(sp?) and the green card scam.
Anyway, I do wish that more sites would use this grand ole protocol. I wish that/. used it. Then I could just put together a kill file...
Wouldn't that be nice? Hey, I might even be convinced I should get a subscription if I could news://slashdot.com/apple
Sure they will. Some spammers get paid per message sent, not per message responded to. Plus, since it costs next to nothing to send, why not send it? Maybe the filters will miss it.
Yeah, right. I should become a spammer - I could easily send millions of messages - to nobody[1-9999999]@dev.null. Think anyone will buy my service? I believe that spammers get paid for messages austensibly delivered. If it becomes well known that AOL has a good filter, spammers will not bother (unless they have a really good payload). Or they will stop getting paid. This is simple econ, stop trying to make it into some kind of magic.
Although parent post sounds trollish, it has a valid point. Filtering incoming mail by the ISP is a bad idea, at least much worse than filtering outgoing ones.
Disagree. FORCED filtering is [maybe] a bad idea. Optional filtering is a great idea (and I use it, myself).
* It doesn't help the wasted bandwidth problem.
Unless spammers figure out their email isn't getting through. Each message is not free - it's just really cheap. If a spammer realizes that 100% of their spam to *@aol.com won't get through, they won't bother.
* Since the users don't know what mail they were going to get, there is much less accountability.
True, unless the ISP does the smart thing and has the option of sending you a digest every [whenever] with a list of senders and subjects so you could check and see if Bob@somewhere.net sent you something.
OTOH, if my ISP blocked the (legitimate) mail I sent, then I can complain to them.
How will you know?
* The ISP can be forced to implement arbitrary filters like "pro-terrorist", "anti-US", etc by the government and no one would be the wiser.
Yeah, "forced" - how? And that would stay quiet, how?
That only works in OOP if you actually are creating a derived class (and, depending on language, if the other programmer didn't make it a "final" method)
Or if you're writing in Obj-C. Using Obj-C, you can dynamically replace instance methods on the fly and call the previously defined method when you're done/before you start (or both, or not at all).
It's easy to do, and it's a dream if you need to patch a system, but it leads to code that is hard to debug/understand.
Nobody has asked the big question yet: How many mouse buttons do you get with that, or do you add it/them, too?
(from my iBook, with USB 3button mouse plugged in!)
Re:That's not really the problem.
on
NYT on RFID Tags
·
· Score: 1, Interesting
The fact that they continue to work for a very long time and the fact that they are, or can be, completely unique means that a store can identify YOU by your panties. National chains such as Walmart could track YOU and your panties all across the country. Suddenly they don't sound very nice, do they.
More power to 'em! Sooner or later they should be able to do this with those newfangled face recognition systems, anyway - and why should I mind? I was at that place at that time, it's their store - I want to know who is in my house at all times...
I just wish that ANYONE would come out with a modern JDK for FreeBSD. No, I'm not happy with the patchwork solution, and I'm not happy with linux emu (memory overhead, thanks).
Dunno how you can say that - you get as many bits as you want. Certainly, *I* bank using https with no fear.
Frankly, HTTP's upload mechanism is rather sucky as well.
Granted.
And FTP user/pass exchanges can certainly be dropped into an encrypted layer, the same way HTTP works with SSL.
See also sftp, scp, and whatever others there are out there. But note the adaption rate - not real good. Certainly my browser doesn't know what that protocol (sftp) is.
"Sorry, but I live behind various firewalls and am sick to death of FTP. The sooner it dies, the better." Maybe your firewall is stupid, or is intentionally denying it?
The thing that pisses me off most is CPAN updates. I have to tell every damn thing I use that I want PASSIVE ftp. I don't understand why that is not the default. That's not really the fault of the protocol - it's just that ftp is so damn old, and was designed before firewalls and NAT was common (or existed, really). Anyway, http just works.
[sorry if this got double-posted - I may have type-o'd ]
Let me preface this by saying that I have not done any Obj-C debugging in years.
The GUI debugger for PB is just a layer over gdb. It is unfortunate that it does the worst of both worlds: keeps you from having to learn gdb while hiding it's amazingly powerful features. As is the case with many GUI-less tools, gdb may be one of the most powerful debuggers there are - but the learning curve is damn steep.
Yes, it is possible to save breakpoints - you just have to edit your.gdbinit file. Does that suck? Yup, but that's how it is.
I hope that they do get around to integrating more of the powerful features of gdb with the GUI, but historically, this has been low priority. All the 'old time coders' know how to use the gdb commands and are used to it. It's really too bad.
It read more like a FUD article (to me) than anything useful. Seems like they spent 40% of the time saying things like "If you work an a poorly configured network, zeroconf may make some things seem worse."
Thanks for the heads up:-/
Zeroconf won't end world hunger, but it will make system administration much easier for admins who are on the ball. If you don't know a subnet from a hole in the ground, you're probably still hosed (if you're a network admin, anyway).
Rendez-vous is cool, but it still has a long way to go before it is as polished (from a user POV) as the old Appletalk system.
Yeah, how come it's not as well supported as a technology that is about a decade old?
Please. Rendezvous support is coming soon to printers near you.
I AM disappointed at the lack of system software support for Rendezvous thus far, but it's just a matter of coding things up. I expect this coming WWDC (may) to be Rendezvous heavy.
Re:You probably won't like this...
on
.NET or CORBA?
·
· Score: 1
SOAP is complicated and messy.
XMLRPC, on the other hand, is really really easy to implement, and is very cross-language.
It's just functional, and just passes data, but depending on your needs it might be enough.
Not true. If you have a good manager, and a good producer who is an asshole, the manager isolates them and let's them do their job without bothering the rest of the team. That's what managers are for - letting folks do what they do well. If a non, or even average producer is an asshole, then can them. But my all counts, that's not the case here.
Not that I've read the piece, yet, but I'd say that has nothing to do with being a developer. That has everything to do with being a release control engineer - which is another hat.
Yes, many developers wear more than one hat (developer, QA, RC, etc), but the RC hat is not the same as the developer hat.
That would make sense except for the fact that it invalidates the very reason for RH's existence, which is to provide precisely that sort of service. People who buy RH are the ones least likely to maintain the code.
You missed the "or pay anyone you like to maintain it" part.
It turns out (I'm certain) that if you REALLY wanted M$ to support '95 for you, they would. You'd just have to fund the entire effort yourself, plus whatever profit they wanted.
Likewise for Redhat. However, there are a lot of other folks you could convince to support whatever old version you want in the case of Redhat. It's not really feasible to try to get someone else to support M$ software - not the way you'd like, anyway.
I actually worked for a company where this was done. We were paid VERY good money to support a free (as in speech) product. This back in '96 or so.
Yet this is the very thing that Microsoft has been vilified for to no end in the past. Are we having short-term memory problems now?
2 points: 1. It is reasonable for companies to drop support, contrary to the BS that M$ got for the '95 EOL announcements around here. You may have confused the poster you responded to with one of the many... less reasonable ones around here.
2. You can grab "Redhat's code" and maintain it yourself, or pay anyone you like to maintain it. Not so with M$.
Slashdot Mirror
Pretty sure this has been done, and is called UseNet. I seem to remember having done something like this back in ... 1988. Oh, and I have a news reader now!
/. used it. Then I could just put together a kill file...
/., cowboy?
That's where the first spam that I ever saw happened - good old canter&siegel(sp?) and the green card scam.
Anyway, I do wish that more sites would use this grand ole protocol. I wish that
Wouldn't that be nice? Hey, I might even be convinced I should get a subscription if I could
news://slashdot.com/apple
COWBOW NEAL, HEAR ME! Do you kibo
Sure they will. Some spammers get paid per message sent, not per message responded to. Plus, since it costs next to nothing to send, why not send it? Maybe the filters will miss it.
Yeah, right. I should become a spammer - I could easily send millions of messages - to nobody[1-9999999]@dev.null. Think anyone will buy my service?
I believe that spammers get paid for messages austensibly delivered. If it becomes well known that AOL has a good filter, spammers will not bother (unless they have a really good payload). Or they will stop getting paid. This is simple econ, stop trying to make it into some kind of magic.
Although parent post sounds trollish, it has a valid point. Filtering incoming mail by the ISP is a bad idea, at least much worse than filtering outgoing ones.
Disagree. FORCED filtering is [maybe] a bad idea. Optional filtering is a great idea (and I use it, myself).
* It doesn't help the wasted bandwidth problem.
Unless spammers figure out their email isn't getting through. Each message is not free - it's just really cheap. If a spammer realizes that 100% of their spam to *@aol.com won't get through, they won't bother.
* Since the users don't know what mail they were going to get, there is much less accountability.
True, unless the ISP does the smart thing and has the option of sending you a digest every [whenever] with a list of senders and subjects so you could check and see if Bob@somewhere.net sent you something.
OTOH, if my ISP blocked the (legitimate) mail I sent, then I can complain to them.
How will you know?
* The ISP can be forced to implement arbitrary filters like "pro-terrorist", "anti-US", etc by the government and no one would be the wiser.
Yeah, "forced" - how? And that would stay quiet, how?
You're right:
National Do Not Call List
I do agree, though, that the email protocols could use serious fixing.
That only works in OOP if you actually are creating a derived class (and, depending on language, if the other programmer didn't make it a "final" method)
Or if you're writing in Obj-C. Using Obj-C, you can dynamically replace instance methods on the fly and call the previously defined method when you're done/before you start (or both, or not at all).
It's easy to do, and it's a dream if you need to patch a system, but it leads to code that is hard to debug/understand.
Nobody has asked the big question yet:
How many mouse buttons do you get with that, or do you add it/them, too?
(from my iBook, with USB 3button mouse plugged in!)
The fact that they continue to work for a very long time and the fact that they are, or can be, completely unique means that a store can identify YOU by your panties. National chains such as Walmart could track YOU and your panties all across the country. Suddenly they don't sound very nice, do they.
More power to 'em! Sooner or later they should be able to do this with those newfangled face recognition systems, anyway - and why should I mind? I was at that place at that time, it's their store - I want to know who is in my house at all times...
What's the problem?
What on earth do you want to use this for?
I guess you've never heard of VRML
I just wish that ANYONE would come out with a modern JDK for FreeBSD. No, I'm not happy with the patchwork solution, and I'm not happy with linux emu (memory overhead, thanks).
It would have been nice to know what OS[es] - client and server - you are using, as well as things like the number of clients you expect.
HTTP auth isn't all that secure either.
Dunno how you can say that - you get as many bits as you want. Certainly, *I* bank using https with no fear.
Frankly, HTTP's upload mechanism is rather sucky as well.
Granted.
And FTP user/pass exchanges can certainly be dropped into an encrypted layer, the same way HTTP works with SSL.
See also sftp, scp, and whatever others there are out there. But note the adaption rate - not real good. Certainly my browser doesn't know what that protocol (sftp) is.
"Sorry, but I live behind various firewalls and am sick to death of FTP. The sooner it dies, the better." Maybe your firewall is stupid, or is intentionally denying it?
The thing that pisses me off most is CPAN updates. I have to tell every damn thing I use that I want PASSIVE ftp. I don't understand why that is not the default. That's not really the fault of the protocol - it's just that ftp is so damn old, and was designed before firewalls and NAT was common (or existed, really). Anyway, http just works.
[sorry if this got double-posted - I may have type-o'd ]
FTP is quickly becoming a special-needs protocol. If you need authentication,
Yeah, if you need CLEAR TEXT auth, FTP is for you. If you want SSL auth, maybe enable auth for your http server.
uploads, directory listings,
Which http can do fine, thanks.
accessability with interactive tools, etc. then this is for you.
Dunno about this.
Mainly useful for web designers these days, IMO, since the site software packages can use the extra file metadata for synchronization.
I'd push for SSL webdav in an instant...
Sorry, but I live behind various firewalls and am sick to death of FTP. The sooner it dies, the better.
(best not to take this post too seriously - FTP just really pisses me off)
I thought that what [?]FS is for, where ?=> N, or A, for example.
Damn, I *AM* crazy.
Anyone who doesn't think this is the beginning of a huge market is insane.
I must be insane.
What is the use case for this, again?
Let me preface this by saying that I have not done any Obj-C debugging in years.
.gdbinit file. Does that suck? Yup, but that's how it is.
The GUI debugger for PB is just a layer over gdb. It is unfortunate that it does the worst of both worlds: keeps you from having to learn gdb while hiding it's amazingly powerful features. As is the case with many GUI-less tools, gdb may be one of the most powerful debuggers there are - but the learning curve is damn steep.
Yes, it is possible to save breakpoints - you just have to edit your
I hope that they do get around to integrating more of the powerful features of gdb with the GUI, but historically, this has been low priority. All the 'old time coders' know how to use the gdb commands and are used to it. It's really too bad.
I doubt many hardware vendors will add Rendezvous support until Windows (aka 90% of the user market) includes Rendezvous.
l
From http://www.apple.com/macosx/jaguar/rendezvous.htm
Epson, HP, Canon, Brother, Chaparral, Lexmark, TiVo, Xerox
So, by number that's just 8. But that's rather a large 8, I think...
It read more like a FUD article (to me) than anything useful. Seems like they spent 40% of the time saying things like "If you work an a poorly configured network, zeroconf may make some things seem worse."
:-/
Thanks for the heads up
Zeroconf won't end world hunger, but it will make system administration much easier for admins who are on the ball. If you don't know a subnet from a hole in the ground, you're probably still hosed (if you're a network admin, anyway).
Rendez-vous is cool, but it still has a long way to go before it is as polished (from a user POV) as the old Appletalk system.
Yeah, how come it's not as well supported as a technology that is about a decade old?
Please. Rendezvous support is coming soon to printers near you.
I AM disappointed at the lack of system software support for Rendezvous thus far, but it's just a matter of coding things up. I expect this coming WWDC (may) to be Rendezvous heavy.
SOAP is complicated and messy.
XMLRPC, on the other hand, is really really easy to implement, and is very cross-language.
It's just functional, and just passes data, but depending on your needs it might be enough.
Not true. If you have a good manager, and a good producer who is an asshole, the manager isolates them and let's them do their job without bothering the rest of the team. That's what managers are for - letting folks do what they do well.
If a non, or even average producer is an asshole, then can them. But my all counts, that's not the case here.
They're failing at #1, and as far a I know, #2 would be illegal - it's basically exactly what they were found guilty of in court already.
And that would change things...how?
Not that I've read the piece, yet, but I'd say that has nothing to do with being a developer. That has everything to do with being a release control engineer - which is another hat.
Yes, many developers wear more than one hat (developer, QA, RC, etc), but the RC hat is not the same as the developer hat.
That would make sense except for the fact that it invalidates the very reason for RH's existence, which is to provide precisely that sort of service. People who buy RH are the ones least likely to maintain the code.
You missed the "or pay anyone you like to maintain it" part.
It turns out (I'm certain) that if you REALLY wanted M$ to support '95 for you, they would. You'd just have to fund the entire effort yourself, plus whatever profit they wanted.
Likewise for Redhat. However, there are a lot of other folks you could convince to support whatever old version you want in the case of Redhat. It's not really feasible to try to get someone else to support M$ software - not the way you'd like, anyway.
I actually worked for a company where this was done. We were paid VERY good money to support a free (as in speech) product. This back in '96 or so.
Yet this is the very thing that Microsoft has been vilified for to no end in the past. Are we having short-term memory problems now?
... less reasonable ones around here.
2 points:
1. It is reasonable for companies to drop support, contrary to the BS that M$ got for the '95 EOL announcements around here. You may have confused the poster you responded to with one of the many
2. You can grab "Redhat's code" and maintain it yourself, or pay anyone you like to maintain it. Not so with M$.