samdk

You're mistaken. With Tor you are (in theory) anonymous at every leg of the journey. The only connection Tor doesn't encrypt is the connection between the exit node and the server you're connecting to, which is unavoidable. Your ISP can probably tell you're using Tor, but they won't know what you're sending or what its ultimate destination is.

In a little more detail, when connecting through a circuit of Tor routers R1 -> R2 -> R3, the encryption looks something like this.

    client <- E1(E2(E3(msg))) -> R1 <- E2(E3(msg)) -> R2 <- E3(msg) -> R3 <- msg -> server

It's not perfect, though. If you can see the traffic between the client and R1 and between R3 and the server and you're being reasonably clever you can probably break Tor's anonymity. (This is what's called an 'end-to-end correlation attack'.)

I don't know if the person you're responding to is actually correct or not, but the map you're referring to is very misleading. The places you named--and, not coincidentally, many of the places on the map with the highest murder rate as a percentage of population--are all sparsely populated.

Notice that the many of the places with the lowest murder rates also tend to be sparsely populated. What you're seeing is the increased variance that one should expect to see when dealing with smaller sample sizes, not evidence that small towns are more dangerous than big cities.

You are asking someone to execute a shell script directly from the internet, which is questionable in the first place. And then you're making it much much worse by asking them to do it with a non-https link, meaning that someone can trivially execute a MITM attack.

Your webpage doesn't have any explanation other than a video. I can read a paragraph or two in a couple of seconds--I'm not going to take a minute and a half (and stop listening to the music I'm listening to) to watch a video. The GitHub README doesn't really have any information about what it is either.

I haven't actually tried this, because I have no idea what it is. The other comment in here linked to an example .freshrc file--I noted that every line that's not a comment starts with the string 'fresh ', which seems like an obvious annoyance. Even if you want it to just be a shell script you can execute, you could support a batch mode to do something like this, for example:

    fresh batch <<'BATCH'
    config/vimrc --file
    config/gemrc --file
    config/pryrc --file
    BATCH

...or anywhere you're using a 'let' statement. I write a lot of OCaml, and I write a lot of multi-line anonymous functions that aren't stateful. I think it's less common to do this in Haskell, but that's more because it's Haskell than because there aren't any side effects.

Random other tidbit that doesn't deserve its own comment:

In Python, instance.method is the same as doing ClassName.method(instance). This can be helpful when using map/filter, because you get to do map(ClassName.method,lst) instead of map(lambda x: x.method,lst).

Even for people who don't read as much as I do, I think those benefits exist and that you're understating them. (Especially because my Kindle is part of the reason I read so much, not just the means by which I do it.) A Kindle is still a lot more portable than even a paperback. (I can comfortably fit it in a jacket pocket.) It's still way more convenient to be able to buy books whenever you want than to have to plan a trip to the bookstore or library. It's still a lot nicer of a reading experience than most paperbacks.

Yes, I do spend a lot of money on books every year. When you look at it in context though, that number really isn't crazy, even for something I don't end up owning. Cable TV, a Netflix account, Spotify, and going to the movies once a month are all in the same order of magnitude for similar-ish kinds of things, and you don't end up owning anything as a result of any of those, either. Reading--even when you're buying every book you read--is actually a surprisingly cost-effective means of entertainment.

And there's definitely not a 100% premium compared to me buying the physical books--that's a very silly way to do cost analysis. A sizable percentage of the actual benefit of reading a book is reading it for the first time, so losing access to it later doesn't completely devalue your purchase. Even if you were to factor in the chance of losing access to the books you've spent money on later (which is entirely reasonable), you should also be factoring in the chance that you don't ever lose access to your books. Anecdotally, events like this seem extremely uncommon, and so treating them like a certainty doesn't make much sense.

As I said, I'm not trying to defend Kindle (or any other) DRM here. I'm trying to argue against the idea that people who own and use ebook readers are idiots.

(And as for how I read so much...20 minutes both ways on the subway plus another 3-4 hours throughout the week is easily a book a week for me--I read pretty quickly--and I occasionally just sit down and decide to spend an evening reading instead of doing something else.)

You're understating the benefits and missing a few key ones.

First, the instant purchase ability is extremely important. It means that books gain some measure of equality with other forms of media (the internet, movies/tv, music). With a Kindle I can read whatever book I want whenever I want, which means that I read many more books than I used to.

Second, the mobility advantage isn't slight at all, especially for people who read a lot. If you're never carrying more than a single book around that's one thing, but I read 1-2 books a week, and a lot more (often 5+ a week) if I'm traveling. Even just during my daily commute, it's far easier to read while standing on the subway with a Kindle instead of a book.

Beyond that, I find reading on a Kindle to be far more comfortable than reading a book. The actual reading experience is much nicer than trade paperbacks, which are printed very cheaply. It's much lighter and only requires one hand to hold/turn pages, so I can more easily read while lying down, and the newest version has a very nice backlight, so that I can read in bad lighting.

There are obvious disadvantages, and I absolutely hate that DRM is still a thing, but the benefits absolutely outweigh any possible disadvantages for me. Anecdotally, it's the difference between me reading 5-10 books a year and me reading 50-100 books a year, and I'm a much happier person in the latter state.

--

Also, if you're not saying something to be rude, you should actually write like that, not add a disclaimer at the top of what you're writing. There were a lot of ways to get the same message across without calling people idiots.

If you're worried about this, you can get the bundle for free, and then increase your contribution later (for as long as the bundle is still going on) once you're sure all of the games work on your computer.

I use my up/down keys to move between visible lines (rather than real lines, which is what they and j/k do by default). This can be helpful occasionally when you have lines wrapped for something that's text rather than code.

    " up/down move between visual lines
    " instead of actual lines when wrapped
    imap <silent> <Down> <C-o>gj
    imap <silent> <Up> <C-o>gk
    nmap <silent> <Down> gj
    nmap <silent> <Up> gk

(You could also map j/k to just do this if it's something you use often, but I prefer not to.)

That's a fucking stupid rule.

(And I say that with the full knowledge that my phrasing will make you less receptive to my argument.)

Environments where you can't discuss mistakes are poisonous. People make mistakes. People do stupid things. If those mistakes are not dealt with directly, they become larger mistakes, and you end up in situations where people don't take minor actions that can prevent disasters because they're afraid that somebody's feelings might be hurt.

As an example, a few years ago the college I was then attending switched from internally managed email to gmail. For a month after the switch, you could log into anyone's email account without a password. This happened in large part because there was a culture of ignoring mistakes, and people who regularly raises issues were branded as "complainers". And so when they were doing the switch, nobody was willing to stand up and say "have we done basic testing?"

There are, of course, times and places where your goal is not offending people, and criticizing them is obviously a bad idea. (Telling a VC "that investment you made a week ago was really dumb" is probably a bad way to get them to invest in your company.) But much of the time, that rule causes many more problems than it solves.

It's also worth noting that phrasing and delivery matter quite a lot, and that's something that's much harder to convey in text. There's a huge difference, as I've said already, between insulting somebody and criticizing their work. The first is not productive--the second can be.

    "X is rubbish and whoever came up with this is stupid"

To be clear, I agree that this is awful feedback. It contains no useful information and personally insults the creator, both of which are bad. There is a world of difference between saying "this design is bad" and "you are a bad designer". Even good designers come up with truly terrible ideas constantly--it's part of the process. (I certainly have more than my share!)

Obviously people get emotionally attached to their work. I certainly do. But you have to be able to let go of that while you're receiving feedback, or there's no point in you getting any.

Again, to be clear, I would not say "this is rubbish" or "this is awful" while critiquing a design. I would say "this is not working at all because you're ignoring considerations A and B". There are many, many design ideas that just do not work. As a designer, you are much better served by someone telling you "this is not working at all, you need an entirely different approach" than you are by someone trying to hint you towards evolving a design that's based on a faulty premise.

If I am working with someone on a design and they bring me something as bad as that redesign, I'm going to tell them it's awful. That redesign is rubbish and it very clearly was done without thinking about what was important, and nobody benefits by pretending that's not true. As a designer, you should not be offended by people telling you things you've made don't work, so long as they're providing reasons. Those people are doing you a favor. You cannot remain emotionally attached to your own work and be a good designer.

It is far easier to work with people who are direct and harsh than the people who dance around the matter. You can never trust anything the latter group of people tell you, and so you end up wasting a tremendous amount of time because you have no idea what they actually want because they refuse to actually tell you.

(That said, there is a world of difference between "that is rubbish, you did not think" and "that is rubbish because you did not think about things X, Y and Z". The first is useless, the second is helpful.)

--

Your idea that people must offer alternate suggestions before criticism is ridiculous. If you present your redesign idea to the public and it's terrible, the correct response is "that's not very good, go back and try again", not "that's not very good, therefore I will spend the months required to come up with a non-awful alternative before commenting".

The parallels to Unix are strong enough that having an actual pipe operator can be very useful. I frequently write code that looks something like this:

    List.map data ~f:(fun elem -> ...)
    |! List.find ~f:( ... )
    |! Option.map ~f:( ... )
    

(This is OCaml, not Haskell, but the syntax is similar.) The definition of the '|!' operator is quite simple:

    let (|!) x f = f x

Please actually read what I've written before making assumptions. I have used Gnome 3 for many months and found it to be a step backward in almost every way from Gnome 2.

I read through the release notes to confirm that I wasn't missing anything important in my own use--which I noted in the part of the quoted sentence you excised. I also said, in the same comment you're replying to, that I spent many hours trying to get Gnome 3 to a point where I found it an acceptable desktop environment, and failed.

I'm not evaluating it from the release notes--I was rereading them to make sure I wasn't just missing some major improvements I just hadn't noticed while using it. I don't think it's well designed at all, and it's certainly not polished at all, which is an important part of good design.

I suspect that most of the major changes have been on the back end, and that it is a substantially better platform to develop on. Unfortunately, that doesn't affect me at all as a user. I want to be able to run terminals and a web browser and not much else (and I don't think I'm alone in that), and so making Gnome a better environment to develop against is unlikely to make my life any better in the foreseeable future.

Of course there'd be less criticism if Gnome 3 were a new project. If it were a new project, everyone content with using Gnome 2 would've been able to safely ignore it. Gnome 2 was boring and mediocre, but it worked. Gnome 3 is still worse in many ways than Gnome 2, and--as you said yourself--has not done anything particularly innovative.

It's one thing to go through the pain of a major version transition to make something substantially better, but Gnome 3 hasn't done that. I just read through the release notes for the 3.0, 3.2, and 3.4 releases of Gnome to confirm that I wasn't missing anything, and can find literally nothing that actually makes my life significantly better. When you're making major, breaking changes, you need to be able to justify them. As a user, Gnome 3 has done nothing at all to justify the many hours I spent trying (and failing) to get Gnome 3 to a point where it wasn't actively painful to use. (And reading posts like this gives me no confidence that it's going to get any better.)

According to the article, they're getting 2 million uniques/month, which suggests that demand exists. And with such blindingly obvious product/advertising tie-ins, it seems like there's the potential for actually making money here.

I'm certainly not in any position to make intelligent comments about this market, but I'd be wary of dismissing it because it's something that's not important to you personally. Fashion is another example of a market that many people here don't care about at all but that generates quite a lot of money.

It's actually not that. Spacing a header equally between preceding and following paragraphs can work fine. There's an obvious association with the following paragraph, because headers are expected to come before content, and so you don't need to imply that association visually.

In this case, the header is closer to the preceding paragraph (~15px) than to the following paragraph (~19px). It's visually implying a connection that doesn't exist, which is why it's problematic.

This advice, as with much other good advice, should be taken and understood in context. It is an essay about how to write a good essay, and there are times when you want to break some of these rules.

As one example, expressions like "I think that" and "in my opinion" can be useful if used purposefully. When reading an argument, we have a tendency to fixate on the points that we take issue with personally. By saying "I think X is true" instead of just "X is true", you make it easier for someone to disagree with your specific point rather than your entire argument. In some contexts (like HN comments), this can help to reduce animosity and get much more of your point across to people who don't fully agree with you.

It's obvious Apple isn't the only offender, but they are a big and, lately, very active one.

I fault them for their actions because I think what they're doing negatively affects a large number of people. It being legal and them being able to make money because of what they're doing doesn't make it okay.

To be clear: I will say the same thing about any company using using frivolous patents to suppress competition. It is a flawed system, and the people in the best position to oppose the system are the people in charge of large tech companies. Apple is not doing the best thing possible within a flawed system, and they are not trying to change the state of affairs. They are using their patent portfolio aggressively to try to suppress competition, and I think that's a problem.

    "Don't hate the player, hate the game"

If you find your arguments relying on catchy phrases like this, you should reexamine them, because they're probably lacking.

I especially dislike this one in particular because it's used as an excuse to avoid having to justify harmful actions. "Everyone else was doing it too" is not a valid excuse for doing something wrong, especially when you are--as Apple is--a large enough "player" that your actions help shape how the "game" is played.

In any case, your presentation of Apple's actions is a lot more benign than reality. It's one thing to acquire questionable technology patents to help you defend yourself against litigation. That's unfortunate, but doesn't really actively harm anyone. It's also not what Apple is doing: Apple is using its patent portfolio offensively to try to shut out competing products.

I think that many people post jokes here because on other similar sites they're an easy way to get (often quite a lot of) upvotes, and a lot of us here dislike that mentality.

My criteria for upvoting a joke are generally the same as my criteria for upvoting any other comment: if I feel it adds something to the discussion, it gets an upvote. If I feel like it contributes nothing at all, it gets a downvote, because reading it is a waste of someone's time.

Most of the jokes posted here are surface humor. They are relatively obvious and add nothing to the discussion, and so I downvote quite a lot of them.

Occasionally someone will use humor to make a good point, and then I will upvote them. In general I'd discourage it, though--it's usually much easier and clearer to just say what you mean, and people here are usually receptive to well-argued points.

Responses like this to people who don't like PHP are just as bad as the people constantly and loudly attacking it. Neither accomplishes anything other than building animosity.

Your suggestion that people improve PHP instead of attacking it is naive. PHP is, as you said, a big legacy open source project. As a result of that, it's basically impossible to make the extreme, breaking changes that many people (me included) think would be required to make it a reasonable competitor to the existing options. (And the PHP community is not especially inclined to change. It took years for short array syntax to get added to the language. If something as obviously beneficial as that is going to be hotly debated, making real, breaking changes is impossible.)

Faced with the alternatives of trying to radically change PHP (which is, as I said above, impossible) or to use and improve other languages and frameworks, I think the choice is obvious. It was one thing 5-10 years ago when there weren't necessarily good or mature alternatives, but we have many choices now. In my opinion, it makes very little sense to use something with as much extraordinarly painful legacy baggage as PHP unless you have an exceptionally good reason for doing so.

I do this whenever I read complicated pieces of code. It's enormously helpful, even if I don't keep my changes around.

Some of the time the changes are broadly beneficial (like taking a multi-thousand-line file and adding some organizational structure) and it makes sense to commit them upstream. Some of the time the changes are personal preference and aid only in your own understanding of the code.

As with most things, the best approach is to use your judgement, not get too attached to your own changes, and to understand that context matters.

And they're charging (as far as I can tell from finding the same/equivalent parts on newegg for the lowest end $2,500 model) 4-5x the actual hardware cost.

CPU: $260, 3x2GB ECC DDR3: $60, 1TB 7200 RPM HDD: $120, Radeon HD 5770: $120

Having strong opinions is different from having an opinion on everything.

Being in a place full of opinionated people is nice, so long as those people are able to discuss their opinions rationally and are okay with not getting their way every time.

Design feedback: Your 'buy now' and 'learn more' buttons on the homepage are very hard to see. They need to stand out. Make them bigger and bolder, or change the color (red would stand out much more and still fit into your overall theme), or fade out the background slightly. Or, ideally, do more than one of those things. You really don't want those buttons to be hard to see.

Cost and details of what you get should be listed prominently on the signup page. I see the cost on the homepage, but only after looking really hard. You need details on what kinds of socks you're going to be sending out. Pictures seem essential for something like this. (Don't make me go looking for them. Make them bigger.) Your 'learn more' page desperately needs actual information as well.

You're conflating two separate arguments I made about two separate topics. The first is about per-project vs per-user pricing. The second is about tiered pricing. They are independent.

First, per-project pricing: Any pricing scheme creates incentives. You get customers' money when the benefits outweigh the price. Per-project pricing makes it easy to get your product in front of as many eyes as can benefit from it, which can create internal network effects that boost internal adoption, which in turn leads to more use. Per-user pricing does not have similar network effects, because you associate a cost directly with adding people to the network.

(Which doesn't mean that per-user pricing has no place ever--that's absolutely not my point--just that it's not something that always makes sense.)

Second, tiered pricing: It absolutely makes sense that your customers like per-user pricing: they've already self-selected to use your product, which has per-user pricing. The people who don't want per-user pricing are probably just going to ignore your product in the first place, and you'll never know they exist. Tiered pricing is preferred by a certain class of customers. Some of the reasons for that are listed in my initial post. It's unsurprising that it's not preferred by other classes of customers.

Again, I am not arguing that tiered pricing is a universal good or anything similarly silly. What I'm doing is arguing against your suggestion that tiered pricing is always bad.

I'd argue that charging per-project makes much more sense than charging per-user. Charging per user creates incentives to have as few users as possible using Basecamp, which makes it much less useful. Charging per-project means that you're charging based on how much people are actually using your product, not based on how many people happen to have accounts.

Tiered pricing is easy to understand and predictable. Businesses (and people) like predictability when it comes to pricing. In most companies, it's a lot easier to say "we are going to pay $X a month (or year) for this product" than to say "we are going to pay somewhere between $X and $Y this year".

In any case, if you have more than 10 projects you're probably a large enough group that paying another $30/month is not an issue. And if you're not and $30/month more is too much, 37s response would probably be that you're not the kind of customer they're targeting.

I don't program in Node very much or in Go at all, but I think there are reasons to use Node that aren't "Node is fast". I think the "Node is fast" mantra was originally really meant as a comparison to Ruby/Python/PHP, not as a comparison to lower-level languages like Go. (I personally wish Node would just abandon speed as a selling point altogether--I think it'd lead to many fewer misunderstandings.)

In any case:

Node lets you reuse the same code on both the client and server. This can be very valuable if you're writing a JS-heavy webapp. In my experience, the most useful bits of code are the in-code data representation (models in an MVC world). Being able to have identical functionality client- and server-side can save a lot of time.

Node also has Socket.IO, which is very useful if you want to use websockets. (Go has a library for it, but it hasn't been updated in a long time.) The vast majority of the Node ecosystem revolves mostly around building interaction- and communication-heavy webapps. I don't know Go or its community at all, but I don't believe they have the same kind of single-minded focus that Node has. If you're trying to do the things Node does well, you will likely benefit from the community support.

There are, of course, many downsides to Node as well, but much as I dislike Javascript, I still think it's one of the best choices for writing highly interactive webapps right now.

Python lists are array-backed, Lisp lists are singly-linked lists. Appending to the front of an array list is O(n)--you don't want to do it. Appending to the back is constant time, but is an in-place operation and doesn't return anything, which is less than ideal for FP purposes.