telent

Indeed. Google is a free service and Google Apps is a paid service, but I wouldn't expect significantly more longevity from the latter just because I'm paying them $x a year than I would from the loss-leader service.

I don't think the issue is so much "what should they do now", because what they should do now is constrained by what they can do. The issue is "what should they have done in 2008?" - should they for example have said "please note that our current business model is not sustainable, and while you are welcome to enjoy it while it's here you are cautioned not to behave as though it will be here for ever"? Providing a limited, ephemeral, or best-effort service is a perfectly OK thing to do provided your service users know that's what you're doing and can (as raganwald says he has) tailor their behavour accordingly

It's interesting (to me at least) that we have largely dispensed with the Unix privilege model in production and replaced it with running an entire unix system for each application, virtually hosted on the real one. I wonder if, had there been more emphasis historically on reliability and decoupling, we would nowadays be running more than one service on a host instead of running them in individual VMs hypervised by that host.

I suspect the answewer is "no, not entirely" due to other limitations of the model: ports under 1024 are root-only, regular users can't call chroot(), etc etc - but there have been solutions proposed/designed/implemented for most of this stuff , they just haven't had much uptake.

I thought it was a jsmin "do no evil" analogy. Even Apple ships GPL code

Guess what? I consider that a bad thing too.

But you're still reading things into my comment other than what I said.

(1) Rails had insecure defaults which encourage bad programming

(2) pthreads has an API which - at least, in its designer's view - fails to sufficiently discourage bad programming.

(3) The post I was originally responding to was suggesting that it would be in some way an unusual mindset ("startling" was the actual word used, I think) for a library author to wish to discourage bad uses of his library. I think otherwise. Rails was pretty much the first (recent, well-known) example that came to mind where a library author had (imo, anyway) not sufficiently discouraged bad uses of his library.

That's all. I make no argument about the comparative size of the communities,nor the comparative intellectual smarts of their members, nor the reach/impact of the design decisions that the library authors made in each case. That's all I said. Library authors can and do and should design their libraries to encourage their consumers to do the right thing, and this should not be startling.

Indeed it is as you say. "attr_accessible kerfuffle" was my (apparently, and quite bizarrely, considered inflammatory) shorthand to refer to the whole episode. I'd edit the post to clarify, but it won't let me do that any more

I think you've jumped at a different parallel than the one I was trying to draw. It's considered a bad thing that Rails prioritised developer convenience over the encouragement of reliable programming practice. Why should it be considered a good thing for a Posix standard to take the same position? Ignore questions of reach and impact, the comparison is one of attitude not of effect.

Irrespective of what the tutorials say, many developers will go reaching for a recursive lock the first time they get a recursive deadlock - especially if they come from a Java background - and tutorials or no, it's not as though the information is hard to find. Five minutes browsing Stack Overflow will quickly disabuse you of any perception that all the people writing POSIX threaded apps are in any way particularly gifted, even compared to Rails developers

The difference is that memory checking in debug C runtimes doesn't paper over your mistake: instead it breaks your program reliably so that you know you have a mistake. As per the linked article, "While recursive mutexes may seem a convenience for debugging, in fact it's the opposite -- you're better off with a "strict" debugging mutex (like the POSIX error-check attribute) that checks, tracks, and enforces ownership restrictions a "normal" mutex may ignore in favor of runtime efficiency."

Compare and contrast with the Rails attr_accessible kerfuffle of last week, where it was generally held by (I think) the majority of commenters that the library should not have provided this convenient feature or at least should have made it more difficult to enable.

I'm right there with this "startling" (some would say "opinionated") position. And so is my C library, which complains at me every time I compile a program using getwd()

("my" as in the one I have installed here. I am making no ownership claim)

If I set my browser window to a reasonable width I can have legibility without foofy margins and I can use the rest of my 1280 pixels for something else. Window systems - they rock

I said it was a nitpick, but the post to which I responded did say "all economic activity".

Does it even matter? It matters if it means our fully automated jobless future is penury and starvation instead of the post-scarcity Culture we're looking forward to.

This is a nit pick, but much economic activity these days is nothing to do with alleviating scarcity and everything to do with introducing artificial scarcity where it didn't previously exist. See e.g. Intellectual property.

AFFECT, grrr. Not effect. To effect every coder would be to bring them all into existence, which is clearly not what happened here.

Here's a rather less paranoid article that's (partly) about SO.

http://www.tbray.org/ongoing/When/201x/2012/02/29/Undocument...

Seriously, given that the data is freely available and for as long as it remains so, "OMG you're making money from my knowledge how dare you you cad" is about as valid a complaint as it would be if levelled at any of the ISPs in days of yore that ran Usenet servers. And it's definitely saved me more time (a factor of 100 - 10,000? I have no idea) than I've ever given back to it

What's not true? Exec used some OO techniques in non-OO languages. So does Linux. I can't see which post this was intended as a response to

If "I've never heard a good argument", "a completely academic waste of time" and "why should anyone non-academic building actual systems care what it means" aren't implications that your experience is valid and others' experiences aren't, then I concede and am happy to admit that you have totally Won The Argument if it makes you feel better

In either case, I'm done here.

See where I said "usually"? And where I said your experience is valid but don't assume it's universal? Right

How can you say (TCP|Unix|C) is going to give you a bunch of stuff "for free" when you haven't even seen the application. How do you know you're even going to get what you want?

You don't, of course, but it's usually a pretty reasonable assumption that the effort involved in implementing your own (reliable stream sockets|scheduler and memory manager|high level language compiler) will eclipse severalfold any advantage from doing so. If you don't find that the same obtains from using HTTP and hypermedia then that's your position and you're welcome to it, but don't go assuming your experience is universal.

Bundler and rvm? "now you have two problems" :-)

From my perspective Rails popularized (perhaps even normalized) tdd, which I think is probably a significant contribution to programming culture.

Or were high-ceremony Java enterprise folk doing tdd all along and rails just adopted it? I don't know but I suspect they were at best pretending to

For "could be used for", read "was designed for".

I have that exact alias. But it still adds 3 seconds to the startup time of any command run under it

Maybe my laptop is underpowered, but three seconds to do essentially nothing is still a long time

I use emacs and have done for ~ 20 years, but I don't think this article would sell me on it if I didn't already.

An editor is just an editor: an editor with a variety of unrelated crap (text adventure, tetris game, mail reader) bolted on the side is not obviously better, it might just be bloatier. The compelling feature of emacs is its extensibility and self-documenting nature: that Gnus exists is not a big deal, but that you could invent it if it didn't already exist - that's where the magic lies. Emacs is a habitable programming environment.

If HN lets me post links in comments, here's an example from a little while ago showing how I once extended the Gnus email composer to check for missing attachments - http://ww.telent.net/2003/1/14/_updated_for_elisp_syntax_err...

"First off, we didn’t need to restart emacs. In fact, we didn’t even need to load any files. All of this was done on the fly. Second, we didn’t at any point have to read an info manual, fiddle around in the filesystem, or search a web site to get to the documentation for anything. We had a little help from customize to tell us that ispell-message was a suitable function for this hook, but aside from that, all we needed to know was in function and variable docstrings."

"I think that trying to shoehorn Vim or Emacs into becoming something that it’s not [an IDE] isn’t quite thinking about the problem in the right way."

This may or may not be true for Vim, I don't know. But I think the majority of GNU Emacs users would view it as, to a large extent, supplanting the unix shell environment. Stallman notably didn't even use unix until he had written enough of emacs to be able to avoid ed and vi: he edited on another system and transferred the files across the network

Yes. "let x=1" is quite clearly syntactic sugar for "(lambda(x) { ... rest of block here ... })(1)" so while you might argue that it's unnecessary (I'd disagree, but it's a respectable argument), you can't realistically claim that it would be adding a layer of complexity. The complexity is there already: the sugar is just encapsulating in a more eyeball-friendly format

But what does it do that makes it apparently uncacheable? Your pages change when you write a new blog entry, or when someone posts a comment - and even then there's no hard constraint that requires their comment appear immediately - serve a stale-by-60-second page and I doubt most people would notice, never mind care. If your blog engine can't serve one page every sixty seconds to the nginx/vanish/other reverse caching proxy in front of it, just what is it doing?

(This is partly a genuine question and partly a rant caused by seeing my VPS go into swap death spiral when the googlebot came around, just because WP apparently couldn't serve more than about ten simultaneous requests. Intellectual curiosity says I'd like to know, but life really is too short to go back to having to deal with it fo rreal)