rwos

GNU rm has exactly that built-in:

    $ rm -rf /
    rm: it is dangerous to operate recursively on ‘/’
    rm: use --no-preserve-root to override this failsafe

While static analysis can be quite a powerful tool, it doesn't magically fix everything. Some of the typical web-application vulnerabilities are shell/SQL injections, XSS, and CSRF. Also, passwords saved in a insufficiently hashed form, or even in plain-text. All of those are bugs on the architecture level, or "business logic bugs".

The semantic diff is pretty cool. It will probably be pretty hard to apply that to C (cpp) and Lisp (macros, and especially the programmable readers in some Lisps). But maybe we don't actually need a solution for the general case and displaying "most" changes in a semantic way is enough.

I imagine these higher-level diffs could be especially useful for things where one doesn't have that much insight into the source code - for example, scanning for API changes between two versions of a Framework (where maybe even displaying only changes to public methods/exports would be enough). In any case, diffs on the AST level seem like a good, and quite under-explored, idea.

1.) Yes, I think so. 2.) Don't worry, it has been done before:

http://news.ycombinator.com/item?id=1259695

(That particular instance doesn't work anymore, though)

Is this censored? There's nothing related to copyright infringement or porn in there. Also, the categories and trending/most-searched selection seems arbitrary. Every country has a different set of data.

No, as others have said these are only recent ones.

Here's the real top ten: http://www.hnsearch.com/search#request/submissions&sortb...

This was on /r/programming and now it's here - I'm sorry, but I don't really understand what this is all about. 600 lines doesn't seem ultra-small to me. And Lisp - well sure, not too common a language for games, but it's not as if this was written in a purely functional style or something. In fact, it looks like pretty standard imperative programming to me - it wouldn't look much different in C.

Am I missing something here?

I'm not the parent, but I do web development - here's how I understand it:

> hard for end users to customise

I think, he means that a css-based ("modern") solution would allow end-users to just swap the css (a feature most web-browsers have as a built-in) to change the site's appearance - whereas you cannot change the way a <table> looks, for example. That is, you can't easily make <table> columns appear below each other, for example.

> works terribly in any other context than a desktop browser

The parent probably means modern non-desktop web browsers, i.e. ones with javascript and media-query support. Using media queries would allow automatically changing the site's appearance to something more usable for small-screen devices (for example) - by using bigger buttons/links/up-vote-triangles or something like that.

The problems you mentioned are orthogonal to that - mostly caused by devs that only target js-enabled modern browsers. That's bad, of course, but it's not part of "modern web development" per se - it's just bad web development.

> plays terribly with all other web tooling

If you use "modern" web-dev methods (that is, styling only per css), other (web-)services that display your site in different contexts (think google reader or desktop mail readers or something like that) can swap or remove the css and get the content (including semantics like "headline", "list" and so on) without the styling ("these are table columns", "this is centered"). In theory, at least.

I don't understand the rest of the points either, to be honest. <center> and <table> are very compact, compared to equivalent HTML/CSS solutions - that's part of the reason why people keep using them.

Ideally, there should be a feature that lets you see the personalized (that is, real) search results of others. Maybe divided into target groups ("programmers", "male users under 20", etc.). Of course, everyone's real search results will be slightly different, incorporating "+1"s of Google+ friends for example.

But, I assume, the bulk of the search ranks will be the same for people in the same (advertising) target group. (I have nothing to back up that assumption - it just would be the most sensible thing to do, I think.)

You could have said the same thing about unix-like operating systems in 1991 - yet, somebody wrote one from scratch without a full-time team.

I'm not trying to put this little project here down, far from it. I think it's pretty neat. I can imagine even neater (if that's a word) things, though... :-)

I wouldn't call that a "Haskell based browser". 1500 lines of Haskell against maybe 300 KLOC (guessed) of webkit alone. That's not "Haskell based", that's only using Haskell as a glue.

The same goes for uzbl, too, of course. Things like the Grail Browser [1] (a Python webbrowser, including the possibility to run client-side python-code - but sadly obsolete and not maintained anymore, as far as I can tell) are so much cooler than just tying webkit to GTK using $LANGUAGE.

I mean, it's not like HTML layout engines or JS-interpreters are somehow impossible to write from scratch.

[1] http://grail.sourceforge.net/

What a nice way to find out that my rather old Thinkpad (on Debian testing) now has WebGL support - I only updated everything from time to time, and apparently stuff actually started working. Great!

Great hack, too. I really, really want that thing as a screensaver!

It's funny how one of the relatively few design errors in Unix shells now indirectly comes back to haunt us. Recursing is built into pretty much every command that can handle multiple files - which very strongly suggests it should have been made a feature of glob (or the shell).

I think it's a bit sad that those "big-picture" features in unix are treated as if the were written in stone.

The quote doesn't make it an allegation, that's right. The other parts do ("[...] that he has advocated for truly awful practices"). That "fact" is not part of the question and as such can only be refuted by invalidating the whole comment, not by answering the question (I hope that makes sense). A real (fair) question would have been something like "Here's a quote - what do you think about it?". Besides, again, it's not the right occasion.

Asking such a loaded question when RMS can't even defend himself is just incredible cheap. If you had genuine interest in knowing whether these allegations are true, you could have asked differently (and on a different occasion). No, that's not a "Social/Moral" question, that's just a statement. I would down-vote you, if I could.

I have a pet theory about why so many[1] people find him "threatening". I believe it's because people do think it's important what he talks about - but feel he talks about it in the Wrong Way[TM].

Anecdotal data points to support my view: The most hateful comments against Stallman usually appear in highly technical forums - I have yet to see that amount of negativism in the comment sections of main-stream media articles about him. Most technical people, I think, know very well what free software is, and how, generally, it helps us getting stuff done. You would be hard pressed to find a programmer nowadays who has never used any free software for his or her programs. Even if they "only" used Eclipse to write proprietary enterprise code.

Yet, some technical people are - it seems - completely against free software, and completely against RMS. But consider:

They wouldn't rally against Stallman if they didn't care about free software at all ("Ah, that freedom guy again, how cares"). They wouldn't rally against him, if they thought that free software was completely stupid ("Ah, that freedom guy again, well that whole free software thing will be going down the drain, anyway"). No, the only real reason to say something against Stallman is if you are supportive of free software as an idea - but think that he spoils it.

If you think about that, then the people writing the most hateful comments (minus the trolls, of course) are the ones that support, and care about, the idea the most. And with that conclusion I can accept these comments, knowing that the idea of free software still has supporters, and still has people caring. Caring so much, in fact, that they even feel they have to insult a human being to get their point across - because it's obviously _that_ important. More important than Stallman.

I also have some anecdotes of why their fear of Stallman "spoiling" the idea is ungrounded: None of my non-technical friends know Stallman. None. Not one. Some do know Linus Torvalds "wrote Linux", some run Ubuntu on their laptops, and some know what open source means - but nobody of them thinks RMS is the sole speaker of the free software movement, as it were. I believe that even if they'd ever read an interview with him they would still be able to separate the idea of free software from the person Richard Stallman.

[1] I mean "many" here more in the sense of loudness, not necessarily of quantity - on the internet, nobody knows you're holding forty-two anti-Stallman accounts.

Sorry, but I have my Firefox at about 600px width and your logo still obscures the text. User-agent sniffing won't solve this one, you should do media-queries based on the actual window size.

Python lends itself quite nicely to code-golfing, that's true. In fact I am constantly amazed of how terse Python code can be, despite the significant whitespace stuff.

  from os import*
  r='s=[0]*8**5'
  p=0
  for c in read(0,9**9):r+='\n'+' '*p+dict(zip("><+-.,[","p+=1|p-=1|s[p]+=1|s[p]-=1|write(1,chr(s[p]))|s[p]=ord(read(0,1))|while s[p]:".split('|'))).get(c,'');p+=c in'[]'and 92-ord(c)
  exec r

Using gets() also makes writing exploits much quicker - win-win! ;-)

Sorry, I couldn't resist - you are of course right with the general stdio over std::iostream thing, though. I've also found that memory usage and executable size explode when using streams - though that's not C++'s fault per se, more a stdlib/compiler problem.

> It's politically easier to bring on someone new, deal with the productivity hit, and then have them start addressing the systemic technical issues.

I can see the reasoning behind that and it would be wonderful if that tactic actually worked. In my experience however, it does not.

I work at a company that is heavily driven by a non-technical management. They don't understand the concept of "technical debt" and your characterization of how it is to work at such a company is _exactly_ like I have experienced it. But: the managers/MBAs/what-have-you at my company are not idiots. The problem is: if they bring in a new hire into a team (which happens fairly often, we went from ~100 engineers to more than 250 in 2011 alone), they also raise their expectations of said team's output.

The team-leads (which is the highest technical position in my company) do, of course, try to fight that back and try to use the plus in productivity for fixing underlying technical problems (of which there are plenty). Sadly, they have a hard time explaining even the productivity drop that stems from bringing the new team member up to steam. After that, there is just not enough argumentative leverage (I hope that's a term that exists) left to explain why we could not move even faster, now that we are one engineer more.

So, in the end we are exactly where we were - and find ourselves longing for another new hire to work exclusively on the technical debts.

Reading the article and the comments here, I came to the conclusion that I seemingly don't really use vi. As in: I don't live in it.

On a typical day, I work with my files using grep, awk, bash, python, sed, make, cat, xargs, etc. And, of course, vi.

But I don't really use it like some (most?) people here seem to do. I don't list and navigate through files in vi (I use tree, ls and find for that). When I use vi, it's mostly for short bursts of manual editing. Occasionally, vim's syntax highlighting comes in handy - but that's about it.

Don't get me wrong: that is exactly why I _love_ vi. It starts fast[0]. It fits in pretty well with the rest of the unix environment (it can read stdin, for example; and with vim you can open multiple files given on the command line - and you can construct that file list with any of the standard unix tools, of course).

So, for me, the question "IDE or vi" ends much earlier. I don't even come to the point where I could discuss editing features. Can't read from stdin? Doesn't start in less than 1 second? Doesn't fit into my work-flow.

Of course, vi(m) is a great editor, for all the reasons mentioned here and in the article. But the unix user-land has some great tools, too. And it includes vi. So it is by definition an even better editor than vi. :-)

So that's what I use.

[0] Believe it or not, emacs starts still too slow for me. These one or two seconds tend to disrupt me a lot (I've tried it, with GNU emacs). And, as I said before, I invoke my editor pretty often, maybe 50 times a day.