Varnish author criticizing HTTP/2.0 proposals - <AUTHOR> http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0172.html <comment><USER2> After the whole IPv6 story, I'm surprised the author ignores the political dimension of designing a new protocol. As Mitch Kapor said "Architecture is Politics". It's not just about what solution is best from a technological perspective, it's about what we want our future to look like.

The internet has become way more important than back when these protocols first became standard, and every time a protocol or standard is up for debate, political and commercial forces try to influence it in their favor. Some of the concepts they tried to shove into IPv6 were downright evil, and would have killed the internet as we know it. Personally, I'm relieved all that is left is a small, un-sexy improvement which albeit slowly, will eventually spread and solve the only really critical problem we have with IPv4.

I really dread subjecting HTTP to that process. Although I fully agree with the author's critique of cookies for instance, the idea of replacing them with something "better" frankly scares the crap out of me. Especially when the word "identity" is being used. You just know what kind of suggestions some powerful parties will come up with if you open this up for debate, and fighting that will take up all of the energy that should be put towards improving what we already have.

As techies we should learn to accept design flaws and slow adoption and look at the bigger picture of the social and political impact of technology: HTTP may be flawed, but things could be way, way worse.

<comment><USER3> You don't go to the author of Varnish for political advice, you go to the author of Varnish for _technical_ advice. I'd be disappointed if he took advantage of his good name to push political advice when he got his reputation for being good at technical matters.

After all, is any of his technical advice invalid due to political concerns that are not wild speculation on your part?

\----

Not to say that politics doesn't enter into it, just that it should be brought to the table and discussed by other actors. And those actors should probably be all ears about the technical issues.

<comment><USER4> > _Not to say that politics doesn't enter into it, just that it should be > brought to the table and discussed by other actors._

How so? You seem to be distinguishing between politics actors (politicians?) and technical actors.

In a democracy it is not just important but essential that ALL have their say on policy, not just "political experts".

</comment></comment></comment><comment><USER5> His proposal is at [http://phk.freebsd.dk/misc/draft-kamp-httpbis- http-20-archit...](http://phk.freebsd.dk/misc/draft-kamp-httpbis- http-20-architecture-01.txt)

It comes with the caveats that "Please disregard any strangeness in the boilerplate, I may not thrown all the right spells at xml2rfc, and also note that I have subsequently changed my mind on certain subjects, most notably Cookies which should simply be exterminated from HTTP/2.0, and replaced with a stable session/identity concept which does not make it possible or necessary for servers to store data on the clients."

<comment><USER6> If I'm interpreting that correctly, that could be a huge win for privacy

<comment><USER7> How so? A unique identifier is a unique identifier.

<comment><USER8> If the browser created the unique identifier instead of the server it could create a new one as often as necessary.

I think that would actually work very nicely.

<comment><USER9> Browsers can do that now with cookies, by just clearing old cookies.

</comment></comment></comment></comment></comment><comment><USER10> While in general I understand where he is coming from, I believe his main argument about adoption is flawed.

What do you think is more likely going to be adopted? A protocol that's not backwards compatible at all (heck, it even throws out cookies) or something that works over the existing protocol, negotiating extended support and then switching to that while continuing to work the exact same way for both old clients and the applications running behind it?

See SPDY which is a candidate for becoming HTTP 2.0. People are ALREADY running that or at least eager to try it. I don't think for a second that SPDY is having the adoption problems of ipv6, SNI issues aside.

Even if native sessions would be a cool feature, how many years do you believe it takes before something like that can be reliably used? We're still wary of supporting stuff that a 11 years old browser didn't support.

<comment><USER11> _I don't think for a second that SPDY is having the adoption problems of ipv6, SNI issues aside._

Google being able to modify both the client (Chrome) as well as few fairly significant server installations has kind of helped there a little bit...

<comment><USER12> The key difference with IPv6 is that SPDY is opaque to routers and only needs changes at the endpoints. IPv6 has the chicken-and-egg problem that it only becomes usable once everyone (hosters, ISPs, core networks, home networks, web frameworks, client devices) has deployed it, and most of those actors don't bother with things that bring no immediate benefit.

<comment><USER13> You do know that when IPv6 roll-out was initially contemplated, it would happen on IPv4-convertible addresses only, until everybody had converted. That would have allowed seamless IPv6/IPv4 interop and made migration a breeze. Lacking any "must have" features, nobody could see a reason to bother. Now we have to do the migration without the benefit of seamless conversion.

<comment><USER14> Luckily, HTTP only requires the browser (which tend to be frequently updated) and server to be upgraded, not some random aging routers, there is little reason to fear adoption, there is minimal harm in keeping both protocols around for some time, and there is something much closer to a "must have" feature - speed.

<comment><USER15> A lot of hardware (proxies, DPI gear, hotel wifi hotspots, cellular carriers, etc) sniffs/mangles HTTP in transit and must be verified to be compatible with new HTTP features. HTTPS doesn't have this constraint.

</comment></comment></comment></comment></comment></comment><comment><USER16> How protocol adoption happens, in three steps:

1\. Working code. 2\. Publicity. 3\. Ubiquity.

That's it. Kamp is making a lot of the right noises here, but he's already lost ground to SPDY just because they've shipped code. No amount of sitting round tables bashing out the finer details of a better spec will help as much as getting code written - even if it's just a placeholder for an extensible spec, as long as that placeholder does something useful.

<comment><USER17> > he's already lost ground to SPDY just because they've shipped code.

Is SPDY good enough now and fixable enough in the future to leverage this gained ground?

As more and more people deploy SPDY, they will understand its problems and there will almost no chances to change it, differently from what Google did at the beginning (they have gone through 1 big change and many small changes in the protocol). When the authors of the main servers (varnish, apache, nginx) will start feeling its limits, will they have to keep it around just for sake of compatibility?

Please note that SPDY on the server is not a requirement, just an opportunity. Nothing will change for your users if you want to remove support for SPDY in your server after you deployed it and used it for some time. There are no "http+spdy://example.org" URL around, so supporting HTTP only will always be sufficient. Maybe not as much performant as SPDY but 100% supported.

</comment></comment><comment><USER18> (These are just my opinions as web developer. Please feel free to downvote if my expectations are wrong)

While I can completely agree with the technical merits of this proposal, there are some very two-faced statements.

Author begins by pointing out the painfulness of IPv4 to IPv6, says that the next HTTP upgrade should be _humble_. But then proceeds to kill cookies and remove all the architectural problems in HTTP. Isn't that the same what IPv6 was? Wouldn't such an approach produce the same amount of pain to the implementors (that is us, the web developers)?

Any upgrade will certainly have some backward-incompatible changes. But if it is _totally_ backward incompatible, I don't understand why it still needs to be called HTTP. Couldn't we just call it SPDY v2 instead, or some other fancy name?

Cookies are a problem. But the safest way to solve that problem is in isolation. Try to come up with some separate protocol extension, see if it works out, throw it away if it doesn't. But why marry the entire future of HTTP with such a do-or-die change?

I blindly agree with the author that SPDY is architecturally flawed. But why is it being advocated in such big numbers? Even Facebook (deeply at war with Google) is embracing it. It's because SPDY doesn't break existing applications. Just install mod_spdy to get started. But removing cookies? What happens to the millions of web apps deployed today, which have $COOKIE and set_cookie statements everywhere in the code? How do I branch them out and serve separate versions of the same application, one for HTTP/1.1 and another for HTTP/2.0?

More doubts keep coming... Problem with SPDY compressing HTTP headers? Use SPDY only for communication over the internet. Within the server's data center, or within the client's organization - keep serving normal HTTP. There are no bandwidth problems within there. Just make Varnish and the target server speak via SPDY, that is where the real gains are.

I could go on. I'm not trying to say that the author's suggestions are wrong. They are important and technically good. But the way they should be taken up and implemented, without pain to us developers, doesn't have to be HTTP/2.0. Good ideas don't need to be forced down others throats.

<comment><USER13> No. Ipv6 is Ipv4 with bigger addresses, it didn't try to solve any of the other problems of IPv4 (or attempts to solve them were killed by ISPs).

One example was multihoming (having more than one ISP) serveral smart proposals were floated (anycast, nearcast etc) but they were killed by ISP's who protected a lucrative business.

If Ipv6 had made multi-ISP multihoming possible without all the trouble of BGP, business would have killed to get it back in the late 1990ies.

Cookies only disappear from the wire, they are trivial to simulate on your server (see my other reply here).

<comment><USER19> "Ipv6 is Ipv4 with bigger addresses,"

Yeah, I used to think that, then I participated in some IPv6 conversions and watched some others. I don't think that any more. IPv6 may not be the Glorious Solution to All Network Problems Ever, but it's not just the obvious incremental improvement on IPv4 either. It's a new protocol.

(I do sometimes wonder if an IPv4.1 that simply set a flag and used 8 bytes instead of 4 was proposed _right now_ if it could still beat IPv6 out to the field even with IPv6's head start. Note, I'm not saying this would necessarily be a good idea, I just find myself wondering if IPv4.1 could still hypothetically beat IPv6 to deployment.)

<comment><USER20> What practical problems, aside from address range exhaustion, does it solve? I've read some technical articles about benefits of IPv6, but most of them keep returning to address size problem.

<comment><USER21> I think a big part of this is address range exhaustion is the root cause of many other problems. For example, IPv6 effectively obsoletes NAT, which removes all kinds of complexity from many protocols (off the top off my head: IPSec, many P2P protocols).

IPv6 also brings saner (IMO) protocol headers, and introduces a variety of other incrementally improved protocols (see ICMPv6, DHCPv6) that have been tweaked with the benefit of years of deployment experience.

</comment></comment></comment></comment></comment><comment><USER22> I have a lot of respect for phkamp, varnish is an impressive piece of engineering.

I disagree with the stab he takes at cookie-sessions here, though. He seems to ignore that sessions are not only about identity but also about state.

Servers should be stateless, therefor client-sessions (crypt+signed) are usually preferable over server-sessions.

Having a few more bytes of cookie-payload is normally an order of magnitude cheaper (in terms of latency) than performing the respective lookups server- side for every request. Very low bandwidth links might disagree, but that's a corner-case and with cookies we always have the choice.

Removing cookies in favor of a "client-id" would effectively remove the session-pattern that has proven optimal for the vast majority of websites.

<comment><USER13> No, servers should hold _all the state_ and clients none. If I add something to my shopping basket from my mobile phone, I want to be able to add more from my browser, rather than have two shopping baskets.

Servers storing stuff on the clients is just plain wrong, and it is wrong from every single angle you can view it: Its wrong from a privacy point of view, it's wrong from a cost-allocation point of view, it's wrong from an architecture point of view and it's wrong from a protocol point of view.

But it was a quick hack to add to HTTP in a hurry back in the dotcom days.

It must die now.

<comment><USER22> _No, servers should hold _all the state_ and clients none._

That's the opposite of the general consensus in the webdev-community.

Client-state is not only vastly more efficient in many cases but it also usually leads to cleaner designs and easier scaling.

Many of the modern desktop-like webapps would be outright infeasible without client-state. What's your response to that, should we just refrain from making such apps in the browser?

 _If I add something to my shopping basket from my mobile phone, I want to be able to add more from my browser_

And at the same time you probably appreciate when on your slow mobile-link the "add-basket" operation happens asynchronously, yet doesn't get lost when you refresh the page at the wrong moment.

I'm a bit confused here. You know better than most how critical latency is to the user-experience. Saving on server-roundtrips or hiding them is a big deal.

Yet you promote this dogma without providing an alternative solution to this dilemma.

<comment><USER13> Cleaner for who ? Easier for who ?

That kind of cookie usage just makes it Somebody Else's Problem instead of your problem.

<comment><USER22> _Cleaner for who ? Easier for who ?_

For the webapp-developer, which results in a faster and cheaper experience for the user.

I'm still baffled at your persistence given you sit pretty much at the source. You have probably written VCLs for sticky sessions yourself and pondered the constraints wrt data-locality and single points of failure? Sticky sessions are just not a good design when the alternative is so readily available; it's the first time in a long time I hear anyone disagree with that.

 _That kind of cookie usage just makes it Somebody Else's Problem instead of your problem._

And who would that "somebody else" be?

Users certainly don't care about a few hundred extra-bytes that their browser sends with each request, especially since that trade-off usually makes their browsing faster than the alternative would be.

The privacy concern is valid but boils down to developers using cookies _wrong_ (without encryption). If we were to remove all technologies that are used wrong by incompetent developers then the internet would be a pretty empty place.

</comment></comment></comment></comment></comment><comment><USER23> > See for instance how SSH replaced TELNET, REXEC, RSH, SUPDUP

> Or I might add, how HTTP replaced GOPHER[3].

telnet and gopher were used by a few thousands servers only and were not consumer facing technologies (for the most part), it doesn't make sense to compare that to IPv4 and HTTP that are used by millions (billion?) of servers.

<comment><USER24> >telnet and gopher were used by a few thousands servers only and were not consumer facing technologies

The card catalogs at most university libraries and most libraries of any national or international importance were reachable by telnet in 1992. And I think card catalogs count as a "consumer-facing" service.

The vast majority of internet client software in 1992 was text only. The first exception to this that I am aware of is the WWW, which most internet users had not started to use by the end of 1992 (email, newsgroups and ftp being the most widely used services). The way most connected to the internet or an intranet from home was by sending vt100 or similar protocol over a dial-up link -- with a Unix shell account or VMS account at the other end of the link. Repeating myself for emphasis: in 1992 most people accessing the internet from home or from a small office used a modem and IP packets did not pass over that modem link. The point of this long paragraph is that the vast majority of the machines on which these shell accounts ran were also reachable by telnet.

Finally, the telnet protocol in 1992 was a "general-purpose adapter" similar to how HTTP is one today. For example, the first web page I ever visited I visited through a telnet-HTTP gateway so that I could get a taste of the new WWW thing without having to install a WWW browser. Note that this telnet-HTTP gateway is another example of a "consumer-facing" telnet server.

In summary, there were probably more than a few thousand telnet servers in 1992 -- and many of them were "consumer-facing".

I am almost certain there were a few million users (certainly so if we include college students who used it for a semester or so, then stopped) of the internet in 1992, and most of those users used telnet.

<comment><USER25> IRC was pretty widely used back in the day too, and it was and still is text- only. There have been a number of non-text replacements for IRC (SecondLife being the most successful) but most died off. IRC's grandchildren, Twitter, SMS, all of the instant messaging and chat services, are all still text-only or close too it.

<comment><USER24> OK, but I feel the need to stress that when I wrote "text only", I was referring to the _user interfaces_.

(And the reason user interfaces are relevant here is that telnet was the main way to export user interfaces over the internet in 1992.)

</comment></comment></comment></comment><comment><USER26> Excellent judge of the protocol. It's interesting that no one is trying to solve the cookie bloat problem with http.

</comment><comment><USER14> Removing cookies from a protocol which is otherwise fully compatible with HTTP/1, in the sense of being able to be interposed as a proxy or substituted in the web server without breaking apps, is a terrible idea.

> Cookies are, as the EU commision correctly noted, fundamentally flawed, > because they store potentially sensitive information on whatever computer > the user happens to use, and as a result of various abuses and > incompetences, EU felt compelled to legislate a "notice and announce" policy > for HTTP-cookies.

> But it doesn't stop there: The information stored in cookies have > potentialiiy very high value for the HTTP server, and because the server has > no control over the integrity of the storage, we are now seing cookies being > crypto-signed, to prevent forgeries.

Anyone with a grain of skill is capable of using cookies as identifiers only; it's hard to see what cookies vs identifiers has to do with "notice and announce" or security. An explicit session mechanism could provide benefits over using cookies for the same purpose, but what exactly would _removing_ cookies achieve other than breaking the world?

<comment><USER27> Why must HTTP 2.x be backwards compatible with 1.x? Should SSH have not been created because you can't talk to it with a telnet client? If a new protocol offers sufficient benefits, it would be worth having to make minor changes to apps to support both.

Cookies suck, from a technical and regulatory-compliance standpoint. Plus, I'll finally stop having to clear my cookies every month or so just to log in to my PayPal and American Express accounts. Both sites keep creating unique cookies on every login until there are so many that they pass their own web servers' max header length limits.

<comment><USER14> > Why must HTTP 2.x be backwards compatible with 1.x?

Because the only benefit of removing cookies is a tiny bit of simplicity which could theoretically allow removing (a small amount of) code browsers will already have to keep around for probably at least a decade to support existing websites. If cookies are mostly unused by the time HTTP/3.x rolls around, we can talk...

> Cookies suck, from a technical

Agreed, but...

> and regulatory-compliance standpoint.

I don't understand this point. Surely the need for regulation of user tracking by websites doesn't depend on whether cookies or an equivalent mechanism are being used? If people start using Not Cookies(tm), they will be unregulated at first, but the law will be changed if the effect is the same.

Edit: Similarly, any protocol that gives a website a persistent identity token without its explicitly requesting one is a bad idea - cookies do provide a modicum of visibility to the user regarding who's tracking them. Not sure exactly what Kamp is proposing.

> Plus, I'll finally stop having to clear my cookies every month or so just to > log in to my PayPal and American Express accounts. Both sites keep creating > unique cookies on every login until there are so many that they pass their > own web servers' max header length limits.

Hah, no you won't. I strongly suspect legacy codebases will remain on HTTP/1.1 approximately forever, at least if 2.0 is backwards incompatible.

<comment><USER28> > and regulatory-compliance standpoint

One of the main reasons why people can't just turn off Cookies is because they are needed for session management. This makes it very difficult to just disable. If there was a dedicated session management method in HTTP/2.0 then that would remove a lot of the need for Cookies. Then they could be used for what they were intended (local persistent state). This would also give users better methods for managing them (or just disabling them).

<comment><USER14> Eh... maybe eventually, once nothing uses cookies anymore (including existing HTTP sites). But surely this can be solved today by having browsers force cookies to expire with the session?

</comment></comment></comment></comment></comment><comment><USER29> Frankly many problems addressed by these proposals are not things that should be solved in a protocol like HTTP. Do you want every HTTP request to be slowed down with a crypto token exchange and verification? unlikely. In special cases you definately want it, but all the time? Absolutely not.

<comment><USER12> It may be counter-intuitive, but with the right cyphers, the crypto costs of SSL and SPDY are negligible.

<comment><USER13> No, they are not. For one thing you have to terminate all your SSL on your loadbalancer in order to distribute the traffic. That makes SPDY a no-go for web-hotels/web-hosting where each customer has their own certificate.

Second, there are perfectly valid legally mandated circumstances which forbid end-to-end privacy, from children in schools to inmates in jail and patients in psych. hospitals, not to mention corporate firewalls and the monster that looks out for classified docs not leaking out of CIA.

<comment><USER14> > No, they are not. For one thing you have to terminate all your SSL on your > loadbalancer in order to distribute the traffic. That makes SPDY a no-go for > web-hotels/web-hosting where each customer has their own certificate.

That's what SNI is for.

> Second, there are perfectly valid legally mandated circumstances which > forbid end-to-end privacy

Then install spyware on the user's computer, or add a trusted SSL key and mitm all the things.

</comment></comment></comment></comment><comment><USER30> One huge benefit I think people are missing about the notion of a protocol standard session mechanism, is that we can use HTTP auth much easier, and perhaps get away from this notion of every site having to redo the login process. Browsers can handle the "remember login" settings, and logging out is as simple as tab closing. No "remember this computer" or "don't remember this computer" checkbox confusion. No random sites saying "remember me always" and requiring manual logout on a borrowed computer. It certainly helps with the password wallet concept too.

Sure all that stuff has become semi-standard as it currently exists, but it is ugly, hacky, and sometimes doesn't work, and other times opens doors for hilarious malfeasance.

</comment><comment><USER31> "Overall, I find all three proposals are focused on solving yesteryears problems, rather than on creating a protocol that stands a chance to last us the next 20 years."

</comment><comment><USER32> "We have also learned that a protocol which delivers the goods can replace all competition in virtually no time."

This is an argument for websockets eating protocol lunch.

</comment><comment><USER33> In my opinion it is always a good idea in these kind of situations to set a goal we should strive to.

I wonder what the ideal web protocol would look like. If, for example, we didn't have a burden of billions of servers and Internet reliance on HTTP/1.x protocol.

What would be the most ideal solution that would suite emerging use cases for the Web? Are there any research papers on this topic?

<comment><USER34> I agree with this way of thinking. phkamp has come up with some innovative ideas, but if it doesn't come easy for the rest of us there are lots of techniques to help e.g. asking, "if I was superman and could implement any solution, what would it be" [http://personalexcellence.co/blog/25-brainstorming- technique...](http://personalexcellence.co/blog/25-brainstorming-techniques/)

</comment></comment><comment><USER35> load balancers aren't meant to just be "HTTP routers". they can definitely be used as such for smaller applications and do a good job at it, but a real load balancer needs to be quite complex, being able to adapt to the underlying applications that make use of it.

if your goal is to only route HTTP requests, then you're only solving the first step of an increasingly complicated field of computer science (namely, web applications).

Cookies aren't going to go away. if you want to improve the protocol to deal with cookies better, that makes sense, but acting like they are some kind of evil on the internet that should be forgotten isn't going to work. it's a bit self-defeating to argue that some protocols failed because of failure to provide new benefits and then argue against Cookies in HTTP!

<comment><USER11> _load balancers aren't meant to just be "HTTP routers". they can definitely be used as such for smaller applications and do a good job at it, but a real load balancer needs to be quite complex, being able to adapt to the underlying applications that make use of it_

I think Poul-Henning Kamp is fairly well qualified to discuss what load balancers do.

(And yes, load balancer _are_ fundamentally HTTP Routers. Yes, sometimes they do content manipulation etc, but all those features are add-ons to the basic use-case)

<comment><USER36> Perhaps Kamp is qualified to discuss what some 'load-balancers' do...

The proxy developers have always had their doubts about SPDY (you can see them when @mnot first proposed it as a starting point)

Terminating SPDY at the HTTP Router makes a lot of sense architecturally but I know some orgs don't terminate SSL at the load-balancer due to the licensing costs.

Ultimately we need load-balancing options and someone to develop the opensource proxies (haproxy, varnish etc.) into more sophisticated offerings.

Perhaps they'll be a SPDY module for Traffic Server

</comment></comment></comment><comment> mike-cardwell I can think of a few organisations that benefit financially, a great amount from the fact that cookies allow them to track users. Ad companies like Google and Microsoft spring to mind. The same organisations building our major browsers... Conflict of interest? You better believe it.

<comment><USER37> Imagine if browsers reported a user-resettable uuid sent over on each connection open. Advertisers get the benefit of being able to track users, do it more securely since no data is ever stored on the client, and must eat the cost of actually storing the key-value pairs, instead of passing it down to users and expending massive amounts of bandwidth bouncing the data back and forth.

It's not about killing cookies, it's about finding a better solution that solves the problem better.

Note: I work for a startup that "benefits financially" from tracking users—a feature without which we would not have a business.

<comment><USER38> This already exists in spirit, in the form of "Incognito" or "Private" browsing. This doesn't solve the protocol issues of cookie bandwidth and insecure storage, but it does provide a user-resettable store of cookies.</comment></comment></comment>


Paul Graham: Lisp in Web-Based Applications (2001) - <AUTHOR> http://ep.yimg.com/ty/cdn/paulgraham/bbnexcerpts.txt <comment><AUTHOR> Interesting comment on evolving code (& keyword parameters):

> Rtml even depended heavily on keyword parameters, which up to that time I > had always considered one of the more dubious features of Common Lisp. > Because of the way Web-based software gets released, you have to design the > software so that it's easy to change. And Rtml itself had to be easy to > change, just like any other part of the software. Most of the operators in > Rtml were designed to take keyword parameters, and what a help that turned > out to be. If I wanted to add another dimension to the behavior of one of > the operators, I could just add a new keyword parameter, and everyone's > existing templates would continue to work. A few of the Rtml operators > didn't take keyword parameters, because I didn't think I'd ever need to > change them, and almost every one I ended up kicking myself about later. If > I could go back and start over from scratch, one of the things I'd change > would be that I'd make every Rtml operator take keyword parameters.</comment>


EU publishers on proposed "link tax" - <AUTHOR> https://www.techdirt.com/articles/20180607/18054639989/eu-publishers-freak-out-now-that-people-are-realizing-just-how-fucked-up-their-link-tax-really-is.shtml <comment><USER2> I wait for google to ask for an opt in in robots.txt and reward this with a higher rating. Then, in a few years, they can exclusively serve opt in content.

<comment><USER3> Google News is already an opt-in system by way of defining metadata and a very particular XML sitemap

</comment></comment><comment><USER4> I was reading this article until a full page ad with no close button created a fake Facebook page with a roulette wheel offering me a prize.

<comment><USER5> Well, at least you got a prize.

All I got was a modal I had to remove with the element inspector.

</comment></comment><comment><USER6> You can read it without annoyance by copy/pasting even if the modal is up. As much as I'd like a rational discussion about link preview of snippets (such as Google and DDG do for Wikipedia, StackOverflow articles, and also for news from ad-financed sites such that users don't go to the origin sources), this article unfortunately isn't contributing.

</comment><comment><USER7> Techdirt has trackers and profiles enabled by default which is against GDPR.

<comment><USER8> They operate out of the US so they probably don't care. As an EU citizen you should file a formal complaint.</comment></comment>


Rules of Logo Design - <AUTHOR> http://www.tannersite.com/rules-of-logo-design/

<comment><USER2> Every successful design breaks at least one "rule". Because information is retained when it's distinct from the norm. Talent in design consists not in following rules but knowing when and how a rule can be broken.

IBM's logo is way too busy. Apple's original logo has too many colors and isn't serious enough. GE is almost antique. UPS has that dull brown.

</comment><comment><USER3> Hmm .. let's see .. rules demand logo to be recognizable, unique, timeless, bold, confident, surprising in presentation, solid, simple, not distracting and balanced visually.

If you are having trouble with memorizing all these cool adverbs, just stick to the rule #42 .. ready ? ..

      It should be honest in it's representation.

A list that is perfect in its complete and utter uselessness.

<comment><USER4> Pedantry Corner: They're adjectives, not adverbs.

<comment><USER3> Damn right they are :)

</comment></comment></comment><comment><USER5> His logos suck. A good logo should be recognized from it's outline - like BMW, IBM, Apple, Mercedes, the Nazi Party. Using a nice font and adding a butterfly is not a good logo.

So I prefer not to take advice from someone who is not even particularly good.

</comment><comment><USER6> Too many rules. Examples would work better than a list of rules.

<comment><USER7> I'm sure you are supposed to assume he follows his own rules and that examples are in his portfolio. That being said, after looking at his portfolio, I was not impressed. Some of the logos he created did not seem memorable at all, had unnecessary detail, etc.

You can't just follow a set of rules to come up with a nice logo. You kind of need to have talent and an eye for colors, typography, etc.

Nevertheless, give him credit for listing out some helpful things to keep in mind for designing things.

The one thing I would say differently is that if you really like a certain logo's style, it isn't a crime to adopt similar styles for your own. All art is influenced by others in some way, and don't stick with something that sucks merely because it's 'original'.

<comment><AUTHOR> Yeah. The most interesting ones were ones of practice rather than design - check it in b&w, scale it, mirror it, etc. All perhaps obvious to many.

</comment></comment></comment><comment><USER8> "Use sharp lines for sharp businesses, smooth lines for smooth businesses."

What is that supposed to mean?

<comment><USER9> use vague descriptions for va...

... blog articles.

</comment></comment><comment><USER10> Was I the only one who read this as "Rules of Lego Design" only to have my excitement crushed into a fine powder?</comment>


Give HN: A chrome extension to bypass paywalls - <AUTHOR> Hey!
I've this idea.
Can anyone roll out an extension to bypass paywall using outline.com? <comment><USER2> Its already available at [https://chrome.google.com/webstore/detail/quick- javascript-s...](https://chrome.google.com/webstore/detail/quick-javascript- switcher/geddoclleiomckbhadiaipdggiiccfje?hl=en)

<comment><USER3> How does this extension to disable javascript relate to bypassing paywalls via outline.com?</comment></comment>


Ask HN: Fitting a Rockchip RK3399 into an X201? - <AUTHOR> I've been using a librebooted X200 for 3 years now. It's no overstatement to say that it delivers the most holistically amazing computing environment I've ever worked in.
If I'm to buy a new laptop, it must remain "superficially" identical/comparable. I want better performance, but what's ciritcal is getting as much battery life and improved thermals as I can. Even the screen is not as much of an issue to me as those 2.
Now I've been looking at some products offered by thinkpad modders, but knowledge of the non free bios weighs some on my mind.
Since acquiring this laptop, beside remaining abreast of news about Pine and others striving toward software/hardware freedom, I've totally cauterized myself from the greater consumer tech ecosystem.
With the context out of the way, what I want to know is whether it's possible to retrofit a Thinkpad X201 (When I'm casually using my X200, while laying down and watching a video for example, I miss the touchpad), with modern hardware capable of running mostly/all free software. I'm honestly not sure what projects are out there, and which ones are promising. Now although I do crave more performance, the thought of going from this beut to ANY of the machines I see on the market is appalling.
In parallel, why do consumers love sodomizing themselves with whatever garbage companies throw at them? What happened to voting with one's wallet?
Anyway... I don't even know how to make headway into a project like this. I'd love a little guidance specifically about retrofitting X201s, as well as about  retrofitting any of the prime era thinkpad shells for my needs. <comment><USER2> Try looking on r/thinkpad there's a lot of decicated enthusiasts. Or if you can read Chinese, 51nb is your best bet.

<comment><AUTHOR> 51NB has actually been fragmented, and various members of the original project are selling their own modded equipment.

Thank you though, I'll make sure to check r/thinkpads!</comment></comment>


Faster-than-light neutrino result may have been due to bad connection - <AUTHOR> http://news.sciencemag.org/scienceinsider/2012/02/breaking-news-error-undoes-faster.html <comment><USER2> The real issue is that experiments that give "expected" results are not subject to this kind of scrutiny. Thus experiments are much less trustworthy than one would assume. It sometimes takes decades for errors in experiments to come out - eg. from "Surely your joking, Mr. Feynman":

Millikan measured the charge on an electron by an experiment with falling oil drops, and got an answer which we now know not to be quite right. It's a little bit off because he had the incorrect value for the viscosity of air. It's interesting to look at the history of measurements of the charge of an electron, after Millikan. If you plot them as a function of time, you find that one is a little bit bigger than Millikan's, and the next one's a little bit bigger than that, and the next one's a little bit bigger than that, until finally they settle down to a number which is higher.

Why didn't they discover the new number was higher right away? It's a thing that scientists are ashamed of - this history - because it's apparent that people did things like this: When they got a number that was too high above Millikan's, they thought something must be wrong - and they would look for and find a reason why something might be wrong. When they got a number close to Millikan's value they didn't look so hard. And so they eliminated the numbers that were too far off, and did other things like that...

<comment><USER3> Actually, most major experiments in particle physics these days (including the OPERA experiment) avoid this sort of confirmation bias by being run "blind." The scientists write all of their data reduction pipelines before taking any actual data and test their pipelines on simulated data. When they are confident that their pipeline is running as expected they run the experiment, put the data through their pipeline and publish the result, no matter how unexpected it is.

As the OPERA result showed, it has the problem that if you don't understand everything in your experiment perfectly (which is difficult to do in a very large, complicated experiment) you run the risk of embarrassing yourself by making some obvious-in-retrospect mistake and publishing an obviously absurd result. But in the long run it's not so bad a price to pay to avoid the sort of confirmation bias that Feynman was talking about.

<comment><USER4> Physics is far ahead of other disciplines in this regard. Choosing your statistical test after you gather the data, selectively removing "outliers" after you gather the data, non-blind interpretation of pictures by humans who have a stake in the outcome and only publishing statistically significant results are all par for the course in e.g. neuroscience.

<comment><USER5> This paper [1] points out that commonly-used measures of statistical significance are downright meaningless when additional degrees of freedom are hidden in the way you describe.

[1] [http://people.psych.cornell.edu/~jec7/pcd%20pubs/simmonsetal...](http://people.psych.cornell.edu/~jec7/pcd%20pubs/simmonsetal11.pdf)

<comment><USER4> It's even worse than that paper describes and this is something that every statistics 101 class worth its salt points out: if you are allowed to choose a statistical test after you've gathered your data _you can prove any conclusion you want with arbitrarily high confidence_. Note that the paper does not list choosing a test before you gather the data as a requirement. The only way to do meaningful statistics is the way splat describes: describe exactly how you're going to analyze it before you gather the data, then send the paper to a journal which decides whether to publish it before the data has been gathered, and then complete the paper by actually doing the experiment and adding the data to the paper.

</comment></comment></comment></comment></comment><comment><USER6> While noodling around for more information I found this article which describes some (completely unrelated) other super-conducting cable used at LHC.

([http://lhc-machine-outreach.web.cern.ch/lhc-machine-outreach...](http://lhc- machine-outreach.web.cern.ch/lhc-machine-outreach/components/cable.htm))

> _The cables house 36 strands of superconducting wire, each strand being > exactly 0.825 mm in diameter. Each strand houses 6300 superconducting > filaments of Niobium-titanium (NbTi). Each filament is about 0.006 mm thick, > i.e. 10 times thinner than a normal human hair._

> _tolerances are only a few micrometers._

> _Total superconducting cable required 1200 tonnes which translates to around > 7600 km of cable (the cable is made up of strands which is made of > filaments, total length of filaments is astronomical - 5 times to the sun > and back with enough left over for a few trips to the moon)._

</comment><comment><USER7> I'm really impressed with how open this group was to be proven wrong and how hard they worked to rule out or confirm error on their part.

Compared to Wolfe-Simon et al (the group that claims to have found arsenic in the DNA of certain bacteria) they show exactly how science should be done.

<comment><USER8> Wolfe-Simon and NASA is an absolute disgrace.

I think they could gain far more with a mea culpa than with living in denial, which is what they seem to be doing.

<comment><USER9> > I think they could gain far more with a mea culpa than with living in > denial, which is what they seem to be doing.

Scientists are humans too. I can understand why they prefer to live in denial, even if that doesn't make them better scientists. Or humans.

</comment></comment></comment><comment><USER5> Standard caveat: while Science is an extremely reputable outlet, this blog post is unsourced. There hasn't been an official statement from the OPERA collaboration yet.

Update: a spokesperson for CERN has confirmed "a problem with the GPS system." [http://www.cbc.ca/news/technology/story/2012/02/22/technolog...](http://www.cbc.ca/news/technology/story/2012/02/22/technology- faster-than-light-neutrinos.html)

</comment><comment><USER10> The best comment on this, courtesy of Ars Technica:

>At the AAAS meeting's discussion, CERN's director of research, Sergio Bertolucci, placed his bet on what the results would be: "I have difficulty to believe it, because nothing in Italy arrives ahead of time."

</comment><comment><USER11> > <http://news.ycombinator.com/item?id=3252135>

jonhendry, you're a prophet :)

</comment><comment><USER5> The official statement from the collaboration:

"The OPERA Collaboration, by continuing its campaign of verifications on the neutrino velocity measurement, has identified two issues that could significantly affect the reported result. The first one is linked to the oscillator used to produce the events time-stamps in between the GPS synchronizations. The second point is related to the connection of the optical fiber bringing the external GPS signal to the OPERA master clock.

These two issues can modify the neutrino time of flight in opposite directions."

[http://blogs.nature.com/news/2012/02/faster-than-light- neutr...](http://blogs.nature.com/news/2012/02/faster-than-light-neutrino- measurement-has-two-possible-errors.html)

</comment><comment><USER12> The best _pessimistic_ response I read to this experiment when it first came out stated that overturning well-established theorems in physics should be left to experiments where the result is clearly and simply binary, not where the result is an extraordinarily precise measurement in a complex system.

<comment><USER13> Otoh, one of the early tests for general relativity was a minor deviation in Mercury's orbit from what was predicted by classical mechanics. My rough intuition is that inconsistencies can show up initially as faint flickers, but once you investigate more closely, one can find interesting and prominent counter examples.

<comment><USER12> I'm not an expert on this, but I believe the deviation in Mercury's orbit was easily observed and calculated, and thus became in a sense a binary call-out of Newtonian physics. Until highly precise measurements of relativistic velocities is common place, experiments like this are of course valuable and interesting, but one instance of an experimental result like this cannot be relied upon to supersede special relativity.

<comment><USER14> And no one was claiming that.

</comment></comment></comment></comment><comment><USER15> the description of the error appears just too vague in my ears. due to "bad connection between a fiber optic cable that connects to the GPS receiver" seems unlikely, since it's first of all a very systematic error and secondly I can't fathom how a fiber optic cable can have a bad connection - at least not in this setting... unless they would've unintentionally bent the cable, resulting in a higher error rate in the transmission of the signal but shouldn't that show up in some network diagnostic tool?!

<comment><USER14> If the connector was bad or broken, there could be an air gap between the fiber and the diode, creating an unwanted refraction that could introduce transmission error.

</comment></comment><comment><USER16> I thought they already proved that the faster-than-light neutrino was due to relativity between the GPS satellite, the origin, and the destination? Did I just hallucinate that?

<comment><USER6> META - why is nathnb's comment being down-voted? (It's not rude or aggressive or meme-spewing or vapid "me too" / "plus one".)

<comment><USER17> I didn't downvote, but nathnb's comment isn't adding anything to the discussion. It's a personal aside about some confusion he is having; his last question especially emphasizes that aspect.

But I see that several other comments at that level were also downvoted.

</comment></comment></comment><comment><USER18> Keep the dream alive!

</comment><comment><USER19> Shouldn't they have tried to eliminate instrumentation errors before going public with findings that conflict with all human understanding of physics?

<comment><USER20> Shouldn't you eliminate ALL bugs from your software before you release it? All of them.

<comment><USER19> But bugs in my software don't prove Einstein wrong. There's a difference.

<comment><USER6> They didn't claim to have proved Einstein wrong. To continue the weird analogy: They looked for the bug themselves, and couldn't find it, and then asked other people to find the bug.

<comment><USER20> Modern science - open source before Open Source was invented.

<comment><USER21> pretty much. the mess newton caused by keeping calculus a proprietary technology for so long (due partially to existing practice in the alchemy industry and partially to being completely nuts) made it pretty clear that some degree of openness was necessary to really get anything done.

</comment></comment></comment></comment></comment></comment><comment><USER22> they just tightened the cable to see the error? science is scary.

<comment><USER23> Actually, from the beginning they've mentioned that equipment failure would be one of the ways to account for the findings. They also have been incredibly open in asking for help to explain the anomaly. I don't see this as scary at all. Science has come out looking incredibly even keeled and reasonable. Some of the news outlets that have covered the science... less so. But still, almost every article I read had all the caveats listed even if there were have some overly hopeful headlines.

<comment><USER24> Oh, "scary" is the right word, notwithstanding everything you just said, which is all true.

It takes courage to stand in front of every camera on earth and claim to have measured something impossible, no matter how cautious you are, and no matter how gracious everyone else is. It takes courage to knowingly and deliberately turn yourself into the butt of jokes in foreign languages whose names you don't even know, all on the very slim chance that this thing you can't explain is something breathtakingly awesome, Isaac Newton-awesome, Albert Einstein's 1905-awesome. It was bound to be embarrassing in the end, and lo and behold it is shaping up to be _exactly_ as embarrassing as every one of my fellow experimentalists knew it would be, and I can't decide whether to laugh, cry, or salute, because when you've spent months or years of your life in utter despair, trying to get your experiment to produce something halfway believable, or redoing six months of work because a broken fridge probably contaminated the first batch, or trembling as you cross-check the simulation code the week before your thesis is due, you've learned how it feels: Awful.

I'll go with "salute": Let's all raise a glass to these folks and be grateful that they are on the road to finding their problem, rather than being haunted by uncertainty forever. May their next result be twice as exciting and only half as wrong!</comment></comment></comment>


Ruby 1.9.3-p194 is released with RubyGems security fixes - <AUTHOR> http://www.ruby-lang.org/en/news/2012/04/20/ruby-1-9-3-p194-is-released/

<comment><AUTHOR> RubyGems 1.8.23 is also out with the same fix.

Two security issues were fixed:

* RubyGems did not validate SSL certificates (the dreaded OpenSSL::SSL::VERIFY_NONE problem).

* RubyGems allowed HTTPS-to-HTTP redirects. And in fact rubygems.org did redirect gem downloads from HTTPS to HTTP (also fixed).

Either of these mean that an attacker could MITM your `gem install` or `bundle install` and give you malicious gem contents. You'd be owned when you required the gem -- possibly sooner, in fact, because gem install itself provides mechanisms for arbitrary code execution.

It's also important to note that RubyGems does not default to HTTPS. I highly recommend using `source "<https://rubygems.org`> in your Gemfile and the following in your ~/.gemrc:

        :sources:
          - https://rubygems.org</comment>


Is time an illusion? - <AUTHOR> http://www.newscientist.com/article/mg19726391.500-is-time-an-illusion.html?full=true <comment><USER2> Great article - bad title. Saying that time might be an illusion is saying that time might not be "real". But a different model of time doesn't affect its realness.

Is temperature an illusion? Certainly not. And yet, as the article says, it's merely a model of the interaction between molecules.

Some models explain more than other models. Models that explain more are better. Thinking in terms of real/illusion is not helpful at all.

<comment><USER3> >> Saying that time might be an illusion is saying that time might not be "real".

No, the word "illusion" references an artifact that is both real and effective, yet whose true nature is misunderstood.

Moreover, for X to be an illusion, it necessarily _must_ exist in some way.

<comment><USER4> You're both (a little) wrong! :)

You can't call something an illusion _just_ because its true nature is misunderstood. An illusion is something that _looks deceptively like something else_. A hologram of a table is an illusion, but just misunderstanding the nature of a table (e.g. misunderstanding the fundamental particles from which it's constructed) does not make it an illusion.

Saying that time is an illusion is like saying that we _appear_ to be living in a universe with time, but actually we don't. We are in fact experiencing something that _looks_ like time, but isn't really time.

But obviously we _do_ live in a universe with time, and the fact that time may turn out to be something strange or unexpected does not make it an illusion. It just means we misunderstood its true nature.

<comment><USER5> I believe they are saying time is a concept that is useful for explaining certain local experiences, but under certain more global circumstances, the defining characteristics of the concept of time could potentially change, causing us to need a new concept to describe it.

</comment></comment></comment></comment><comment><USER6> I've always been more personally inclined to the social sciences - how people work and interact with each other. It always seemed to me that there's less red tape and formal background necessary to do interesting and practical work in social sciences.

But the more I think about it, the more I realize that damn near everything we do of value relies on hard science. If you had me pick one post-agriculture profession to be my only formal profession in the world, it'd have to be engineering. Engineering creates tools that greatly expand the ability of everyone else to do what they're doing. And yet, without physics and chemistry, we're not engineering damn near anything of value. Behavioral and social sciences have made such huge leaps due to increased communication, mobility, and processing and storing of information. All that can be credited to some damn amazing engineers, who all needed math and hard science to build what they did. It makes me remember from time to time, that though I'm not a hard scientist and will likely never more than dabble in it, it's pretty damn amazing stuff, and ought to be regularly given a nod of appreciation to its amazingness.

<comment><USER7> _"All science is either physics or stamp collecting."_

Ernest Rutherford

<comment><USER8> All Computer Science is either assembly programming or garbage collecting.

<comment><USER9> All generalizations are bad.

<comment><USER8> All assumptions about generalizations are generalizations.

</comment></comment></comment></comment></comment><comment><USER10> Just to clarify: the problem here is wave collapse. Wave collapse happens at an instant of time, and therefore picks a frame of reference. The wavefunction changes instantaneously over all space when "measurement" occurs, and does not obey the Schrodinger equation (or relativistic equivalent).

The "intriguing development" by Rovelli is that he used decoherence to explain measurement probabilities in some relativistic model. Time still exists in this model (which lives over R^{3+1}), but nothing happens instantaneously. Basically, he showed that the relativistic schrodinger equation gives the same experimental predictions as wave collapse.

<comment><USER11> Wave collapse hasn't been taken seriously by physicists in years. It's been thoroughly debunked again and again (c.f. <http://www.npl.washington.edu/npl/int_rep/tiqm/TI_toc.html>, <http://www.flownet.com/ron/QM.pdf>). The press keeps reporting it because it's such a delicious mystery.

<comment><USER10> Which physicists? As far as I know, copehnagen is the mainstream ontology.

I gave a talk last week on decoherence, just working out an explicit example where we can almost exactly solve the combined particle/measurement device system. The idea that wave collapse is unnecessary was not uncontroversial.

A quote from before I even gave the talk: "I don't believe you."

<comment><USER11> > Which physicists?

Well, Cramer (the one I cited) for one. David Mermin. Cerf and Adami. Roland Omnes. John Preskill. How many do you want?

> I gave a talk last week on decoherence

To what audience?

<comment><USER10> The audience of my talk was mixed math, physics and chemistry with a shared interest in quantum control.

As for the physicists you cite, the ones I recognize seem to work on either quantum information or foundations of QM. Decoherence is far more accepted in these fields than in the rest of physics.

<comment><USER11> Yeah, well, those are the people I would consider the authorities, wouldn't you?

BTW, collapse is easily debunked: take a two-slit experiment a put a detector at one slit. Interference is destroyed for all photons despite the "fact" that only half the photons "actually" interact with the detector. Collapse cannot account for this. (I put "fact" and "actually" in scare quotes because in true fact all the photons interact with the detector, but not according to the collapse theory.)

</comment></comment></comment></comment></comment></comment><comment><USER12> Try to define time. Or just go to the wikipedia article and listen to them try to define it, and digress into a discussion on how some people don't believe in it.

It's very hard to describe time without using the word time: A series of events -- What's an event? The best one I have is: Why can't two object occupy the same space? Well, they can, but at different _times_. Not really an explanation, but I think it's a good illustration.

Isn't time sort of like goodness, so fundamental that it's indescribable with invoking itself?

<comment><USER13> I've always thought of time as a measurement of change. No change, no time (i.e. if all particles in the universe were frozen in place at absolute zero then there would be no measurable change and time would not exist).

<comment><USER14> What you describe sounds like all particles in the universe suddenly lost all their energy. If time is change, time must be energy.

</comment></comment></comment><comment><USER15> If time is an illusion, it's a very persistent one.

</comment><comment><USER16> It's like physicists are discovering functional programming....

</comment><comment><USER17> If science eventually proves without-a-doubt that the Big Bang was only one of many Big Bangs and that in fact, there seems to be no beginning or end to the Big Bangs, then the universe would essentially be infinite.

If it's determined that the universe, and everything in it, lasts (in one form or another) forever, then the meaning of time disappears. You cannot have time unless you have a beginning and an end.

<comment><USER18> Time only needs a beginning, it doesn't need and end.

Nobody can prove the Big Bang theory without-a-doubt: we only could rise theories against it, or bring facts against it, but it will stay an unproven theory forever, very similar to math theories: you can't prove them without-a- doubt, you only can give it credit _currently_ , and because there hasn't been found any counter example yet.

</comment></comment><comment><USER19> Time is a very real perception, so the answer is "Yes" unless you're asking the metaphysical question "Is all perception an illusion?"

</comment><comment><USER20> Maybe time only exists if it can be observed.

</comment><comment><USER21> Maybe we are wasting our time discussing this. I agree that discussing this makes us feel intellectually satisfied, but nothing really worthwhile comes from this discussion.

I think 'Is time an illusion' is akin to asking 'define love'. I know it is corny.

</comment><comment><USER22> Lunchtime - doubly so.

</comment><comment><USER23> If time is an illusion that might explain why I feel like it disappears.

</comment><comment><USER18> There is a theory that we only do exist because there is an entity outside of time which 'thinks' us continuously.

<comment><USER24> How can an entity that is outside of time think us "continously"?

<comment><USER18> And how would you try to express something which is outside of our own possible experience? Sure, you could say "eternal present" or something; doesn't seem to sound much better...

<comment><USER24> I wasn't picking on your choice of words. If there is an ever-present something which effects our universe, and there is change in our universe, then there must be change in that ever-present something's universe, right? I mean, I suppose you could look at our universe as just a const 4-dimensional chunk of data with us simply moving along the time axis, but us moving along it is still change.

</comment></comment></comment></comment><comment><USER25> time isn't an illusion here where we are now, but it doesn't exist outside of this physical life-space.

</comment><comment><USER26> > Is time an illusion?

Yeah, probably, just like all human sensory input.

</comment><comment><USER27> I have a brilliant proof of this, but I'm so busy it'll have to wait until tomorrow.</comment>


Woman sues US border agents over seized iPhone - <AUTHOR> https://www.bbc.com/news/technology-45295615 <comment><USER2> Good luck with that - I bet we never hear anything about it again.

Is there any way to bookmark these sorts of things an follow up on the story to see how it plays out?

Here are more details:

[https://arstechnica.com/tech-policy/2018/08/woman-my- iphone-...](https://arstechnica.com/tech-policy/2018/08/woman-my-iphone-was- seized-at-border-then-imaged-feds-now-must-delete-data/)</comment>


Ask HN: Vagrant on Windows or OS X? - <AUTHOR>

I am a front-end developer and I am about to start doing some contract work on a Rails web app. I currently use a Windows PC but I don't want to try and mess with getting RoR and the app to play nice with Windows. It looks like I have two options, I can use Vagrant and stick with my pc or I can purchase a MacBook for OS X.<p>I would rather not have to buy a new MacBook right now but I certainly don't mind if it would be best. My main question is, would there be any advantages to using OS X over Vagrant and Windows? <comment><USER2> You can run RoR in Cygwin

[http://phaseshiftllc.com/articles/2008/10/02/setting-up- rail...](http://phaseshiftllc.com/articles/2008/10/02/setting-up-rails-on- windows-with-cygwin.html)

</comment><comment><USER3> i bought a MBP a year ago, so i can learn rails on it. I've been a PC guy for the longest time. But rails development on a mac is just so convenient. Unfortunately at work, we're a PC shop. So do our development on a debian VM using virtualbox. It works fine. So if you have the money, go for the MBP. Other than that, I highly advise not to do rails development on Windows....use a linux a distro in a VM</comment>


A Game Jam Diary - <AUTHOR> http://bishopgames.com/game-jam-diary-part-1/

<comment><USER2> More details about the making of the game, please!</comment>