radm

From my point of view, your free software license represents a marketing effort. But it's a highly specialized kind of marketing - it's your marketing to development communities.

From another point of view (also one of mine), your license says something about the kind of community you see yourself being a part of. And, when you make this choice, you are excluding certain kinds of participants and inviting others. But community is not just a license, it's also how you treat others, how you see them, and how they see you, and the kinds of activities they find interesting (and/or sustainable - sometimes but not often the same thing).

A license is also a cost. For some people this will be a moral or ethical cost. The more desperate the startup the bigger an issue cost starts to become. Related is whatever small bit of return the startup can get - this is the babyfood that it will need to survive and grow.

Ultimately, I think our systems of economics (and if you pretend we only have one you are fooling yourself) demand diversity. There cannot be only one good choice when talking about all startups. There can be one good choice when talking about a specific startup (but for a few, multiple licenses might be a good thing).

Not that I have ever spent any time thinking about these kinds of issues...

Finally, note that while what I am saying here is so overly general as to be entirely useless, there are other [almost conflicting] ways of thinking about these issues which can also have value for a startup.

Carry on...

It seems to me that a fundamental problem in all software security systems is that you cannot necessarily trust the location where the software is deployed. Javascript has issues here, but I think it's a mistake to claim that anything but the instances of those issues is unique to javascript.

If you do not know if your system is already compromised, you cannot guarantee that using your system is without risk. And that's even before we get to people willing to break down doors and other such nastiness.

That said, these are not "crypto flaws" - these are flaws that exist in systems even if the math of the cryptography is perfect.

That said, there's something to be said for interacting with other people. And focusing on security risks while ignoring denial of access risks seems silly.

Anyways, my reading of the people writing here suggests to me that almost no one here is really serious about security. There's too much focus on trash talk and struggles with properly characterizing a now-non-existant version of a blog page not enough focus on useful security mechanisms for me to have learned anything useful.

One thing to keep in mind, though: everything that happens on the internet has visibility. So if some code is advertised as stable and it changes from day to day? Something is wrong. Similarly if I download the same code from two different machines and I get something different for supposedly stable code, something is wrong...

And, one of the nice things about open source browsers is that - hypothetically at least - anyone can take the browser and build it for themselves, with their own monitoring and tracking code. This can take time, and modern browsers seem to be updated almost as fast as they can be built, but they do seem to have internal APIs which are rather stable. (Other approaches are also possible - what I am describing here is an off-the-cuff variant tailored at some of the risk suggestion raised in other posts on the page where I am responding...)

Grey boxes and human readable documentation for the win...

I believe I have two or three "upvotes" in my voting history where I meant to click parent. I'm pretty sure I was not authenticated then, so maybe those upvotes were discarded, or maybe not...

It's perhaps also worth noting that the "bogus upvote" problem is in some way related to some other social problems which we struggle with. Spam, and the wrong person using a password, both seem to me to be a reflection of social problems reflected by system design.

For spam, there's no way to ask the supposed origin mail server "is this from:, to:, message-id: combo a plausibly legit in-flight message?" Because some systems cannot handle that functionality efficiently, mail standards people have rejected it (and similar approaches, perhaps identifying a sequence of mail servers, perhaps involving multiple queries when mailing lists are involved) for the multitude of cases where it makes sense. But note that you do not need perfection here, to massively reduce spam volume. Note also that there are efficiency arguments, here, but the original protocol worked fine on machines with <64k memory and ~1MHz clocks.

Passwords and authentication protocols and buffer overflows are a more complex issue, and I'm drifting dangerously off subject already. But that's another issue, I think, where "design efficiencies" and "overly focussed thinking" sometimes bite us. (And perhaps sometimes benefit us, but how can we even measure this?)

Anyways, trying to get back on topic, personally, I have little faith in upvotes here, not even my own, so mostly I rely on friends to point out if there's anything worthwhile here, for me to read.

It's a triangle, someone clicked on it. Counters are a good first pass, for filtering bulk raw information and indicating things to focus on, but they are not the end-all and be-all for good ui design. Borrowing wholesale from stack overflow might be good, or maybe some variant would also be plausible (like, maybe: when replying, let people with parent posts weight child posts under theirs that they found helpful, giving some fraction of the total weight of upvotes in any child posts of their parent post to posts they want to highlight. This should be adjustable, in some simple way, or we live with accidents. There's also an issue when one person has multiple parents but maybe it's best to default to the top level eligible parent.)

My above parenthetical suggestion is not perfect, but it might help for distinguishing between some sincere and insincere replies. Another approach might be to give the user some "downvote" ability - abiding by the original site design, these need not be preserved for others (it's a personal decision, after all).

Ultimately, to really get this right, I would want to be able to segregate other voters into "agree" / "disagree" / "irrelevant" buckets based on a label which reflected my current point of view, and have the content displayed based on that categorization. But that's a much harder problem.

I don't have a formal definition of a string reduction language, so maybe I'm mis-generalizing. That said, J's parser (http://www.jsoftware.com/help/dictionary/dicte.htm) looks like what I imagined the phrase meant.

But these kinds of languages do exist and it's reasonable to think about writing compilers for them and/or subsets.