This is true. But I wouldn't say it is an absolute justification for using iframes, as if that was the only possible way to approach the problem Stripe is trying to solve.
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?
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.
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?
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.
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.
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.
Maybe it won't matter. We'll see.