samdk

I think that not having points has some nice qualities, but it also feels like I'm being denied information that I find useful in reading/skimming a thread. I've noticed I find reading HN a lot harder while this has been in effect. (I've also noticed that I tend to unconsciously give numbers in usernames some weight when reading a comment. The same applies for the time it was posted.) One possible compromise would be to display either a number or simple graphic that approximates point totals instead of displaying them explicitly.

Also, I've been planning to write a longer blog post on the following, but given that I've had no time lately and am not likely to have any soon, I'll just float the idea here.

One idea I've had that I think might be interesting is dealing with upvotes or points in terms of logarithmic scales. That is, it takes one upvote/point to get a comment from 1-10, 2 upvotes/point to get from 11-20, etc. (Exact numbers would have to be scaled, of course.) I find that going into a thread an hour or two old and seeing comments with 50-100 points is a major disincentive to commenting, even if I have something to say. That comment or couple of comments and their resulting threads are going to make sure very few people ever read what I've written. An appropriately scaled log-scale system might make it so that really really good comments still get really really high scores, but so that others (which might have simply come too late in the discussion to be competitive on a raw-point scale) still get a chance at being seen.

(One related idea would be to make the point-approximating graphic log-scale even though the points themselves remain the same underneath.)

I'm going to be a dissenting voice here and say that these need a lot of work, because I think that's a lot more useful than saying they look nice. Please don't take this too negatively, because I'm not trying to tear you down and say these are terrible or anything--I'm trying to help you make them better. Mostly the issues are in the details, but there are larger things too. I don't have a lot of time right now (or any time between now and Tuesday), but if you'd like more specifics, feel free to send me an email (it's in my profile) and I'll be happy to get back to you later this week.

There are definitely good reasons to look like Facebook (which I'm pretty sure is intentional). The most obvious reason is user familiarity: people know how Facebook works and they're going to be a lot less intimidated if they've seen something like it before. However, one not-necessarily-obvious downside to doing this is that people know Facebook and know how it works, and if things look like they do on Facebook but don't behave the same then they're going to be confused. That's not necessarily a reason to change the look entirely, but it definitely is something you need to be aware of if you're going this route with your design. Another potential issue is that people really don't like change. (For an example, see your Facebook news feed any time there's a design change.) If you look similar to Facebook but not as good, you may have issues getting over people's initial reactions.

There are a lot of little details I could pick out, but I think your biggest problem right now is with spacing and whitespace. The info page, for example (http://opensource.appleseedproject.org/preview/images/info.p...) has way too much whitespace around the actual information. Whitespace can be a good thing when your content is balanced with it, but right now the whitespace is dominating the page and it looks very empty, which is not at all the impression you want to give off.

The other thing I think you can improve on immediately is your use of gradients and drop shadows. Right now they're too obvious: a little goes a long way. The design is otherwise very flat and text-based (not a bad thing!), and so they stand out a ton and look out of place. The combination of the square tabs and the very large drop shadow is especially jarring. As a first step, I'd suggest getting rid of all (or almost all: the subtle blue to white from top to bottom is working pretty well) of them. Focus on getting the basics of spacing and hierarchy right first, because that's much more important.

As a final note, the Appleseed logo in the top left is going to cause some undesirable behavior if left like that. Either the logo is going to be hidden by the edge of the window or the picture when the browser gets narrower, or it's going to cause a horizontal scrollbar. Both are bad things.

Hopefully that was at least somewhat helpful and gave you some things to think about. And like I said above, I'd be happy to give more (and more specific feedback) later in the week once my thesis is finished.

From the HN guidelines: "Please submit the original source. If a blog post reports on something they found on another site, submit the latter."

The submitted post is badly written, covered in ads, and includes less information than the original. (Which can be found here: http://windowsteamblog.com/windows_phone/b/wpdev/archive/201...)

Awesome, thank you. I'm definitely going to be checking this out the next time I do server admin. Or maybe even just the next time I'm setting up a new development environment--it'd be nice to not have to remember to install everything manually.

One note: your blog is lacking a link back to your homepage on individual post pages.

(Also, previous discussion on HN for those who missed it: http://news.ycombinator.com/item?id=2344080)

I'm not sure if it's where the 'param: Type' idiom is where it came from originally, but its use in Mirah almost certainly descended from its use in Haskell and ML. Scala also uses it, and its use there is definitely ML/Haskell-inspired. (Haskell technically is 'param :: Type', since ':' is the cons operator, but it's basically the same thing.)

Since languages like Haskell and ML (and Scala, to a lesser extent) do type inference, type annotations are often unnecessary, and so having the type listed after the name probably makes more sense in that context: what's important is the name, and variable-specific type hints are usually there for the compiler, not the human reader. The exception is functions, which very often get type definitions just because it's very helpful to have that information as a human. Since ML/Haskell-like languages have multiple function definitions and rely on pattern matching, the postfix type notation fits in very well:

    func :: type1 -> type2
    func a = ...
    func b = ...

If anyone is interested in this stuff, I recommend taking a look at "How Much Anonymity Does Network Latency Leak?", by Hopper, Vasserman, and Chan-Tin, published in ACM Transactions on Information and System Security. (There's a PDF link listed on http://www.freehaven.net/anonbib/, which is a very large and comprehensive list of papers about these kinds of things.)

The second half of the paper deals with an attack very similar to the one described here. They're trying to do it against multi-hop proxies like Tor though, and so what they have to do is a lot more complicated. Some of the multi-hop proxy stuff is on (in my opinion) somewhat shaky ground since it relies on an older published attack that's only been verified to work when there were ~15 Tor routers on the network (now there are ~2500), but other than that it's a very solid paper.

(My background: I've been doing research related to attacks on Tor since my sophomore year, and I'm now writing my senior undergrad thesis on that research.)

You can set up default private browsing/incognito mode if you want to. None of the major browsers have support for doing it through the normal options GUI as far as I know, but getting it working isn't at all hard.

In Firefox, set the "browser.privatebrowsing.autostart" about:config flag to true.

In Chrome/Chromium, append " --incognito" when starting to open an incognito window. Alias it or add it to your GUI shortcuts to start it that way by default.

In IE8+, append " -private".

Why is it stretching things a little far? Non-infinite tape is, as you noted, a limit on everything we consider turing complete: this is just running at a much higher level of abstraction than your computer. You could (if you were so inclined) create a physical machine with a grid of memory that behaved according to rules defined by CSS selectors. Just because this doesn't do direct memory access and behave like the computer or a traditional TM doesn't make it not a TM. (Or, at least, any less of a TM than the computer you're using.)

Running

    coffee -cw *.coffee

will watch all of the CoffeeScript files in a directory and compile them to JavaScript whenever they change, which is what I use for keeping things updated in development, and the production deployment scripts I run compile the CoffeeScript to JS before deploying.

Aside from having to set up a terminal running the compilation task when I start a dev session, the fact that it has to be compiled doesn't affect me at all.

SendGrid and MailChimp might be large competitors relative to the size of PostageApp, but the scale difference is orders of magnitude less than the scale difference between WePay and PayPal.

I counted 18 people on the "team" page of SendGrid, and MailChimp's website lists them as having about 70 people working for them. I haven't been able to find exact numbers of employees at PayPal, but I know it's easily into the thousands, and very possibly into the tens of thousands.

I think you have a good point: that relying on being able to move faster than your competitors can be dangerous if your competitors aren't actually slow. I don't think you can really make an accurate comparison between SendGrid/MailChimp and PayPal though. The scale (and culture) is just completely different.

That's not why I use Vim, and that's not why most people use Vim.

I use Vim because it's an enormously powerful tool that makes me more efficient and because I enjoy using it. (I've never spent four hours attempting to debug my code only to discover that the problem was a bug in Vim. I can't say the same about Eclipse.)

Vim and Emacs are not toys. If you think they're toys you haven't invested enough time in them to understand how they work. Note that I'm not saying that a competent Vim/Emacs user might not prefer something else. I'm saying that you can't get to the point of being a competent Vim or Emacs user without understanding how enormously powerful both are.

Vim and Emacs can do just about everything your IDE can do (and, in many cases, more). The difference is that you're not starting with everything built in and crowding a complicated GUI. You're starting with something simple and powerful and (if you want) building it up with exactly the features you want.

Evaluate what the consequences of getting a 90% average are, and decide whether it's going to hurt you or not. If you're applying to very selective schools it likely will. If you're starting your own company it won't matter at all. I did most of my work during my lunch period (it's astonishing how much busywork you can bullshit your way through in 30 minutes--I almost never had any work to do at home except for AP classes), ended up with a mid-90s average, got into a very good college, and am very happy with how things turned out.

Don't ignore the things that don't interest you just because they don't interest you. Even the things that aren't directly relevant to your future can become very useful in unexpected ways. School might be an incredibly inefficient way of learning things for you, but if you're forced to be there, put the time to good use. (I might be very happy with how things have turned out in general, but I do wish I'd put actual effort into my foreign language classes.)

One thing to look into is graduating early. I graduated a year early from HS, and it's one of the best decisions I've ever made. (I'm now a senior in college.) I had to take English classes at a local community college for one summer to satisfy requirements, but otherwise it didn't really change much for me. If you're interested, talk to your guidance counselor now. I started planning in the beginning of my sophomore year.

I should really be doing work right now, but if you have questions about anything or would like someone who's been through this before to talk to, my email's in my profile.

One option is Tarsnap (http://www.tarsnap.com/), which is developed by HN's cperciva (http://news.ycombinator.com/user?id=cperciva). It's specifically written to be secure online backup.

Another option is using Dropbox, but with some kind of encryption. I know that some people use Dropbox to store TrueCrypt volumes, and I think it does an okay job with them.

Downsides to both are that you're not likely to be able to access them from a phone. Tarsnap also has no GUI (and requires Cygwin to work on Windows), which may be a consideration.

Things like Node Knockout and Rails Rumble are a great way of identifying potential problems relatively quickly. From experience, it's high-stress and you're more irritable than normal because you haven't been getting enough sleep. It's very easy to get annoyed, even when you're doing it with the people you work with all of the time. You discover who you can work with well and who you can't pretty quickly.

This sentence in particular stuck out to me:

    The novice writer, he argues, has a "natural tendency ... to think primarily of
    himself—hence to write primarily for himself."

One of my writing professors had us write a description of our target audience as part of the heading of each essay we wrote to try to help prevent us from doing this.

It's a danger not just when you're writing, but when you're doing any kind of design. I think it's very hard to be a good designer without being able to understand how different audiences are going to see and interact with your work.

It's especially an issue in web/web application design when you're designing for people that aren't at all tech savvy. Besides being very important if you're trying to reach a broader market, it's amazingly gratifying to hear someone who self-describes as "terrified of computers" tell you about how they learned to use your webapp in 5 minutes.

The problem is not that infographics are aesthetically pleasing. The term "infographic" has come to be represented with low-content, high-flashiness presentations of data. (There are many good graphics that also convey information. "Infographics" generally do a bad job of the latter.)

Since they're pretty and usually not completely content-less (bad infographics are a great way to spread very few facts over a very large area), they often get a lot of hits on social news sites like Reddit, Digg, and even, sometimes, HN. Because of this, they've become a favorite tool of people trying to do SEO to take advantage of that traffic.

I'm pretty sure that was intentional (or, at least, part of the joke), since there's this text right above it:

    Also you can get your own infograph done for about $150 bucks from
    "derri_hasmi at yahoo.co.id", although proof reading the infograph before
    you publish is recommended.

Linux has been doing this for a lot longer than Windows has. (Which I only actually know because there was so much FUD about Vista's pre-fetching when it came out.)

edit: Sorry, getting prefetching and SuperFetch confused.

The short answer: not a whole lot. A government or other entity with enough resources could probably compromise the anonymity of a significant amount of the traffic going through Tor. It's generally accepted that if an attacker controls the first and last router in a circuit then they can use timing attacks to compromise that circuit's anonymity. (And if an attacker controls all three routers they definitely can.)

The long answer: Tor does some things with circuit creation to try to make this kind of attack a lot more difficult. In general, clients will attempt to choose geographically distributed routers to go together on a circuit. (I believe the restriction is that they won't choose multiple relays on the same /16 subnet--certainly not an infallible measure, but it does make it more difficult to control multiple routers on a single circuit.)

Another countermeasure is the use of guard nodes. Guard nodes are generally fast, long-running routers that serve as the entry points onto Tor. Clients with guards enabled (and they're enabled by default) have a list of 3 guard nodes, which they will try to use if at all possible as the first router on any circuits they create. (If all of those guards go down, they'll pick more.) The reasoning is that without guards, if there's someone who's trying to attack Tor by controlling routers, eventually you're going to create enough circuits that at least one gets compromised. With guards, some people will get unlucky and potentially have a lot more of their traffic compromised, but others will be much safer. Also, because guards stay relatively static over time (and because it takes a few weeks to be considered stable enough to be a guard), any attacker just setting up a ton of routers isn't going to be able to immediately compromise a ton of traffic.

(Of course, there are other attacks too, which don't necessarily require controlling nearly as many routers. Tor is very far from perfect. Designing a good general-purpose low-latency anonymity system is very difficult.)

My experience: I've been doing research related to Tor for the past two and a half years, and my undergrad thesis (which I'm working on right now) is a practical evaluation of the attacks that do exactly this kind of end-to-end correlation.

I don't have time right now to list specific citations for all of the above, but it's pretty much all covered by papers in the Free Haven Anonymity Bibliography (http://www.freehaven.net/anonbib/) and the Tor spec documents, and I'd be happy to come fill them in later if people want.

Creating a simple, inefficient Prolog interpreter (that has most of the core functionality) is pretty easy (as far as implementing languages goes), especially if you're using another functional language to do it. I think it can be done in 100-200 lines of Haskell or ML pretty easily (although I haven't actually implemented one myself).

Implementing an efficient Prolog involves implementing the Warren Abstract Machine (WAM) [0]. I just implemented a very small and restricted subset of the WAM with a friend for a class final, and doing that is much harder. (Largely because there's not a whole lot in the way of documentation, and even the book that's supposed to serve as a WAM tutorial [1] is light/vague on some of the trickier implementation details.)

[0] http://en.wikipedia.org/wiki/Warren_Abstract_Machine [1] http://wambook.sourceforge.net/

There's a very big distinction between saying "I consider X harmful" and "X [is] considered harmful". In the former, it's very clear that you're expressing your own opinion. In the latter, it's implied that your opinion is "the" opinion, and that X is considered harmful by people in general, not just by you.

(At least, that's how I've always read it. I suppose one could argue that "X considered harmful" actually should be read "X [is] considered harmful [by me]" or maybe "X [should be] considered harmful", but I don't think either of those interpretations are obvious.)

The traffic graphs linked in this post [0] are an interesting addition to the "How often do you visit HN?" poll [1] that was done a week ago. From the graphs, it looks like there are about 10x as many page views as unique IPs.

[0] http://ycombinator.com/images/hntraffic-17jan11.png [1] http://news.ycombinator.com/item?id=2090191

As other commenters have said, he meant the book was a commercial disaster. However, that's probably at least in part because Python 3 adoption has been really, really slow in general, in large part because it's backwards-incompatible and a lot of the big existing libraries still haven't been ported yet.

One of the biggest offenders is scipy, Python's very good and very widely used statistical computing library. The soon-to-be-released scipy 0.9.0 does support Python 3 [0], but Python 3 was released in 2008, so it's taken quite a while.

Another big problem has been with web applications. Python has WSGI, a standard interface for implementing webapps that allows you to use a lot of different frameworks with a lot of different servers. (Similarly to Ruby's Rack and Java's servelets.) However, the WSGI standard for Python 3 (which has to be changed because the existing specification has encoding-related issues in Python 3) has only just been finalized as PEP 3333 [1].

[0] http://projects.scipy.org/scipy/roadmap#python-3 [1] http://www.python.org/dev/peps/pep-3333/

I think it's just important to know a little about a wide variety of things as it is to know a lot about a few specific things. Breadth and depth are both valuable.

I ended up doing something similar to what this author tried to do starting in my sophomore year in college (although I didn't have any particular goal in mind when I started). Over the course of about a year and a half, through some combination of classes and my own projects, I programmed Standard ML, Prolog, Haskell, PHP, Ruby, JavaScript, x86 Assembly, Scala, SuperCollider, and Scheme for the first time. At that point, all I really knew were Java and Python.

I think it was an immensely useful experience for several reasons. I've now had some exposure to most/all of the major programming paradigms (and some less common ones too). A month is enough time to begin to get a feel for a language and its idioms, and being able to think and solve problems in different ways will make you a much better programmer even if you do end up working mostly in one or two languages.

Learning how to learn a programming language quickly is also an exceptionally useful skill. New languages don't scare me any more--I can usually learn enough to start hacking on something in a couple of hours, and enough to not be writing completely horrible code in a couple of days. And it's now very rare that I sit down to read a piece of code and can't figure out what's happening because I'm not familiar with the language, which is very helpful when I need to work on something I've never seen before.

That all said, there's a reason I didn't continue doing that indefinitely. Learning one or two languages really well is also very important.

Yep, you're right that a single GET request has some problems. We don't right now (because we wanted to get feedback ASAP), but we will definitely be checking from multiple nodes (running on multiple different providers) by the time we're charging people money so that we're as sure as we can be that the problem isn't us.

Getting an API together (to enable a server daemon) is also very high on our priority list. (Although the disadvantage with that is that then you're not actually checking to see if the site's up: you're checking whether the server's alive, and that doesn't necessarily mean the site is up.) We do recognize we're dealing with something tricky and we want to get it right. Thanks for the feedback.

Custom CSS/branding and an API are the next two big things we're planning on getting working, so that's good to hear. :) thanks!

Yeah, the homepage definitely needs to be redone. I did that, did the rest of the site (in a completely different style), and haven't gotten a chance to take a look back at the homepage yet. Thanks for the feedback.

(I'd also appreciate others' opinions on this, although I do agree.)

Yep, the custom messages/status overriding will be accessible through the web interface soon, and an API is definitely in the pipeline. We wanted to get something out the door quickly though.

This is not so much for me, but if you have anything you didn't like about it, I think a lot of people would really like to hear about it. The most negative blog post I've seen on HN was something to the effect of "it wasn't the right fit for me", and it's really hard to judge something critically without getting both positive and negative opinions. From what I've seen of you guys it looks like it was a very positive experience for you though, so I'm not sure this is really applicable.

For myself, I'd say write it if you can think of any related tidbits/stories to tell. Those are always interesting.

This has been posted before, but is worth reading if you haven't.

http://news.ycombinator.com/item?id=1195641 -> a few comments

http://news.ycombinator.com/item?id=1476425 -> lots of comments