skysight-inc/HackerNews huggingface dataset:
I'll take a stab at it as I've used both. Or rather I've used both for actual work.

DropBox wins for me because it can access their servers through our firewall (which only allows HTTP/S access to less than 5 ports). Live Mesh could not do this.

I found dropbox a tiny barrier to entry. It was so unobtrusive. Live Mesh pops up stuff on startup, complains that it can't access the internet. Etc. Dropbox just stays silent and waits file locks are released and internet connectivity returns.

Getting at my files online is SO much easier with DropBox, ESPECIALLY now since they have the new UI. It's fast, Mesh isn't.

I've never used the remote desktop feature so I can't comment.

Oh and the feature I use nearly daily is the Public folder where I just save a file in there, right click in Explorer, copy the public URL and give them the URL rather than worry if the email client can support a 10MB file. Brilliant, much faster than slow Messenger file transfers! I don't believe Mesh has this ability.

Anyway, DropBox is a simple enough concept and I feel they refined it so well that anyone can use it. Mesh is just complex and has way too much UI stuff going on.

I'm still well under the 2GB limit but have a 50GB Pro account (for now anyway) - just waiting for the selective sync feature now
> Never emit contents of any variable to the browser without treating it with htmlspecialchars() (or equivalent) first.

That seems like one way of using a sledgehammer to needlessly burn server-side CPU cycles.
You want 10pc equity for 5 Lakhs and all you are going to do is setup a bank account, which cannot be directly operated by the founders??? Top it all of with a Wordpress blog for a website, and you're not really instilling much confidence.

Comparisons to YCombinator is highly unfair to YC.
A review of "The Web Startup Success Guide" (book by Bob Walsh)
The issue isn't that js has a global namespace, it's that scripts included on the same page all use the same global namespace.

This could easily be changed/fixed in browsers without changing anything about js.

It'd be nice to be able to specify in a <script> tag if you want a new js execution context setup, and also what access you want to give that script to your own execution context.

For example, maybe:

<script src=http://widgetmaker.com/wm.js newContext=true permissions="modifyDom:false,readNamespace=false,passMessages=true">

<script src=http://hitcounter.com newContext=true permissions="NONE">

With such a scheme, everything is executing in completely separate contexts, with clear permissions about their interactions. Some script messes with the Object constructor? only affects its own execution context.

Saying a blanket "js must die" isn't really understanding the issues, as they are actually in browsers, not js.

It's like saying python/perl/etc is an insecure language and must die, because it usually shares the same filesystem between processes.
> If we follow the idea of killing everything that's "insecure" then we will end up killing everything, because nothing is 100% secure

Perhaps, but killing off the stuff that is obviously and demonstrably broken seems like a pretty sensible policy.
This is pretty much true for many languages; runtimes offering reflection usually make even private members available. OO protection is not a security feature.
You may want to consider using Lua for game scripting. It's a lot more strongly influenced by Scheme than e.g. Python, and has been designed from day one to be embedded as a scripting language for existing C/C++ projects. It's quite mature, widely used in the game industry, and has been in production use for over fifteen years.
It's not a flawed language security model.

Change browsers to use separate execution contexts for each <script> tag, and specify permissions about what they can and can't do to the containing context.

<script> tags are not part of the js language.
One has to admire rms for sticking to his guns and living up to his ideals. He is a bit brash, true, but a) he has been proven right many times before when it comes to software and b) he is consistently being himself and doing his thing. See him eat a piece of his foot on camera while giving a lecture (it's on youtube) and you'll perhaps have a Zen moment. He is a walking, talking media antidote.
Infinispan vs Gigaspaces
I agree that the execution model of JavaScript in the context of web scripting, especially in regards of security, could be better. On the other hand, I think that a too complex or restrictive model would alienate non-programmers such as web designers who don't understand (or don't want to understand) such abstract concepts.
Unplanned. I believe this word best expresses the meaningful part of "accidental" and leaves out the meaningless philosophical part.
Huh, that approach would never have occurred to me. Very elegant.
The other 3 country graphs show business as usual. I'd say it's mostly because everyone in the US is freaking out.
Compared to the cost of accessing the database, html-escaping plain text is basically free.
zero minutes: microbes die at temperatures below boiling, by the time the water is boiling, it's pasteurized enough
Sorely lacking from this article, even if we take it at face value, is any workable alternative solution.
I'd love to know how this compares with the going rates for other architectures. I assume Macs are at a premium, but by how much?
Choose Best Web Hosting with Web Hosting Geeks.
...You use auto-generated integer IDs for pagination links, but not for users? I don't mean to be disrespectful, but... it's wrong.
Nowhere does he propose a new language built on the same foundation.

What he actually proposes if you read the presentation is more security for/around JS.
Yes, but I do believe that it would be best to rethink JavaScript. Essentially you could start from a safe subset of JavaScript that remove the global nonsense and rebuilds with a proper object model that restricts how you can get a reference to an object.

Douglas Crockford makes a proposal for this in a recent presentation: http://www.slideshare.net/webdirections/douglas-crockford-aj...
Hire people? If it is growing rapidly yet you can't afford to hire someone to handle such a task, perhaps you need to revisit how to monetize it.
Which gives rise to the next evil: Multi-level Marketing.

MLM and its astro-turfers are the bane of my life. (Amway being the biggest culprit here..)
37signals Valuation at $1.0E11 After Bold VC Investment
We Hold Twitter For Ransom For $100 Billion Dollars
Water no get enemy.

http://www.youtube.com/watch?v=YdV1V4vPPLI
For this to be an accurate comparison, the word processor would have to support only one formatting option -- dar only has one form of compression built in, does not seem to support writing to stdout, and was last updated in 2006, so the advantages of a pipeline setup and having the ability to choose alternative tools as they become available outweigh the limited feature set over more traditional tools.

However, there is this (from the man page):

"Because, even when using dar to write a slice on a tape,
you will loose all the interest of another feature of dar
which is its ability to directly access any of the
archived files, even when compression is used."

which can be tremendously useful, but isn't compelling enough to warrant using it.
Summary: If "nations" were modular, ocean-going barges, then citizens could freely detach their modules and go live in or start a different nation for very low cost. This would provide competition to government, and therefore force them to be efficient.

It's a pretty attractive idea, but I think it needs to studied (modeled maybe?), before we can really say what would happen in a system like that.
My GF has used both DropBox and SugarSync extensively, and the vote goes to SugarSync - more flexible in what's shared.
Microsoft Office plays detective in new novel
'basically free' * lots of users = not free.
How age impacts social-gaming monetization
I read the title in the spirit of the classic Unix-Haters Handbook: It is both tongue-in-cheek and brutally honest at exactly the same time.

Though much of the suckage which inspired the the Unix-Haters Handbook has been fixed... or at least finessed [1]... it's still the case that there are aspects of Unix that suck. But of course that doesn't matter. Unix isn't going anywhere fast. It has outlived many of its alternatives, and the remaining alternatives are either worse or have little traction. None of the Unix-Haters were under any illusions about this: They would point out various features that were done better in other operating systems (old-school Mac OS, Windows, OS/2, perhaps even the Commodore Amiga though I don't remember that, and of course the late, lamented Lisp machine) but none of them seriously thought that any of these things had a chance in hell of unseating Unix, just as I suspect that jgc does not seriously think that Javascript will be replaced anytime soon.

Javascript and the DOM, like Unix, isn't something that was designed by a rational committee of experts, but it snuck up on all of us and is now ubiquitous, and the social and economic forces that built it in the first place will not let it disappear easily. To paraphrase Crockford, we should all thank god that JS is as good a system as it is, given the inauspicious conditions that surrounded its birth. But I'm perfectly prepared to hear jgc's argument that its security problems are so dire that you can't really fix them while still calling the result "Javascript". That's important information. The first step in working through a hopeless situation is to understand the size and shape of the hopeless part.

---

[1] Or, let's face it, in some cases we've all just joined hands, smiled, and agreed to love the suckage. It's the industry standard!
I think this is just an example of Parkinson's Law of Triviality: http://en.wikipedia.org/wiki/Parkinsons_Law_of_Triviality
Is Eating a Plant-Based Diet a Cure for Cancer?
The security needs to be in the browser - as in the user needs to enforce the security, not the code - leaving it up to developers to specify what permissions things should have is a recipe for lazy developers getting us into a situation much like the one we're in now.
really? the only interesting part of presentation you found to be the title? it was quite opposite for me - very interesting examples/proposals he has there under inflammatory attention-seeking title...
It does add a little - it's clearly not viral growth, that would be millions overnight. Weeds self-seed and grow steadily overtime getting larger as resources allow - it seems to be a fine analogy. Necessary, no; worthy, yes.
Incremental backups is my guess.
I agree! Improve the BROWSER security model. Javascript is an innocent bystander in the mess.

It's the browser that allows 20 scripts from different domains all come together in the same execution context each with full permission to do anything.
But there is lots of code that relies upon that behaviour. We can argue about the exact source of it if you like, but if the language execution model is dependent on that behaviour, then the language execution model is flawed, which was my original point, I think.
hehe two retards arguing on the internet, who'd have thought that possible!
Don't you think that something that prevented people from unintentionally introducing XSS vulnerabilities into their code would actually be easier? Building broken software is always easy, so shouldn't we be focusing on making it easier to build software that isn't broken?
By giving away Internet Explorer free, Microsoft made web browsers a commodity. Before that, commercial users had to buy licences for Netscape Navigator. I think the web greatly benefited from that move.
axod is right. It's a fallacy to say those are "features of JavaScript," when of course it is really a feature of the runtime environment.

JavaScript in a browser runs in the global namespace of the WINDOW, which is defined by the DOM API. Remember that JavaScript, on its own, is a headless language, with no I/O of any kind. It relies on the runtime environment to provide it with scope, context, and i/o, among other things.

Moreover, you can easily "fake" private members/functions/etc by using closures. (Yay!)
Wouldn't it be nice to also see the numbers for the Sky (Murdoch-owned/controlled) channels?
I was quite surprised there was no consumer web apps per se, happy to see david mytton on there, server density looks like a great product.
Web Design Trend Hunting – 15 Amazing Infinite Scrolling Websites
Having a strategy doesn't mean being fake and uninterested. Anyone who networks with individuals can tell you there's certainly a strategy involved, but to be really good at it you have to also take a genuine interest.
There's no js code that relies on <script> tags using the same execution context, because <script> is not js code. It's an HTML tag.

It's outside of the scope of javascript. It's the Browser security model that needs toughening up.
There are several free short URL scripts for your own domain out there. Which one do you recommend, which one is secure enough and prevents such simple exploits at least?
> Javascript is an innocent bystander in the mess.

No, it's not, because well-formed, valid Javascript code is permitted to depend on this execution model.
http://www.visuwords.com/ is a fun way to find stuff like that.
Visuwords - Online Visual Dictionary
You're not making any sense whatsoever any more.

The decision to combine 20 <script> sources into the same execution context is the BROWSERS decision. NOT javascripts.

It's the BROWSER that doesn't have any concept of allowing <script> fine grained permissions within the execution context, or specifying you'd prefer if the browser put that script in a separate execution context.

It's the BROWSER that needs fixing here, not js.
"basically free compared to the cost of something way more expensive" * lots of users = still "basically free compared to the cost of something way more expensive"
If you did something so horrendously asinine, like make each <script> tag a separate execution context, then you would undo the huge leaps that web interaction has made - in one fell swoop.

I, for one, remain totally unimpressed by these accusations of insecurity. They don't seem like a big deal at all.

Lazy and/or incompetent programmers will always find a way to write insecure code.
So how's CL different for getting support than Python?
Does plan9 support 15 different archs with all of their quirks and subarchitectures?
no. only 11

WiFi stack?
yes, and bluetooth

Support for different power modes?
yes, I think so, can't say I've ever used it. does
"echo blank > /dev/vgactl" count?

Framebuffers?
no, it is a 21st century os

Kernel probes, high resolution timers, extended inbuilt security APIs?
yes

all in 13 syscalls
I might be able to "get over" the privacy and creepiness issue if I saw some benefit to the service, but I don't. I don't see any reason why I would want to share this information with others, or why I would care about anyone else's stream. Then again, I don't use Twitter or Facebook either.
>> " then you would undo the huge leaps that web interaction has made - in one fell swoop."

Why? Just have them in a separate execution context, and give them specific permissions... eg you can mess with the DOM, but only within this specific element, you can pass me messages, you can't access my execution context etc etc.

Such fine grained permissions would allow everything that goes on already, and disallow things you don't want to happen.

I agree though, the 'brokenness' is being vastly overplayed here. js isn't "broken", browsers aren't "broken", they just need improving, which is happening.
Dar 2.3.9 was updated on March 22th this year; there were 4 commits to CVS in the last 21 days, too.

Never heard of Dar, but I thought it deserved to be on record that it is still alive and kicking (unlike your statement of when it was last updated).
Javascript is now being used even in remote controllers today. See http://www.webdigi.co.uk/blog/2009/rise-of-javascript/

It certainly is a useful language.
Step 1: Use them.

Step 2: There is no step 2. ;)

All statistics "lie" to some degree. All data leaves out factors that might influence the data.
However in the vast majority of cases

Sorry, but that is extremely wrong. In the vast majority of cases, every bit of work you did amounts to nothing.

For every successful startup, there are thousands of failures. There is absolutely no point in wasting time on ANYTHING long term until you are sure of success, whether that be attracting a shitload of users or making a shitload of money. I learned this lesson in an extremely painful way.
Part of the problem is that it's really hard to fully put yourself out there in a way that scales. You could see huge and immediate benefits by running muckwork as 'the derek sivers show,' but sooner or later you're going to run into situations where there are people you don't actually want to be talking to right now and you just wish you could put on the face of 'derek sivers the businessman' to avoid the obligation.

I think that last word is really the key thing, because social media can be insanely powerful in only a few weeks or months, but it comes with all these longterm obligations that can quickly get to be completely overwhelming.
Who Killed California?
I'll refer you to this comment now, as we appear to be arguing about the same thing in two threads:

http://news.ycombinator.org/item?id=843320
I read that the Indians in New York would also dry the pine bark, grind it up into flour, and use it to make breads and pemmican.

As a kid growing up in upstate New York I was pretty into "survival foods," until one day I ate Jack-in-the-pulpit shoots. The calcium oxalate it contains made it feel like I had lit my mouth on fire. That sure nipped my "survivalist" career in bud.
The would help, but it doesn't eliminate the problems. For example, the JSON Hijacking attack would still work because the attacker would control the 'permissions' attribute in your proposal and allow himself access to the JSON object via modification of the Object constructor.

It also adds a layer of decision making on the part of a web designer. I believe it would be better to alter the language so that these global problems are eliminated at the language level. Because any decision making about the execution context are likely to cause problems themselves because people make all sorts of mistakes and they would have to understand what it means.
Main project is Duck Duck Go. Check out my Web site for a list of others.
It is interesting to compare the tax climates to the $s of funding. California, Minnesota and Iowa manage to have successful startup per capita despite these harsh laws.

And, Wyoming is dead last in dollars for funding, but second in tax environments. Clearly Wyoming has a sparsely populated state, but per capita was supposed to account for that.

As a native Marylander, I am a bit intrigued by how the recent tax changes targeted at businesses will effect this sort of data. It is already seemingly hurting Maryland in comparison with other states (1 year avg < 3 yrs < 5 yrs), but other factors may come to play.

Perhaps a great indicator is population density, or more specifically educated peoples density.
Hacking musical compositions with python
Twitter Raising Huge Huge Cash - Close To 100 Million, @ 1 Billion Valuation
witter is raising somewhere close to $100 million in its newest fundraising activity. This is almost double than what was being expected. WSJ reports that.....
Running a url shortener: please don't make one we do not need any more.
Let me retitle that for you.

"Other people doing work I could theoretically do, at least in part, is making me lazy."

It's got nothing to do with UX and he even admits it. Linkbait.
Interesting...

I'm surprised by Massachusetts being even slightly higher than California per capita but possibly has to do with population size I guess.

At any rate, good to know that 'number 2' may not be so far behind 'number 1' as some would have you believe...

Thanks for this great post!
Complexity, Simplicity, and Elegance
Moblin originally was an Intel/Atom thing. They've sort of handed it over to the Linux foundation so you'd expect it to grow from there but while Intel have made that move to avoid looking predatory, you can't really expect them to put in the man hours for other architectures.
10 Power Productivity Strategies
In an increasingly connected business community, the online project manager often doesn’t report to bosses, but to products – you might have three or four different groups to deliver to, and they’re all interested in end results instead of excuses.
Really? Generally the need to put secrets into your code, as required by DRM, makes open source and DRM mutually exclusive.

But that wouldn't stop a proprietary Silverlight for Linux (which this may be) from working with DRM.
Your code is the same size and still runs the method when when the state is changed - which is cool. But what's the advantage?
Perhaps to prevent rampant Collusion, Corruption and Casteism in India.
http://business.rediff.com/report/2009/sep/24/indians-among-...
>> "because people make all sorts of mistakes and they would have to understand what it means."

I think this sums it up really. People make mistakes and make insecure software. Whatever language it is. I fail to see how swapping out js for anything else would solve anything. It's all pretty moot also, since it'd never happen.

The JSON attack again, isn't any inherent insecurity in the language, just in the way it is used within browsers.

Lets improve browser security rather than focusing on a language which has pretty much nothing to do with security issues. None of the examples you give had anything to do with the core javascript language. They were all about how it is used in the context of browsers.

Just to get this straight, one of your arguments is that since some browsers apparently execute the javascript inside css "url('javascript:...", the solution is to change javascript for some other language? Do you understand how ridiculous that seems?
Duh

http://www.amazon.com/Dark-Chocolate-Cashew-Bark-Lb/dp/B000Q...
I'm really not trolling. The only reason I started arguing this point is that it was with some irritation that I saw the suggestion from amichail that the definition of "Theoretical Computer Science" excluded theoretical computer scientists. An alternative name for what SPJ does was even offered, to make it distinct (once again) from "theoretical computer science".

The original article comments may have been talking about a specific community that happens to be called "the theoretical computer science community", hence my point that it is up to members of that community to remember to mentally translate into words that the rest of the universe can understand when talking to people outside their community (which I view as a sub-group of theoretical computer science, for the record).

For some reason you picked up the argument which was only directed at amichail's original comments.

Basically, the framing of the question should actually have read "Are people who go to conference X friendly?" - the actual discussion point was buried in the comments. The question annoyed me, and amichail's even stronger re-statement of this same viewpoint annoyed me further.

And then it just got silly, because now we're arguing about the meanings of words like "many" (my word), or "common" (your word), when really the use of quantifiers in this is really not necessary.

My point was not that there are only a small number of people who use this definition of TCS that I'm complaining about (although I do believe that to be the case) - my point, illustrated with my example about chemistry above, is that it is completely bonkers to use it in this way outside of that community.
Type 2 Diabetes on the Rise
Given that I object to the use of Javascript outside of browsers, you've basically negated (for me) any reason to treat the issue of language security versus browser security separately.
Build a Better Bulb for a $10 Million Prize
Count down to google acquisition?