Ditching responsive design - <AUTHOR> https://gocardless.com/blog/unresponsive-design/ <comment><USER2> This post is somewhat odd, because their site design is so clean and simple that it seems like an easy candidate for RWD. I don't really see how this design is unconstrained compared to what they'd be able to implement if they used a responsive design.

As far as RWD taking twice as long to design and implement, perhaps this is just a question of experience. Once you've had some practice with RWD, although it does take some extra time, I don't think double the time is typical.

The argument that only a few of their customers are on mobile is the strongest reason presented not to use RWD, but the question I would be asking is, "Is this situation likely to remain that way? Will mobile users only ever be 2% of our traffic, or can we expect that this proportion will climb?"

Personally, I would expect that this proportion would in fact increase over time, but I don't have a crystal ball and can't say this for certain.

<comment><USER3> Building responsively is an investment for the future. You can bet good money that there will be more and more diversity of screen sizes as we keep going.

I'd be interested to learn more about their design and implementation workflow, that they mention RWD taking 'almost twice as long'. How much time are they wasting building static comps that illustrate a picture of what some people will see when they come to their website? This is speculation - I don't know how much live prototyping they do in their design process.

I'll have to mention Edit Room again, my web design tool that makes creating responsive, multi-screen web layouts as easy as dragging things around on- screen. If you start your design work in the browser, you save so much time that lets you go that extra 10% on a design. That gives you the time you need to make your designs work everywhere.

<http://www.edit-room.com>

<comment><USER4> I agree that the estimate of amount of time it takes to make their site responsive seems high to me. Even if it's not perfectly designed it's better than not being responsive at all, and getting it pixel perfect will probably be cheaper and reasonably performant as designing a mobile-only experience.

However I disagree that making a design responsive today is an investment for the future. Designs change much quicker than demographics, so if they don't have significant mobile traffic today it's unlikely they'll have it during the lifetime of the design.

</comment></comment></comment><comment><USER5> The popular interpretation of responsive web design has been, I feel bastardised. It's not just about a fluid grid with break points in your CSS to move things around depending on the size of your viewport.

It should be much more about how system responds to where, how and why it's being used. That might well mean apapting the layout to fit a smaller device, but equally it could mean things like presenting considered controls to touch devices, offering geo-aware information, changing content to user patterns etc.

The term itself is derived from responsive architecture which is defined thus:

 _Responsive architectures are those that measure actual environmental conditions (via sensors) to enable buildings to adapt their form, shape, color or character responsively_ <http://en.wikipedia.org/wiki/Responsive_architecture>

Go Cardless have made the right decision for them about layout, but I can't help feeling that they're setting the conversation about RWD back.

</comment><comment><USER6> >For our new design, we decided to stick to a fixed grid of 980px.

Yep, this is what I've been doing for a while now. Looks great on desktops, and looks great on iPad devices and tablets.

Responsive sounds good on paper, but when your 1 person in a team of 2 startup, you can't afford to waste time like that building something truly flexible. Not worth the time investment.

Again: MEASURE your audience. If your mobile visitors are a small percentage, it ain't worth it. Let them pinch and zoom.

<comment><USER7> How does a 980px grid look good on a 768px-wide screen?

<comment><USER6> My answer to those people, "Deal with it."

My analytics on my sites have shown people with screens smaller than that are in the very very small minority.

<comment><USER7> I just asked because you specifically mentioned iPads, and 2 of the 3 models on sale today are only 768px wide.

</comment></comment></comment></comment><comment><USER8> Personally, I have to disagree with their reasoning. No, I will often not use their service from my phone, but what if I'm surfing on the bus and want to look at their pricing or features? On my iPhone, which has a relatively small screen, I'd be almost out of luck. I would either have to hope Safari Reader or Pocket could pick out the text, or deal with scrolling back and forth. Normally, I'd just leave and likely forget about their service.

Which is kind of why I decided to use responsive design completely on ThreeBar (<https://threebar.net>). In fact, not only are the static pages responsive, but the _entire_ administration dashboard is responsive as well, so users of the service can actually manage their entire account on their phones if they wish. Often, I want to check analytics from my phone, and with this design I can do that. In contrast, my original prototype design was _not_ responsive. It made the site impossible to show off on my phone to anyone who was curious, and there was no easy way to read the text.

It isn't perfect on mobile, but it does give a slightly better experience when just casually surfing, and it's worth it to me-- even if it only affects 2%.

<comment><USER3> Great points. Also you never know who's in that 2% of visitors - they may be your most important next customers!

</comment></comment><comment><USER9> Great post and great reality check. If the data really showed that people shopping for Direct Debit do so from the desktop then this makes a tonne of sense.

There is a certain mob dogma that occasionally overwhelms the design community. The passion around responsive design today reminded me of the heated advocacy of accessible design back in 2004. It was a good thing and opening up the web to more people and especially people who are isolated in the outside world is a wonderful thing.

When a site or a service isn't yet fully formed and doesn't know what it is or who exactly wants it, "enabling it for everyone" can accidentally be paid for by "making it appealing to no-one". You need to start by figuring out why people want to go into your site and once you know that, let more of them in.

Some sites which are already useful can best improve themselves by making themselves available to more people on more devices. During the teenage self- discovery phase though, when a service is still learning who its customers are and what it itself is, there's no point optimising that for everyone because it could be different tomorrow. The important thing is to first of all find out what is right.

</comment><comment><USER10> 980px is annoying.

I for example use at night as my "laptop" a cheap tablet with keyboard, it is 800px wide.

Also 980px also will suck for people with VEEEERY WIIIIDE monitors.

Or apple retina (that has absurd resolution, thus resulting in their site becoming very small and unreadable).

<comment><USER11> It also sucks if you don't use a maximised browser window.

<comment><USER12> Exactly! I normally run two browser windows side by side on a 1600px wide screen. I generally don't go back to sites that force me to resize my browser in order to view them correctly.

</comment></comment></comment><comment><USER13> I can see where they are coming from, but I think they're missing the point of RWD completely. Responsive Web Design is more than ensuring your site looks good on a mobile screen, a truly responsive site will not only scale down but also scale up for larger screens as well. They mention using a 980px grid, The Semantic Grid System (<http://semantic.gs>) sounds like a perfect candidate for this. You set your column width and gutters and it handles the rest for you, set the container width to 100% for fluid and BAM! you've got a responsive site that only needs minimal work.

The difficulty of responsive web design is way over-exaggerated. A decent web developer shouldn't take any longer than an extra day (if that, just a few hours) to make a grid based responsive site. I feel as though it's embedded in my developer workflow so much so I don't think it makes things more complicated having a responsive aspect. It's never taken me double the time even when I first started building responsive sites, another exaggeration. All you need to do is divide the width of an element by it's parent container and multiply it by 100, the same can be applied for left and right padding and margin values as well.

Another thing about RWD is if you're doing it for the sake of a good mobile experience you've already failed. Shrinking a site down doesn't reduce the overall page weight. An iPhone will still load stylesheets, Javascript files and other unneeded bloat you're hiding with a display:none; so the experience can sometimes be extremely cumbersome for a mobile user as opposed to building a separate mobile site. Having said that, making an already relatively light page respond to a smaller screen is acceptable.

PS. Don't forget to set max-width:100% and height:auto on your images as well!

<comment><USER14> I think you may be missing some of the difficulty in RWD. The hard part, as you said, isn't implementing a few media queries and resizing stuff. That is easy, you're right.

The hard part is the _design_. If you need to shrink an element down 50%, is it still readable? Crisp? Does your logo do well under that kind of pressure or does it become a blob of color? If you blow it up and make it 100% on a large screen, how are you handling the columns of text? Because of course you're not just letting text lines expand indefinitely, right? Because that would be a readability disaster.

Those are just a couple examples of where an overzealous programmer can get the design totally wrong by implementing the "easy fix." RWD is still pretty hard to get really right.

</comment></comment><comment><USER15> This post kind of annoys me actually. The only actual legitimate reason on here not to pursue responsive is lack of mobile audience. The rest are problems with not knowing what the hell one is doing. OF COURSE YOU'RE SUPPOSED TO DO APPROPRIATE DESIGNS FOR YOUR MARKET, ALSO SKY IS BLUE. And while your mobile audience is low now, you sure aren't going to fix that by ignoring that audience. Now this product, perhaps that's okay. It really is okay for everything not to be responsive, but the title of this article would be more accurate if it were "we ditched responsive because we couldn't figure it out."

<comment><USER16> _The only actual legitimate reason on here not to pursue responsive is lack of mobile audience._

Or having a separate webapp. There are numerous times when that is the more appropriate response, even if it involves more work.

</comment></comment><comment><USER17> I'm on a Retina Macbook Pro 15" set to use "Best for Display" I use my web browser on 25% of my screen via window snapping. Here's what I see now on their website:

<http://imgur.com/0xy16xo>

...and the navbar does not scroll with the content, so I can't even click "Sign Up" if I wanted to!

It's also inappropriate to disregard 2% of your audience unless you have analytics proving that this minority is opting not to convert specifically. What if your conversion rate is ONLY 2% and there is a corollary?

<comment><USER18> why are you putting a browser into 25% of the screen? Also, on a 15 inch screen a retina resolution of only 1440 x 900 is pretty crazy. slide it up to the next notch on the scaling in display preferences - i love 1680 x 1050 on mine.

<comment><USER19> >why are you putting a browser into 25% of the screen?

Because that's how he wants it? I do the same thing, my web browser exists to retrieve information from web sites. Having it take up my entire screen would be a hindrance. People who foolishly assume that because I have a high resolution display, that my browser must also be that resolution are, quite frankly, incompetent. This is web design 101 stuff, nobody should be working in a professional capacity that thinks a fixed resolution website is acceptable.

<comment><USER18> Well would your argument stand if I said i have my browser filling 5% of my screen? responsive design is useful, but designing for majority screen resolutions is just good business sense. How far do you take responsiveness? 100px wide?

<comment><USER19> >Well would your argument stand if I said i have my browser filling 5% of my screen?

That depends how big your screen is.

>responsive design is useful, but designing for majority screen resolutions is just good business sense.

And limiting your site to 960+ is a pretty dumb idea for that reason. A quarter of my monitor is 800 pixels wide. That is an entirely usable size, and any decent website works fine in it. It is especially dumb to break a website for people using <960px browsers when the website in question is incredibly simple and could easily work in a 300px window.

</comment></comment></comment></comment></comment><comment><USER20> It's perhaps interesting to note that at the size I run my browser (half my screen horizontally), the 'Sign Up' button is cut off - maybe responsive is slower to implement, but at least it makes you think about issues like that before launching your new site.

<comment><USER21> I have the same browser setup and a majority of the sites I visit have cut off edges (I have to view most at 90% zoom). Saying that, I'd rather view at 90% than be greeted by a site like FOWD - <http://futureofwebdesign.com/london-2013/>

</comment></comment><comment><USER22> Why not use something like Foundation that helps you with this, rather than a static 980px?

</comment><comment><USER23> When thinking about these two options, responsive vs. not, I try to pull myself away from the developer or designer roles. If wearing either of those two hats one might be tempted to become an evangelist for responsive design because, among other things, it's an interesting challenge. Intellectually stimulating challenges do drive decisions sometimes.

What I do is put on a business hat and think in terms of actual benefits. An, in my not-so-humble opinion, responsive design doesn't really mean greater revenue. Here "responsive design" means a site where elements squeeze, move, re-align, collapse, etc. as you grab the sizing handle on your browser window and shrink or expand the browser canvas.

Why do I think this way?

        www.ebay.com
        www.craigslist.com
        www.nytimes.com
        www.latimes.com
        www.ticketmaster.com
        etc.

Of course, there are plenty of examples for responsive design. Amazon uses a mild form of it and it works well.

IF responsive design were critical to keeping or increasing interaction or revenue all major sites would be using it today. I think it might be safe to say that the vast majority of the top 500 sites use fixed designs.

This doesn't mean that you can't have one or two alternative CSS layouts for mobile viewing. That might be the smartest approach: one fixed design for desktop and one fixed design for small screens.

With this, if you have the traffic, you can A/B test and slowly optimize each fixed design to improve conversions. With responsive design you might have to optimize over a dozen layouts, which is a huge job.

Again, in the end, I think that considering the options from a business perspective can cut through the crud and cause one to focus on what really matters if you don't have a hobby site.

<comment><USER24> I would argue that just because those fixed-width sites you mention aren't currently responsive doesn't mean that they never will be, or aren't currently in the process or being developed. It is certainly no trivial task to develop a responsive version of a site like eBay.

Even though RWD is a relatively new concept for a lot of people, I think we are past the "It's a fad!" phase (despite the small amount of middlebrow dismissal/stubbornness that is still evident), and I think it's encouraging that there are a lot of major companies embracing the approach. I made a quick list off the top of my head below.

      http://www.time.com
      http://bostonglobe.com
      http://www.vogue.co.uk
      http://www.starbucks.com
      http://microsoft.com
      http://disney.com/?intoverride=true
      http://www.about.com
      http://www.sony.com

<comment><USER23> There are always at least two sides to every story.

I guess the point I am arguing is that I don't think responsive design makes you any more money than fixed design. If it did organizations such as eBay would have certainly made the move by now.

At some level --at least for me-- if it isn't going to generate more revenue it isn't worth the extra effort.

Clearly I don't have any data to back-up my claim so we'll have to leave it as conjecture at this point. I can't say either way. Just a hunch from observing what's going on with top-level sites both as a developer and a user.

I equate this to the whole 3D movie/3D TV fad. Yes, this is probably a bad analogy. The point is that 3D has always been a fad. It comes back every N years and everyone proclaims that "this is what it will take off". Film producers get all hot-and-bothered and jump on the 3D bandwagon and forget why people go to see movies: The story. A 1940's black and white movie with a great story will always do better than a new film with a bad story, no matter how much tech, 3D and special effects you throw at it.

I guess what I am saying is that content is far, far more significant than design gimmicks. Customers don't come to your site to be in awe of your engineering or design chops. Craigslist proved that point long ago. No, they come to your site for the value they may be able to derive from it. Good relevant content and great value are at the top of the list. Ease of use and security may be second. Beyond that, everything else is optional and, in my book, can only be justified if you can show that it can improve conversions relative to other approaches.

As I said before, one of the reasons I currently tend to reject the idea of responsive design is that it can create a situation where site optimization becomes a geometric problem. Now you have a dozen layouts per page to optimize vs maybe two. I've seen some really amazing optimization reports where things as simple as the position and size of elements have made a huge difference. I am not sure how you'd even begin to approach that with responsive design when you've introduced so many additional variables in to what --in the cased of fixed design-- was so simple.

</comment></comment></comment><comment><USER25> If your last site design was responsive without looking at analytics, your first error was not making a data driven decision.

If no data existed, your product guy should have asked himself when was the last time he evaluated and purchased a financial services product from his phone. And asked people around you... answer probably would have been close to 0.

What should be responsive is your customer account center where a user will want to sign in and check their balance while standing at a cash register about to check out. And they might not have your app yet, nor want to download an app.

I think it would serve you all well to compile user-stories the next time you redesign anything, whether its your marketing site or account center.

On a related note, I think yalls acquisition designs look very nice. Props.

</comment><comment><USER26> Only 2% of their traffic is mobile? Surprising in the modern world. So they are a statistical outlier.

For most sites using tools like Bootstrap, etc. to make responsive sites using media queries should in my opinion be the default strategy.

<comment><USER27> Most people visiting our homepage are small business owners looking for a new payments solution - this is typically done from the office, behind a desk.

By way of comparison, we also host payment "checkout pages" which allow these merchants to accept payment from their customers. These customers are much more likely to be using mobile devices, so we spent a lot of time making these checkout pages responsive & fast-loading by stripping out unnecessary javascript & other assets etc.

You can see an example of the checkout pages here; <https://gocardless.com/example-checkout>

<comment><USER17> I'm a decision maker on products like this and in my case much of my new product research is done initially from bookmarks I check out from my Galaxy Note II while horizontal on my couch at home.

A site that adapts to whatever form factor I'm on screams "current technology" to me and delivers the expectation that the product its selling probably has equal attention.

In a similar vein, how likely would you be to rely on shopping cart technology if the company's website had the old "Built for Internet Explorer" animated gif from the Geocities days displayed prominently on its front page?

<comment><USER28> On the other hand, as someone who is also a decision-maker and currently integrating with GoCardless, we have been far more interested in what _our customers_ are going to experience than in what we see ourselves.

I'm going to give GC a free plug and say that so far what we've seen on the information and back-end pages has also been nicely done, and as the guy using it and juggling many other things as well I do appreciate that. But they're also a relatively young business, and if they have limited resources and need to prioritise, I'd definitely prefer they prioritise improving the experience for my own paying customers than for me as the admin guy.

<comment><USER17> I couldn't agree more. But what I gather from the article is that they actually went back and started over and eschewed the design they already had...

As a non-customer of theirs, I'm speaking from an impressions point of view. Any new service I look at I am weighing my decision to dig further based on the presentation of their product. Having it be too "markety" is just as bad as having an e-brochure that looks 10 years old.

There is balance in everything.

</comment></comment></comment></comment></comment><comment><USER29> As a user, I typically dislike responsive design on anything other than email/blogs/news/text heavy content. Usually when I visit a business/service site the first thing I look for is the "full site" link. Sometimes if I can't find it, I just bounce.

I actually find it more inconvenient to be served a dumbed-down version of the site just because I'm on mobile/tablet, when really I have a fully capable browser. I don't know if my preference is (a)typical.

</comment><comment><USER30> I'm sorry that's a big step backwards.

At a minimum you should have incorporated an adapative (which is what most people actually mean when they say responsive) grid like <http://www.getskeleton.com/> into your redesign process.

Does it take a bit longer? Of course - but not much longer. Sounds like you're just copping out of investing the time to implement this stuff properly.

<comment><USER31> When you run a business you have to make decisions about where to invest your time and these guys found that the extra time was not worth it for their particular business. It has nothing to do with "copping out".

</comment></comment><comment><USER32> I don't agree with those reasons at all. It looks like they tried to build their mobile site by just downsizing their desktop site instead of going mobile-first. And yea, not everything is easy and stuff may take a bit longer, but next time and the time again you get faster and faster.

Doesn't seem like that innovative of a company with a post like that.

<comment><USER33> Responsive design isn't an "innovation". It's a presentation shortcut. 1 data source, multiple views. Considering how little of my career the idea of responsive design has even been around let along appropriate (say the 6 months to a year out of 15) I can't actually believe that the comments here so far seem to assume that responsive is the defacto approach when it's solving a problem that doesn't really exist by using a solution more complex than is needed.

</comment></comment><comment><USER34> Responsive is a great tool, but it isn't a solution for every problem (or a necessity). Too much dogma around at the moment; not _every_ part of every web-property your company owns has to be responsive (but obviously optimise the right bits for mobile - namely checkouts)

</comment><comment><USER35> Responsive design is "hard" as in, it takes effort. It might be worth doing for some sites and maybe less so for others. It's a question of priorities.

The bigger ongoing question is not up front cost, it's maintenance. Responsive design might get you device support across bigger or smaller devices over time without going back to specifically support them, as people are doing now to support mobile and tablet.

We don't know what people will be using even in 5 years... iPad is what only 3 years old?

Not everything needs to be responsive or perfectly responsive, but getting the best experience to your user on whatever platform THEY are on will always be the name of the game (otherwise nobody would support IE 6, 7, or 8).

</comment><comment><USER36> Responsive design sounds like a glorified switch clause: instead of making good fluid design which scales you essentialy fork your webpage design into multiple versions, and swap between them based on screen size. Seems like a bad idea to me.

<comment><USER19> It isn't, some people just do it that way. Competent web designers have been doing fluid designs that work at any resolution for over a decade already. Those also qualify as responsive, not just the stupid grid nonsense people are obsessed with.

<comment><USER24> Not really. What you are describing is commonly referred to as 'liquid'. See here for the difference between the terms responsive/liquid/adaptive (<http://liquidapsive.com/>).

There is a lot of misinformation/misunderstanding surrounding responsive web design, coupled with a decent amount of middlebrow dismissal. It is not simply just shrinking the page down.

And the use of media queries, or 'stupid grid nonsense' as you call it, is just one piece of the puzzle.

<comment><USER19> Your interpretation of what I wrote, and what I actually wrote share very few similarities.

>See here for the difference between the terms responsive/liquid/adaptive (<http://liquidapsive.com/>).

That website has no authority over the term responsive. That is precisely the nonsense I am saying is wrong. Responsive is not defined as "having several fixed layouts and choosing between them". Responsive is defined as "responding to the environment and conditions to customize the behaviour". This encompasses correct web design.

>And the use of media queries, or 'stupid grid nonsense'

Media queries have absolutely nothing to do with grids. We use media queries all the time, every single site we have uses them in fact. We have no grids anywhere.

</comment></comment></comment></comment><comment><USER37> > Mobile visitors often have a very different set of objectives for visiting > your site.

In my experience, this is not true anymore and continues to be less and less the case. I thought this was the case before I started really using a smartphone. Now I want to do exactly the same things than on a desktop computer and the best mobile sites are the ones that let me do everything I do on a larger screen and make me forget that I'm using a different device with less comfort.

</comment><comment><USER38> >> _responsive designs took almost twice as long to design and implement compared to fixed-width designs. This was valuable time we could have spent improving other areas of the product._

Does this include time to implement + time to write blog post about why you did it? :)

I jest, but as screen size variation isn't resticted to mobile devices I tend to go at least "semi responsive" from 1140 to perhaps 800 (<http://cssgrid.net/>)

</comment><comment><USER39> "I cant accomplish structuring my content for mobile audiences so I'm going to give up and write an edgy post to put on hacker news."

Try harder.

Edit: Try starting with mobile first and maybe your content strategy will be stronger for everyone else: <http://www.abookapart.com/products/mobile-first>

</comment><comment><USER40> Responsive design as a design system isn't at fault here. The article implies (indirectly) that it is.

</comment><comment><USER41> What about increase in smartphones' screen sizes and resolutions? The next generation of Galaxy and IPhones will probably have 1920x1080 5" screens. Doesn't it invalidate the biggest need for responsive design (no need to zoom to see 980px elements)?

</comment><comment><USER42> As with many technologies that become cool, more people jump on the bandwagon than ideal. These guys realized (after some wasted effort) that they are over- optimizing and went back to doing what's truly needed for their company.

</comment><comment><USER43> <http://vimeo.com/32143919>

</comment><comment><USER44> I am 100% with the author. Moreover, I now always check the audience and try to make assumptions about the changing browser usage picture. After that I design for that particular audience, not for everyone.

</comment><comment><USER45> I fucking hate the term "responsive design" because in reality nothing is "responsive". A shitty fixed 980px site will still look like crap on 1080p 24'' monitor.

Calling it responsive just because the navigation menu is moved above the content when viewing it from the phone doesn't make it "responsive".

<comment><USER46> You know what's really responsive? Proportional width, aka the default.

HN is great and usable on my 27" desktop monitor or my 4" phone screen. Less design is more.

<comment><USER47> If you call "having to zoom in to make the text even readable" great and usable, then yes, HN is "responsive".</comment></comment></comment>


Ask HN: Linux networking interview questions - <AUTHOR> What are some good interview questions for a kernel developer in the networking area (bridging, Layer2, netfilter/iptables, IP routing, Layer 3 and TCP/UDP stack) <comment><USER2> Give the lifecycle of an sk_buff structure from birth (in the driver) all the way up to a user's socket read syscall. Familiarity with various layers and how the TCP state machine works are a given. Do they know any dark corners? IP routing in linux can do some incredible things, do they know anything about that.

Sources:

[http://vger.kernel.org/~davem/skb.html](http://vger.kernel.org/~davem/skb.html)

[https://people.cs.clemson.edu/~westall/853/notes/skbuff.pdf](https://people.cs.clemson.edu/~westall/853/notes/skbuff.pdf)

If you're good enough to read the kernel code yourself take a look at a wifi or ethernet driver with them and have them explain what's going on all the way up the stack. Even if you don't know that much you'll be able to smell BS if they don't.

<comment><AUTHOR> thanks!</comment></comment>


Presenting unexpected futuristic solution to client - <AUTHOR> I'm in talks with a client who is asking me to build a software solution for his company. They have a preconceived idea of the software (that I'll build for them) which is very ancient way of doing things. But I have a far advanced solution that is being adopted around the world and it will change they way they work in very awesome way.
Trouble is, I think they'll be scared away from the new ideas and reject it altogether.
Question: Have any of you ever been in to my situation? What did you do and what outcome did that bring?
Thanks in advance. Waliur <comment><USER2> Probably some really simple sales advice. Don't try and sell the product/solution to the customer. Sell the customer to the product. That means show the customer that their immediate needs can be easily meet by your product. That's it. They dont need your full solution yet.</comment>


FBI: New Jersey Mayor Felix Roque hacked website - <AUTHOR> http://www.politico.com/news/stories/0512/76723.html

<comment><USER2> Seems funny following of the recent debate on HN about politicians teaching themselves technology/to code.</comment>


Doas – Dedicated OpenBSD application subexecutor - <AUTHOR> http://www.tedunangst.com/flak/post/doas <comment><USER2> Compare the code in doas: [http://cvsweb.openbsd.org/cgi- bin/cvsweb/src/usr.bin/doas/](http://cvsweb.openbsd.org/cgi- bin/cvsweb/src/usr.bin/doas/) to the epic beast that was sudo: [http://cvsweb.openbsd.org/cgi- bin/cvsweb/src/usr.bin/sudo/](http://cvsweb.openbsd.org/cgi- bin/cvsweb/src/usr.bin/sudo/)

Amazingly - for such a tiny bit of code, it still has 100% of the functionality I've ever used with sudo: [http://www.openbsd.org/cgi- bin/man.cgi/OpenBSD-current/man5/...](http://www.openbsd.org/cgi- bin/man.cgi/OpenBSD-current/man5/doas.conf.5?query=doas%2econf&sec=5)

And you just have to love a man page like this:

[http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD- current/man1/...](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD- current/man1/doas.1?query=doas)

I really, really like the direction OpenBSD is going. Bit by bit the base operating system is becoming a leaner animal, rid of a lot of cruft that has the potential to bite people in the future.

And, note - for anyone who is wondering how one can get by without sudo for backwards compatibility - sudo isn't going away, it's just being moved out of base into ports. If you want to install it in your system - it's just a pkg_add away.

<comment><USER3> _to the epic beast that was sudo:_

I don't want to defend sudo, but by definition any C utility that is multi- platform is going to be larger. Also, sudo has features that are required in some enviroments, like LDAP or PAM support.

I definitely agree that the direction they are going in is great: a lean base system that has as little attack surface as possible and covers 95% of the use cases. If you do need extra functionality, get it from ports.

One thing I wonder about though is: why does a system which goal is security still use C for utilities/programs that are not really CPU-bound? Maybe it's time to slowly ditch C for a safer language where possible? (There are languages that would fit in quite well with OpenBSD, except that they require some portability work.)

<comment><USER4> Most systems developers are proficient with C. Code isn't going to be safer in language XYZ if developer isn't proficient with it, no matter how awesome XYZ is. This also ties into the legacy: there's a lot of code in C out there that you can't simply replace. Also keep in mind that most of the "safe" languages depend on runtime which isn't written in a safe language. So you're just pushing the problem somewhere else.

Even pretty bare metal languages like Rust aren't very well suited for OS development (yet) since they come with certain assumptions about memory subsystem. Which has to be implemented to be used. This is also true for C - there's some stuff in every C standard library that has to be written in asm, once for each supported platform.

So the bottom line is: there's always something underneath. You can get to a safer place by minimizing these pieces of "unsafe" code and writing code in something else above or, what OpenBSD does, you can abstract and isolate things away and use the tiniest possible solution for each problem and achieve safer environment by proper separation of concerns.

<comment><USER3> _Code isn 't going to be safer in language XYZ if developer isn't proficient with it, no matter how awesome XYZ is._

There are safe languages that are similar enough to C that it is not hard to pick them up for a C programmer. I agree if the replacement is ML or Haskell. But e.g. Rust, Cyclone, or Go (if a GC is acceptable) are not going to be hard for most C programmers.

 _Also keep in mind that most of the "safe" languages depend on runtime which isn't written in a safe language._

Rust is almost runtime-less. The Go runtime is mostly Go since 1.4.

 _This is also true for C - there 's some stuff in every C standard library that has to be written in asm, once for each supported platform._

I didn't say it's not going to be work :).

 _So you 're just pushing the problem somewhere else. [...] So the bottom line is: there's always something underneath._

That does not mean that, say, Haskell is not tremendously much safer than C. First, because you only have to implement the icky parts once. Second, because a better type system and abolishment of undefined behaviour gives you more safety for a very small cost (if at all, the extra compile time for a better type system is probably negated by the cost of headers).

<comment><USER5> zamalek got it correct above. Those languages above only cover 2 or 3 architectures that the project works with. There is no Rust or Go compiler for vax, alpha, macppc, sparc64. There are C/C++ compilers though.

<comment><USER3> Yes, I know, that's what I mentioned in my original post: it requires portability work.

 _There is no Rust or Go compiler for vax, alpha, macppc, sparc64. There are C /C++ compilers though._

Well, I think compilers for some of these architectures (e.g. VAX and Alpha) still exist in gcc largely because OpenBSD and NetBSD have put so much effort in keeping them alive (yes, I know that OpenBSD is using an older version). So, it's not as if you get C compilers for these platforms for free.

</comment></comment></comment></comment></comment></comment><comment><USER6> This tool exec's, and its return status reflects whether the command could be launched. Sudo waits and returns the exit code of the process. I'm surprised this wasn't mentioned in the blog post, it's probably the most important difference.

<comment><USER7> If the exec is successful, it will be _replaced_ by the exec'd program, and its exit code will then be whatever the exit code of that is.

</comment></comment><comment><USER8> Does anybody can use sudo in a way that it adds additional but limited privileges to certain user groups securely? I'm sure it's used only for giving admin privileges to the admin group 99% of the time. If your OS needs a tool that allows users to run processes as another user then maybe your OS needs finer access controls instead.

And for the 99% use case I think a few lines long C code would suffice.

<comment><USER2> sudo (at least everywhere I've used it) - is typically used to (A) allow me to run code as root without having to type my password, and (B) give select groups of people the rights to run a few specific commands. In terms of number-of-time executed, in a recent environment that I was in, in which approximately 100 or so people had sudo rights, 90+% of the time it was to allow people in various group to run commands like "tcpdump" or "netstat", without giving them full root rights to the system.</comment></comment>


CAPTCHA Economics - <AUTHOR> http://www.marginalrevolution.com/marginalrevolution/2010/08/captcha-economics.html

<comment><AUTHOR> Stefan Savage's team strikes again!

CAPTCHA's are done. Bad project idea! Doubly bad startup idea! It costs less to farm them out to Malaysia for solutions than it does to build the rest of your script as if there were no CAPTCHA's in the way.

That doesn't mean "stop using CAPTCHA's" --- they at least limit your attackers to people who actually want to attack you, personally --- but it does suggest that it's not worth investing any time trying to make them better.

This is old news (Jeremiah Grossman had this same point as one slide in his "how to make money as an Internet criminal" deck --- spoiler: not by solving CAPTCHA's), but it's good to have an authoritative source.</comment>


Stripe Open-Source Retreat - <AUTHOR> https://stripe.com/blog/stripe-open-source-retreat <comment><USER2> I wish more companies and hacker spaces would launch programs like this. With so many companies relying on open source, giving projects a little bit of stability is crucial.

The no-strings attached is also a huge deal. Versus being employed, this program lets people work on something that they are passionate about without the risk of the company assigning them to a new project that they aren't interested in.

<comment><USER3> Well, okay:

If you're an open source developer that needs space to work on their project in Phoenix, you can come to heatsync labs (a hackerspace) and work on it every day you want to for free.

Check it out here: [http://live.heatsynclabs.org/](http://live.heatsynclabs.org/)

We can't give you money, though (since we don't have a ton of it; we're a non- profit).

[By the way, this is kindof meant in jest: anybody can come and work on their projects here if they want to, and that has always been the case.]

<comment><USER4> I'm a programmer that does open source and teaches classes in his free time. I live in Austin, but all the coworking spaces here charge more money than I'm comfortable paying, would somebody be willing to sponsor me or offer a reduced-rate?

I can provide Github profile for proof.

<comment><USER5> I'm also in Austin and have been hanging out at Center61 ([http://www.center61.com/](http://www.center61.com/)). It's a pretty nice space for social entrepreneurs. Their definition of social entrepreneur is flexible and I bet your open source work would qualify. At $25/mon it's pretty affordable too.

</comment></comment></comment></comment><comment><USER6> I thought this meant that Stripe was retreating from open-sourcing internally- developed software.

A potentially better title is "Stripe offering open-source retreat for select software developers".

<comment><USER7> jjallen was downvoted, but I thought exactly the same thing. I was full of righteous indignation, which was promptly defused by the actual article.

I'm very happy to be mistaken!

</comment></comment><comment><USER8> I'm interested to know where ideas like this originate within the company. Outreach like this is great for their brand within the dev world, though this may be more altruistic than CTF (semi-recruitment tool). There's no question that both initiatives are clever enough to make one wonder how they come to life internally. Love the idea(s)!

<comment><USER9> We have an internal mailing list called "Crazy Ideas". No idea is too crazy.

Greg emailed the list two weeks ago with a proposal for the open-source retreat. The reaction internally was quite positive. He polled open-source maintainers externally to see whether this was something they'd be interested in. The reaction externally was quite positive too.

Greg hammered out the details and shipped it.

<comment><USER10> This idea has been making me smile for like the past 40 seconds.

</comment></comment></comment><comment><USER11> I'm generalizing here but I would hazard to guess a good majority of OSS project maintainers (myself included) do so in their spare time and have full- time jobs. It's unrealistic to leave a job for a 3 month "retreat", regardless of how great the opportunity is.

I'm not suggesting it won't work, I think it's a fantastic program and I'm rooting for its success. I'm just suggesting you may want to consider remote opportunities (maybe with occasional visits for in-house tech talks) for future iterations which would undoubtedly increase the talent pool and presumably be more effective at delivering your end-goal.

<comment><USER12> Sure, it's not going to work for the majority of OSS developers; but nothing is. It's nice to have different kinds of opportunities available. Some people can do stuff in their free time; some may be more productive with a dedicated sprint. Some people may have the opportunity to do it between jobs; some developers are consultants, and can probably find a way to free their schedule up for a few months if they can justify it with the extra income.

Different companies contribute in different ways. The company I work for funds major features that we need, as well as having support contracts with the primary developers of some of the key software that we use, and we contribute back patches when we find bugs that need fixing. Google does their Summer of Code, in which students can work remotely over their summer break, plus does primary development of a lot of projects like Android and Chrome, and contributes to others like the Linux kernel. Red Hat and Canonical mostly develop open source software directly. The Gnome OPW funds internships for women, over several periods over the course of the year.

So there are lots of opportunities out there, with a lot of different ways to get funding and support. I don't think that each program needs to be all things for all people; it's OK to have particular targeted and focused programs, either on different groups of developers, different projects, different types of time commitment, and so on.

<comment><USER11> I completely agree with everything you said. I got the impression from the blog post they are looking for people to solve real world problems, and people who are good at that are generally employed (comfortably). I hope the program is successful and they expand it at some point to allow for different types of arrangements.

</comment></comment></comment><comment><USER13> If there is ever a company to look at to model your developer relations, Stripe is it. It is really a joy to see the stuff these guys come up with.

</comment><comment><USER14> Stripe does a good job about staying top of mind for devs by doing things like this. When I think of a great company to work for, Stripe and Github are usually near the top.

And benefiting open source? Double win.

<comment><USER15> That's a really good point. I always reference them as a company that seems great, despite never having used their service or known anybody who has worked there. They have really great developer PR which, given their market, is also just really great PR.

</comment></comment><comment><USER16> Asking people to move to San Francisco for 3 months is just a tad bit crazy/expensive don't you think?

One might spend ~$5,000/mo for a short 3 month stay in San Francisco.

Why not organize accommodation for them as well? Renting a house for 3 months over a summer and dividing it by 3-4 grantees would be cheaper for both parties. And it would help manufacture some incredible collaboration as well imho.

<comment><USER17> There are a lot of people who manage to live in the bay area on far less than $7500/month. For example, it's very affordable to live in Oakland and commute in on BART.

<comment><USER16> Sure, I could spend my expertise living frugally in one of the world's most incredible cities... or the company I am helping out could help me better by providing me with a simple room to live in inside a house near their office filled with other like minded people.

I am an expert programmer, I don't want to spend my 3 months in San Francisco in a hostel just to help the greater good and save a few bucks.

</comment></comment></comment><comment><USER18> Can we nominate other developers who are working on projects we're not?

</comment><comment><USER19> Wow, this is the exact idea I have been thinking about!

For successful companies like Stripe, the cost of doing this program is negligible. And yet many open-source projects (OpenSSL comes to mind) can really take a huge step forward by having several professional developers working full-time on it for three months. Lots of kudos to Stripe for doing this, and hope to see more companies follow this example!

<comment><USER20> As a bonus, they're working in the Stripe office. If Stripe thinks they're awesome, they can extend an offer at the end.

<comment><USER21> I'd be more excited by the opportunity to exchange ideas and experiences with other talented professionals.

</comment></comment></comment><comment><USER22> This is really great. Kudos to Stripe. I'm curious about what the ideal scenario is at the conclusion of the 3 months? Some options are...

\- The project has progressed significantly to the point where the developer can hope to find continued sponsorship at Stripe or elsewhere.

\- The project has progressed to the point where it no longer needs the tender loving care of the maintainer full time. Either it got more contributors or has reached a new level of stability.

\- The developer joins Stripe (or somewhere else) full time and the project is left better off, but without a full time contributor/maintainer

Any thinking about what the end-game is from the developer's perspective. Either way, it's an incredible opportunity.

<comment><USER23> The great thing about this that there are many good possible outcomes, for Stripe, the developers, and everyone.

</comment></comment><comment><USER24> It's amazing how many cool things they come up with and follow through on. Respect.

</comment><comment><USER25> So, hopefully some OpenSSL developers will apply?

<comment><USER26> Hopefully not. The heartbleed debacle is going to see that project showered with money and corporate aid. We need to see projects that have absolutely no support but are critical (a lot of the GNU utils are good examples). nginx could probably use some of this goodwill, as can core language compilers, and frameworks like Qt. Albeit Qt is probably a bad example, because you have to sign copyright over to Digia. KDE5 is supposed to be very library portable, it seems like a good place to put Qt extensions businesses are uncomfortable turning over to Digia.

<comment><USER27> I think Nginx is good with [http://nginx.com/](http://nginx.com/) and their Nginx Plus + Support Contracts model.

I'd like to see OpenSSH on this list simply because it is probably as widely used as OpenSSL and I don't think it has better funding...I could be wrong tho.

<comment><USER28> OpenSSH originates from the OpenBSD developers. While the OpenBSD foundation could always use more money, they are no where near as bad off as the OpenSSL team was/is.

<comment><USER29> Really? I seem to remember them nearly having to shut down their servers a few months back?

<comment><USER30> I don't have a link to give you, but recently they have received good funding.

</comment></comment></comment></comment></comment></comment><comment><USER31> Even it is not explicitly mentioned, I wonder if Stripe will let 'whether the applying project can be used somewhere inside Stripe' be one deciding factor, or the project can be totally irrelavant to what Stripe is doing.

It is great seeing YC companies giving back to the community, first teespring and now stripe. I can see it is the future that it is startups pushing forward the technologies and communities, much more than big corps.

</comment><comment><USER32> I wonder if US immigration would count this as "work" for people without ability to work in US?

<comment><USER33> Not an immigration lawyer but I unfortunately have to care about this stuff w/r/t a non-US nation and have previously had to care about it w/r/t the US on behalf of third parties: even "You talk at our office and we pay you a modest honorarium" requires a B-1 (short-term travel for business purposes to e.g. negotiate a contract) as opposed to e.g. a visa waiver. It is vanishingly unlikely that the duration and scope of this project, which looks an _awful_ lot like "We wish to purchase your professional services for 3 months", would be sustained under the B-1 visa.

Speak to a lawyer prior to relying on the above, etc.

</comment></comment><comment><USER34> This is super cool. Love seeing all the new incentives for open source and nonprofit startups.

</comment><comment><USER35> Is there a reason this article is future dated by 5 days?

"Greg Brockman, April 29, 2014"

<comment><AUTHOR> Good catch. Mostly I'm just bad at reading calendars :).

<comment><USER35> I like to think that your brain was just prioritizing more important concepts :)

Sounds like an awesome idea - I look forward to seeing which projects get selected.

</comment></comment></comment><comment><USER36> Why don't you give the grant to the current maintainer of the open source project. I think that can have more impact on the open source project

</comment><comment><USER37> This is really awesome. Super inspiring and wish more companies would do this.

</comment><comment><USER38> Sounds like you wouldn't be willing to give a grant to a pair?

<comment><AUTHOR> You're welcome to apply together. We're looking to maximize impact, and e.g. bringing together a pair who normally work together remotely could be a good fit.

<comment><USER38> Sounds good! (I was asking in general not for myself)

</comment></comment></comment><comment><USER39> This is a pretty inspiring initiative. Thank you for doing this!

</comment><comment><USER40> This is awesome, can't wait to see what comes out of it.

</comment><comment><USER41> I'm going to submit an app for the NeoVim guy.

</comment><comment><USER42> Are you guys accepting recent graduates for this?

</comment><comment><USER43> This is great. Well done Stripe.

</comment><comment><USER44> You guys are SO awesome!

</comment><comment><USER45> smart hiring strategy!

<comment><USER46> I think so too. It also works both ways. For those lucky enough to work on a mutually agreed Open Source 'pet project' they will have a good idea as to whether they really like the atmosphere and if the challenges available at Stripe are going to suit them.

</comment></comment><comment><USER47> anyone know what software Stripe is using for their blog?

<comment><USER48> We're using site/blog.rb, pretty much the last thing I wrote that's still in production at Stripe...

</comment></comment><comment><USER49> Wow, this is amazing.

</comment><comment><USER50> outstanding hiring strategy.

<comment><USER51> Yes indeed. Encouraging open source contribution, validating that he/she can get stuff done and evaluate culture fit. Win-win-win.</comment></comment>


'Why The Hell Do I Have To Keep Updating Apps On My iPhone? - <AUTHOR> http://www.businessinsider.com/john-mccain-tim-cook-questioning-2013-5

<comment><USER2> I do /not/ want my phone apps updating automatically without my knowledge. That's just asking for an app developer to abuse that level of trust and install something under the radar. I can't imagine the level of spyware and malware that would be rampant in an app marketplace where third party apps just automatically updated without user knowledge.

Oh, wait...</comment>


Automatic braking to be standard by 2022 - <AUTHOR> http://techcrunch.com/2016/03/17/automatic-braking-to-be-standard-by-2022/?ncid=rss&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Techcrunch+%28TechCrunch%29 <comment><USER2> I'm actually surprised they chose a date that far in the future. Automatic braking reduces low-speed forward collisions by up to 14% [1], which is a huge improvement in overall safety.

[1] [http://www.iihs.org/iihs/news/desktopnews/crash-avoidance- fe...](http://www.iihs.org/iihs/news/desktopnews/crash-avoidance-features- reduce-crashes-insurance-claims-study-shows-autonomous-braking-and-adaptive- headlights-yield-biggest-benefits)</comment>


Girl, 11, is youngest US chess master - <AUTHOR> http://www.bbc.com/news/world-us-canada-32618139

<comment><USER2> Amazing! I believe everybody has a strength, it's just not every strength is a celebrated achievement. I could've been a nationally ranked hopscotch player at 9, but alas...</comment>


Html5 Custom Elements – It's Time to Leave BEM Behind - <AUTHOR> http://mikeybox.com/devlife/2015/7/16/html-5-custom-elements-its-time-leave-bem

<comment><USER2> I think BEM was good or at least had its benefits in days past but now its time to move on.</comment>


Ask HN: Do you trust low-code platforms? - <AUTHOR> I'm the CEO of a low-code platform called Hatch Apps. We started as a no-code platform and are shifting to low-code (i.e. in-browser code editing) to enable developers to edit and extend an app's features, business logic, and integrations.<p>Curious how much developers trust (or appreciate) low-code platforms? This can be in relation to speed to market, quality, app complexity, etc. <comment><USER2> Unpopular opinion here...

Investors and Technologists are always chasing after solutions that will drop the barrier between hard tech things and "normal" people. Think wix, squarespace, salesforce, etc.

...But the uncomfortable truth is that code isn't that barrier. Most Devs lego-piece projects together from open source repos that are fairly easy to configure and use IDEs that code-complete A TON of our work for us. The hard part isn't the code, it is the way that we approach problem solving, the way that we put projects together... its the way that we think about "hard tech things". Low code doesn't make that part any easier.

So do I appreciate or trust low code platforms? Sort of... mainly because it gets people started in our world.

</comment><comment><USER3> The main problem I have with low code solutions is that it doesn't work with traditional development workflows.

\- can I export/import a plain text representation of my implementation and version control it?

\- can I create separate environments dev/qa/UAT/staging/prod and automate pushing changes to the environment via the command line?

\- Is there an "escape hatch"? When I get to the limits of what the platform can do, are there extension points?

</comment><comment> BA4gDY-cqjsEPWn I'm very appreciative until I come by a limitation that would be trivial in a "traditional" development environment, but practically impossible in the low- code platform due to it's design. Then the magic is gone and suddenly I have a bunch of negative emotions about the platform as a whole.</comment>


CompCert - Compilers you can formally trust - <AUTHOR> http://compcert.inria.fr/index.html

<comment><USER2> Also worth reading: the paper that found bugs in the proven-correct compiler: <http://www.cs.utah.edu/~regehr/papers/pldi11-preprint.pdf>

(okay, so only a portion of the compiler is proven correct, and they didn't find any bugs in that portion).

Note also that a compiler with a proof isn't necessarily correct - it just means that you've pushed all your bugs into your description of the rules of C and of the target architecture. Since neither C nor any common CPU architecture have a formal semantics, someone has to read the (english) description and convert it to a description in their theorem proving software, and there's no reason to believe this will be easy.

<comment><USER3> One thing I missed the first time reading the paper is that those were the only bugs they could find in the compiler. After reporting them and getting fixes, several CPU-years more of random programs haven turned up another failure.

All the other compilers pick up tens of failing cases a night, which they skim off and report as their previously reported tests are fixed (the LLVM and GCC teams are quite responsive, others less so).

This kind of differential testing also provides some evidence that the formalization isn't too far off - each "passing" case means that almost all the compilers produced exactly the same results for the program.

Both projects are awesome, especially if you like reliable compilers.

</comment></comment><comment><USER4> This old Knuth quote seems apt:

 _"Beware of bugs in the above code; I have only proved it correct, not tried it."_

<comment><USER5> That seems like it either a statement about the nature of informal proof or the disconnect between the proof and the code. How does that apply to something written in Coq, where the program is extracted from a mechanically verified proof?

<comment><USER6> Mechanical proof of what, though? The spec can fail to capture intent.

<comment><USER7> In this case, the semantics of the C subset chosen are captured perfectly by the assembly produced by the compiler.

Seems like that's the intent of a compiler to me :)

<comment><USER6> Right, but first you have to specify "the semantics of C" and "the semantics of assembly". How do you prove you did that right?

<comment><USER5> Compcert uses small-step operational semantics for both the source language and the assembly output (and intermediate languages that are irrelevant to the final statement of the semantic preservation theorem).

Specifying such a semantics is basically like writing a very simple functional interpreter for the language. I don't see how it could get much simpler. Here is the description of the semantics for their input language:

<http://compcert.inria.fr/doc/html/Csem.html>

and their PPC output:

<http://compcert.inria.fr/doc/html/Asm.html>

<comment><USER6> Yes. The approach is probably as good as it can get. And yet, it's not perfect. That functional interpreter could have a bug. And thus Knuth's quote is applicable. Testing the compiler could reveal to you that your specification wasn't really what you intended.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I'm confused. The title made me think "list of compilers I can trust", but the website provides no such thing. It looks to me like they've written their own compiler.

<comment><USER9> Yes. CompCert is a project of the French research institute in computer science and automation (INRIA). The goal is to have a certified compiler for the C programming language. I believe they're writing a C compiler in Coq (a proof assistant also developped mainly at INRIA).

The main guy behind CompCert is Xavier Leroy (already known for OCaml).

<comment><USER10> Yeah, the big thing here is that almost all of this thing is _proven_ , meaning that the compiler's behavior is well-defined and correct, all the time, on all inputs.

I still had a jaw-drop moment the first time I heard about this; Coq is not a pleasant language, and proving this thing must have been a nightmare.

<comment><USER11> What does it do about the undefined behaviour parts of the spec?

<comment><USER3> You can see the statement here: [http://compcert.inria.fr/doc/html/Compiler.html#transf_c_pro...](http://compcert.inria.fr/doc/html/Compiler.html#transf_c_program_correct)

A C compiler doesn't have to promise much of anything about the behavior of the code produced for a program with undefined behavior.

This statement could be vacuous for a program p with undefined behavior if (Cstrategy.exec_program p beh) isn't true for any behavior beh, or only true for a behavior which makes (not_wrong beh) false.

If they don't always, then they actually give you a guarantee for some bad programs as well. Nothing in the spec says running a bad program _has_ to make demons fly out your nose.

</comment></comment></comment></comment></comment><comment><USER12> To be realistic: The frontend is not verified. Only very few optimizations are done. It only seems to have a PPC backend.

However, i still think verified compilers are the future. It will just take two or three decades until we see them at LLVM quality.

<comment><USER5> It now has X86 and ARM backends.

</comment></comment><comment><USER13> I seem to remember a CPU that was stack-based that was built for correctness. I think it was called the Viper, but I cannot seem to find it. It would be logical to me to run your formally trusted compiler on a chip designed the same way.

<comment><USER14> You might be thinking of Verisoft and their "VAMP" hardware stack: <http://www.verisoft.de/SubProject2.html>

The original goal of the project was to have a verified computer stack, with proofs going from the software, compiler and processor all the way down to the gate level.

I am not sure how far they got, but I don't think the project is still active, which is a bit sad.

</comment></comment><comment><USER15> Would someone explain "formally trust" in this sense?

<comment><USER16> The trust you place is based on mathematical evidence for the soundness of the compiler. The compiler is thus trustworthy, based on formal arguments, as opposed to informal arguments (such as "we did some testing" or "no bugs are were reported").

Going back to Kant, formal arguments in this sense are _a priori_ knowledge -- knowledge that is in some sense objective, and independent from any observer making empirical measurements (as opposed to _a posteriori_ , or experimental, knowledge).

<comment><USER15> Thanks. My school's CS department was very strong in theory, among other things, and so there were a lot of very mathy people in the program mixed in with the more practical proles. Most of them were very nice, but there was something of a communication problem because (I assume) they were too naturally talented at such things to be able to explain them very well. I remember one guy who would get this look of satisfaction on his face every time a teacher would start talking about formalisms, as if he were eating his favorite food, or sitting down after a long day on his feet, and that's my first association with the word "formal" in a CS context.

<comment><USER17> A little bit of explanation about formalisms and the communication problems you mention from a computer scientist/linguist who gets that same look of satisfaction:

In natural languages, the relationships between utterances and what they convey are somewhat fuzzy. Words like "tree" and "run" don't have single precise meanings; they have a variety of senses associated with them, and these senses vary in how closely they are related to each other. Biological trees made of cells are quite closely related to computer science trees by their shared shape; the relation between running with your legs and running for office is a bit fuzzier, via the race metaphor; the relation between a river bank and a financial bank is even more unclear.

Meaning in natural language is built in aggregate from associations, with the senses of expressions converging over time in groups of communicating speakers. Natural languages do not clearly define the relationships between different expressions, nor between expressions and the real world. Because natural languages are unspecified and evolving, you can only measure how often (in your observation) different expressions and relationships between expression reflect different situations.

Formalisms, like natural langauges, are also used to represent meaning via expressions made of symbols and relationships between them. (Technically, formalisms don't have to represent anything, but in practice they usually do because otherwise they're not very useful.) Unlike natural languages, formal languages have normatively defined specifications. These specifications can be written in a variety of ways, but usually they define rules (which always apply) for deriving expressions from each other.

To be able to use formal languages for real-life problems, you need to have these five skills:

Symbol manipulation: deriving expression in desirable forms from old ones using a specification Interpretation: relating formal expression to the domain Encoding: capturing domain knowledge in the formal language Abstraction: finding consistent patterns in the domain (to be expressed in the formalism) Modeling: expressing relationships in the domain using relationships between symbols

Unfortunately, most people are not very good at these skills. It is hard to break habits like using intuition and relying on others' ability to resolve ambiguity. Furthermore, most people are not very good at dealing with abstractions, especially new ones or higher-level ones. To make things worse, some of the problems involved in using formal systems are genuinely hard, even for computers and mathematicians. Obviously, even the most accomplished mathematicians are not always able to get the results they are looking for, let alone quickly, but people who are good with formalisms usually don't have as many problems with things like checking their intuition or dealing with abstractions.

The problem with communicating formal ideas to people who are not good with formalisms is rather fundamental, because the very attributes which make formalisms useful are the ones that those people have trouble understanding. You can, of course, relate the results of using a formalism, but without using formalisms it is often very hard to usefully express the "why" of the result. The problem is compounded because people who are good with formalisms have a hard time figuring out what is understandable to others, due to the general "knowing it too well to teach it" effect as well as lack of practice (since most people who care about formalisms are good with them).

Some talented communicators are able to explain formal results satisfactorily to others by relating them to familiar abstractions or rephrasing their logic in everyday terms, but unfortunately this frequently results in misunderstanding and misapplication of the results. Furthermore, there are a number of formal results which really can't be properly understood unless you have mastered the skills above (particularly in theoretical computer science and formal logic). The problem is akin to trying to talk to non-programmers about programming, but more general. Programming languages are formal languages, of a sort, but most programmers only understand a few particular formalisms. Theoretical computer science and proof theory involve dealing with a larger and more abstract set of formalisms, including formalisms about formalisms.

If you need examples of the difficulties, just look at all the ways that people try to explain Gödel's incompleteness theorems or monads informally.</comment></comment></comment></comment>


Disable the User's JavaScript Console - <AUTHOR> http://davidwalsh.name/disable-console <comment><USER2> I'm sad to see this become practice. Playing around the javascript console is one of the "WOAH" moments I had when I was first learning to code.

I remember using the Facebook "Like Bomb" during an all nighter at the library. It was a javascript snippet that would like everything on the page and annoy all your friends. Back then, I didn't consider myself a coder, and didn't think for a second I'd be doing this 4 years later.

I also remember being on gTalk with a friend and he was really annoyed by a paywall he couldn't get around. It was nothing more than a popup modal, so I sent him back a couple lines of javascript that got him through the paywall. I felt like a wizard.

The JS console is like peeling back a layer of the web and seeing a whole new world. Web pages stop being this thing you consume, and starts being something you manipulate and break. Anyone with experience will be able to get around this, but its sad that a lot of people might just shrug it off and not have those same experiences.

</comment><comment><USER3> I for one can not wait until EME expands beyond Video to include full encryption of entire web pages so the web can be locked down behind DRM.... That will be fun for everyone

Netflix and Facebook will be the first to adopt it, the kind of thinking that creates locking out the console will create the expansion of drm.

</comment><comment><USER4> Couldn't you easily write a scriptlet (javascript: ....) to bring it back?

<comment><USER5> Aye: javascript:void(delete window.console)

<comment><USER6> That works perfectly for me on Netflix.

</comment></comment></comment><comment><USER7> I'd expect a bug fix for this soon. I don't see it as anything else. Regardless, it's still security by obfuscation, which is hardly secure.

</comment><comment><AUTHOR> This definitely makes sense, as you can't open up the execution environment of native programs and execute code there. Though it is disappointing.

<comment><USER8> Worth noting that this only works for Chrome. For what it's worth I don't support the practice and think it will not help prevent "self-XSS" at all. The idea of self-XSS being ridiculous to begin with.

<comment><USER9> Apparently it's common enough on Facebook, and not that ridiculous to imagine.

It's just like the "delete system32 to make your computer go faster" trick. For anyone on this site it's a laughably stupid prank, but you only know about it because there are people out there ignorant enough to fall for it.

</comment></comment></comment><comment><USER10> I'd imagine this is pretty easy to circumvent. Ready, set, go.

</comment><comment><USER11> Yes, put the security on the client-side. -_-

</comment><comment><USER12> The hack-ssembly of the web.</comment>


Open-Source Speech Recognition: Simon 0.4.0 Released - <AUTHOR> http://simon-listens.blogspot.com/2012/12/simon-040.html

<comment><USER2> This might be better described as scenario-based command recognition, where a scenario is something like "Firefox", "Skype", and so on with commands specific to the scenario you're in. In other words, if you're looking to do automated voice transcription these aren't the libraries you're looking for.

Main site: <http://userbase.kde.org/Simon>

<comment><USER3> Wait, so if your universe is ["Coke", "Pepsi", "Sprite"], then this library will tell you which one the user spoke?

Just being clear, it wouldn't take you from a bucket of raw sound samples to a string like "I'd like a Coke, please" ?

<comment><USER4> Yeah, this tool is focused on recognizing specific utterances given the curent context, e.g. (to take an example they use) voice-operating a browser. So you say things like "close tab" and it realizes that you've said one of the command words it recognizes in that context, and acts accordingly. They also have an example somewhere about controlling a calculator by speaking digits and arithmetic operations. Doesn't seem to be aimed at free-form audio-to-text transcription, though some of the technologies it's built on, such as CMU Sphinx, are fairly general.

</comment></comment></comment><comment><USER5> This seems to be the most important/interesting part:

"There is a simple rule of thumb in speech recognition: The smaller the application domain, the better the recognition accuracy. [...] Simon can now re-configure itself on-the-fly as the current situation changes. Through "context conditions" Simon 0.4 can automatically activate and deactivate selected scenarios, microphones and even parts of your training corpus. For example: Why listen for "Close tab" when your browser isn't even open? Or why listen for anything at all when you're actually in the next room listening to music? Yes, Simon is watching you."

It is one of the best subconscious techniques humans use both for listening and reading, so it makes complete sense to implement it here. I do find the choice of words in the final sentence somewhat ominous though!

</comment><comment><USER6> Bottom line: speech recognition in the general case (more than a few predetermined words) is only as good as the 1) acoustic model (which utterances were heard), and 2) language model (how do we group the utterances into words).

This requires massive amounts of labeled data. This is why Nuance is king and few others come close - the amount of labeled data necessary to catch up is astounding. Not to mention a patent minefield to navigate.

This is unfortunately one field in which open-source alternatives face real obstacles and won't be viable in the near future.

<comment><USER7> Seems like there ought to be a way to crowdsource some of that.

<comment><USER8> Yeah there is <http://www.voxforge.org/home>

I have CMU Sphinx (pocket edition even though I'm running on a full blown server) and for my use case it works fairly well.

<comment><USER6> This cool. But are these audio files transcribed, or just provided?

I downloaded a couple here:

[http://www.repository.voxforge1.org/downloads/SpeechCorpus/T...](http://www.repository.voxforge1.org/downloads/SpeechCorpus/Trunk/Audio/Main/16kHz_16bit/)

and it didn't seem to have a log of words labeled each by timestamp offset into the audio recording - which is the vital part for training a recognizer. Am I missing something?

<comment><USER8> It's trickier than just matching word sounds, the sphinx docs are first rate: <http://cmusphinx.sourceforge.net/wiki/tutorialam>

It is very interesting but unfortunately just appears to be too much hassle for sane people to tackle (although it'd be extremely worthwhile if someone would innovate in this space and lower the barrier to entry - most are using commercial acoustic models with the FOSS software)

</comment></comment></comment></comment></comment><comment><USER9> I'd love to hear some opinions from anyone with speech recognition experience on how this stacks up to the commercial alternatives.

<comment><USER10> I don't think this is quite the sort of answer you want:

My sibling (using Debian Testing) had wrist RSI this summer and we tried to set up Simon Listens (the previous version; 0.4 looks from the release notes like it's improving). We are both Linux nerds. We were not able to get it to do anything useful after a few days of work, and I estimated a 50-50 chance that working harder on it would help[1]. I did not find any other FOSS speech- to-text that I could get working either. (FOSS Linux text-to-speech is much better; e.g. Orca is good.) We did not try any commercial products; Dragon Naturally Speaking is the only one I know of having a good reputation but it is Windows-based. Also, it's hard to integrate well into the Linux stack without being FOSS. A list of products we looked at: <https://en.wikipedia.org/wiki/Speech_recognition_in_Linux>

[1] Issues with compiling, dependencies, figuring out the conceptual model Simon Listens uses, trying to figure out whether Simon-not-doing-anything was because we miscompiled it, or audio input, or incompatible dep versions or misconfigured deps, or us just doing the wrong thing because the English documentation wasn't super thorough... Imagine setting up Apache, MySQL and PHP if there weren't a billion tutorials online, you'd never used Apache, and MySQL wasn't compatible with your GCC unless you pulled the git version and hoped you didn't get confused by dev-version-only bugs.

<comment><USER11> That is unfortunate, but somehow that sort of user experience doesn't come as a surprise to me. I think it is the _"blog as the main project page, and no version control link in sight"_ thing that gives off that feeling. The only other thing that gives off vibes that bad is a sourceforge page with no hint of a real project page.

 _Really_ frustrating when you see projects with potential botch basic developer usability so badly.

<comment><USER10> There's also <http://www.simon-listens.org/> . If you speak German there might be some info there that we couldn't read (some is in English, but I think the developers are mostly in Germany).

<comment><USER11> Ah, that's bit better. Found the version countrol: <http://sourceforge.net/projects/speech2text/>

<comment><AUTHOR> Actualy Simon project has recently moved to KDE infrastructure: [http://dot.kde.org/2012/04/08/simon-speech-recognition- proje...](http://dot.kde.org/2012/04/08/simon-speech-recognition-project- moves-kde) and the code is here: [https://projects.kde.org/projects/extragear/accessibility/si...](https://projects.kde.org/projects/extragear/accessibility/simon/repository)

</comment></comment></comment></comment></comment></comment><comment><USER12> I've spent a good bit of time trying to get CMUSphinx to transcribe audio with any amount of reasonable accuracy. I never was very successful. Resorted to using paid third party APIs.

I really wish there were better options out there. Hopefully Simon will help improve the landscape. The automatic contributions to Voxforge should help.

<comment><USER13> What third party APIs do you use? And how accurate are they in transcribing long audios with a reasonable amount of noise?

<comment><USER12> I have the most experience with Nuance's NDEV API. It is not really for very long audio. I'd say < 2 minutes.

</comment></comment></comment><comment><USER14> I would love to see a good, quality, open source alternative to Nuance. They are pretty much a monopoly (patent and market wise) in this area. It also has to be open source, Nuance is known for either suing into oblivion (for patent infringement) or buying the competition.

<comment><USER15> This is actually the sort of project that will/can never be open-source. NOt because of the patents. Because its hard, requires 1000s of hours of thankless data collection. There's no shortcut to something cool - and open source loves cool demos that are easy to build.

</comment></comment><comment><USER16> Does anyone know if this does full speech-to-text transcription, i.e., I speak, it fills my speech into a text box? Or is it just for controlling the desktop via speech I tried googling, but couldn't come up with much.

Also, there is no Wikipedia page for them!

<comment><USER17> on a side note: this is part of the HTML5 specification. If people are not afraid of Google/Chrome and if being online is not an issue, it's as simple as this: <http://jsfiddle.net/dirkk0/pGFuR/>

<comment><USER18> I only found <https://wiki.mozilla.org/SpeechAPI> for the FF implemenation, looks like it has no Linux support either, but I only glanced at the patch they made... It seems to support recording for OSX and Windows at least.

</comment></comment></comment><comment><USER19> I'm really glad somebody's working on this. When my ex got RSI a couple of years ago it seemed like there was no option but to go back to Windows. There aren't many unsurmountable issues left for Linux users, but this seemed to be one of them.

<comment><USER20> I had some success (five to ten years ago now) with having a Windows machine purely to run the dictation software, and using a remote access tool like x2x or synergy to pass the keystrokes through to a Linux box which ran my actual desktop. Obviously you lose some of the application-awareness but for people who need the voice recognition but find Windows drives them up the wall it's better than nothing, and it has the incidental advantage that the dictation software isn't competing with anything else for CPU and RAM.

</comment></comment><comment><USER21> I would like to include a speech recognition in my commercial projects, but the license is GPL and is tied to KDE. I've also tried sphinx before but the recognition is kind of poor and it lacks a gui for user/developer configuration of the grammars.

I wonder if speech recognition software can be developed with a : \- Dynamic Time Wrapping (DTW) algorithm for comparing utterances/words. \- A recording device for the users to record their words. \- Context separation like simon uses for limiting the phrases to listen at any time and improving accuracy.

<comment><USER22> "A recording device for the users to record their words."

Do you mean a software device like some kind of control panel? While that's a solution that eases the software developer's job, that's not how people want their software to work. I'm a software developer myself and _I_ don't want my speech software to require training. Or if it's going to require training, fake it for me. Maybe a wizard: "Hi, I'm Simon! I need to hear your voice a bit before we get started. Please read the following sentence: ..." or something.

Sure, while this is a <1.0 release, maybe this recorder will help the devs learn their problem domain a bit more deeply, but I'd sincerely hope it doesn't become an engineer's crutch- IMO, it's Not Good expecting users to adapt themselves to the technology that's supposed to be serving them.

</comment></comment><comment><USER23> Looks like it depends on KDE4, but they distributed the binaries under windows? Anyone know if they plan a DEB or RPM release?

<comment><USER24> I just compiled it on ubuntu 12.04. It wasn't too bad. Although I agree, ppa would be nice

</comment></comment><comment><USER25> Can it be used for making education programs? For example a program to help improve English pronunciation.</comment>


Licensing for media companies in Canada would likely be proportionate: Minister - <AUTHOR> https://www.ctvnews.ca/politics/licensing-for-media-companies-in-canada-would-likely-be-proportionate-heritage-minister-1.4792838 <comment><AUTHOR> _One of the report's proposals, drafted by former telecommunications executive Janet Yale, specifically suggests requiring all companies that deliver "audio, audiovisual, and alphanumeric news content" to Canadians be regulated by the Canadian Radio-Television and Telecommunications Commission (CRTC) or another body, through a licence or registration._</comment>


$20M proof that the U.S. government doesn't understand incentives - <AUTHOR>

Many of you will already be aware of this, so it'll come at no surprise. Recently, I received a packet in the mail from the Federal Housing Finance Agency (FHFA) and the Consumer Financial Protection Bureau (CFPB). The cover page explained that since I purchased a home in 2013, I was being asked to complete a survey about my experience regarding the mortgage application process.
Then I noticed a five dollar bill folded around the survey. Awesome!
Yes, $5 is small - so small it's practically insignificant. But then I decided to check some numbers.
According to census.gov, over 5 million homes were sold in 2013. Even if we account for 20% of home sales not using a mortgage/loan, that's still roughly $20 million potentially spent for this "small token of appreciation".
But that's not what infuriates me. After all, $20 million is practically a rounding error in light of the U.S. government's total annual spending.
The thing that gets me is the fact that the cash is given before you do anything in response. Why would any rational human fill out the lengthy survey (which offers no further reward or even chance of reward) when the "reward" is given - either way - upfront?
What rational, competitive company would use this strategy (giving away money with absolutely no commitment or effort required) to somehow encourage customer response?
To be honest, I actually would have felt slightly more inclined to fill out the survey if no money had been included at all - merely out of a sense of respect for my country. Instead, the money is just a slap in the face and a proof of ineptitude by those sending it out.
It proves to me that the people running this show have no competency when it comes to incentivizing behavior.
And then there's the irony of this coming from the Consumer Financial Protection Bureau.
(full text at http://pastebin.com/r7ZkeGbz) <comment><USER2> the strategy is sound and it works because normal human beings feel indebted and as a result feel a strong urge to reciprocate

this was used for many years very successfully by the Hare Krishnas who hung out at airports and handed people a small flower as a gift and goodwill gesture

invariably, people felt a strong urge to reciprocate and donated cash

[http://www.evancarmichael.com/Marketing/79/The-Sales- Psychol...](http://www.evancarmichael.com/Marketing/79/The-Sales-Psychology- Influence-and-Persuasion.html)

<comment><AUTHOR> I might be wrong, but I strongly suspect the behavior you describe (the feeling of indebtedness and urge to reciprocate) is very much dependent on factors like receiving the gift in person, as well as the context/entity who is giving the gift.

In other words, yes, I'd feel somewhat indebted to give back to a religious or non-profit organization, especially if given a gift in person. The U.S. government sending me money in the mail and asking me to fill out a long survey, not so much.</comment></comment>


Fox News Reporter Claims She Was Fired for Using Harassment Hotline - <AUTHOR> http://fortune.com/2017/05/05/fox-news-sexual-harassment-discrimination/ <comment><USER2> Kinda like when the Amazon "crying at their desk" incidents came out, Bezos said to email him _personally_. Those emails got forwarded to HR and those people subsequently got blackballed. Don't EVER trust a large corp that says they're gonna help with things that can even be conflated as "whiney." Corporate policy is to root out whiners, can you really blame them?

</comment><comment><USER3> I cannot stress strongly enough to everyone: HR is there to keep _managers_ out of trouble. I had someone once put it to me this way:

Why is it that when musician has problems, his or her manager gets fired, but when an employee has problems, the employee gets fired? The reason is: the musician is paying the manager, the employee is not.

It's the chief officers who are paying for the manager. A manager's job is the manage the issues of the officers. They pay the his or her salary. The way companies manage employees is to flat out lie about that relationship. Those who challenge the obvious (i.e. harassment, pay issues, etc) are the ones who are let go. If you speak up, always be willing to accept the possibility of the axe.</comment>


Pinephone – Community Edition: UBports - <AUTHOR> https://store.pine64.org/?product=pinephone-community-edition-ubports-limited-edition-linux-smartphone <comment><USER2> Congratulations to have made it so far!

I am really happy with my pinebook which I am using as a daily driver, hopefully I will finally be able to switch my dumbphone to a pinephone soon now.

Of course the camera does not looks great, could anyone recommand me a slim digital camera that I could easily take with the pinephone that is at least on par with current generation smartphone cameras in the $100-$200 price range?

<comment><USER3> A Sony RX100. Even the earlier generations are pretty cheap used nowadays and are miles better than smartphones cameras.

</comment></comment><comment><USER4> One thing stops me using UBport is no full disk encryption support. The reason seems to be there are no way for them to get around the bootloader of a standard Android phone to boot an encrypted UBport. With a more open hardware Pinephone, are there any roadmap for them to implement on it?

<comment><USER5> Huh.

So which of the Linux distros that run on Pinephone _do_ support FDE with LUKS?

<comment><USER6> postmarketOS now has that option, and Ubunutu Touch has an unofficial guide on how to accomplish this, though very much unsupported.

</comment></comment></comment><comment><USER7> Is this still the Brave Heart edition of the hardware, or is this the full production release?

<comment><USER8> It should be the production release. It is the 1.2 hardware rev which fixes the vast majority of issues with 1.1 (Braveheart). There were a couple 'nice to have' modem debug suggestions they didn't go with apparently because it would have required a new DTB, which they really wanted to avoid. But other than that, it looks like they fixed everything that's been reported to date.

</comment></comment><comment><USER9> Does anyone have more recent experience with pine64 hardware quality? I bought three devices a few years back and all three stopped working within a few months, and support was non-existent. I'd be interested in this, but not if it breaks after two months and the only support is "ask the forum".

</comment><comment><USER10> I haven't had the chance to use a UBports device at all yet. Any good phone models to try to run this on?

<comment><USER11> It depends on your specific need, if you want something that is daily driver ready I recommend the OnePlus One, if you want something to hack on, and you're into alternative mobile OS, then consider to buy the PinePhone.

</comment></comment><comment><USER12> Anyone has experience using UBport, which seems to be the touch version of ubuntu?

<comment><USER13> I used ubports for a week once. I liked it. The only drawback is it lacked a handful of apps I needed (signal, authy, and anki I think)

A few years ago I heard they were working towards android app emulation. Might have been called Halium?

<comment><USER11> There's a signal text messaging application, there're a few 2 factor authentication applications, I don't know what anki is.

Hallium is an hardware enablement abstraction layer. We use it to port Ubuntu Touch and other OS, to devices that where built to run android.

We are not working towards android app emulation, we are working for running apps natively. We're doing this by using anbox, which basically is an minimal android image, with just enough to run apps, and that image is running inside an lxc container. However that is very hard to put it to work fully (access to sensors is one of the problems), and we have been asking for help with that.</comment></comment></comment>


ARMv7a architecture gets 40-bit addressing and virtualization support - <AUTHOR> http://www.eetimes.com/electronics-news/4206387/ARM7-40bit-virtualization

<comment><USER2> Heres linus's take on it - "Paul (email@example.com) on 8/24/10 wrote: > >'ARM Ltd. announced extensions for virtualization and 40-bit >addressing to the ARMv7a architecture, two of the key new >aspects of ARM's upcoming Eagle core.' Oh gods. Please don't say that it's another PAE mess. It's a major pain, and having to specially map all the physical pages that you can't fit directly in the virtual address space leads to some nasty issues.

I hope they have a plan to move it towards a real 64-bit architecture. But it sounds like ARM is doing the whole "do all the mistakes x86 ever did" thing.

And the funny thing is, ARM people think that x86 is the ugly architecture. But with x86 cleaning its stuff up, and ARM apparently convinced it needs to do all the mistakes x86 did, we'll soon see ARM as the real cesspool.

                          Linus"

from [http://realworldtech.com/forums/index.cfm?action=detail&...](http://realworldtech.com/forums/index.cfm?action=detail&id=112310&threadid=112309&roomid=2)

<comment><USER3> Still there's a good reason not to use 64 bits: interconnections, transistor count, die size. You can't have a CPU that sips milliwats of power and make an architecture of a 50 Watts beast.

<comment><USER4> But to the extent they want to compete with Intel and AMD in server space they're going to have to go all in to a full 64 bit design. What is the Eagle design for? Is there any other target market that needs a PAE half-measure like this?

</comment></comment></comment><comment><USER5> Thank goodness some CPU designers have some common sense. There is no advantage whatsoever to 64 bit addressing. You are just pushing a bunch of zeros around forever. That's not to say 32 bit is enough. 40 bit shows the designers have some sense and aren't just pandering to ignorant masses who think that because 2*32 = 64 that means something.

<comment><USER6> Eh, not if involves using the equivalent of PAE. 40bit addressing in that requires applications to utilize a window to use memory. And pointers get invalidated when the window is moved. Hurrah for CPU designers shoving immense workloads onto the software devs, especially application programmers.</comment></comment>


Show HN: Create awesome wallpapers (iPhone app) - <AUTHOR> http://getquotespaper.com

<comment><AUTHOR> Some cool wallpapers created by users: [http://quotespapr.tumblr.com/](http://quotespapr.tumblr.com/)

<comment><USER2> So that means you are storing all the user-generated wallpapers on your servers, or are these user-submitted ones?

<comment><USER3> I'm storing them for logging purposes. Not the ones from camera roll though, only Flickr/500px. The ones on Tumblr are shared by users.

</comment></comment></comment><comment><USER4> Mind uploading the "skate" and "mountain" wallpaper from that site? I can't find the jpg link in source

<comment><USER3> Sure, you can find those images here: [http://unsplash.com](http://unsplash.com) :)

<comment><USER4> Thank you!</comment></comment></comment>


I overlaid paulgb Facebook connections world map with countries. Thoughts? - <AUTHOR>

So I loved Paul's visualization of facebook connections and how it drew a map of the world. But I wanted to see the actual country lines. Thoughts?<p>http://ow.ly/3tYy8 <comment><USER2> Pretty strong correlation with democracy

<comment><USER2> Also, Greenland is missing :)

<comment><AUTHOR> indeed.</comment></comment></comment>


App shows how much time you've got left in life - <AUTHOR> https://apps.apple.com/us/app/lifeviewer-organize-your-day/id1482922018 <comment><AUTHOR> This can be both motivating and frustrating. Depending on how you view your life and time. What's your opinion people?

</comment><comment><USER2> the link isn't working for me</comment>


Think of Growing a Company as Building Construction - <AUTHOR> https://zeko.me/blog/think-of-growing-a-company-as-building-construction <comment><USER2> I've always thought about building a company / website as watching a child being born / grow up.

Idea conception = conception

Development = while in the womb

First push to production = birth

Everything after that is watching the child (website) grow, evolve, learn to do new things, become mature, become successful (or not). Hiring employees = making new friends. First word, teeth, graduation, etc... these are website milestones. Career change is when a company pivots. Marriage is being sold to another company and death is of course, closing the doors.

<comment><AUTHOR> Interesting analogy and nice script for whiteboard story.</comment></comment>