End to Democratic Primary:Anonymous Super-Delegates Declare Winner Through Media - <AUTHOR> https://theintercept.com/2016/06/07/perfect-end-to-democratic-primary-anonymous-super-delegates-declare-winner-through-media/ <comment><USER2> I am disgusted with the democratic establishment. I am in my 60s and a life long democrat, BTW.

I plan on changing to Independent status and will stop making contributions.

My 94 year old Dad said that the super delegates are the opposite of democracy, and I agree.

The real problem is that Sanders (and also Trump) hold political opinions that are against the financial interests of the military industrial complex and also the one world government crowd.

<comment><USER3> If you're not a fan of Superdelegates, you must really be upset with the Sanders' campaign for choosing Tad Devine as their top adviser. Devine was "instrumental in the creation of the superdelegate process," and is one of its ardent defenders. [0]

In fact, the Sanders' campaign strategy now is to 'flip' the Superdelegates _even though Clinton has a majority of the popular vote_ [1]

[0] [http://www.nbcnews.com/politics/2016-election/super- delegate...](http://www.nbcnews.com/politics/2016-election/super-delegates- center-democratic-nomination-fight-again-n516891) [1] [http://www.npr.org/2016/05/19/478705022/sanders-campaign- now...](http://www.npr.org/2016/05/19/478705022/sanders-campaign-now-says- superdelegates-are-key-to-winning-nomination)

<comment><USER4> I don't believe anyone in the Sanders Campaign is serious anymore about actually cinching the nomination. They were certainly after the initial results were promising, but Bernie got further than he expected. Now since flipping the super delegates is their only legal and conceivable way to win, and they need to appear to win to continue, it's their stated strategy. It seems to me like the main goal is to continue in the Media spotlight talking about progressive issues, and funnel money into more progressive candidates to change the face of the party. People like Tim Canova in Florida going after establishment democratic seats. I think it's an excellent strategy and will make use of the following Bernie has gathered to actually affect domestic change where change is most needed in the legislative branch.

</comment></comment></comment><comment><USER5> Voter suppression at its finest. Like him or not, we should be embarrassed by he unfair treatment Sanders has received at every turn of this race.

</comment><comment><USER6> Wow! Glen Greenwald put into words (much better than I could of course) some of the thoughts that ran through my head when the AP story showed up on my twitter feed. The timing really made it smell like an attempt to pull the rug out from Sanders the day before the California primary.

<comment><USER7> Why will this hurt Bernie's turnout more than Clinton's? From her campaign's recent posts, Clinton seems worried that this coverage could cost her points today.

<comment><USER8> > Why will this hurt Bernie's turnout more than Clinton's?

Because once the media crowns a winner (or even just declares a candidate practically eliminated), they tend to underperform their polls even if they haven't publicly conceded.

(When a winner is crowned, it also tends to depress turnout for the whole contest, which has to be a concern for downballot Democrats in California, especially with the top-two primary system for non-Presidential races which actually makes the primary more like the general election in a general + runoff system than a normal primary; while it probably doesn't matter a lot in the statewide races or areas which are Democratic strongholds, it could matter in other places. Actually, in some of the Democratic-favored races it could make the difference between two Democrats advancing in the top-two system and a Republican actually making the cut, so it might matter even there.)

> Clinton seems worried that this coverage could cost her points today.

That's not what you'd usually expect based on history, but its certainly possible (that Clinton supporters could stay home because they don't feel the need to vote, and Sanders supporters show up as a protest to the media coronation), and given the effect it has on interpretation of the results, its the expectation the Clinton campaign would want voice concern about and use to shape media coverage whether or not its a real concern.

</comment></comment></comment><comment><USER9> May I remind the seething masses, unpopular though this opinion may be, that more people have voted for Hillary than Bernie. They just tend to be less vocal about who they support on the internet.

<comment><USER8> > May I remind the seething masses, unpopular though this opinion may be, that > more people have voted for Hillary than Bernie.

Which would probably be more meaningful if (1) all states had similar election systems for Democratic delegates, and (2) all states voted at the same time.

> They just tend to be less vocal about who they support on the internet.

No, that's not at all true.

<comment><USER10> > No, that's not at all true.

Given the demographics, I suspect that it is at least a little true.</comment></comment></comment>


Fronty.com - <AUTHOR> https://fronty.com/ <comment><USER2> World's first service which generates website powered on screenshot powered by AI.</comment>


Ask HN: What tool do you need that you would pay for? - <AUTHOR> What is something that you feel is missing and you would pay to have it? <comment><USER2> You might be interested in the Opps Daily [1] newsletter. Every day is someone describing a software product they would pay money for.

[1] [http://www.oppsdaily.com/](http://www.oppsdaily.com/)

<comment><USER3> Similarly, there's also Nugget[1] which was Opps Daily's inspiration.

[1] [https://nugget.one/](https://nugget.one/)

<comment><USER4> FYI Nugget is a $$$ service but there is a free daily idea here: [http://nugget.one/daily](http://nugget.one/daily)

</comment></comment></comment><comment><USER5> I guess we've hit rock bottom for market research

</comment><comment><USER6> These types of questions always gives you horrible answers.

Go to a forum, or StackOverFlow, and see what people want that you could make a tool out of.

</comment><comment><USER7> A machine with can print legit money in any currency I want. I would definitely pay for that.

On a more serious note, I have a few workflow problems which will definitely make me shell out few bucks if there is a polished product.

In fact, i have more than a few. I'll give you one example. There should be a really nice cross-platform diff viewer for people who use git from the command line. My reasoning for that is that i like using the command line for git because it is way faster than GUI, but i always end up using the terminal for viewing diffs and stashes.

</comment><comment><USER8> TortoiseGit-like GUI for Linux. Surprisingly there is nothing even remotely as comfortable as it was.

</comment><comment><USER9> 42.

On a more serious note; just in case.

\- A tool that combines logic of my source control (commit history), static code analysis, and my ticketing system to produce a risk matrix for my code components so I can better estimate how risky a feature or bug fix is to implement. I.e. Many commits in a short amount of time, with multiple issues reported in that code area and bad static analysis results probably means I need to rewrite that part entirely and hence have to double estimations.

\- jetbrains resharper for Web languages.

<comment><USER10> 42 is the answer. Did anyone came up with a reasonable question?

<comment><USER11> 6 by 9. This was determined by

D E E P L E A R N I N G

E

E

P

L

E

A

R

N

I

N

G

</comment></comment></comment><comment><USER12> An app that let me replace 80% of my apps.

<comment><USER13> <insert obligatory Emacs reference here>

</comment></comment><comment><USER14> One that does my work automatically.</comment>


Facebook rolls out code to nullify Adblock Plus' workaround - <AUTHOR> https://techcrunch.com/2016/08/11/friendblock/amp/ <comment><USER3> It's been interesting to watch the escalating complexity of business models vs. the opportunities to make money by nullifying someone else's business model. Sometimes it seems like capitalism is about to devolve into chaos (in a mathematical sense), and that the flow of money is becoming increasingly arbitrary until it becomes entirely random.

It used to be that market economies were simple: you wanted something, you paid for it. Companies would pay their employees a fair wage for their labor, and then those employees would spend that money on consumer products. Their were some exceptions, like advertising on broadcast TV, but they were a relatively small part of the economy.

Netscape seems to have opened the flood gates with their "commoditize the browser, and make money selling servers" approach. Suddenly, it became consumers' expectation that things should be free, and business's expectation that you can't actually make money by selling to consumers. And businesses adapted: first it was the dot-com boom, where the business model was "use VC to grow marketshare while losing money on subsidized products, IPO, and have clueless tech stock investors foot the bill for cheap cool consumer products." Then there was Google, which made finding stuff free but extracted huge rents for getting found, and Facebook, which is similar but with more personal data. Then there were all the startups whose only revenue model was to sell to Google or Facebook - sometimes by threatening legal precedents (YouTube) or irrelevance (Instagram/Whatsapp). Consumers don't have money and would never be able to pay for their YouTubing/Instagramming - but Google & Facebook will pay a lot to maintain their business model.

Now we have ad-tech to optimize the ads shown; clickbots to make (fraudulent) money for a publisher; more clickbots to bankrupt advertisers; botnets (often distributed through these ads!) to hijack users' computers; clickjacking to hijack users; adblockers so consumers don't have to deal with any of this; and counter-adblockers to block the adblockers. It's like humans are doing their best to never see ads, which are only getting clicked by machines, which aren't actually buying the product but are usually attempts by competitors to bankrupt their competition. Oh, and of course all of these players are getting hacked on a regular basis.

Add to this the whole credit-card & consumer debt industry, which is based on some portion of the population never paying for stuff, but making up the losses on the interest payments of people who pay for their stuff late.

It's occurred to me that if a financial terrorist wanted to do _a lot_ of damage to the capitalist system, they need only hand out free credit cards that are backed by lists of numbers stolen in one of the many data breaches that have happened this year. It's free money for the consumer, who can buy whatever they want, anonymously, with no bill. Indeed, with the lists of credit cards stolen in 2015, someone could pose as the credit card company and mail out these cards to unsuspecting consumers, who would think they were using a legit card rather than one with someone else's account number. The merchants won't care initially until the cards start getting declined, which may not happen for a month. The CC & government resources dedicated to investigating card fraud would be overwhelmed if millions of people became fraudsters at once. And then straightening out the mess of who owes what would likely be impossible, with goods already "purchased", fenced, converted to cash, and gone.

<comment><USER4> > Netscape seems to have opened the flood gates with their "commoditize the > browser, and make money selling servers" approach.

Netscape originally charged for their browser. They only switched to this business model after Microsoft began giving away IE for free. Netscape couldn't compete with a free browser, especially not when that browser is included with the most popular desktop OS in the world, so they came up with the idea of using the browser as a loss leader for their server product.

Before IE, the only free browsers were the terrible TCP/Connect II-based browsers that various ISPs, such as AOL and Interramp, bundled with their service. Netscape was able to position Navigator as a premium offering, as the TCP/Connect II browser was horrendously slow and feature-bare. Navigator, meanwhile, was adding proprietary extensions to HTML such as tables, frames, the font tag, and blinking text (yes, <blink> was considered a selling point back then), it was fast for its time, and it had a toolbar with some useful features (like a button that took you to a search engine; I think Infoseek was the default). But IE had their own proprietary extensions, and it was about as good as Navigator, so Navigator was no longer the sole premium product.

<comment><USER3> Netscape was always free for personal non-commercial use. They charged businesses, but it was pretty common for ISPs to give away Netscape free on the welcome CDs they sent out when you started subscribing. And you could always download it off their website (or technically FTP server, IIRC) - <USER2> remember downloading it when I first got on the WWW, June 1995 (before IE 1.0 came out), and thinking how cool it was that all this software was free.

<comment><USER4> I think it was WinRAR-style shareware, where you were supposed to pay after a certain number of days but it wasn't enforced.

</comment></comment></comment></comment><comment><USER5> I checked the new ad preferences yesterday* that supposedly gives users so much more control over their ads than the "blunt tools" that adblockers are. So far it looks like a thinly-veiled attempt to get users to opt-in to targeted advertising: There is no way to disable certain types of ads (e.g. distractinv video ads) and (obviously) no way to reduce the number of ads. That last point is even stated explicitely: None of the preferences will influence the number of ads shown, only the "quality".

The only thing you _can_ do is give facebook some vague hints topics of ads you are particularly interested in and which you are not - with facebook making it clear that you'll get the same results with less hassle if you just opt-in to targeted advertising.

What annoys me most about Facebook's approach is their dishonesty. If the just stated "look guys, we have to show you ads cause that's how we make money. We can't let you block them", that would at least show some basic respect for their users. Instead, both the announcements and the preference page seem to recite the tired old fairy tale that users secretly _love_ ads and are only shunning them because they are not "relevant" enough to them. I don't know if they actually believe what they are writing but I don't know anyone who thinks like this.

They show the same cynicism in the linked post. Yes guys, we all know ad- blocking is a cat-and-mouse game. But first making it deliberately hard to distinguish ads and content, then blaming ad-blockers that they also remove content smells like a really cheap attempt to shift the blame.

</comment><comment><USER6> Honestly, if Facebook serves ads from their servers and not just loads them from random ad networks, and takes care, that they reasonably blend with the page in look and appearance (especially no special blinking, noise etc.) and in general curates them, like paper publications do, then I am all fine with ads on Facebook.

We have lived with (and sometimes even liked) curated ads in paper publications for decades. If the web just had those kind of ads, it would be great. Web pages need some way of financing, and if there is a reasonable one, it would be good for everyone.

The big problem with current web ads, and the reason I do run adblock is, that they are uncharted, often violently annoying and unfortunately a growing security risk.

In this sense, I support Facebook in having proper ads.

<comment><USER7> The problem with this is that you will no longer know what is an ad and what is not. On facebook that may not be such an issues but for example on your local news program. You no longer know if the report you are watching is actually news or a native ad.

<comment><USER6> I was assuming that all ads continue to be clearly labeled as such, as they were in print media. And for TV, of course, ads also needs to be clearly labeled.

What I was talking about is, that the page showing ads needs to be fully responsible for their content to prevent malware attacks, and of course, should see to that they are aesthetically acceptable.

</comment></comment></comment><comment><USER8> Adblockers, as a whole, would have so much more legitimacy if the most popular one didn't accept money for whitelisting.

If they want to advance an agenda that whitelists ads they consider "not annoying", fine, people who disagree with that agenda can use a better adblocker that blocks _all_ ads. But accepting money allows articles like this one to paint all adblockers with that same brush, making them all seem less legitimate.

<comment><USER9> That whitelist can be disabled by simple disabling one checkbox in settings.

<comment><USER8> Some spam has working unsubscribe links, but it's still spam.

</comment></comment></comment><comment><USER10> >We're disappointed that ad blocking companies are punishing people on Facebook as these new attempts don't just block ads but also posts from friends and Pages.

lol they designed it this way. I'm disappointed facebook, but what could I expect from you anyway...

</comment><comment><USER11> How's uBlock Origin go with this? (I use it and still don't see ads.)

<comment><USER12> Beats my why anybody would still use ABP over uBlock Origin. Their "acceptable ads" program is basically a protection racket scheme.

<comment><USER13> Because as soon as I started using uBlock "Origin", I started seeing more ads and more sites that didn't work at all where they previously worked with ABP.

Because the uBlock "Origin" UI sucks compared to ABP.

Because acceptable ads is easy to turn off with one click.

And because gorhill is a real asshole when you submit an issue. It's now obvious to me why uBlock had all sorts of drama at launch.

<comment><USER14> The a-hole part is certainly bad if it is true. Can you show some examples?

The "seeing more ads" part can just be the result of having fewer users.

<comment><USER15> The "seeing more ads" is baseless, I can easily provide cases where it is the opposite, because ABP is vulnerable to the "display: block !important" trick used by many web sites on Chromium-based browsers, is unable to block popunders, does not support script injections, and many other shortcomings. For instance, just try focus.de with EasyList Germany enabled.

I think it's possibly just a case of someone unhappy for whom I declined[1] to take care of their pet issue, so lashing out with vague supposed flaws so as to undermine my work makes him feel better.

1\. [https://github.com/gorhill/uBlock/issues?q=label%3Adeclined+...](https://github.com/gorhill/uBlock/issues?q=label%3Adeclined+is%3Aclosed)

<comment><USER13> > ... so lashing out with vague supposed flaws ...

That's funny. Because the reason I said it was that you close issues without pointing out WHAT item in your huge list of ridiculous guidelines (like "I don't accept pull requests") has been broken. LOL.

It's a real asshole move and if anyone actually reads the list of declined issues they can clearly see that people are annoyed by that.

<comment><USER15> To just respect the guideline to contributing shouldn't be too much to ask keeping in mind the time and work I happily volunteer to this project.

Given the amount of invalid issues that keep being opened[1], asking me to spend time to detail why issues marked as "invalid" are invalid is to ask me to spend a whole lot of precious free time on _not_ working to improve uBO.

CONTRIBUTING[2] is there to be read and respected. If you disagree with it, best is to not open issues. Countless other people understand why it is needed and respect it, and helps the project get better.

1\. [https://github.com/gorhill/uBlock/issues?q=label%3Ainvalid+i...](https://github.com/gorhill/uBlock/issues?q=label%3Ainvalid+is%3Aclosed)

2\. [https://github.com/gorhill/uBlock/blob/master/CONTRIBUTING.m...](https://github.com/gorhill/uBlock/blob/master/CONTRIBUTING.md)

<comment><USER16> You might wish to rename CONTRIBUTING.md to something like SUBMITTING_ISSUES.md.

In most open source projects, contributing refers to _contributing code_ not opening tickets for issues or requests. Even Github's help documents align with this understanding:

[https://github.com/blog/1184-contributing- guidelines](https://github.com/blog/1184-contributing-guidelines)

I have never used uBlock or looked at its project pages before now and would have skipped-past CONTRIBUTING.md if I was looking for issue-reporting guidelines. The current title doesn't even tally with the first line of the document. There is also no reference to the appropriate issue-reporting process from README.md.

<comment><USER15> The link to CONTRIBUTING appears at the top of the issue template when one click the "New issue" button. This the top line which appears when opening a new issue:

> Read first: > <[https://github.com/gorhill/uBlock/blob/master/CONTRIBUTING.m...](https://github.com/gorhill/uBlock/blob/master/CONTRIBUTING.md#>)

<comment><USER14> Okay. For me it looks like the complaint was unsubstantiated. Thanks for the detailed discussion, gorhill.

And thanks for maintaining uBO. Using it happily since it became a topic on HN.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> I see where it goes. It goes to real-time Ads reporting by adblock users and real-time blocklists. Facebook can not win that, unless they serve unique ad for every user.

<comment><USER18> I also think Facebook cannot win this. What if someone makes a plugin that, on top of removing the Ad, also sometimes virtually clicks it (without the browser actually showing the Ad page) thereby completely ruining any way of knowing who really clicked the Ad, hurting the advertiser instead of Facebook?

<comment><USER19> This exists:

"As online advertising is becoming more automatic, universal and unsanctioned, AdNauseam works to complete the cycle by automating all ad-clicks universally and blindly on behalf of its users. Built atop uBlock-Origin, AdNauseam quietly clicks on every blocked ad, registering a visit on the ad networks databases. As the data gathered shows an omnivorous click-stream, user profiling, targeting and surveillance becomes futile."

[https://adnauseam.io/](https://adnauseam.io/)

</comment></comment></comment><comment><USER20> Isn't this ultimately something Facebook cannot win? It seems to me that updating the 'ad detection' in a Chrome plugin is significantly easier than updating the Facebook codebase, so much so that it offsets the potential difficulty of writing the code to detect these ads in relation to code that obfuscates the fact that something is an ad.

Or am I missing something?

<comment><USER21> Yep. Besides the legalese they must include ([https://www.ftc.gov/tips- advice/business-center/guidance/nat...](https://www.ftc.gov/tips- advice/business-center/guidance/native-advertising-guide-businesses)), they will never win because users control the client/browser. Facebook's efforts to block ads will always be futile.

They could block ad blocking users completely, but that would be too much negative PR and hurt their already peaking MAUs.

</comment></comment><comment><USER22> Immediatly what went through my head:

"Maybe Facebook has planned this like a chess game, and planned several moves ahead even before their first move."

I wonder how many moves they have in advance.

<comment><USER23> If the portrait of 'Boz' in Chaos Monkeys is any indication, not far.

</comment></comment><comment><USER24> EasyList maintainers are also trying to bypass Facebook ads, with no success for now.

[https://forums.lanik.us/viewtopic.php?f=62&t=31995](https://forums.lanik.us/viewtopic.php?f=62&t=31995)

<comment><USER25> > You have been permanently banned from this board.

> Please contact the Board Administrator for more information.

> Reason given for ban: Let's play whack a mole

> A ban has been issued on your IP address.

uhhh ok? I've never visited that forum, even.

<comment><USER26> Using a VPN?

</comment></comment></comment><comment><USER27> From the link within the parent link[0]:

>Facebook commissioned research firm Ipsos to investigate why reports say 70 million Americans and nearly 200 million people worldwide use adblockers.

Americans are less than 10% of the online population but around 35% of adblockers? Is this just am exposure thing?

[0][https://techcrunch.com/2016/08/09/facebook-will-bypass- web-a...](https://techcrunch.com/2016/08/09/facebook-will-bypass-web- adblockers-but-offer-ad-targeting-opt-outs/)

<comment><USER28> it's probably because a more computer savy relative installed it on their computer so they don't get a call constantly when an add pops up saying

"Your WiFi was infected with 99.5 viruses call this number so we can scam you out of your money".

<comment><USER29> Yeah... between this and the malware, I can't leave my family without ad blockers.

</comment></comment></comment><comment><USER30> On some websites, longtime text-only browser users are seeing new greetings like "I see you are using an adblocker."

Usually they are greeted with warnings about lack of functionality because of absence of Javascript, and imperatives that they _must_ upgrade to a "modern browser".

Once-free websites that were converted to companies, like Google and Facebook, must survive on web ads.

But web ads are built on an unstable foundation; their presence relies on several assumptions.

And, quite simply, the web works without them -- without the assumptions and without the ads. Longtime web users, who grew up with early "browser" prototypes, including "text-only browsers", remember this.

The network is very fast now. We can move all manner of data across "the web". But the architecture of the internet and the web is still more or less the same.

This is, thankfully, why "blocking" (not requesting) web ads is so easy.

</comment><comment><USER31> I'd like to know at what point the revenue generated from these ads would surpass the cost of simply acquiring Eyeo GmbH (the company behind Adblock Plus).

<comment><USER8> 1) They're a private company, not a public one, so acquiring them would be entirely at their own discretion and pricing.

2) EasyList is maintained by others, and could be used by any other adblocker. Eyeo only maintains the so-called "Acceptable Ads" whitelist.

3) Even if someone managed to acquire the company behind that "Acceptable Ads" whitelist, that list has no value without users. The value of the purchase would evaporate if all the users switched to another adblocker, or a forked version of Adblock Plus itself.

<comment><USER31> I agree with all your points, but I'm still curious as to what that price point of item 1) would be, realistically.

Also, the remaining user base of item 3) -- the "even if" case -- might still be sufficiently large to warrant a purchase.

According to this source [0], which seems to come from their public filings, in 2014 they apparently had "only" €4.32m in revenue.

Edit: According to [1], in 2015, they apparently struck a much more lucrative deal with Google, Microsoft, and Amazon, among others.

[0] [http://de.statista.com/unternehmen/434815/eyeo- gmbh](http://de.statista.com/unternehmen/434815/eyeo-gmbh)

[1] [http://on.ft.com/1CmZiBO](http://on.ft.com/1CmZiBO)

</comment></comment></comment><comment><USER32> I wish there could some discussion about an intrusiveness score of an ad. I'd be glad to block ads that are not too intrusive.

As long as ads are hosted on the same server of the website, there is no problem. Until that's done, I'll keep blocking. Google ads were a fine example of unintrusive ads.

</comment><comment><USER33> This might still work as fb-only ad blocker: [http://www.fbpurity.com/](http://www.fbpurity.com/)

I've been using it for years and have turned off my entire news feed on desktop. I don't miss it one bit.

<comment><USER34> That site looks like a scam site.

</comment></comment><comment><USER35> Would be funny if we eventually end up with some artificial intelligence algorithm that processes content on a webpage and modifies it for the end user to remove any content they don't want to see.

<comment><USER36> I totally expect this to happen. Although it will only lead to advertisers also using those programs to check their content and modifying it until it fits. I mean we already have pretty much an always on going evolution in advertising, why should it stop.

</comment></comment><comment><USER37> I recently worked on an extension to disable Facebook's news feed completely since I (and probably many others) mostly use it for chat and groups. Might be helpful for some people in the HN community! :)

Link: [https://chrome.google.com/webstore/detail/fb-feed- modifier/h...](https://chrome.google.com/webstore/detail/fb-feed- modifier/hbhdccjdfjcpakliojfnpincocolhcob/reviews)

</comment><comment><USER38> Facebook cannot win this. If not ABP, it'll be a browser extension or something else. Fundamentally, they're bringing in something users are against, and hence will take any easy action against.

The hard part is the 'easy action'. Installing ABP is pretty easy. If that does not work, and "FB ad block" extension is the easy thing to do, that will be installed. Sooner or later.

</comment><comment><USER39> Some sites detect adblockers and prevent users from using it until they disable the adblocker. Why doesn't FB do that?

<comment><USER40> They don't want to create user friction in their direction.

If facebook stops something working because of the ad-blocker, or accidentally cause something to break while trying to do so perhaps even for users without the blocker, the users will see facebook making it difficult for them to do what they want.

If on the other hand facebook stops the ad-blocker from being able to work on their site, without breaking other bits of the facebook experience at all, the same users will see the ad blocker failing to do its job.

</comment></comment><comment><USER41> Fixed here: [https://github.com/easylist/easylist/commit/1fb0590737b4fc83...](https://github.com/easylist/easylist/commit/1fb0590737b4fc834eaf23c665591d68cb28600d).

</comment><comment><USER14> As always when this topic pops up: Zero empathy here for the companies that shove ads into users faces. Make money by providing reaosonable services, not by treating your users like cattle.

<comment><USER42> > companies that shove ads into users faces

ISPs intercepting traffic and injecting ads that neither the user nor the site owner intended, yeah, I can see how that could be classed as "shoving ads in people's faces", but "here's a free service with ads attached, please either take both or leave both"? What part of that is "shoving"?

<comment><USER14> I see your point. But I can decide which part of your service I want to see. If I want my browser to not show the Hacker News header line, am I doing something wrong? No, I don't think so. And if you still try to circumvent my browser config to show it to me anyways then it is shoving it into my face.

<comment><USER42> That analogy is ineffective because the HN header bar isn't the price that the provider has asked you to pay in exchange for the service.

When I walk into a shop I am presented with a similar "here are some objects with prices, please either take the object and pay the price or don't do either". However, it's physically possible for me to decide which part of a transaction I want to take part in. If choose to accept the "taking objects" part of the deal while ignoring the "paying for them" part of the deal, am I doing something wrong?

If the shopkeeper then said "hey, you should pay for that", would you have "zero sympathy" for the shopkeeper because they were "shoving capitalism in my face"?

</comment></comment></comment></comment><comment><USER43> link?</comment>


Steam Removes Paid Mods Feature - <AUTHOR> http://mezbreezedesign.com/2015/04/27/steam-removes-paid-mods-feature/

<comment><USER2> From my understanding - a large amount of the hate mail are from people who think mods should be free.

Mod creators could still release their mods for free but could opt into payment if they felt they were deserving of pay. So the people who thought mods should be free could just _not purchase any mods for sale_. Instead they took to complaining to Steam about opening a venue that might encourage mod development and create more content for everyone.

Correct me if I'm wrong... but it sounds like a bunch of reactionaries got mad over something that would largely only have a positive effect on them. In fear of pissing off its consumer-base, Steam took a step back.

Am I missing something here?

E: Reading through the comments on the scenario. Seems like there was a bit more corporate muckery going on. I'll have to read more, I've only been following this drama loosely.

<comment><USER3> I have no interest in the issue and have barely skimmed some comments on it, but from what I understand a lot of the problem is the high chance mods will conflict or just not work at all - a game can update at any time and break mods. Paying for something that has no real support is hard to swallow for some people.

In some ways it seems similar to the jailbreak community, and there are paid apps and tweaks there - but it does come at the cost of greatly reduced performance, stability, and security.

<comment><USER2> Which still doesn't really effect anything.

      a) If the developer wants to continue sales,
      they must fix their mod to work with future updates.
      This gives them incentive to keep it up to date.

      b) It's an accepted and known risk that updates
      might break the mod at time of purchase.

I don't use Steam but I assume it lacks Version Control - so you wouldn't have the option to download an outdated version of a game for mod compatibility. [0]

The ability to sell a mod could incentivize people who would otherwise not create mods.

So here are the two scenarios:

      1) No sales = less content created; same issue of future incompatibility

      2) Sales = more content created; same issue of future incompatibility.

Those who do not wish to risk a mod becoming incompatibility (and unfixably so) could simply not buy any mods that are for sale, choosing to stick with 'free' mods.

The suggested donation-model (optional payments) is how I think most media should run regardless. It seems theres a fair amount of support for a "donation button" instead of the sale model.

[0] Based on nothing but posts from 4 years ago and a quick Google search and the fact that future incompatibility is an apparent issue.

</comment></comment></comment><comment><USER4> So this [0] article is where I got the numbers that have caused a fair amount of the outrage that led to this announcement from Valve.

The modders were getting 25% of the mod sales, Valve was getting 30% (a standard for digital distribution channels), and 45% going to Bethesda. The outrage being how much Bethesda got. Bethesda responded to this in the linked article [0]:

> Many have questioned the split of the revenue, and we agree this is where it > gets debatable. We're not suggesting it's perfect, but we can tell you how > it was arrived at.

> First Valve gets 30%. This is standard across all digital distributions > services and we think Valve deserves this. No debate for us there.

> The remaining is split 25% to the modder and 45% to us. We ultimately decide > this percentage, not Valve.

> Is this the right split? There are valid arguments for it being more, less, > or the same. It is the current industry standard, having been successful in > both paid and free games. After much consultation and research with Valve, > we decided it's the best place to start.

> This is not some money grabbing scheme by us. Even this weekend, when Skyrim > was free for all, mod sales represented less than 1% of our Steam revenue.

> The percentage conversation is about assigning value in a business > relationship. How do we value an open IP license? The active player base and > built in audience? The extra years making the game open and developing > tools? The original game that gets modded? Even now, at 25% and early sales > data, we're looking at some modders making more money than the studio > members whose content is being edited.

> We also look outside at how open IP licenses work, with things like Amazon's > Kindle Worlds, where you can publish fan fiction and get about 15-25%, but > that's only an IP license, no content or tools.

> The 25% cut has been operating on Steam successfully for years, and it's > currently our best data point. More games are coming to Paid Mods on Steam > soon, and many will be at 25%, and many won't. We'll figure out over time > what feels right for us and our community. If it needs to change, we'll > change it.

If you ask me 45% is too high, I don't think it should be exactly 0% but to give the developers so little seems criminal...

Another source for this was fact that there is no real support for mods especially with mods interacting with other mods. While there was a return period (24hrs IIRC) a number of gamers were arguing that you don't always find out within 24hrs if a mod will conflict with another mod. Maybe a long trial period would have helped to alleviate some of this.

[0] [http://www.bethblog.com/](http://www.bethblog.com/)

<comment><USER5> A lot of the backfire could have been avoided if they they had this info prominently displayed on the homepage.

I can't tell you how many times I read about these knee jerk reactions from people with their self imposed boycotts of the entire Steam platform. The reason most given? "Because Valve takes 75% and only leaves 25 for the mod maker".

These people were so quick with their math they never even got to the fact that a) Bethesda takes a cut, the highest one at that and b) this split came from Bethesda and did not originate at Valve.

But, as these things go, have one of these people spew out this misinformation, get enough people to echo this and many others will take it as fact. You can then try to tell them as often as you like how that is wrong and they will just downvote you because "you're just a valve shill" resulting in nobody seeing the actual facts and the echo chamber happily moves down the wrong way getting more and more worked up.

In the end, it was just an option to treat mods like DLC and games. Make em either free or charge for em. Nothing more. If mod makers want to make their work free, literally nothing changed. If they want to they could have started chargin for them. And if people didn't like it, they just didn't have to buy them. If there was a mod that was once free and was then moved to the pay side, people could have let the maker know that was a dick move. And if a paid mod breaks because of a game update, people could have let the maker know to better fix that asap or they'll demand a refund. Only with free mods you could say "yeah, it broke with the newest update. don't have time to fix. working on other stuff". If you sell it, you have to support it. But that is up to the mod maker, not the owner of the distribution platform.</comment></comment>


Gmail XSRF? - <AUTHOR>

<img src="https://mail.google.com/mail/?logout&hl=en" /> will log you out of your google account.  But at least other functionality like sending messages seems to be protected? <comment><USER2> Google does not consider this to be a security vulnerability (or at least not one they feel they can deal with). See <http://www.google.com/corporate/rewardprogram.html> (Logout cross-site request forgery is the section to look for).

</comment><comment><USER3> Taking steps to prevent malicious logouts would mean that you're creating cases where a logout will not succeed. This opens the possibility of having a bug that prevents people from logging out at all, even if they want to.

Would you rather have a bug that allows logouts, or a bug that prevents them?

That said, I would love for Facebook to put this snippet in their footer.

<comment><USER4> >That said, I would love for Facebook to put this snippet in their footer.

Google has an effective way to retaliate. Consider all those non-expert users who type "facebook" in the search bar to get to Facebook and who do not know the difference between the search bar and the location bar.

</comment></comment><comment><USER5> It's definitely a bug, but I'd be shocked if they didn't know about it (and thus accept it). Its net result is to make Google accounts _more_ secure (if more annoying to use).

Google products are pervasively checked for CSRF, in case you were worried that this was a worrying sign. I'm sure they have CSRFs, but not because they don't hunt them down.

</comment><comment><USER6> <http://www.google.com/security.html>

<comment><AUTHOR> I emailed firstname.lastname@example.com, but I figured that posting it here would make it more likely for them to fix it faster.

<comment><USER6> Noble intentions but please don't do this in the future. Working in security (not at google) I promise we are trying to fix it as fast as possible already :)

You may also get cash+prizes if you submit as you did but don't release it publicly.

</comment></comment></comment><comment><USER7> There's probably a reason it's so unprotected (though probably not a very valid reason).

Writing CSRF-safe logout would mean that you can't have an href to a static link, and you'd to implement some sort of unique id/key and/or a form post behind the scenes.

</comment><comment><USER8> Sorry, but I call that a feature, not a vulnerability.

<comment><AUTHOR> Including that tag on _any_ page - forum, blog, whatever, will log you out without your consent. For comparison, Facebook has cross-site request forgery protection for logging out</comment></comment>


Generation loss: comparison of FLIF, WebP and JPEG [video] - <AUTHOR> https://www.youtube.com/watch?v=bpne6IhI57Y <comment><AUTHOR> And comparison of FLIF, WebP, BPG and JPEG:

[https://www.youtube.com/watch?v=IheZzcYUV9w](https://www.youtube.com/watch?v=IheZzcYUV9w)</comment>


What Can't Tech Money Buy? - <AUTHOR> http://nytimes.com/2016/05/29/opinion/sunday/what-cant-tech-money-buy.html <comment><USER2> "Philanthropy has the power to do a great deal of good, but so do tax dollars allocated in an equitable democratic system. Perhaps it's time to adopt a Gospel of Government."

I trust Gates 10x more than the US government. I feel optimistic that Zuck will prove himself. The other billionaires? Not so much. They will allocate money more efficiently but will it go to the right causes?

<comment><USER3> The good thing about the US govt is that it can't operate with as much secrecy as a private entity, nor can it operate without accountability.

I also disagree in theory about allocation efficiency. Govt is inefficient, but so are humans and corporations. Look at the huge amount Zuck wasted trying to fix NJ school districts without understanding the problem.</comment></comment>


Why it's wrong to call copyright infringement theft - <AUTHOR> http://gigaom.com/2012/03/30/why-its-wrong-to-call-copyright-infringement-theft/

<comment><USER2> I will agree if we stop calling it "theft" when GNU/open source software is used in a proprietary application.</comment>


HermitCore-rs – A Rust-based, lightweight unikernel - <AUTHOR> https://github.com/hermitcore/libhermit-rs <comment><USER2> I'm not familiar with HermitCore but the authors "...promise that this will make it easier to maintain and extend our kernel [originally written in C]." It'd be great if they could elaborate.

<comment><USER3> It may or may not be easier to "maintain and extend" a Rust implementation, but it will surely be even easier to find people to do those things if they keep it in C.

EDIT: Rephrased the sentence

<comment><USER4> I don't know about that, they teach C at pretty much every reputable University in america

<comment><USER3> That was my point - a lot more people know C

<comment><USER5> There's quantity, but what about quality? Whenever there's a vulnerability found in a C program, its authors are dismissed not _real_ C programmers (since a real programmer would know to avoid buffer overflows and dangling pointers).

Apart from DJB, is there any other real C programmer? ;)

<comment><USER6> > Whenever there's a vulnerability found in a C program, its authors are > dismissed not real C programmers (since a real programmer would know to > avoid buffer overflows and dangling pointers).

This was the first time ever I've heard of such a thing.</comment></comment></comment></comment></comment></comment>


Curse of class of '09 - <AUTHOR> http://online.wsj.com/article/SB124181970915002009.html

<comment><USER2> This article would be a lot more amusing if they took the opposite angle: "Times of economic growth obscure the fact that a large percentage of Americans graduate with no practical skills, and still get decent paying jobs."

</comment><comment><USER3> Curse is a really strong and almost sensationalistic word to use. If making less money because you happen to graduate during a recession in the US is a curse, what's left to those born in the poorest parts of the world.

While there may be a lot not to like about the US, it's still one of the best places to be if you want to make money.

</comment><comment><USER4> "For a typical worker, that would mean earning $100,000 less over the 18-year period."

The biggest purchase the typical worker will make is a house purchase. Assuming "typical" means median, and assuming (big assumption) that the median worker buys a median house on a married two-income household, the median household is losing around $200,000. The median house price in the United States is $220,000.

The median college graduate family for the class of 2009, when they hit their forties, will be behind their expectations by about a house. Ouch.

<comment><USER3> No, they won't. If _everyone_ is making less money, housing prices will adjust accordingly. What the article doesn't mention is that the 80s were an excellent time to buy a house.

<http://mysite.verizon.net/vzeqrguz/housingbubble/>

</comment></comment><comment><USER5> "For a typical worker, that would mean earning $100,000 less over the 18-year period."

That is not at all a frightening statistic.

<comment><USER6> That is an average of 5500+ dollars per year, ~463 per month. Depending on who you ask that is a big deal.

</comment></comment><comment><USER7> I wonder about the change in marriage dynamics here.

Suppose you have a decade of fellows who, due to bad luck, are on a low- earning streak compared to those in the preceding years. Would this add incentive for the women of the right age, from the current decade, to marry men from the preceding "block"?

Alternatively, suppose all earnings are down, which means that relatively everybody is still about the same, within the current decade "block". Then women won't have much incentive to marry the older men.

But I think the previous case is more likely. Then we will have some kind of a gap in M/F distributions among the age groups. How would the current decade block's males adapt? When the women of the subsequent decade block enter the workforce, the males from the current block will have to compete with the males in the next block as well, but won't have much advantage from greater salary.

So it looks like a slow correction, a loss, to me, i.e. there will simply be an increased number of bachelors in this block.

</comment><comment><USER8> In a downturn economy, everybody is either looking for a way to cut their operating costs or increase revenue with no additional cost. Startups that improve efficiency are riding this wave.

</comment><comment><USER9> Wow no one has said "thats why a recession is the best time to start a business"

</comment><comment><USER10> This article gives the impression that the class of '09 is actually entitled to have wonderful, high-paying jobs. It's a job market, no one is entitled to anything. It sucks, but the faster these gen-Y'ers face the harsh reality, the better. There's nothing to gain in whining and denial.

<comment><USER11> It sucks, but the faster these baby boomers face the harsh reality (of the mess they've created), the better. There's nothing to gain in whining and denial.

Generationalism is just like every other -ism. Not that you are being explicitly generationalist, you just give that impression.

<comment><USER10> I was born in 1980. Which generation am I officially a part of? I honestly don't know, and I truly don't care...

I didn't mean to be a _generationalist_ , but after having taught these kids in grad school, I don't have the highest opinion of them, to be frank. And, indeed, the baby-boomers f*cked up big time... and it sucks that everyone has to pay for the mistakes of a few.

<comment><USER11> That seems to be how it always goes, though. Each "generation" thinks the previous one is incapable, incompetent, or over-privileged. The young attack the old who they feel don't understand. They rebel. Again and again.

I'm just saying that the argument is tired and over-general. "Generations" or semi-birth-year-based orderings (class of '09) have only the slightest commonalities.</comment></comment></comment></comment>


Whats the best SaaS software for entrepreneurs? - <AUTHOR> http://blog.entryless.com/software-as-a-service-saas-accounting-suite-for-your-financial-freedom/

<comment><AUTHOR> besides github and a project management saas, what other service is a must for your startup?</comment>


Which Programming Languages Use the Least Electricity? (2018) - <AUTHOR> https://thenewstack.io/which-programming-languages-use-the-least-electricity <comment><USER3> Interesting results, but I think the farther you go down the list the more the fact that you're using the Computer Language Benchmark Game affects what you're seeing, as not all languages get the same attention.

For example, Javascript and Typescript. Theoretically, I would assume those to be very close, since one compiles to the other. And for memory usage, they are very close. But for running time, Typescript is an _order of magnitude slower_. That looks suspiciously like entirely different algorithms were used in each implementation (with one being obviously superior in terms of performance), and if that's happening in this specific case, where else is it also causing problems in the analysis?

<comment><USER4> > Theoretically, I would assume those to be very close, since one compiles to > the other.

I don't think that's a safe assumption. The Javascript results would be a lower bound (assuming the same algorithm, etc.), but there's no telling what "extra" Javascript (and thus overhead) might be inserted by the Typescript compiler.

As far as individual results go, there's no point jumping to conclusions when the results and code are available online and easy to try for yourself:

[https://benchmarksgame- team.pages.debian.net/benchmarksgame/...](https://benchmarksgame- team.pages.debian.net/benchmarksgame/faster/typescript.html)

Typescript is still 2-3x slower than Node in several of the benchmarks, and the results could have been different in May 2018 when the article was written.

<comment><USER5> Typescript is a superset of Javascript, you can literally submit the faster JS programmes as the TS ones.

<comment><USER6> This may be a dumb question as I know nothing about Typescript, but is it idiomatic to do that, though? You can, for the most part, use C in C++. But if C was beating the pants off of C++ in benchmarks it wouldn't tell me anything useful if someone submitted a C program as the C++ benchmark. If I wanted to use idiomatic C, I'd use C. I expect a C++ vs. C comparison to compare the encouraged features of C++ with what's available in C.

<comment><USER7> The benchmark is flawed. It should compare the fastest possible C++ implementation and a more idiomatic C++ implementation. The entire purpose of the language is to allow both to coexist in the same code-base.

I would be very surprised if the fastest C++ and C are actually different.

<comment><USER8> If the benchmark claimed to be perfect then "flawed" would be an important criticism.

You _can_ see 4 or 5 C++ fannkuch-redux programs "compared"

[https://benchmarksgame- team.pages.debian.net/benchmarksgame/...](https://benchmarksgame- team.pages.debian.net/benchmarksgame/performance/fannkuchredux.html)

</comment></comment></comment></comment></comment></comment><comment><USER9> Can't run Rust without powering the HN servers, to host the screeds of its acolytes.

I jest, (and I'm a Rust admirer myself), but my more serious point is: so many different kinds of electricity go into a plush tech company with its well paid developers and our copious brain food that powers us through all our developing and debugging. If you want to talk about sustainability, ask about the lifecycle maintenance of a software base. These benchmarks are cute, but academic, and only tenuously related to any green solutions. Especially if people in this thread are taking this seriously in terms of "This is exactly how we should all be thinking about server engineering moving forward, as we aim to drastically reduce carbon footprint within 11 years", then this is an feels like an awful, awful way to measure it.

What language is most conducive to writing algorithms that are smart in terms of Big O, or designing systems that can be refactored intelligently instead of throwing boxes at the problem?

<comment><USER10> Scala is a nice sweet spot. Good type system, solid for refactoring, good for expressing algorithms. You burn tons of CPU compiling but that's one dev footprint.

Anyone from Twitter care to comment on this?

</comment></comment><comment><USER11> Couple points (I've worked on app servers):

1- This is exactly how we should all be thinking about server engineering moving forward, as we aim to drastically reduce carbon footprint within 11 years. Efficiencies at the language level are one of biggest bangs for buck here. Just by redeploying, you can reduce energy consumption by perhaps double digits. Imagine how hard that is to do at the hardware or energy farm level.

Think about it: You, brave software engineer, can literally make a significant contribution to _saving the world_ by adopting a more energy-efficient language, if you are fortunate enough to deploy something at scale.

2- Rust is killing it in these metrics but developer productivity / friendliness is important to overall success. Looking at these results I have a conjecture that is maybe provocative: The top two candidates for long-term success at supplanting Java on the server in my eyes are

a) Go

b) brace yourself.. Swift

Swift is extremely young on the server, to the point where I'd expect your natural reaction to be "WTFLOL?! never heard of it". But here's some food for thought: the Netty team, one of the top performing Java server stacks, has been recruited by Apple and is chewing through all that stuff and _just_ launched their NIO2 release[1] which I've heard is already very close to Netty.

Go has an amazing concurrent garbage collector and has really pushed the envelope with that.[2] Swift is unique in the server world in that it uses reference counting which sidesteps the whole GC collection problem, which could translate into very low, very consistent latencies as well as memory usage. It's still quite early days for Swift, but these are the two languages I'm watching the closest.

[1] [https://forums.swift.org/c/server](https://forums.swift.org/c/server)

[2] [https://blog.golang.org/ismmkeynote](https://blog.golang.org/ismmkeynote)

<comment><USER12> Go's GC is not really pushing the envelope. They have merely improved from a STW, non-compacting, non-generational collector with a 25% CPU overhead to a concurrent, non-compacting collector with reasonable overhead.

JVMs and CLR had those a decade ago. The state of the art are concurrent, compacting, region-based pauseless or millisecond-pause collectors.

<comment><USER13> Comparing Go's GC to one of the many specialized fine-tunned Java GCs is pointless, I find.

I'm sure you're also aware that recent Go's GC pauses are sub millisecond for most use cases:

"We now have an objective of 500 microseconds stop the world pause per GC cycle." \- 2018 Go team

[https://blog.golang.org/ismmkeynote](https://blog.golang.org/ismmkeynote)

My personal experience with microservices is to expect STW pauses in the 350 microsecond range. The best part is that it requires zero tunning or developer's attention while still being light on memory usage. Can't say the same for Java's default GC.

<comment><USER12> I was talking about technology state of the art, not out-of-the-box experience.

OpenJDK's default collector - parallel or G1GC, depending on version - is not the best available among JVMs and if your goal is pause times then yes, it will be worse than Go's. But if you switch to say C4 or ZGC you'll get comparable pause times and compacting on top and being able to scale to terabyte heaps.

10 years ago we had Metronome and CMS, which are more comparable to Go's collector.

And pause-times are not everything. Throughput and fragmentation resistance matter too. Compacting collectors fare much better on the latter metric. I don't know how the former is now, but those slides talked about 25% GC overhead in older versions of Go, that's utterly terrible.

Go is facing one challange that java doesn't: internal pointers. But the CLR's collectors have to deal with those too, so that's not terra incognita either.

<comment><USER13> Of course gains are to be expected when switching from Java's default GC to something specialized.

> 25% GC overhead in older versions of Go, that's utterly terrible.

25% overhead of what? And compared to what? Just throwing numbers in the air and saying it's terrible makes no sense.

The only 25%'s if could find in the slide were these: [https://blog.golang.org/ismmkeynote/image6.png](https://blog.golang.org/ismmkeynote/image6.png)

2014 Go: 25% of CPU used by GC

2018 Go: 25% of CPU used _during_ 2x STW GC of < 500 microseconds

So even if STW GC occurred as frequent as every second (which it doesn't in my use cases), this would amount to 0.025% of the CPU being used for GC, not 25%.

<comment><USER12> The 2014 numbers read to me that 25% of all CPU cycles are spent on GC. If you re-read my previous post I was talking about that old version. The point was that Go started improvements from a fairly bad place, were gains are still relatively easy to obtain.

> Of course gains are to be expected when switching from Java's default GC to > something specialized.

So? That's irrelevant for what's state of the art.

<comment><USER13> I re-read our conversation thread to understand our communication mismatch and indeed you were taking about Go's GC not being novel, which it isn't. I apologize for the unproductive conversation, it's all on me.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> > A faster language is not always the most energy efficient

My rule of thumb now is that memory access, not compute, is the primary consumer of energy. That would tend to confirm the above statement while also supporting the data that scripting languages aren't super energy efficient, since they tend to do a lot more dynamic allocation than compiled languages, when generally broadly speaking about common programming practices in each language.

This is mainly colored by GPU usage and a paper/presentation some friends made: [https://www.researchgate.net/publication/324217073_A_Detaile...](https://www.researchgate.net/publication/324217073_A_Detailed_Study_of_Ray_Tracing_Performance_Render_Time_and_Energy_Cost)

In the GPU case, memory access costs sometimes 10x more than compute, meaning that minimizing average (not peak) memory traffic is more or less the only path to significantly reduced energy. (See figs 7 & 10 in the linked paper)

<comment><USER15> "Costs more" in terms of energy per... what quantity exactly? Instruction executed? Clock cycle? Datum processed?

<comment><USER16> I think practically, for useful analysis in business it would be wattage per unit of useful work (or datum processed as you suggest). For instance, I work in finance, so what is the wattage per option price calculation?

<comment><USER15> The reason I asked was that it wasn't clear to me if the parent comment was measuring the same way or not re: memory accesses. It seemed pretty expected that a memory access would be more expensive per byte (it takes like hundreds of clock cycles...) but it wasn't obvious to me if it would be so per clock so I wanted to clarify which was meant.

<comment><USER16> I absolutely agree that it wasn't clear. I don't think wattage per clock cycle is a meaningful measure here - after all, all languages will have the same wattage per clock cycle, if they're executing the same instructions.

What's important is wattage per unit of useful end product, in my example pricing an option. For others, it might be wattage per web page served or anything else.

</comment></comment></comment></comment></comment><comment><USER17> Not sure what to make of this research. It's not like I can switch out JS in favor of these other languages (many of which are compiled binaries) in my web apps. The performance of for example web servers written in the different languages entirely would seem more interesting to compare.

The JS/TS comparison was directly fishy. I found no mention in the paper of how they managed to "run" the tasks in Typescript, which AFAIK is not possible, or at least not how one would do it in a real life.

<comment><USER18> Maybe you _can_ switch it out :) [https://webassembly.org/](https://webassembly.org/)

<comment><USER19> It _wouldn 't_ be switching out. You'd just be running WASM.

<comment><USER20> Instead of a binary. You're running whatever the language compiles to. So then it depends on how efficient the WASM compiler is compared to the binary on whatever platform, and compared to JS.

</comment></comment></comment></comment><comment><USER21> Reversible computing should be mentioned, as it could be the holy grail of low energy use.

[https://spectrum.ieee.org/computing/hardware/the-future- of-c...](https://spectrum.ieee.org/computing/hardware/the-future-of-computing- depends-on-making-it-reversible)

<comment><USER22> Almost 20 years ago I took courses under a professor who was very into reversible computation. As I recall it was mainly on the language side, though.

Glad that it's still moving, sad that it's at an even slower pace than the "functional/immutable will save the parallellization worries" stuff I encountered in the same period.

</comment></comment><comment><USER23> Historically, virtually every move up the abstraction level sacrificed performance to gain programming efficiency. Assembly to C, C to C++, C++ to Java, Java to Python/Javascript. And now there are wars over Javascript vs. Typescript, and jQuery vs. React/Angular. Every new step up the stack claims that the higher level of abstraction can either be implemented with only a minimal penalty, or could actually improve performance due to easier automated optimization. However, every time, it seems that in practical applications, performance is sacrificed to make software development faster.

I don't know enough about the performance of Javascript vs. Typescript to form a strong opinion about it, but if history is any guide, it's likely that it improves software development efficiency at the expense of performance.

<comment><USER24> Typescript usually transpiles to javascript, just without the type information, and this is not done in the browser. If you target old browsers it can add maybe add some overhead like babel does.

I don't know about javascript's usual JIT compilers, but LuaJIT's JIT compiler (trace compiler) does a pretty good job of figuring out abstractions.

</comment></comment><comment><USER25> I always feel like there is a big misunderstanding of what it means to "write a program in some language" in these types of comparisons.

For example, saying that Python uses much more energy is a foolish thing to say. The "same" algorithm written in pure Python is a very _semantically_ different thing. It involves allocation of flexible objects that obey certain attribute lookup protocols, operator protocols, dynamic attribute mutation / creation, iteration protocols, etc. It is presumed that if you wrote in pure Python, you need this dynamism and ability to introspect at runtime, modify data structure layout arbitrarily, utilize an automatic garbage collector, etc. So you'd need a benchmark test that requires all that functionality before it could possibly make sense to test Python. Otherwise you're penalizing Python for a bunch of expensive overhead, which is totally unfair and foolish because the whole point is that such overhead exists for use cases where either the costs are negligible or the flexibility that necessitates that overhead in _any_ language happens to be a desired and important part, such that to write the same functionality in other languages would first require building all the protocols, garbage collection, etc. machinery that essentially defines Python.

If instead you have some benchmark problem that can be solved in e.g. C or Rust without needing any runtime dynamism or heavy machinery of certain protocols or garbage collection, then to write it in Python you would just write it in Cython or as a hand-made C extension module to specifically bypass the overhead of the interpreter or Python protocols / dynamic lookups / etc.

Basically, it never makes sense to compare Python and C on a benchmark that doesn't require reimplementing most of Python in C first. Because to solve that problem in Python, the ubiquitous, basic, Python 101 way to do it would be to use Cython or numba or write your own extension module.

Python is basically a special C language DSL for dynamic types, garbage collection, and a set of conventions and protocols.

"Pure Python" is a linguistic trick for saying "a huge ton of tools that make C-level polymorphic structs easy to use."

<comment><USER26> Yes except some people are using python where they should be using C++ and powet consumption is a good reason not to use python in these cases.

<comment><USER25> No, it's a good reason to use Cython or one of the many other techniques for generating pre-compiled C extensions in the Python ecosystem. You may also use C++ directly or something if you prefer, but there would not be any performance based reason to do so.

</comment></comment></comment><comment><USER27> Really silly to state how much electricity "languages" use without specifying implementations. You can specify for unstandardized languages, but languages don't have performance characteristics in the typical sense, implementations do, and this can very greatly between implementation.

<comment><USER8> _fyi_

[https://sites.google.com/view/energy-efficiency- languages/se...](https://sites.google.com/view/energy-efficiency- languages/setup)

</comment></comment><comment><USER28> The code size metric was pretty interesting to me. I would have imagined that functional programming languages should lead to the most succinct code. But I was surprised to see Haskell in the middle, and Go at the top there! Functional languages are right in the middle for all 3 metrics.

<comment><USER29> Unfortunately there are no APL/array languages there, they are notorious for being succinct! It's not a stretch to say "lines of code" in most other languages would be close to "characters of code" in APL. It'd be interesting to compare it using the other metrics too.

</comment></comment><comment> forgot-my-pw PHP's performance is quite impressive nowadays. It's one of the top fastest interpreted languages.

<comment><USER30> For how much shit PHP gets, it is a pretty good lang for building things

<comment><USER31> I'm curious: I've used PHP (not by choice) for the past two years and I strongly dislike it. (I could wax eloquent on this subject, but I don't want a flame war. :) What do you see of value in PHP? Is it the language itself? Its ecosystem or community?

</comment></comment></comment><comment><USER32> I'd be interested to know the added energy cost (in terms of programmers) of writing the code in the first place and subsequently maintaining it

* edit- thinking about it it's probably negligable

<comment><USER33> Cost is a good first order proxy for energy used, so this is not negligible if you want to take into account all the energy used by the developer (including home activities).

As for any other product, this is a trade-off between fixed and variable cost: want to do some quick processing on an hourly basis? Just write a quick python script with a Cron. Want to compute something billions of time? Use C or something more modern that compiles. Need even more savings? Build an ASIC doing the job.

</comment></comment><comment><USER34> It would be interesting to match these results to what you get using EO-(efficiency-oriented)languages. (MOQA for example). There's a whole branch of computer science involved in static average-case analysis for algorithms and data structures. The results are 'interesting'.

</comment><comment><USER35> The big surprise for me is where Perl stands in the rankings, below Javascript in all three tests.

<comment><USER31> Amen: I'd have to take a look at the actual code in use.

<comment><USER8> You can, the authors of the paper provide the actual code they used on their website.

</comment></comment></comment><comment><USER36> "On average, compiled languages consumed 120J [joules] to execute the solutions, while for a virtual machine and interpreted languages this value was 576J and 2365J, respectively."

IMHO it's not quite right to evaluate energy efficiency just by looking at the runtime performance. Compiled (incl. JIT) programs have to be compiled. So for compiled programs, you have upfront costs (e.g. rust, haskell much more than c), you would have to include in the calculation. Then you have programs/script that run once (a day maybe). I wouldn't be surprised if taking this into account would change the calculation.

</comment><comment><USER37> They should include Julia in the results.

</comment><comment><USER38> No mention of assembly language, which should be even lower on electricity and RAM usage than C and Pascal.

<comment><USER29> Yes, I was looking for "carefully optimised Asm" on that list too. Even if it's not faster it will pretty much always be smaller. (Compilers are surprisingly easy to beat at size optimisation.)

<comment><USER39> Well -Os can be a bit better. However I doubt program size is very significant compared to data size in Compiled languages by example.

</comment></comment></comment><comment><USER40> Very interesting!

We have wanted to do a similar conversion from the results data in our TechEmpower Framework Benchmarks [1] to energy efficiency. I've wanted to go as far as converting watt-hours to some average carbon emission rate for electricity generation in a given region.

I imagine the carbon emission per request would be amusing, if nothing else.

[1] [https://www.techempower.com/benchmarks/](https://www.techempower.com/benchmarks/)

</comment><comment><USER41> Aren't the savings more in the type of application? For example, driving users to addictive content makes them use their phone more. Also, Bitcoin comes to mind.

<comment><USER42> To me, the amount of electricity used is a similar issue to RAM. Just because we have computers with more RAM does NOT mean programs NEED to use that RAM. So many applications right now that don't need as much memory as they are using but, whether it be lazy or poorly planned code or any other excuse, they guzzle it up like they are the only application running on your device.

I'm all for figuring out what's the most efficient option while also ensuring it's an effective one as well. If you kept a knife in its sheath to keep it nice, but never take it out to use it, then it's not servicing its purpose as a tool (ignoring ornamental ones). However, no matter how cool it might seem, you really don't need a samurai sword to pear apples.

</comment></comment><comment><USER29> _But at the same time, when manipulating strings with regular expression, three of the five most energy-efficient languages turn out to be interpreted languages (TypeScript, JavaScript, and PHP), "although they tend to be not very energy efficient in other scenarios."_

I believe that's because they're all using a regular expression library which is probably written in C/C++, maybe even with some pieces in optimised Asm, so none of the _actual_ RE-work is being done in the interpreted language itself. If you wrote actual RE processing in the interpreted language and let the interpreter interpret/JIT it, I bet they would be as (in)efficient as the "other scenarios" where the "heavy lifting" is running through the interpreter.

</comment><comment><USER43> Hope that the cloud providers don't bill according to energy consumption. I like Python a lot...

<comment><USER44> They already do, in the sense that you'll need beefier/more machines to do the same job.

Of course, using Python means you have a lot of low-hanging fruit to pick. We have a Python service where we moved ONE ~60 line recursive function to Go and overall CPU consumption dropped to 15-20% of what it used to be.

<comment><USER45> That sounds pretty damn nice - would you happen to have a good link in mind for reading more on the subject?

<comment><USER39> What's interesting is also how go and python interaction is since you seem to be able to call go from python and the reverse very efficiently.

<comment><USER44> Sorry but we actually cheated on that part. Redid the page so that the function that is now in Go is a separate little service that is called via ajax directly by the users' browsers.

So there's no actual Python-Go interaction in our code.

This was quicker, cleaner and has made the page more responsive for users.

<comment><USER39> Thanks this comment is useful, client side integration is integration after all, and I think if it was simple, you would have it done differently (if I understand your words correctly - "cheating").

</comment></comment></comment></comment></comment></comment><comment><USER46> I really wonder that FORTRAN is so bad - I think that they didn't try good compiler, like Intel's

<comment><USER8> _fyi_ ifort 17.0.3

[https://sites.google.com/view/energy-efficiency- languages/se...](https://sites.google.com/view/energy-efficiency- languages/setup)

</comment></comment><comment><USER47> Can anyone extract what the impact of a JIT compiler is on these figures? The initial performance hit is eventually eroded by the runtime optimizations, so will a long-running Java program eventually close the energy performance gap on a C program?

</comment><comment><USER48> Which lisp? Those numbers don't seem right from my experience with SBCL.

<comment><USER49> The data for the paper the article talks about is online [1], and it says [2] that the benchmarks are "implemented in 28 different languages (exactly as taken from the Computer Language Benchmark Game)".

The LISP evaluated by the Benchmark Game - and, apparently, this paper - <USER2> indeed SBCL [3], which seems about on par with Java.

"Lisp, on average, consumes 2.27x more energy (131.34J) than C, while taking 2.44x more time to execute (4926.99ms), and 1.92x more memory (126.64Mb) needed when compared to Pascal."

[1] [https://sites.google.com/view/energy-efficiency- languages/ho...](https://sites.google.com/view/energy-efficiency- languages/home)

[2] [https://github.com/greensoftwarelab/Energy- Languages](https://github.com/greensoftwarelab/Energy-Languages)

[3] [https://benchmarksgame- team.pages.debian.net/benchmarksgame/...](https://benchmarksgame- team.pages.debian.net/benchmarksgame/faster/lisp.html)

<comment><USER50> I think this is what is so cool about Common Lisp. You can literally get pretty darn close to C in performance and still be at the highest levels of development efficiency/prototyping speed. I don't think too many other languages can say so. Take Python. It has really fast development time, but very slow performance.

</comment></comment></comment><comment><USER51> C and Haskell were about what I expected, but those Pascal results have me scratching my head, given that it performed about as well as C and used even less RAM.

<comment><USER52> Pascal and C are roughly equivalent in my eyes, at least as far as what they spit out in the end. Both have pretty similar feature sets and development methodologies.

What surprised me is how much of a hit the OO programs took. I had thought they would compile down to something reasonably similar to the imperative languages, but C++ ended up being 50% slower.

</comment></comment><comment><USER53> So Rust is a little bit more efficient then C++. That's kind of surprising. And I knew Lisp was fast but I am still surprised it scored so high.

</comment><comment><USER54> How does "TypeScript" come out to an energy score of 21.50 when "JavaScript" has a score of 4.45 - that makes 0 sense.

<comment><USER18> maybe they included compilation? it would make sense as that's a real world use of cpu/memory/energy.

<comment><USER54> But it certainly looks like they didn't include compilation time for all of the compiled-to-machine-code languages. C has the reference value of '1'.

<comment><USER52> I think they included compile time if the code is JITed at startup.

</comment></comment></comment></comment><comment><USER55> > We then gathered the most efficient (i.e. fastest) version of the source > code in each of the remaining 10 benchmark problems, for all the 27 > considered programming languages.

I wonder if anyone has attempted to rate how idiomatic or typical CLBG entries are, and whether choosing the most idiomatic implementation for each language would have obtained different results?

</comment><comment><USER56> I improved Rust's version of binary-trees by about 0.05s (on my CPU): [https://salsa.debian.org/benchmarksgame- team/benchmarksgame/...](https://salsa.debian.org/benchmarksgame- team/benchmarksgame/issues/113) , so Rust score may rise.

</comment><comment><USER57> I'm a little surprised at where Erlang features in the list. I've never used it personally, but have heard so much about it being an amazing, performant language. I wonder why it's so time/energy/memory inefficient for the algorithms used in this exercise.

<comment><USER58> BEAM has a 'busy wait' feature. Schedulers with no jobs to do will remain active so they can respond to new jobs faster. You can turn this down so that the schedulers go to sleep quicker, reducing CPU usage.

From [http://erlang.org/doc/man/erl.html](http://erlang.org/doc/man/erl.html):

      +sbwt none|very_short|short|medium|long|very_long

      Sets scheduler busy wait threshold. Defaults to medium. The threshold
      determines how long schedulers are to busy wait when running out of work
      before going to sleep.

<comment><USER57> Interesting. Have you ever used Erlang in production? How did you find it?

<comment><USER59> It's pretty obvious if you're running RabbitMQ which ranks highly in the output of `top` even if no messages are being processed.

</comment></comment></comment></comment><comment><USER60> I did not expect Lua to be that far down the list. I thought Lua was a go to choice for scripting embedded software. Also, I'm not surprised that JavaScript outperforms most of the other scripting languages (according to this potentially erroneous benchmark).

<comment><USER61> I also was disappointed that my favourite language did so poorly in these tests - I wonder, though, what the stats would have been like had LuaJIT been factored in. Perhaps something for future evaluation ..

</comment></comment><comment><USER62> "Of the top five languages in both categories, four of them were compiled. (The exception? Java.)" and "While Erlang is not an interpreted language." Had to check Wikipedia to make sure I haven't become crazy.

</comment><comment><USER63> Is JIT, interpreter and VM startup time included? Some benchmarks finish in just a few seconds. With Python for example just launching the process takes in the order of 100ms, which would be significant time in such short benchmarks.

</comment><comment><USER64> For example on a server the CPU will likely be set at full thrust even if it has nothing to do. So I don't think this matters until you need to scale, where you would need less servers/power with a more optimized program.

</comment><comment><USER65> Are they counting the electricity used to heat the pizzas that feed the programmers?

<comment><USER52> This was said half in jest I suspect, but it's not a completely off the wall concern. For an infrequently used program the energy burned in its development could easily be a nontrivial amount of the total energy used over its lifetime. If you can write a 5 line Perl script that gets the job done (and is only run a couple dozen times ever), then you're probably saving energy over the 100 line C program despite the massive differences in runtime energy consumption.

<comment><USER65> Phew, somebody gets it.

</comment></comment></comment><comment><USER66> The language which uses the least energy is the language no one writes programs in.

</comment><comment><USER67> Question: if these were run on underclocked hardware, would they use less energy? It seems like you'd need an increasingly large amount of energy to run something in a smaller amount of time.

</comment><comment><USER20> No Julia or Crystal, that's disappointing.

</comment><comment><USER68> YMMV. Our experience with Go vs Java showed we could run the same workload on far fewer machines using Go than Java.

</comment><comment><USER69> So do we think Java is benefiting from J2ME and Android research? Is it just a coincidence?

</comment><comment><USER70> How is JavaScript so far up the list? Slack commits murder on my MBP battery every day.

<comment><USER71> Using [https://github.com/xtermjs/xterm.js](https://github.com/xtermjs/xterm.js) as an example (the terminal used in vscode), they draw on a canvas to achieve better rendering in the browser. So I guess not javascript is the cpu hogging bottleneck, but the complexety of html/css. There are just too many footguns that slows down the rendering. If there only was something like "use strict" for html/css.

</comment></comment><comment><USER72> The heavily parralelized C in the language shootout is not how most code is written.

Rust was specifically created to use the paralell hardware resources well, and it excels at it.

</comment><comment><USER73> No COBOL?

<comment><USER74> Seeing to the amount of transactions running over cobol it might deserve a place in a list like this.

<comment><USER75> If you're still using COBOL, power usage is likely very low on your list of concerns

<comment><USER74> No? Just about any financial transaction, insurance calculation and a lot of telcos operations run mainly of cobol.

Something like 90% of all credit card transactions.

<comment><USER75> You can throw money at electricity use, and COBOL is compiled to machine code so the power usage is much less of a concern than it would be in an interpreted language.

Much higher on the list of concerns is finding capable COBOL developers, ongoing maintenance, and security. Those are all things that you can't just throw money at.

</comment></comment></comment></comment></comment><comment><USER76> > Of the top five languages in both categories, four of them were compiled. > (The exception? Java.)

Java is also compiled.

</comment><comment><USER77> Assembly language is the lower bound here. This is a 100% correct fact that nothing can use less energy than assembly language. No such statement can be made about other languages.

<comment><USER78> Not necessarily. Sometimes compilers give better programs than a programmer can with optimization and stuff.

<comment><USER77> Right but if I write a program that converts code into assembly and does the optimizations automatically then I can get something better or equal to a compiler.

<comment><USER79> Isn't that exactly a compiler?

<comment><USER77> Yes. And all of my statements are 100% correct except for this one.

</comment></comment></comment></comment></comment><comment><USER80> This study is a bit silly, I had to check whether it was an April Fool's joke. The chipset running the instructions is going to have a far higher impact on energy usage than the language compiling those instructions.

For instance, switching to ASICs or even FPGAs that are optimized to handle certain types of computations.

Just look at datacenters or mobile devices. Sure, optimizations are made to runtime environments to improve performance, and increase battery life. But you are going to see bigger gains through chip architecture. And that is what vendors focus on.

<comment><USER80> To the naysayers: these languages are either compiled, or will be JIT'ed at runtime. What they will be compiled to will be chip specific binaries-- x86, ARM, whatever. The energy usage will be markedly different depending on which chip architecture is chosen, and will no doubt be inconsistent between different architectures and languages.

Or to put it another way. Why do you think mobile devices almost exclusively use ARM? Why do datacenter operators invest heavily in R&D for ASICs instead of engineering new languages or runtimes? Because languages play a secondary role in energy consumption.

This study is just like countless of other meaningless benchmarks seen in language war flame posts. Pointless and misses the big picture.

<comment><USER81> With regard to datacenter operators, I would argue that a simpler answer to that observation is that they are investing heavily in the are in which they can actually effect change. That is, they can swap in-and-out their hardware, but language of choice is largely up to their customers - the dev. They can advocate and champion a particular language, but really enforcing it in any meaningful way is narrow casting their own user base.

<comment><USER80> They could offer their own compilers or runtimes. Some big companies do. But most dollars and time is spent on hardware R&D and upgrades.

Facebook and Google both have in house chip designers these days, specifically for their data centers.

</comment></comment></comment></comment><comment><USER82> very stupid but clickbaiting question... everything wastes everything...

<comment><USER83> What does "everything wastes everything" mean?

</comment></comment><comment><USER84> Now, seriously: C and the boogieman of managing your own memory is a myth. Anything you want from another language can be built up from C, and be in your direct source code control working in C. Far too much propaganda is written telling programmers perfectly capable of the gains from working in C that they should be afraid of working with their own memory allocations. As if being organized is impossible.

<comment><USER59> Language runtime analysis for server-like programs seems obsessed with putting everything into a single process and address space. With C/Unix, traditionally or at least since inetd, the way to go is start a fresh process per request, which mostly just solves the problem of manual memory management (eg. because the O/S clears up the mess you left behind), at the price of latency. I'd like to see a benchmark comparing these approaches, since gc is far from being free of overhead either.

<comment><USER85> How would that prevent any of these CWE-415 or CWE-416 vulnerabilities?

[https://www.cvedetails.com/vulnerability- search.php?f=1&vend...](https://www.cvedetails.com/vulnerability- search.php?f=1&vendor=&product=&cveid=&msid=&bidno=&cweid=415&cvssscoremin=&cvssscoremax=&psy=&psm=&pey=&pem=&usy=&usm=&uey=&uem=)

[https://www.cvedetails.com/vulnerability- search.php?f=1&vend...](https://www.cvedetails.com/vulnerability- search.php?f=1&vendor=&product=&cveid=&msid=&bidno=&cweid=416&cvssscoremin=&cvssscoremax=&psy=&psm=&pey=&pem=&usy=&usm=&uey=&uem=)

Pedantic note: quite a few of these vulnerabilities don't technically contradict the GP's claim because they're in C++, not C, but I hope there are enough C ones to disprove the point.

</comment></comment></comment><comment><USER86> Not sure how serious they think this is, and how much is this rather a joke. If it's not a joke, they clearly not see the big picture. For example if you can write a software in a higher level language in a fraction of the time which will spare energy somewhere else in the world, it will use less electricity overall.

<comment><USER14> How does less dev time save energy "somewhere else in the world"?

Google & AWS pay money to develop & acquire technologies that save energy because of their scale. The energy used in dev is scratch compared to the energy used to run programs at scale. Google, for example, has a PHP compiler that makes all PHP web pages execute in a fraction of the energy usage of running the PHP interpreter.

<comment><USER87> ...Google has a PHP compiler? Don't you mean Hack/HHVM by FB?

<comment><USER14> Nope, I don't mean HHVM. I was thinking of Talaria. I don't know if they still use it. [http://enswmu.blogspot.com/2013/03/why-google-acquired- talar...](http://enswmu.blogspot.com/2013/03/why-google-acquired-talaria- efficency.html)

But HipHop is certainly another good example that demonstrates that this matters in practice.</comment></comment></comment></comment>


Ethercodes is a crossbreed between Etherpad and Skywriter for collaborative code - <AUTHOR> http://ethercodes.com/

<comment><USER2> I don't understand...isn't Skywriter (previously Bespin) supposed to support real time collaboration on its own?

[http://benzilla.galbraiths.org/2009/08/13/collaborating- with...](http://benzilla.galbraiths.org/2009/08/13/collaborating-with-bespin/)

</comment><comment><USER3> FYI there are grammar and/or spelling errors in most frames of the slider:

"We care about codes highlights as much as you, major languages are here, even more are comming!"

"Crowd coding, bring all peers immediately with simply a URL , in ignorance about Emacs zealots or Vim stickers, watch every others' each single scratch in truly real-time."

</comment><comment><USER4> This would be amazing if it attached to interpreters for appropriate languages.

Collaboratively editing code _and_ seeing the runtime, even if it only supports the console, would be extremely useful.

For pure HTML, a window containing the document rendered in realtime would also be very beneficial.

</comment><comment><USER5> "Your web browser is not supported by EtherCodes"

Fine I didn't want to see you site either.

<comment><AUTHOR> Internet Explorer is the new Linux. Sweet sweet justice.

Works in Chrome/Firefox in Ubuntu

</comment></comment><comment><USER6> Tried in in both Firefox and Safari and got the 'we don't support your browser' dialog even though my version numbers were higher than the ones they gave.

Perhaps it is not ready for prime time?

</comment><comment><USER7> This is a great concept, but I would love to see it implemented as a plugin for Visual Studio or Eclipse, not a new IDE.

</comment><comment><USER8> Page is too wide for my perfectly reasonable browser window.

<comment><USER4> And too narrow for my maximized browser. The default view is only 70 columns. In fact, the help text on the command-line extends off the right edge, with no horizontal scroll, so the shortcut keys are all cut off.

Why not simply scale to the width of the user's browser window?

</comment></comment><comment><USER9> Who's idea was it to use Papyrus in the homepage slider?!

</comment><comment><USER10> Is it just me, or does this thing hate FireFox?</comment>