"This place is nicely remote, and off the grid, relying on solar power. I only get 50 amp-hours of juice on a sunny day, and often less than 15 amp-hours on a bad day. So the whole house runs on 12 volt DC power to avoid the overhead of an inverter; my laptop is powered through a succession of cheap vehicle power adapters, and my home server runs on 5 volt power provided by a USB adapter.
"When power is low, I often hack in the evenings by lantern light"
After digging into things like this for awhile, it seems like the hardest part would be getting a big e-ink display. There are dozens of low cost/low power arm based Linux computers out there, but hobby e-ink displays over 3" are hard to find.
Are there even e-ink displays with characteristics suitable for hacker/developer use? Their application has been so greatly limited to e-readers that I'm unclear how well current displays would function in a general-purpose system.
Likewise, the impression I've gotten is that that e-ink has been kind of stuck behind the dominance of LCD (and OLED to a lesser extent), both in perceived desirability and in resources being put into R&D.
Bottom line: you can drastically increase refresh rate but you loose contrast.
And yes, way too less resources into R&D, people just don't get it. It's just like nowadays everybody likes glossy vs mate LCDs. It's frustrating because all of the problems can be solved: refresh rate, size, color. I have been waiting for years (at least it feels like it!) to code on an e-ink! (And then take notes on a paper-thin one but I'm gonna stop here... :)
The closest to hacking on an e-ink are people transforming their kindle DX into a screen with GNU Screen or even VNC (Don't try it). The loveliest project involves the Raspberry Pi: http://www.ponnuki.net/2012/09/kindleberry-pi/
Pixel Qi had some pretty interesting products being developed including reflective LCD displays. I am not sure how readable they are in low light conditions, but I always thought it would be cool to have one of these for programming.
Pixel Qis are not e-ink but still amazing. As you said they are reflective LCD, and can also be backlit, thus readable in low light just like a regular LCD. Their market is also small devices, so the size problem is still there (Last time I checked I think there max size was 10.1 inches)
The OLPC had a LCD that could either work as a backlit color display or as a reflective b/w screen. That always seemed like a clever feature to me (with clever design it might even be possible to have a higher resolution in this mode, using the sub-pixels for color mode as pixels)
Pixel Qi (discussed in another reply) was funded by Mary Lou Jepsen, a former CTO of OLPC.
The screen you are referring to probably uses the exact same technology (designed while she was CTO?). It's not e-ink but indeed amazing. Too bad we don't yet put a lot of resources into this kind of projects.
There is the crazy expensive Sony Digital Paper DPT-S1 which has a 13.3" screen with 1200x1600 resolution. That resolution really would be good enough for me if I could get tmux on there and connect a physical keyboard.
Please somebody make a hacker friendly terminal laptop with such a screen and a great keyboard. It doesn't have to be ARM, any arch that can run free software is fine with me.
Good luck trying to buy this Sony Digital Paper DPT-S1 if you're not in the US though.
I'm in Europe and contacted Sony. They knew nothing about it since it is a Sony Professional product. I contacted Sony Professional Europe but they knew nothing about it since it is a Sony Professional US product. And they refuse to ship to Europe... Sigh, here is a product I want to spend $1000 on and Sony wont take my money!
Description of problem:
youtube no workee - fedora 9 not usable for wife
How reproducible:
I didn't try a lot of videos, but I couldn't find a single one
that actually worked. And what's the internet without the rick-roll?
This indeed is the pathological case of awful pattern of modal notifications stealing focus. Here the "notification" that connection has failed indeed destroys the whole page you have been working on (by replacing the content you care about, with some message about which you could care less).
The browser (or application, or desktop environment) should be smart enough to allow enqueuing such notification and presenting it via some facility that respects users task and only shows the message via some non-focus-stealing approach. Such as growl.
The bug means loss of user information. We as developers should be treating the user's information as sancrosanct. Such as never presenting question "Do you want to save?". Instead, save everything implicitly. Don't steal focus to ask for confirmation: instead offer unobtrusive undo. Allow user to delete when he wishes so. (Like Gmail does.) Never lose user-entered information. Never destroy user's flow. Never destroy user's view (workspace).
The danger, of course, is that presenting a half finished page and someone missing the growl message. They continue using the page, but miss out on critical information that would have otherwise informed their current actions.
In this case, presenting an overlay saying the page did not finish loading, and you can continue reading if you want with the caveat that the last part of the recipe, perhaps the most critical part, is not present.
After all, if you don't give that cornbread a minute or two to settle and cool, you'll burn your tongue.
Not to distract from the corn bread recipes (which, in all serious, actually led me down some interesting links to some things I intend to have a closer look at later), but what is the mechanism behind the described failure of the browser? Is it when the original page doesn't fully load? Is it a certain type of resource that half-loads? It's happened to me a couple of very inconvenient times (though not quite to that level) and I'd be interested in any possible mitigation strategies.
if the net connection dies while page resources (but not the actual html) are still loading, the already-loaded-partial-page is replaced with an error message
Mobile Safari on iOS behaves similarly.
Trying to scroll, I sometimes I click on a link accidentally.
When network is slow, going back to the original
page does a reload and takes ages or even fails.
On the iPad I can have a tab fully loaded, switch to a different tab, switch back and inexplicably it will try to reload the first tab and barf if it can't. So forget loading a page to read later if later happens to be on a plane or train...
Or worse, it is impossible to fill in a form by cutting and pasting between two tabs. Because at some point it will just decide for no particular reason to reload the form and you lose everything.
Which iPad are you using? For me it improved a lot after upgrading from the iPad Mini to the retina iPad Mini... I still hate the behaviour and it still occasionally happens.
I've seen that problem in chrome before with images; I was trying to read a massive flowchart; the part I was interested in was on the top, and I was busy tracing it with my finger and getting what I needed, when the entire image vanished and was replaced with a placeholder because it timed out while downloading.
This is not just a problem with HTML renderers; JPEG renderers do it too.
Yup. Mr Hess has a whimsical style which I find amusing.
I won't be able to reproduce this bug until February, and even then it will be Parkin (a form of cake made with oats) rather than Cornbread.
Seriously, if I found myself on dialup right now (or more likely a very slow mobile connection) I'd ssh into the shell account and use links from there at least for initial searching and text based information.
I'm wondering if there is some form of directive in the html of the requested page that forces a page refresh every now and again?
FWIW, the statement about the superiority of Chromium does not match my experience. I certainly recall reading a page on mobile Chrome (iOS) under poor radio coverage and having the whole page replaced after a few minutes with an error about the page being not available.
Apple’s App Store policies state: “Apps that browse the web must use the iOS WebKit framework and WebKit Javascript.”
This means that web browsers can’t implement their own rendering engines; they must embed a version of Safari’s rendering engine. They can’t offer a faster rendering engine or new web features. In effect, each third-party browser on iOS is a different interface around Safari.
This is actually a relatively new "feature" of web browsers. When I was a kid, if a page didn't load completely it would just make do with whatever assets it could grab. Images would be replaced with a stand-in icon and some descriptive text.
4realz are you serious? What is the actual downside of that? As a kid, it made perfect sense to me, and I often would right click the image and press reload or just refresh the whole page. Now whenever images don't load (which is often these days, since cloudfare blocks tor 90% of the time until you load the image in a separate window and fill out their captcha, and even without tor, wireless networks tend to be extremely unreliable), it's not easy to tell whether the page is broken, since it just collapses the spaces where the images would have been.
Further, if you directly view an image and it breaks half way, the browser will hide it and say it's corrupt (and have no "show anyway" button), unless the size wasn't provided, then the browser just thinks it's valid, despite that it could parse the JPEG file and find out that lines of pixels are missing. Calling either of these cases a feature seems very biased.
We aren't even talking about one of the worse problems, which is when a page fails to load, the browser doesn't try to reload it - you have to come back and press reload yourself. I've wasted literally hundreds of hours doing this.
It's the cost of it working at all, at least in terms of it being as accessible as it is:
Making it feasible for people to create websites quickly enough to be worthwhile entailed allowing the tag soup non-standard HTML we see in practice now, and the confluence of desire and technical limitations made plug-ins inevitable.
A "better-regulated" Internet wouldn't have had the Web at all. Remember that, according to the people using it circa 1988, file transfer and hypertext were both solved problems, with FTP and Gopher respectively already in existence. Unstructured hypertext, something Gopher was not really designed for, wasn't especially desired until some random at CERN released WorldWideWeb and httpd to the world.
Oooh, can we turn this in to general annoyances about browsers?
Frickin' Safari on iOS that won't render a page until whatever God-awful custom webfont the designer has specified has loaded. 1 in 20 blog pages I load in Safari load with invisible text, and it just ... hangs.
4realz. For me (firefox on slow connections), those kinds of blogs just take seconds to load, then blank out for a few seconds, then the content is displayed again in a different font. Typically I'd be reading half way through the introduction and then the page turns blank. I usually just close the page at that point since those types of blogs don't typically have any useful information.
Chrome also likes to do the "blank out, then redisplay" stunt. Heh, I'd like a "slow connection" mode (maybe triggered by that "tethered" DHCP option on Android hotspots), which disallows custom fonts as well as images.
Besides all the jokes - which are funny - this is something I posted a bug about before, when working on slow unreliable networks this can happen. You end up reading half the page, and then it tells you it can be displayed.
1 cup unbleached white flour (or 1/2 whole wheat + 1/2 white)
Preheat oven to 400 degrees:
In a large bowl, beat together the eggs,
milk, oil and salt until well blended. Sift
in the baking powder and whisk until foamy.
Quickly mix in the cornmeal and flour.
Beat until the batter is smooth. Pour into
an oiled 10" round cast iron skillet. Bake for
20-25 minutes, or until a knife inserted in
the center comes out clean.
(Okay to freeze the leftovers.)
Once cooled, crumble into bowl, add milk for a breakfast-type cereal.
A serious argument [0] can be made that sugar crept in due to the switch from stone milling to steel rollers circa 1900 which greatly affected the flavor of corn meal due to the amount of the kernel being lost but also the heat generated.
Kind of a double whammy... the heat robs it of flavor which is made up for by adding sugar and also decreases the nutrient value of the meal by milling out the germ.
Huh. Wouldn't it be possible to achieve the same result with a steel mill if its surface was irregular? Sounds cheaper than stone. Won't correct the unripe corn harvest, though.
But understand that typically, American grocery store lard (the sort that comes in shelf-stable buckets) uses partially hydrogenated oils containing trans fats; After destroying the lard industry in a slanderous PR war early last century ("It's digestible!"), eventually the vegetable shortening / margarine industry (Crisco et al) decided they needed something to sell to very poor people and people following an insistent recipe, so they applied their hydrogenation tech to porkfat feedstocks, creating a product that did not need to be refrigerated.
According to current nutritional doctrine, you should not buy unrefrigerated pork fat products because of trans fats, even if pork fat itself is no longer vilified.
Here's a tip that makes the sugar component more worth-while without changing an overall savory dish into something else.
Use that same iron skillet, but preheat the skillet in the oven at 475. Pull it out, reduce the oven to 400, oil the skillet and pour the batter. Bake like normal.
The sugar component makes for a caramelized shell when introduced into a hot skillet quickly that has a nearly non-perceivable sweetness, but adds quite a bit to the texture if serving sliced as a side dish.
Top it off with some honey butter and it's so delicious:
Half a stick of butter
A few tablespoons of honey
Melt the butter and then place it in the fridge for maybe 5 minutes or until it starts to firm up slightly. Take the now semi-solid butter and add honey and whisk (using a fork works fine) for a minute or two until you get the honey well mixed in. Spread on warm cornbread and enjoy.
You know, I've been looking for something fun to eat all day. Not because I'm hungry but because I like to cook and I've been in a lull lately.
I have this in the oven now and this thread as put some life into my kitchen today. Thank you so much for this post, it's been the highlight of my day.
As a side note: This only strengthens my choice of having well seasoned cast-iron pans in my kitchen. They are truly my best piece of cookware and they're some of the cheapest too.
I loathe sweet cornbread, but 1 tsp honey didn't make it sweet to the taste and may have helped it get a nice crust. As did cooking it for just 10 minutes on very hot coals of course.
I think next time I'll try with much less (or no) wheat flour.
I'm of the impression that proper southern cornbread is the version without sugar (as well as cooked in a preheated cast iron skillet that goes back into the oven), whereas northern cornbread has sugar. (Wikipedia mostly agrees, at least on the sugar front).
This caused me problems when I tried to make cornbread on my own for the first time after moving north for college. It wasn't as good as I remembered from home until I realized I had to take out the sugar.
In terms of things like "sweet tea" or Pepsi, that's very true. But having grown up in the south, and still living there, I've never known it to be commonplace to make cornbread sweet here. There's also a deep divide among southerners on whether BBQ sauce should be sweet or not.
Personally, even being from eastern NC where vinegary based BBQ rules supreme, I prefer the sweeter style of BBQ. YMMV.
I think the title change was in poor taste here. Most people don't really care about this issue for a browser in of itself, but the mailing list dialogue made the link interesting.
And as a practical matter, I believe the title change led directly to downvotes for my cornbread recipe and perhaps the recipes that other people posted last night. Mine was at +4 last night, now down to +2.
I try not to worry much about downvotes, but I do use them as a signal to help me understand what kinds of comments are appreciated or not.
I often read the HN threads before looking at the original article, and I can easily imagine reading these comments after the title change and thinking, "Why are these people talking about cornbread recipes? What does this have to do with page loads or Iceweasel? Downvote!"
In this case, though, "cornbread" was right there in the title when we started sharing our recipes last night, and the original article talks about baking cornbread and links to a recipe. So the recipes weren't entirely irrelevant at the time we posted them - and the initial upvotes seemed to confirm that - but the title change sure makes them look off-topic.
I actually meant to mention this in my original post but forgot: the first comment I saw when I opened this last night was your recipe. I thought that was a good indicator of where the discussion was going before the title change altered the tone.
As someone who's writings have been on the front page a few times, I've wondered how I can protest the heavy handed title mods. The best idea so far is to wait for one of my pages to "make it" here and then stealthily change my title to something extremely clickbaity.
Anyone have suggestions for titles? "Read this One Weird Article; HN Mods Hate It!" is my personal favorite.
"This place is nicely remote, and off the grid, relying on solar power. I only get 50 amp-hours of juice on a sunny day, and often less than 15 amp-hours on a bad day. So the whole house runs on 12 volt DC power to avoid the overhead of an inverter; my laptop is powered through a succession of cheap vehicle power adapters, and my home server runs on 5 volt power provided by a USB adapter.
"When power is low, I often hack in the evenings by lantern light"