overbroad

But we've tried to regulate this. The telephone has some utility besides just being a marketing channel.

With TV, it's a lost cause.

And, correct me if I'm wrong, they've been delivering that level of convenience for many years and without any need for iframes.

All due respect for Stripe, iframes are a potential security hole waiting to happen. iframes open many possibilities for exploits. I doubt we've seen all of them yet.

Cheers. I have installed Go before and messed around with it. I agree it's pretty good as far as being self-contained and straightforward. I just don't have the energy to keep chasing a moving target. For my purposes, I'm more interested in stuff that is stable and rarely changes.

If you can produce binaries for UNIX (Linux, BSD, etc), OSX and Windows, I'll be impressed. That's something I was interested in doing with Go (is it possible to cross-compile?) but never managed to learn.

Have you even looked at the rules? Paper sizes, fonts, lengths, deadlines. Do you need to be a lawyer to understand rules like those?

You are only interested in what they say about amicus briefs.

Anyway, I'm not even sure you can file amicus briefs for this case as a developer worried about software patents. But there's no harm in reading those rules. They are boring but that's what everyone has to follow. If you want to send stuff to the court, then you'd be wise to read those rules first. Take the initiative. Ask questions.

Maybe some weathly developers will call their lawyers and ask them what can be done? What are the chances of that?

Apathy. It favors the patent trolls.

Noncommercial internet. Original style.

Make the internet more like the telephone network, not the TV network. People do not like to be hounded by telemarketers day and night.

Maybe opting out is not how to stop this abhorrent practice of selling personal information. There is much more at stake than sites just selling email address lists. There is much more detailed information involved.

Perhaps what would work better is flooding these marketers with false information. This is what hampers email lists. Most the addresses do not work.

As it stands the few (or many) people who fail to "opt-out" (or fail to use proxies) may make this sort of personal information sales market worthwhile because the information gathered is detailed and reasonably accurate. It's not just a list of disposable email addresses. It's higher quality.

I'm too lazy to install Go just to try this (I would need to, right?) but reading through the docs this looks far more appealing to me than tent.io. Nice work, at least with respect to the general design. Flexible.

What are those acronyms developers like to use? rtfm, utsl, etc.? :)

There is a link to the court rules in the article. This is the definitive source, besides knowing clerks personally.

There is some cynicism in this thread about whether this rehearing will amount to anything but I think this shows the system is definitely aware of what the media is saying about software patents, and what you are saying in online forums. Does the USPTO read stackexchange? I think we all know the answer to that.

You have the right idea. Make your voice heard.

ice: "Nobody attacked C, not me, not the author. If you disagree, please be so kind to indicate the excerpt where he attacks it."

author: "So fuck - maybe it's time to finally give up and accept that I cannot compete with a well engineered C binding. C must be faster after all.

Well - fuck this! This is unacceptable. Fuck this "C is the only choice if you want the best performance" type of thinking. I want JavaScript to win this. Not because I like JavaScript, oh it can be terrible. I want JavaScript to win this because I want to be able to use a higher level language without worrying about performance."

ice: "As far as I'm concerned, JavaScript is not the best code for anything except pushing code to the browser."

We are in 100% agreement then.

Sure, technically (i.e. by creating a language using a lexer+aprser and some primitives in asm), any language could be used for any purpose. The reason I said what I said about JavaScript being limited is that it was not designed that way, i.e. to do anything. It was as you state, designed to run in a web browser. I would love to use JavaScript from, e.g. the command prompt, outside of a browser, but it has never been easy to do that without pretending you are running a web browser (learning DOM an so forth). The language is designed for a browser. Is that a limitation? To me, yes.

C does not have that sort of limitation. That's all I'm saying. And C works for many purposes right now - my OS has a vast library of C functions to do all manner of things low and high level. And that's without even looking at other huge repositories on the web. Compare this with mere "theoretical" capabilities, e.g. ideas like "low level JavaScript".

I told you why I like C and why I see JavaScript as limited. Not to contradict anything you said, but to explain where I'm coming from. Maybe I would like JavaScript even more than C, if I explored it more fully, but there's no way I'll like it more when it is so limited in what it can do (practically, not theoretically). I approach computer languages from a practical standpoint. I ask myself what can I do if I learn this language? I concluded that for me, C opens more doors, many more doors, than JavaScript. Some people know both. But I'm not that smart. I have to choose.

If I was smart, I'd learn many languages. But I have to work with a smaller set of knowledge.

Given that I have to choose, truthfully, if I had my preference, I'd choose FORTH and devote all my effort to learning and writing in FORTH. Technically anything is possible using FORTH. So what? By focusing only on FORTH I would be losing all the leverage that people's work with C can offer. There is only so much I, with my limited smarts, could accomplish.

Certainly you can understand my position a little, can't you? Why do so many people love Perl and Python? If we took away all the libaries (=enablement, empowerment) would they still love them as much? For what I want to do (i.e. potentially anything, from booting to browsing), C gives me ample enablement and empowerment. Self-hosting JavaScript doesn't. And if someone writes a BIOS for ARM scriptable in JavaScript, but they write some part of it in C, well, I'm still going to want to learn C before JavaScript. That's just how I think.

Not sure if it's relevant but one of the major "DNS providers" (that preceded Google) also chooses to domicile their operations in Ireland. They could just as well locate anywhere, but I doubt they chose Ireland for tax purposes. That just wouldn't make sense, right?

Oxymoron.

Does Javascript run outside the browser and outside of a platform like Node.js? I want stuff that can run on bare metal as well as on top of other code (software platform).

Personally, I don't care about browsers. One application of a gazillion possible applications. They are an afterthought. I care about sockets and the ability to connect a machine to other machines over a network.

I care about code that can boot a computer, code that can be used to write drivers to control hardware (maybe some new hardware that just hits the market), and code that let's us build on top of that. With this code we should be able to build a kernel and userspace utilities and thereby manage to operate the hardware. Once everything is up and running, then we can install any scripting language we want. We don't have to use the same language we used to build the system to do any work after that, but we could. Indeed many higher level things are written in C, e.g., the interpreters for languages like JavaScript and the web browsers they are a part of. Maybe there's a reason for that?

If the best code for building from the ground up on any given piece of hardware is Javascript, it's news to me. Any examples? I have a new piece of hardware. Can I boot it using JavaScript? Can I control the hardware with JavaScript?

I believe the OP just wanted to do parsing in userspace. Personally I use C for that (generated from flex), but there are countless languages that can do parsing. Why he chose to attack C I have no idea. Like I said, once the computer is up and running (thanks to C), we can use any language we like. We can run "web browsers", and software platforms. And JavaScript. So, have fun with your JavaScript. But I'm pretty sure C isn't going away anytime soon.

The problem is the open internet. There are ways to establish connections to a peer-to-peer overlay that take this out of the equation. The ISP is unlikely to block UDP traffic on some high port. Throttle perhaps, but not block. That gets us around the port issue. Once you log on to the overlay, the ISP only sees one port.

Then we are free to do our SMTP of other messaging as we desire. Each connected machine can choose what ports it wants to listen on, if any.

And what if this does not need to scale? What if it's only being used for a small group of people? What if all the people know each other? A very specific but very common use case. Not everyone is a celebrity with a gazillion "friends". Nor is everyone constantly conversing with new acquaintances. Some people have old friends and family. So I've heard.

Is it worth the spammer's time to try to find an SMTP daemon for each indivdual email address? Under the current system, things are centralized enough that a spammer can spam hundreds, thousands or even hundreds of thousands of recipients via sending to a single SMTP daemon.

Spammers have to send enormous amounts of spam to be successful. Having to do extra work to find an SMTP daemon just to send email to one recipient, and have to do this repeatedly, seems like it would not be worth a spammer's time. At least, not when it's so easy to just spam people that are using email the usual way: allowing some third party to handle their mail.

I thought about this and I agree. Sort of.

There was a time when no one cared about Apple computers.

It's one thing to not care about something that you are not (made) aware of. It's another thing to not care about something that is common knowledge.

If Apple was not using UNIX and C, if Steve Jobs had not pushed them to drop OS9, I might not be thinking of Bell Labs when I look at Apple. But essentially by using New Jersey's work, in my opinion, Steve Jobs was admitting "We can't do any better." He borrowed someone else's work of simplicity.

I guess a lot of developers want to believe the public will never ever know how to build things, simple things, using the same substrate as Jobs. That's fine. Personally, I'm not so sure. At this point the public is still not even aware the possibility exists. We don't necessarily know what they'll do once they know. Would anyone have dreamed Apple would displace Microsoft as the most popular computer brand? Would anyone have dreamed companies would embrace "open source"? The future is unpredictable.

Have they changed it? ITA used to be very popular with the FlyerTalk MR crowd. I used to use it for the searching flights stage (getting info but not booking).

I think the best matrix would be something like OAG, listing all flights that each airline is currently offering, but also listing prices on each flight.

A pipe dream if ever there was one.

The biggest problem I see that has plagued software design and the neverending quest for features as a means of recruiting users is...

Large, monolithic do-it-all programs.

Users too often have no choice over what functionality they can acquire or reject. If they want one feature, then in order to acquire it they are often required to accept numerous other features they don't need and maybe don't even want (because it makes the software more complex).

Whether intentional or not, UNIX design addressed this problem by separating functions into small, discrete, and often trivial programs.

But there is still a very strong general idea among developers that to acquire one thing, you must accept everything. It's an interesting psychology. This goes beyond features in programs and applies even more generally to how working materials (code, docs, etc.) are made available. Packaging eveything together is good when you want everything and do not want to have to acquire each part and assemble them yourself. But it can be counterproductive when you want only one or a few parts and not everything.

Examples of this are everywhere.

Frameworks. Combined source trees. Huge tarballs of many disparate programs form various sources packaged as a "system".

It is possible to separate the parts but not always easy. There is often an implied expectation that you will not try to separate them. This type of kitchen sink packaging often makes extra work for anyone wanting to just obtain one part and not the whole enchilada.

One of my favorite examples is multi-GB Microsoft downloads in order to obtain a few commandline utilities of several KB, e.g., WAIK.

I have seen one person attempt to solve this by mounting the ISO over HTTP and then extracting the desired given KB-sized program. This is slightly less than "convenient".

When things are packaged this way, it can make the job of tackling complexity just a wee bit more challenging.

You're making assumptions. About how things would work and about users and what they can and cannot do. Typical online discussion. Lots and lots of assumptions.

I do not understand your last sentence. Didn't he say his ISP is blocking outgoing mail? The recipients are powerless to unilaterally change that situation.

Think about this for a moment. Forget the corporate example. Imagine one user has a daemon listening for mail (no setup, it's all been set up for him:- it's "built-in" to his OS). Imagine there is an authentication method e.g. a shared secret and perhaps even some obfuscation like port knocking to hide the open port. Even assuming a determined spammer can get past this, is it worth his time? He will reach a grand total of one user.

We can even use a small overlay, where the IP addresses are private, not routable on the internet. The spammer needs to get into the overlay network first, again defeating things like shared secrets or perhaps private keys to identify machines before he can even get a shot a access to a listening mail daemon. That's not easy to do if the users stay logged in. And again, if the network is small, with a few hundred users or less, maybe only a handful, is it worth his time?

Yeah, that's usually how it'd done. But from what I've read (not just from the Nature article, I did actually read his papers years ago), this guy basically founded the entire field of what became "priming". It's all on shaky ground now, whether that's justified or not. I'm not sure it would hurt for him to question his own conclusions, in addition to having others repeat some studies. Time to swallow the pride.

Studies are supposed to be repeatable. But in practice a lot of research never gets repeated. I'm sure he must feel a little insulted to have his life's work called into question, even if the cause is other investigators who were fraudulent or incompetent, or even if the questions are arising only indirectly because of unrelated research that happens to use priming.

IANAS, but psychology is obviously not the hardest of the sciences. I think in other areas like e.g. chemistry and biology, it's more difficult to pass off methods and results that are not repeatable _if_ they are going to be foundational and used for lots of future research by others. If some other lab can't get the right results using your methods, I would think they will make some noise. They might first think they are themselves at fault, but they would probably make contact with others outside their lab and make it known, in some way, that these methods were not working for them. Whereas I can't see that as being as common in psychological research. It's too easy if some method is not working to just "make it work". ;)

IMHO, Bargh should redo some of his old expts himself. If he's so sure they are repeatable, then why not? His stuff is foundational to the entire field.

Do you think there will be lots of challenges though? The reexamination procedure will be different.

Alas, if I understand corectly, it is still going to be expensive, even just to submit prior art against a bogus patent.

Crowdfunded re-exams?

Are you suggesting his employer doesn't know the recipients? Hmm, if true, I wonder what sort of email that might be.

Not the type I'm interested in.

I never said there should be a lookup system. Where are you seeing that? I said there isn't one and people still manage to get by. The other commenter was suggesting looking up addresses was some sort of problem. I'm saying it's a non-issue. If not having a public name-to-email lookup was a show stopper, then we would not be having this discussion because email would not be popular. People get by just fine without lookup. They exchange addresses and store addresses on their own.

Discussion is great. But you have to read carefully to understand what's being said. (If I am not being clear, then I apologize.) But if your mind is closed then there's no point reading what I'm typing because I am not regurgitating the usual ideas on email.

Anwyay, discussion is irrelevent when juxtaposed against running code. I'm interested in stuff that works more than getting approval from people in online forums.

This is not some new thing. Anyone can use email this way now. We all have good connections and bandwidth. There is no need for store and forward. What has stood in the way of using email as direct communication is people who can only see email being used one way: daemons that accept commands from any connection, spoofed IP's and all, and email as a service run by someone else, not a small program on the client's machine. If it was impossible to authenticate connections based on any other means besides real-time challenge-response, or DNS run by someone else, then how would people manage to run ssh daemons without the same problems as email?

Installing and maintaining a mail server. What OS doe you use? I'll bet there a whole host of dameons or services running and you never pay much attention to them. Someone else installed and configured them for you. And they just run all the time and you don't even pay attention to them.

What is an "mail server"? At its essence it's just a program that listens on a port for an incoming or outgoing message. Then you have programs for storing, delivering, forwarding, etc. And maybe you have perceived issues of being able to handle lots of messages. But you don't necessarily need all that if you are not providing email for other people. What if you're just a casual user who wants to send or receive a message to/from your friend? If I have an email daemon (or a "service" in Microsoft parlance) listening on a local port, I can type some text and "hit send" (or whatever method I choose to send the text to the daemon) and the mail is sent. No email provider needed. If the recipient has her email daemon listening for messages from my IP address (and only my IP address), she gets the message "immediately". There is no third party email provider. This is how email works.

There is also no spam if we do it that way. Her daemon is not open to the whole internet. It's only open to me. Why is this so baffling?

Neither third party email providers nor some rule that "no one wants to run an email server" or "no one should run their own email server" are a part of the email protocol. Those are your observations of what people have done so far and your opinions. They do not set limits on what can and cannot be done. Are we in the business of startups and trying new things or are we here to preserve status quo?

Email is internet messaging, one of the oldest forms of it. Email is a message sent in a specified format* over the internet. What could be more simple?

*Granted the format is rather rigid, but it's not too difficult for anyone to learn. It's like writing a business letter.

Millions of people have an interest in sending messages to each other over the internet. And millions of people have no interest in sending bulk email for commercial purposes. That's all I need to know. A project is born.

There is a need for an "email replacement" as many others have voiced and as pg identified in his list, but I'm afraid it's not going to come from anti-spam zealots. I appreciate what they try to do, but I do not appreciate their mindless, blunt-force methods and ideas about "good guys" and "bad guys".

There is an enormous amount of bulk email sent every minute of everyday. Just because it is "opt-out" doesn't make it any less impersonal and unwanted (or any less of a huge drain on the world's computing resources). Can we accept that some people have little interest in receiving bulk email, and that there may be a market (besides you) for email inboxes that are not open to marketers, but only to known contacts? Alas, that's not what the anti-spam zealots aim to address. They do not want to curb bulk email. They just want to stop certain senders.

This does not really move me toward my vision of email. It's just the same old thing. An inbox full of garbage.

"(Well, he did, ... "

That's all I'm saying, really.

I see "simplicity" as orthogonal to the idea that Steve Jobs led a revolution in design. I see the so-called revolution he led as being beautiful hardware enclosures, of all sizes. But this is just my opinion. I expect many would disagree.

I also expect many would not choose to look at these devices past their enclosures and what they see on the screen. From that limited perspective, it certainly looks like Jobs made everything simple. (Me, I think Ritchie and his colleagues did that. They dared to simplify when no one else would. Apple like many others took the ball and ran with it. But unlike many others, they also build hardware that looks fantastic... from a marketing standpoint, this is a winning combination.)

No hurt feelings. No yelling. Here's my point: real simplicity is the stuff of Dennis Ritchie. Not Steve Jobs.

As I said, Apple makes beautiful hardware. And you could say they promote a certain "simplicity" of use. Maybe you could even call Apple hardware "simple". I don't know. It's an enclosure with a board inside. What I do know is that once you get to the software side, Jobs is not the guy who should get credit for "simplicity" of design. That guy should be Dennis Ritchie. Alas, many journalists will never know this and write about it, because they don't spend time learning C and UNIX (whereas they do spend time using learning and Apple products that are built with C and UNIX).

It is the simplicity Ritchie gave us, his design philosophy, that allows so much to be created, like the software that drives Apple products. Anyone can create simple things or complex things in software, but we all need to start with something simple in order to do the building. That something is not the work of Steve Jobs. It is the work of Dennis Ritchie and colleagues.

If the title did not use the word "simplicity" I would have no comment. Jobs is a hero of design. But simplicity, to me, is another matter. He is not the true source. Even the early Apple computers where the software was "simple" were not the work of Jobs, but of his co-founder, who is not longer part of Apple.

How Dennis Ritchie's love of simplicity fueled everything that now matters in computing, including the operating systems and software Steve Jobs used to "fuel a design revolution".

Apple makes beautiful hardware, but does that amount to simplicity? If the focus is Apple software, maybe in 1977 it was simple, but today it is anything but simple. Restrictive? Yes. Simple? No.

When I want simplicity in software I look to New Jersey, not Cupertino.

I think there may be some merit to this. The assumption of the patent troll may be that you will not look at their patents. (They are junk, remember?) They may just assume you will believe you need to hire a patent attorney and that the patents cannot even be assessed with so much as a sniff test without first spending thousands of dollars. And the cost will scare you into submission.

If you were to call the troll's bluff and go the distance (rare), eventually your patent litigator that you are paying through the nose is going to be challenging every possible claim in discussions with the troll's lawyers before anyone steps foot in a courtroom. Chances of success in court are going to be considered, and argued. The simple fact is the troll's chances might not be so great. Why do so many cases settle? The troll only needs to scare you into settling, and that's all. Mission accomplished.

I'd say the sooner you start asking those questions about the troll's chances, the more pressure you put on the troll. They have to pay their lawyers, by asking them to devote time to the matter, to deal with the questions in order to maintain fear in you. Meanwhile, in asking these questions you haven't had to pay any lawyers to look at the patents yet. (And they don't necessarily know that.)

The whole patent trolling system is built on fear and the high expense of patent litigation. Even for the most bogus patent claims, it can cost thousands of dollars to have a court declare them as such. Take away that expense, and the fear of having to pay it, and the trolling business goes "Pfft."

But why even place the burden on the content producer to create these formats? Why not just establish a practice of raw feeds and let consumers write their own parsers? (I can imagine where consumers write parsers and put the code on Github.) Clearly, consumers are willing to do some work with respect to the data they seek, they will be doing some bulk manipulation of it, else they would not be ready to jump through hoops like "API keys".

My favorite data is raw file on FTP servers, i.e. bulk data. For me, it is the easiest to work with. I can translate it to XML or JSON if I want to, but many times I do not even need to go through that intermediary step to get what I want. If others wanted the data in, say, JSON, I'd be happy to share my parsers with them. I'd bet others would too.

I think Tom's point was "Cut the BS, and just give us the damn data, already." (Correct me if I'm wrong, Tom.) And I think he is spot on. This API nonsense has gotten out of hand.

"Faster than C" seems to imply that the author is not seeing the true value of C. It is more than just speed.

You can only build so much with Javascript.

With C, the possibilities are limitless.

For a specific task like parsing, use whatever language you want. But please do not believe that by knowing Javascript you can both dismiss C as an optimal language and that you can build anything. You can't, as to either. As it stands, by relying on Javsacsript you're restricted to a browser or Node.js and whoever controls the browser and Node.js effectively has final control over your opportunitities. What's the browser written in? Javascript? What is Node.js written in?

Who cares if your parser is faster than C? If it's "fast enough", that's all that matters. Users of big, complex, graphical browsers or mySQL databases are well accustomed to slow speeds. They have learned how to wait.

Yes, you defined the problem in the opening sentence of your second paragraph. But I disagree that you should not have to maintain a whitelist. What are your email contacts i.e. what is your email address book? You already maintain a list of people you correspond with, whether you think of it that way or not. And when you want to correspond with someone new, you have to give them your email address. As it stands, there is no _reliable_ way for them to look it up. There is no worldwide directory of email addresses. In fact, what do we do? We try to hide lists of email addresses.

If everyone had a fixed address with a mail server running, "lookup" i.e. simple MX lookup, might be possible, e.g. if your IP address is 1.2.3.4, anyone could send mail to inquiries@[1.2.3.4] or something like that. But I'm not sure that alone really solves the problem.

Email still works without a worldwide directory. People exchange email addresses and they keep lists of them known as address books.