I'm not sure if you were being sarcastic, but I was using Google as a verb.
Re:Good old RubyOnRails
on
Advanced Rails
·
· Score: 2, Interesting
In either case, it's the people you have a problem with. There are far fewer legitimate complaints about the Rails Framework than there are about Rails people.
I agree entirely, although occasionally some of the more arrogant things that I don't agree with make it into the Rails Framework.
So far, enough people think like me that it hasn't been a problem -- there's always a plugin or set of scripts somewhere to help me out. A recent example: Schema Validations. While not all validations can be reflected in the database schema, some can, and arguably, it is a Good Thing for stuff to be validated by Rails before it hits the database. You should never have an error coming back from the database about exceeding a VARCHAR(255), but do you really want "validates_length_of:foo, 255" everywhere?
It gets even worse when your database supports real foreign keys. Sure, they'll break down with polymorphism, but won't you still have a large number of relationships for which foreign keys would make sense?
Fortunately, there's a plugin for that, and another if you use real foreign keys.
Sure, it's harder to go without, but if you've got a good reason for doing things a certain way you're free to do things as you wish.
But this, combined with "Convention over Configuration", means that it is very often not possible to do what you want without either performing deep surgery on Rails (not always possible in a plugin, so expect to maintain it yourself if your patch is rejected), or, as in your example, scrapping a chunk of the framework altogether.
And if you have to scrap a large chunk of the framework, or the entire framework, is there really any point in claiming to be a Rails developer anymore? Maybe at that point, you'd be better off with a framework like Merb, which, I'm told, is much more hackable than Rails. In fact, the very concept of Rails itself (stay on the rails) goes against software reusability, to some extent.
All that said, I don't have anything particularly painful right now -- I'm developing a Rails app, full-time, and I'd be lying if I said I didn't like it. But the point is, it's not always laziness -- sometimes it is the framework making a particular way of doing something as hard as possible, on purpose. (Example: Google "syntactic vinegar.") Sometimes, it's not on purpose, but it is there -- these don't bother me so much, because I can always try sending a patch. (Example: Ever try extending an AssociationProxy after it's been created? Don't. But believe it or not, there is a use for that.)
Re:Please O PLEASE stop the Ruby hype
on
Advanced Rails
·
· Score: 2, Insightful
This is one book review. In what way is it hype?
I'm seeing more Anti-Ruby/Rails FUD here than pro-Ruby/Rails hype.
Would you say the same thing if it was a.NET book being reviewed?
Re:"Advanced" for RoR is routine for everyone else
on
Advanced Rails
·
· Score: 2, Insightful
I was hoping for this book to really discuss pushing RoR to the max, allowing us to do what we can't currently do easily with J2EE or.NET.
From what I can say, there's still some things that RoR routinely does more easily than J2EE or.NET -- it's just that good ideas tend to propagate, so I suspect it's not as dramatic a difference anymore.
Re:Good old RubyOnRails
on
Advanced Rails
·
· Score: 3, Informative
Community all depends on whether you're doing things The Rails Way or not. (In fact, one of two books I've read to teach myself Rails was called "The Rails Way.")
But just look at a coupleexamples of why people run away from the community. (For those who don't know, the second example is DHH, creator of Rails.)
Keep in mind, someone else has been posting also. I don't personally have a travelling issue, as I can VPN back to my own server. Not everyone can do this.
Why wouldn't you have your MX record set up properly?
All kinds of reasons. Someone pointed out the mess that can happen in mergers, acquisitions, and splits, resulting in some very interesting MX records (or lack thereof). Right now, I have some servers on Amazon EC2 which want to send mail, but EC2 has dynamically allocated IP addresses, which puts it on a Spamhaus blacklist, which is used by AOL, Comcast, and others. So in order for this mail to not be spam, I have to relay it through somewhere else. However, it's entirely possible that we'll end up going with a service which is configured to be an outbound relay, but not a secondary MX -- thus, it shouldn't actually be in our MX record, but it is sending mail as us.
Oh, and the MX record isn't even supposed to be required.
As for mailing lists, they are a hack to send lots of emails to a list, but you could pretty easily redefine the way they work for the new protocol.
In a way which is backwards-compatible with existing, high-volume mailing lists?
For instance, if it's a smtpx mailing list, The user give's their mailing list public key to the mailing list server, which then uses that to get the email sent quicker through their regular ISP.
So now users have to do public-key encryption. (Why not just use a good old-fashioned user-to-user PGP trust network?)
And now what do you do when the mailing list is spammed? Or when you want to be a part of a particular list which only supports straight SMTP?
But as I said before, it's a band-aid, not a solution. All that email is still sent, all the bandwidth is wasted, and many domains don't have very good spam filtering because they can't afford false positives.
I don't get false positives, tarpitting would stop the bandwidth wastage, and now you're complaining that many domains don't have very good spamfiltering -- why would such domains prefer your solution over mine, if they have to adapt anyway?
It's also interesting that you use tar pitting, which is basically a time delay, and then complain that my system had delays that are unacceptable.
Because your delays are based on not supporting a particular protocol. Mine are based on having actually seen spam come from that IP address -- and having seen it myself, which means there's no trust network to poison or game. That, and it gets to be my own definition of spam -- not everyone has the same definition.
But also, I don't require tarpitting to work -- I still see almost no spam in my inbox, even though I haven't implemented a tarpit yet. So, tarpitting is a mechanism to cut down on the bandwidth usage, not actually itself an antispam mechanism.
2) The servers also allow a client to connect using xmtpx, lets say over SSL as well.
It's worth mentioning that we do already support SMTP over SSL.
6) Destination server contacts the domain in the from header, and asks if they sent that message by providing the signature it attached to the email (or some other means, maybe a new header, it doesn't really matter). If it says yes, all okay. Otherwise, email is rejected.
Again -- only the From field is authenticated?
Also: What about the domain that the server itself actually claimed to be sending from? And you're now saying that multiple mailservers must all coordinate and record every mail sent, in case they get contacted back?
And it does seem to me like a potential DoS attack, though I'm not quite sure how. It does make me nervous that it's checking back, although I know this is done elsewhere.
7) Destination server scans it using current spam filteri
You send the email to mydomain.com, my server then asks aol if they sent that email, they say no, I reject your email.
No, the point here is, aol did send that email. Are you saying that unauthenticated SMTP is not allowed?
So sorry, so sad. That practice has to be let go for the love of god!
It's not going to. Any solution which fails to take that into account will not work, because it will never be implemented.
Plus, that's not the only time mail is sent from a server which differs from those explicitly listed in the MX records.
Acts as a new email, this should not be effected except that the "from" becomes the address doing the forwarding.
Which sucks.
Take a look at my email address -- I came up with this when I was 15. I'm probably going to replace it sometime soon. Does that mean that everyone who still sends mail to the old address should appear to come from ninja@slaphack.com? That if I were to reply to such a mail, it would go to ninja@slaphack.com if I'm not careful?
Oh, right, reply-tos can be left alone. (What if one isn't set?) But now you have that confusing situation where Reply-To and From don't match up, which can be just as confusing as when From and "received" don't match up.
However, even barring other consequences, I like to be able to sort my mail by sender, sometimes into conversations. Why should I have to lose this ability on forwarded mail?
What about them?
The fact that you don't take them into account, at all. A new header is a new opportunity to forge a header.
So you'll have to wait maybe 10 or 20 minutes for your email, and only if you're domain implements the delay. I fail to see how it's a show stopper.
It is pretty annoying -- especially if my domain implements the delay, and my boss' email gets caught. Five minutes later, he wants to know if I got his email.
Or take those "Please verify your email address" emails. I generally want to get those instantly.
And again -- if this only delays each individual email 20 mins from when it would have arrived otherwise, how does it make an impact on spam?
You start with a neutral trust, so you could get some spam through, but not too many before you're score plummeted. The goal is not to eliminate spam (that's impossible), but to make it impractical to send it in mass quantity.
So botnets can still send massive amounts of spam. As a bonus, if it's careful, a botnet could probably game the system and get a positive score to start out with.
The cumulative thing is an interesting idea. But the delay is not to prevent spam, it's to make other domains want to implement smtpx so that their legitimate mail is not delayed.
Which means you still need immediate total cooperation of everyone all at once. Basically, if you implement this on a one-person domain, you'll just annoy yourself. You'll never get Gmail, Hotmail, AOL, Comcast, etc to agree to it, as if any one of them implements it by themselves, it's a net loss for their customers unless enough other domains implement it.
There are a lot of them, but just one example is here.
Interesting -- a bunch of mathematics that I don't understand yet. Probably could spend some time later...
And still doesn't show me anything about this working in the real world. (Last time I was on Gnutella, there were still entirely too many spam/virus results.)
Only as much as all other email is effected. Legitimate reasons for spoofing the "from" header would be affected, but that's the whole point!
Doesn't change the fact that legitimate reasons for spoofing the "from" header are a requirement for email, as implemented.
Why, oh why, do people hold onto this? Jesus Christ. Set up authentication over TLS. You can connect to your server from anywhere. Wow. here is a tutorial for postfix.
Yes, because asking home users to configure their ISP's postfix server is really going to work.
Also, as another poster pointed out, people don't always have their outgoing mailserver set up as a proper MX record for various other reasons -- which means your system would be an inconvenience for a lot of people, for no gain, as I still don't think it would work, once implemented.
There wouldn't be any besides delays due to the rate limiting
Which is unacceptable. Mailing lists can get some very heavy traffic, and building an upper bound to that traffic into the protocol is a bad idea. Plus, set that upper bound too high, and you're not doing much to stop spam, either.
as long as the domain the list is coming from is really the right domain.
Does this fall under the "forging headers" part? That is: If I change the "from" header to say "from mylist@example.com" on every single email, is that forgery? Certainly if I leave it alone, it appears to be forgery.
Don't forget, not messing with the headers is a Good Thing for a mailing list to do. Having "reply" go to the entire list is not good. What usually ends up happening is, people use reply-to-all, which has the list as a CC -- and has the nice side effect of, you're more likely to make a mistake and send something to one person, meaning to send it to the list, than to make a mistake and send something to the list, meaning to send it to one person. Sending something to one person isn't a big deal, just resend it to the whole list. But if you sent something private to the whole list... whoops.
Yes, this is the real crux of the problem. How do you build trust? There are several algorithms out there for such things. Coming up with one for this is beyond the scope of a slashdot thread, but I believe it's doable.
I have never seen a trust net on this scale which cannot be gamed -- and there's still the problem of, how do I get into the net in the first place?
So, it's beyond the scope of this thread... Would you care to link to a whitepaper? Or anything? Because right now, you've proposed a solution which, among the other problems we've pointed out, also relies on a bit of technology which you refuse to explain. And again -- even if it worked, would it have undesirable side effects?
Now, tell me what's wrong with my solution, I'm curious -- especially considering my solution works, right now, with no cooperation required from anyone else.
I always envision a system where a new protocol (say smtpx) simply adds to smtp, adding authentication of where the mail is actually being sent from, allowing rate limiting error codes for domains/addresses, and a relationship trust mechanism built between servers.
This could be built on top of SMTP. The only problem is that either way, you still have to accept mail from people who aren't using it.
Basically, a server could implement smtpx, so that all emails sent using it must be authenticated (no more header spoofing)
How would this work beyond the server? Say AOL implements this -- how does it prevent me from claiming to send mail from someoneelse@aol.com?
What about people who travel around on a laptop, and thus borrow SMTP servers to send mail "from" their home email address?
What about people who want a different Reply-To, on purpose?
What about deliberate forwarding accounts? That is, an alias such that mail sent "to" one person ends up arriving somewhere else?
What about new, as-yet-uninvented headers?
Right now, the best measure I can think of similar to yours is to verify that the actual 'from' in the SMTP itself is from an IP that's actually mentioned in an MX record for said server. And even then, I'd rather it flag the mail, or contribute to some "spam" weight, rather than block it outright.
cannot send X number of emails per Y period (for instance, not more than 10 per minute)
So no more mailing lists. Or at least, you would need to treat them specially -- which means mailing lists must now be approved by some authority.
and the sending server must have a trust score of at least 50/100 with at least 3 other trusted servers
So how do I get into this web of trust, if I've just set up a brand-new mailserver?
Also, what happens in the case where a public mailing list gets spammed? Are we not allowed to have public mailing lists? Yes, it would provide an incentive to clean up the list, but I think pissed-off users and bandwidth costs would help with that, too -- either way, I don't want the legitimate mail coming from that server to be flagged.
Regular smtp would still be accepted for the time being, but would be put on a 30 minute delay before being delivered (or has some other limitation as incentive to use smtpx - like maybe no attachments?).
30 minute delay solves nothing -- someone sends you 1000 spams, getting all of them 30 minutes later won't help anything. Same with no attachments -- they do nothing to stop spam, only annoy people who are still using SMTP for whatever reason.
If you make the delay cumulative -- that is, each untrusted message will take 30 mins past when the last untrusted message was sent -- then the risk of false positives is too high.
Now of course you need some mechanism so that you can't poison or fake the trust relationships, but I believe problems like that are pretty well solved in modern p2p systems.
Really? Care to point to where and how they are solved?
So you've just created a system which kills two major features of SMTP, without even denting the spam problem. I don't mean to sound too harsh, as I can't blame you for trying, and it is a hard problem -- but this is how you find out just how hard a problem it is.
Just my 2 cents... now where is someone with that list of things they put X's in that say why such an idea would never work?
I don't entirely agree with that form, as I think at least a couple of the checkboxes are for things which can work in practice, but here you go:
Except it is a bizarre one -- for one, people can already circumvent the AppStore by creating web apps, although these are limited. For another, why not simply restrict the source of the interpreted code to things that have been vetted by Apple?
The idea that we should continue to write implicitly sequential programs and have some tool extract the parallelism by dividing the program into concurrent threads is completely ass-backwards, IMO.
Maybe so, but it's certainly not what I was suggesting.
Rather, I'm suggesting that we should have tools which make it easy to write a parallel model, even if individual tasks are sequential -- after all, they are ultimately executed in sequence on each core.
One reason is that it uses a coarse-grain approach to parallelism; you can't even parallelize a quicksort routine (an ideal candidate for parallel processing) in Erlang.
Can't? Or isn't easy to?
Consider also that Erlang is not deterministic and has no mechanism for automatic load balancing.
I suspect such a mechanism would be easier to build in Erlang than in most other modern languages. And parallel programming is inherently non-deterministic.
It might not be fast, though, as what immediately came to mind is a bunch of worker threads and one master thread -- workers notify the master when they're ready for more tasks.
The solution is not to use threads at all.
I am referring to threads as the OS concept, not as a programming concept. That is: I am not talking about the Erlang processes, I'm talking about the real OS threads it uses (generally one per core, or just one). And I'm referring to threads as a generalization of OS-level processes.
Are you suggesting that a different CPU and/or OS architecture could be built which would make it possible to write deterministic, threaded programs? Or are you talking about an entirely language-level approach?
Or are you suggesting that we try to keep cranking up the clock?
Trying to derive moral codes is simply an attempt to rationalize the resulting behavior, to make it seem noble, rather than what it actually is: merely obeying your instincts.
Maybe so, but it also helps to turn it into something I can communicate, and maybe convince others of.
Actually, filters have been remarkably good for me. At work (Gmail), a spam slips through every few days. At home, I have an "unsure" box, which gets mostly spam (maybe 10 a day) and the occasional innocent mail -- out of hundreds hitting the actual spam folder.
Also, just about any other system would have problems worse than spam -- but it's hard to talk about something abstract. What, exactly, did you have in mind?
I come from a country where TV station are limited by law to one ad break per movie/tv show and where they don't pollute the screen with overlays of next weeks programming.
I agree with the other poster -- where is this country?
I find US tv simply unwatchable and if it is anything like the futur of googletube you can be sure that I'll be amongst the first to install "video ad block" or whatever the name will be.
I agree. Over here we call it "DVRs" or "BitTorrent", or, occasionally, "Rentals" -- it's very likely that I'll be able to buy a very good HDTV set soon, but if the networks don't catch on, the only service I'd be willing to subscribe to is Netflix -- and even then, I'd have to be stripping ads out manually.
Perhaps the most offensive to me is the "you wouldn't steal a car" bullshit. Look, if I'd pirated it, your "you wouldn't steal" ad wouldn't be there! Ergo, if I'm watching it, that means I'm a legitimate customer, and you're insulting me by calling me a pirate -- which really, really makes me want to pirate it!
Ubuntu fares a little better, but again, no mp3 and no decent graphics unless you enable the proprietary driver/download extra stuff. Then it insists on displaying a graphics driver 'warning' in the taskbar, about something I chose to do, which fyi, hasn't harmed my pc one bit.
If you call "pretty much fully automatic" just a "little better", maybe. But seriously, now you're complaining about a taskbar icon? On an OS that doesn't even require you to have a taskbar if you don't want it?
And it took a bit for me to learn, but I can now go from zero to a fully functional Ubuntu -- flash, mp3, wmv, drivers, everything -- in about as long as it takes to install, which is less than an hour, last I checked.
Actually, no, as a technical user, it's incredibly easy to see the reason that the certificate isn't valid -- and if there were shenanigans going on, it wouldn't be because it was expired.
Also, https means it is actually possible to be secure -- you check that https is in the URL, and you refuse to connect if the certificate isn't valid.
Some sites default to http, but allow https. But no https means that option isn't even there -- you are going to be vulnerable, period. That's one of the many reasons I don't use MySpace.
Without God, you must explain moral codes in practical terms.
No, you don't. You can easily have moral dogma without religious dogma. Didn't your parents ever tell you to do something "Because I said so!"
At a certain point, you do, because the person will outgrow "what Momma said", but people can also outgrow "what God said." So you'll need to understand in practical terms, anyway.
The most basic (lie, cheat, steal)are easy enough. Some of the less obviously explained moral codes are both very important and not easy to explain the practicality thereof. (Envy, gluttony, etc.)
Envy and gluttony are easier to explain, I think, than lying, cheating, and stealing. Envy is just going to make you unhappy, or cause you to do something stupid, especially in the case of a woman, where there are plenty of women you could chase who aren't already in a relationship.
Gluttony is even easier -- if you are a glutton, you'll become fat, and you probably don't want to be fat -- if only out of vanity.
But what about lying? Or cheating? The only way this can work is if you can make a case for the Golden Rule, which is tricky. Since you seem to be talking about indoctrinating children, they're not going to get empathy until about age six or so.
And stealing only works because of the possibility of jail time -- again, without the Golden Rule.
Much less obvious is the long term benefit to society when everyone obeys these rules. Both explaining the full logic of why that is so, and getting the student to accept your and societie's experience is a damn near impossible task with an empty slate of a child or a hormone-driven teenager.
Not at all. My parents did that to me, both as a child and as a teenager, and I turned out alright.
Now, they did start with saying it's "bad", but no connection was ever made with religion. The only things that they told me to do because God told me to were religious things -- my Bar-Mitzvah, for instance -- and even then, an alternate explanation was ready (tradition) in case I questioned the religion.
But seriously, even explaining the consequences to society is absurdly easy. "What if everyone littered?" And if they don't listen to you about that, they won't listen to you about God, either.
Religion is a way of passing down millennia of hard-learned lessons in a way that leaves no room for argument.
And considering how some of these lessons are no longer relevant -- and, indeed, some of them have been dropped completely -- I still don't see it.
One example: Pork is not kosher, perhaps because of certain -- worms, I think? -- which used to be a real problem. In the modern world, we can keep most of our food reasonably clean, so I see no reason to continue that tradition. But the problem is, since the only reason we got was "God said so," we don't really know if that was the reason -- so the only way to preserve that knowledge is to also preserve the ignorance ("The world is flat!...Ok, it's round, but it's the center of the universe!") because, after all, who are you to decide what part of what God teaches is false?
And that's another problem with religion -- why not just pass down the lesson with the reason? After all, if you say "Do as I say because God said so, and no arguing," you've lost as soon as the person decides to argue -- which means that those who leave religion are almost certainly going to lose a few of those lessons.
The whole country's got a fucked up mentality. We all got a gang mentality. Republicans are fucking idiots. Democrats are fucking idiots. Conservatives are idiots and liberals are idiots.
Anyone who makes up their mind before they hear the issue is a fucking fool. Everybody, nah, nah, nah, everybody is so busy wanting to be down with a gang! I'm a conservative! I'm a liberal! I'm a conservative! It's bullshit!
Be a fucking person. Listen. Let it swirl around your head. Then form your opinion.
No normal decent person is one thing. OK!?! I got some shit I'm conservative about, I got some shit I'm liberal about. Crime - I'm conservative. Prostitution - I'm liberal.
Keep in mind, this was a comedy show, and the delivery was actually pretty hilarious. But I think it applies.
Sorting all news into one thing or another is just an extension of this mentality, and it is harmful. Would you tolerate it if they sorted it into Black News and White News? Or into News for Women, and News for Men? Put the gardening and housekeeping on News for Women, and the tech and business stuff on News for Men...
What bothers me here is, your comment asking us to respect what you're saying got +5 insightful. ElizabethGreene's comment hasn't been modded at all. It's entirely possible that I'll get modded up for pointing this out, and she still won't get modded up.
So, apparently, Slashdotters care that you're treated fairly, and that you have breasts, but they don't care what you have to say?
I suppose it's also possible that comment wasn't particularly interesting -- or it wasn't to me, anyway -- but it still bothers me. I guess it's easier when most of us have ambiguous names.
First, how much effort will it take to optimize it, versus throwing another core at it? Or computer? Not always an option, but take, say, Ruby on Rails -- it wouldn't scale to 1000 cores, but it might scale to 1000 separate machines. And yes, it could probably run four or five times faster -- and thus require four or five times less hardware -- but at what cost? Ruby itself is slow, and there are certain aspects of it which will always be slow.
But, you see, the advantage is that development is quicker -- enough to justify the extra hardware expense -- and as soon as your fast(er) Perl, C, or Java needs to scale past that one machine, you have to deal with the same issues. (Did you really think Slashdot runs on a single 1GHz CPU?)
Second: There are enough applications that are CPU-bound that you shouldn't go insulting people offhand about it. Raytracing (or pretty much any rendering) is massively parallizable -- and again, it's that same problem. If you're very good, you might squeeze another 10% out of the renderer -- so the renderfarm will be 1350 beige boxes instead of 1500.
Oh, and the overwhelming majority of code which is slow because it's bad would gain nothing from multiple cores.
I know I built a scheme exactly like this in Perl, once. And Erlang is built around message-passing, which could be used to implement something like this.
And I don't think it needs to be a bottleneck unless it needs to be sequential. All you do is, have multiple LINDAs (or queues, or jars, or whatever), and have multiple sources to each.
For example: Suppose you wanted that raytracer to do some simple anti-aliasing which took into account the surrounding pixels. The antialiasing "jar" could be fed by all of the initial threads. Or, in Erlang terminology, you'd fire up a new process for each antialiased pixel, and after rendering each unantialiased pixel, it sends a message with the result to each antialiased pixel which is interested. As soon as you get one area sufficiently rendered, the antialiasing can start.
Maybe you're right, though -- I did notice that a benchmark designed to test exclusively Erlang's message-passing features ended up running slower when I told Erlang to run on both cores.
Slashdot Mirror
I'm not sure if you were being sarcastic, but I was using Google as a verb.
I agree entirely, although occasionally some of the more arrogant things that I don't agree with make it into the Rails Framework.
So far, enough people think like me that it hasn't been a problem -- there's always a plugin or set of scripts somewhere to help me out. A recent example: Schema Validations. While not all validations can be reflected in the database schema, some can, and arguably, it is a Good Thing for stuff to be validated by Rails before it hits the database. You should never have an error coming back from the database about exceeding a VARCHAR(255), but do you really want "validates_length_of :foo, 255" everywhere?
It gets even worse when your database supports real foreign keys. Sure, they'll break down with polymorphism, but won't you still have a large number of relationships for which foreign keys would make sense?
Fortunately, there's a plugin for that, and another if you use real foreign keys.
But this, combined with "Convention over Configuration", means that it is very often not possible to do what you want without either performing deep surgery on Rails (not always possible in a plugin, so expect to maintain it yourself if your patch is rejected), or, as in your example, scrapping a chunk of the framework altogether.
And if you have to scrap a large chunk of the framework, or the entire framework, is there really any point in claiming to be a Rails developer anymore? Maybe at that point, you'd be better off with a framework like Merb, which, I'm told, is much more hackable than Rails. In fact, the very concept of Rails itself (stay on the rails) goes against software reusability, to some extent.
All that said, I don't have anything particularly painful right now -- I'm developing a Rails app, full-time, and I'd be lying if I said I didn't like it. But the point is, it's not always laziness -- sometimes it is the framework making a particular way of doing something as hard as possible, on purpose. (Example: Google "syntactic vinegar.") Sometimes, it's not on purpose, but it is there -- these don't bother me so much, because I can always try sending a patch. (Example: Ever try extending an AssociationProxy after it's been created? Don't. But believe it or not, there is a use for that.)
This is one book review. In what way is it hype?
.NET book being reviewed?
I'm seeing more Anti-Ruby/Rails FUD here than pro-Ruby/Rails hype.
Would you say the same thing if it was a
From what I can say, there's still some things that RoR routinely does more easily than J2EE or .NET -- it's just that good ideas tend to propagate, so I suspect it's not as dramatic a difference anymore.
Community all depends on whether you're doing things The Rails Way or not. (In fact, one of two books I've read to teach myself Rails was called "The Rails Way.")
But just look at a couple examples of why people run away from the community. (For those who don't know, the second example is DHH, creator of Rails.)
Keep in mind, someone else has been posting also. I don't personally have a travelling issue, as I can VPN back to my own server. Not everyone can do this.
All kinds of reasons. Someone pointed out the mess that can happen in mergers, acquisitions, and splits, resulting in some very interesting MX records (or lack thereof). Right now, I have some servers on Amazon EC2 which want to send mail, but EC2 has dynamically allocated IP addresses, which puts it on a Spamhaus blacklist, which is used by AOL, Comcast, and others. So in order for this mail to not be spam, I have to relay it through somewhere else. However, it's entirely possible that we'll end up going with a service which is configured to be an outbound relay, but not a secondary MX -- thus, it shouldn't actually be in our MX record, but it is sending mail as us.
Oh, and the MX record isn't even supposed to be required.
In a way which is backwards-compatible with existing, high-volume mailing lists?
So now users have to do public-key encryption. (Why not just use a good old-fashioned user-to-user PGP trust network?)
And now what do you do when the mailing list is spammed? Or when you want to be a part of a particular list which only supports straight SMTP?
I don't get false positives, tarpitting would stop the bandwidth wastage, and now you're complaining that many domains don't have very good spamfiltering -- why would such domains prefer your solution over mine, if they have to adapt anyway?
Because your delays are based on not supporting a particular protocol. Mine are based on having actually seen spam come from that IP address -- and having seen it myself, which means there's no trust network to poison or game. That, and it gets to be my own definition of spam -- not everyone has the same definition.
But also, I don't require tarpitting to work -- I still see almost no spam in my inbox, even though I haven't implemented a tarpit yet. So, tarpitting is a mechanism to cut down on the bandwidth usage, not actually itself an antispam mechanism.
It's worth mentioning that we do already support SMTP over SSL.
Again -- only the From field is authenticated?
Also: What about the domain that the server itself actually claimed to be sending from? And you're now saying that multiple mailservers must all coordinate and record every mail sent, in case they get contacted back?
And it does seem to me like a potential DoS attack, though I'm not quite sure how. It does make me nervous that it's checking back, although I know this is done elsewhere.
I am not the issue here.
Millions of home users are the issue here. The kind of people who are still using AOL dialup.
Oh, and simply having authenticated SMTP doesn't mean it's configured to relay from outside its own network.
It's not a bad idea, and I think it should be done.
You're right about NAT, though -- at least a few ISPs are starting to run NAT at the ISP level. We need IPv6 badly.
No, the point here is, aol did send that email. Are you saying that unauthenticated SMTP is not allowed?
It's not going to. Any solution which fails to take that into account will not work, because it will never be implemented.
Plus, that's not the only time mail is sent from a server which differs from those explicitly listed in the MX records.
Which sucks.
Take a look at my email address -- I came up with this when I was 15. I'm probably going to replace it sometime soon. Does that mean that everyone who still sends mail to the old address should appear to come from ninja@slaphack.com? That if I were to reply to such a mail, it would go to ninja@slaphack.com if I'm not careful?
Oh, right, reply-tos can be left alone. (What if one isn't set?) But now you have that confusing situation where Reply-To and From don't match up, which can be just as confusing as when From and "received" don't match up.
However, even barring other consequences, I like to be able to sort my mail by sender, sometimes into conversations. Why should I have to lose this ability on forwarded mail?
The fact that you don't take them into account, at all. A new header is a new opportunity to forge a header.
It is pretty annoying -- especially if my domain implements the delay, and my boss' email gets caught. Five minutes later, he wants to know if I got his email.
Or take those "Please verify your email address" emails. I generally want to get those instantly.
And again -- if this only delays each individual email 20 mins from when it would have arrived otherwise, how does it make an impact on spam?
So botnets can still send massive amounts of spam. As a bonus, if it's careful, a botnet could probably game the system and get a positive score to start out with.
Which means you still need immediate total cooperation of everyone all at once. Basically, if you implement this on a one-person domain, you'll just annoy yourself. You'll never get Gmail, Hotmail, AOL, Comcast, etc to agree to it, as if any one of them implements it by themselves, it's a net loss for their customers unless enough other domains implement it.
Interesting -- a bunch of mathematics that I don't understand yet. Probably could spend some time later...
And still doesn't show me anything about this working in the real world. (Last time I was on Gnutella, there were still entirely too many spam/virus results.)
Doesn't change the fact that legitimate reasons for spoofing the "from" header are a requirement for email, as implemented.
Yes, because asking home users to configure their ISP's postfix server is really going to work.
Also, as another poster pointed out, people don't always have their outgoing mailserver set up as a proper MX record for various other reasons -- which means your system would be an inconvenience for a lot of people, for no gain, as I still don't think it would work, once implemented.
Which is unacceptable. Mailing lists can get some very heavy traffic, and building an upper bound to that traffic into the protocol is a bad idea. Plus, set that upper bound too high, and you're not doing much to stop spam, either.
Does this fall under the "forging headers" part? That is: If I change the "from" header to say "from mylist@example.com" on every single email, is that forgery? Certainly if I leave it alone, it appears to be forgery.
Don't forget, not messing with the headers is a Good Thing for a mailing list to do. Having "reply" go to the entire list is not good. What usually ends up happening is, people use reply-to-all, which has the list as a CC -- and has the nice side effect of, you're more likely to make a mistake and send something to one person, meaning to send it to the list, than to make a mistake and send something to the list, meaning to send it to one person. Sending something to one person isn't a big deal, just resend it to the whole list. But if you sent something private to the whole list... whoops.
I have never seen a trust net on this scale which cannot be gamed -- and there's still the problem of, how do I get into the net in the first place?
So, it's beyond the scope of this thread... Would you care to link to a whitepaper? Or anything? Because right now, you've proposed a solution which, among the other problems we've pointed out, also relies on a bit of technology which you refuse to explain. And again -- even if it worked, would it have undesirable side effects?
Now, tell me what's wrong with my solution, I'm curious -- especially considering my solution works, right now, with no cooperation required from anyone else.
This could be built on top of SMTP. The only problem is that either way, you still have to accept mail from people who aren't using it.
How would this work beyond the server? Say AOL implements this -- how does it prevent me from claiming to send mail from someoneelse@aol.com?
What about people who travel around on a laptop, and thus borrow SMTP servers to send mail "from" their home email address?
What about people who want a different Reply-To, on purpose?
What about deliberate forwarding accounts? That is, an alias such that mail sent "to" one person ends up arriving somewhere else?
What about new, as-yet-uninvented headers?
Right now, the best measure I can think of similar to yours is to verify that the actual 'from' in the SMTP itself is from an IP that's actually mentioned in an MX record for said server. And even then, I'd rather it flag the mail, or contribute to some "spam" weight, rather than block it outright.
So no more mailing lists. Or at least, you would need to treat them specially -- which means mailing lists must now be approved by some authority.
So how do I get into this web of trust, if I've just set up a brand-new mailserver?
Also, what happens in the case where a public mailing list gets spammed? Are we not allowed to have public mailing lists? Yes, it would provide an incentive to clean up the list, but I think pissed-off users and bandwidth costs would help with that, too -- either way, I don't want the legitimate mail coming from that server to be flagged.
30 minute delay solves nothing -- someone sends you 1000 spams, getting all of them 30 minutes later won't help anything. Same with no attachments -- they do nothing to stop spam, only annoy people who are still using SMTP for whatever reason.
If you make the delay cumulative -- that is, each untrusted message will take 30 mins past when the last untrusted message was sent -- then the risk of false positives is too high.
Really? Care to point to where and how they are solved?
So you've just created a system which kills two major features of SMTP, without even denting the spam problem. I don't mean to sound too harsh, as I can't blame you for trying, and it is a hard problem -- but this is how you find out just how hard a problem it is.
I don't entirely agree with that form, as I think at least a couple of the checkboxes are for things which can work in practice, but here you go:
Your post advocates a
(X) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply
Except it is a bizarre one -- for one, people can already circumvent the AppStore by creating web apps, although these are limited. For another, why not simply restrict the source of the interpreted code to things that have been vetted by Apple?
The fact that Apple can, and most likely will, enforce these guidelines, makes it very relevant to the current discussion.
Or do you really think Apple is going to say "Eh, they're just guidelines" when you try to submit a daemon?
Maybe so, but it's certainly not what I was suggesting.
Rather, I'm suggesting that we should have tools which make it easy to write a parallel model, even if individual tasks are sequential -- after all, they are ultimately executed in sequence on each core.
Can't? Or isn't easy to?
I suspect such a mechanism would be easier to build in Erlang than in most other modern languages. And parallel programming is inherently non-deterministic.
It might not be fast, though, as what immediately came to mind is a bunch of worker threads and one master thread -- workers notify the master when they're ready for more tasks.
I am referring to threads as the OS concept, not as a programming concept. That is: I am not talking about the Erlang processes, I'm talking about the real OS threads it uses (generally one per core, or just one). And I'm referring to threads as a generalization of OS-level processes.
Are you suggesting that a different CPU and/or OS architecture could be built which would make it possible to write deterministic, threaded programs? Or are you talking about an entirely language-level approach?
Or are you suggesting that we try to keep cranking up the clock?
Maybe so, but it also helps to turn it into something I can communicate, and maybe convince others of.
Actually, filters have been remarkably good for me. At work (Gmail), a spam slips through every few days. At home, I have an "unsure" box, which gets mostly spam (maybe 10 a day) and the occasional innocent mail -- out of hundreds hitting the actual spam folder.
Also, just about any other system would have problems worse than spam -- but it's hard to talk about something abstract. What, exactly, did you have in mind?
I agree with the other poster -- where is this country?
I agree. Over here we call it "DVRs" or "BitTorrent", or, occasionally, "Rentals" -- it's very likely that I'll be able to buy a very good HDTV set soon, but if the networks don't catch on, the only service I'd be willing to subscribe to is Netflix -- and even then, I'd have to be stripping ads out manually.
Perhaps the most offensive to me is the "you wouldn't steal a car" bullshit. Look, if I'd pirated it, your "you wouldn't steal" ad wouldn't be there! Ergo, if I'm watching it, that means I'm a legitimate customer, and you're insulting me by calling me a pirate -- which really, really makes me want to pirate it!
If you call "pretty much fully automatic" just a "little better", maybe. But seriously, now you're complaining about a taskbar icon? On an OS that doesn't even require you to have a taskbar if you don't want it?
And it took a bit for me to learn, but I can now go from zero to a fully functional Ubuntu -- flash, mp3, wmv, drivers, everything -- in about as long as it takes to install, which is less than an hour, last I checked.
When "my local LAN" is some random wifi hotspot, it would be nice to have it not be broken there.
And "fix your site" is as simple as sticking https in front of it. Google has this as an option, anyway.
Actually, no, as a technical user, it's incredibly easy to see the reason that the certificate isn't valid -- and if there were shenanigans going on, it wouldn't be because it was expired.
Also, https means it is actually possible to be secure -- you check that https is in the URL, and you refuse to connect if the certificate isn't valid.
Some sites default to http, but allow https. But no https means that option isn't even there -- you are going to be vulnerable, period. That's one of the many reasons I don't use MySpace.
No, you don't. You can easily have moral dogma without religious dogma. Didn't your parents ever tell you to do something "Because I said so!"
At a certain point, you do, because the person will outgrow "what Momma said", but people can also outgrow "what God said." So you'll need to understand in practical terms, anyway.
Envy and gluttony are easier to explain, I think, than lying, cheating, and stealing. Envy is just going to make you unhappy, or cause you to do something stupid, especially in the case of a woman, where there are plenty of women you could chase who aren't already in a relationship.
Gluttony is even easier -- if you are a glutton, you'll become fat, and you probably don't want to be fat -- if only out of vanity.
But what about lying? Or cheating? The only way this can work is if you can make a case for the Golden Rule, which is tricky. Since you seem to be talking about indoctrinating children, they're not going to get empathy until about age six or so.
And stealing only works because of the possibility of jail time -- again, without the Golden Rule.
Not at all. My parents did that to me, both as a child and as a teenager, and I turned out alright.
Now, they did start with saying it's "bad", but no connection was ever made with religion. The only things that they told me to do because God told me to were religious things -- my Bar-Mitzvah, for instance -- and even then, an alternate explanation was ready (tradition) in case I questioned the religion.
But seriously, even explaining the consequences to society is absurdly easy. "What if everyone littered?" And if they don't listen to you about that, they won't listen to you about God, either.
And considering how some of these lessons are no longer relevant -- and, indeed, some of them have been dropped completely -- I still don't see it.
One example: Pork is not kosher, perhaps because of certain -- worms, I think? -- which used to be a real problem. In the modern world, we can keep most of our food reasonably clean, so I see no reason to continue that tradition. But the problem is, since the only reason we got was "God said so," we don't really know if that was the reason -- so the only way to preserve that knowledge is to also preserve the ignorance ("The world is flat! ...Ok, it's round, but it's the center of the universe!") because, after all, who are you to decide what part of what God teaches is false?
And that's another problem with religion -- why not just pass down the lesson with the reason? After all, if you say "Do as I say because God said so, and no arguing," you've lost as soon as the person decides to argue -- which means that those who leave religion are almost certainly going to lose a few of those lessons.
I think it was Chris Rock who said it best:
Keep in mind, this was a comedy show, and the delivery was actually pretty hilarious. But I think it applies.
Sorting all news into one thing or another is just an extension of this mentality, and it is harmful. Would you tolerate it if they sorted it into Black News and White News? Or into News for Women, and News for Men? Put the gardening and housekeeping on News for Women, and the tech and business stuff on News for Men...
I can't blame you for trying...
What bothers me here is, your comment asking us to respect what you're saying got +5 insightful. ElizabethGreene's comment hasn't been modded at all. It's entirely possible that I'll get modded up for pointing this out, and she still won't get modded up.
So, apparently, Slashdotters care that you're treated fairly, and that you have breasts, but they don't care what you have to say?
I suppose it's also possible that comment wasn't particularly interesting -- or it wasn't to me, anyway -- but it still bothers me. I guess it's easier when most of us have ambiguous names.
There are two things to think about here:
First, how much effort will it take to optimize it, versus throwing another core at it? Or computer? Not always an option, but take, say, Ruby on Rails -- it wouldn't scale to 1000 cores, but it might scale to 1000 separate machines. And yes, it could probably run four or five times faster -- and thus require four or five times less hardware -- but at what cost? Ruby itself is slow, and there are certain aspects of it which will always be slow.
But, you see, the advantage is that development is quicker -- enough to justify the extra hardware expense -- and as soon as your fast(er) Perl, C, or Java needs to scale past that one machine, you have to deal with the same issues. (Did you really think Slashdot runs on a single 1GHz CPU?)
Second: There are enough applications that are CPU-bound that you shouldn't go insulting people offhand about it. Raytracing (or pretty much any rendering) is massively parallizable -- and again, it's that same problem. If you're very good, you might squeeze another 10% out of the renderer -- so the renderfarm will be 1350 beige boxes instead of 1500.
Oh, and the overwhelming majority of code which is slow because it's bad would gain nothing from multiple cores.
I know I built a scheme exactly like this in Perl, once. And Erlang is built around message-passing, which could be used to implement something like this.
And I don't think it needs to be a bottleneck unless it needs to be sequential. All you do is, have multiple LINDAs (or queues, or jars, or whatever), and have multiple sources to each.
For example: Suppose you wanted that raytracer to do some simple anti-aliasing which took into account the surrounding pixels. The antialiasing "jar" could be fed by all of the initial threads. Or, in Erlang terminology, you'd fire up a new process for each antialiased pixel, and after rendering each unantialiased pixel, it sends a message with the result to each antialiased pixel which is interested. As soon as you get one area sufficiently rendered, the antialiasing can start.
Maybe you're right, though -- I did notice that a benchmark designed to test exclusively Erlang's message-passing features ended up running slower when I told Erlang to run on both cores.