Pointers Are Complicated, Or: What's in a Byte? (2018) - <AUTHOR> https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html <comment><USER2> Also potentially relevant: Ralf, or I should say, Dr. Jung, recently completed a PhD, which I'm sure will have a lot more fascinating material for those interested in this paper. I'm hoping to find time myself to read it, but I seem to spend too much time on sites like Hacker News...

[https://www.ralfj.de/blog/2020/09/03/phd.html](https://www.ralfj.de/blog/2020/09/03/phd.html)

</comment><comment><USER3> The article doesn't touch on this, but in C pointer types are also the only kind that can be invalidated without any apparent change to their value:

      void *x = malloc(...);
      free(x);
      if(x); // undefined behavior

Note that this isn't about dereferencing x after free, which is understandably not valid. Rather the standard specifies that _any_ use of the pointer's value itself is undefined after being used as an argument to free, even though syntactically free could not have altered that.

This special behavior is also specifically applied to FILE* pointers after fclose() has been called on them.

If there is some historical reason / architecture that could explain this part of the specification I would be interested to hear the rationale, this has been present in mostly the same wording since C89.

<comment><USER4> My gut instinct is as follows:

      void *x = malloc(...);
      void *y = malloc(...);
      assert(x != y); // standard guarantees this [1]

Yet it's fairly reasonable that:

      void *x = malloc(...);
      free(x);
      void *y = malloc(...); // malloc reused x's allocation here.

So, in effect, guaranteeing that the results of two mallocs can never alias each other, while allowing the implementation to reuse freed memory, requires semantically adjusting the value of a pointer to a unique, unaddressable value.

[1] I think, but I'm not sure which versions of C/C++ added this guarantee

<comment><USER5> This would be kind of hilarious if true.

It seems like they could have just said: malloc won't give you a pointer that overlaps with the storage of any _live_ malloc'd object. Such a malloc is implementable without too much trouble. But instead, they gave a stronger guarantee--that all malloc'd pointers would be "unique". It would be unboundedly burdensome on the implementation to meet this property, so what do they do? Update the standard to offer the achievable guarantee? No! They add a new rule, ensuring that it's impossible to _observe_ that the stronger guarantee is not met without doing something "illegal". Instead of getting their act together, they have elected to punish whistleblowers.

<comment><USER5> On second thought, the choice they've made isn't as sadistic as it sounds. I was thinking of the standard as a contract between the language implementor and the programmer, but actually it is a contract between the language implementor, the programmer, and arbitrarily many other programmers. The stance they have chosen mandates a social convention, that the names of the dead will never be spoken. If everyone builds their APIs with this covenant in mind, it makes it possible to use pointers as unique ids (for whatever that's worth). C has never had much in the way of widely-followed social conventions, so practically speaking, the only way to ensure everyone knows they can depend on other programmers behaving this way is for the compiler to flagellate anyone who steps out of line.

</comment></comment></comment></comment><comment><USER6> I read the article and I am not convinced by the author arguments.

He is talking about edge cases. I've been using C and C++ for over 20 years now, for both low level and high level stuff, and I never needed to know about those edge cases.

And I think you don't want to know about them, you don't need to know about them to write good code.

Nitpicking about edge cases tradeoffs made by compiler designers and language standards decades ago is like attacking under the belt, in my opinion.

<comment><USER7> Can you clarify what you disagree with in the article? The author wasn't saying programmers need to understand all the complexities of pointers to write good code, nor was he saying anything about the quality of those languages.

Also, it is incredibility defensive to accuse the author of "attacking under the belt" when his observation wasn't aimed at any specific language.

<comment><USER6> From my opinion, this is a way to try and push the adoption of Rust by shading an unpleasant light on the current contender : C/C++

An other way to say is that this is propaganda.

<comment><USER8> That doesn't make sense, given:

> Both parts of this statement are false, at least in languages with unsafe > features like Rust or C:

The two languages share these features, which is the whole reason this is being written in the first place.

<comment><USER6> Unsafe as a language feature is something that was invented by the Rust design team. And I don't think there is much value to this concept.

This is like calling code "ugly" and saying that's a feature.

Pointers are not unsafe.

</comment></comment></comment></comment></comment><comment><USER9> In addition to all the things mentioned above, there's also another kind of byte: structure padding. Nobody really knows how to deal with it, and it has extremely strange rules–it's kind of uninitialized in some cases, but you can give it a value sometimes…and sometimes you can't, or not in any way that sticks. It's truly strange stuff, and its exact nature is still being worked out.

<comment><USER10> Pack your structs to not have padding? The probable reason it sometimes works is purely how the compiler decides to do the copy. Anything that relies on implicit padding is horribly broken software.

<comment><USER9> I think you might be misunderstanding my comment, I'm not complaining about struct padding causing issues in my code, I'm saying the standard is wishy- washy about it. This can be problematic when you are doing things like memcpying a structure, or trying to zero it out before sending it somewhere else. (And, FWIW, there is no standard way to disable struct padding, and doing so will likely generate slower code anyways.)

<comment><USER10> How is the standard not explicit? copying with padding doesn't need to copy the padding at all or can if it's faster, memcpy is a intrinsic the compiler can copy whatever it deems wrt padding.

<comment><USER9> Because there are certain cases in C11 where padding can be legally observed because it is defined to be set to zero–brace initialization, for example. It is unclear what happens in this case when you do anything with the memory other than read it (for example, storing to a structure member, based on the current reading of the standard, may make padding indeterminate again–plus, is "memcpy" a "read"?). See here for some of the questions raised: [http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1793.pdf](http://www.open- std.org/jtc1/sc22/wg14/www/docs/n1793.pdf)

</comment></comment></comment></comment></comment><comment><USER11> It always bothered me that C, and similar languages which are termed "low level", aren't actually compiling to anything like the _actual_ low level hardware anymore. The match used to be quite close in the 1980's, but nowadays the "machine code" which is "run" by a CPU is actally a kind of virtual byte code language with an interpreter implemented in microcode inside the CPU. But this byte code has flaws: For instance, this virtual machine byte code language has little or no sense of memory caches (of any kind), out-of-order execution, branch prediction, etc. Both the compiler and the CPU knows (or could know) about these things, but the compiler has no way to communicate this to the CPU other than using this '80s style byte code which does _not_ have these concepts. It's like talking about advanced mathematics using nothing but words in "The Cat in the Hat" – a rather narrow communication pipe.

I'd always imagined that as parallelism rose, a new model of virtual machine would rise with it, with its own "assembly" (i.e. low level language closely tied to the machine), which would in turn be the target of a compiler of a new parallel-by-default high level language. Alas, this has not happened.

<comment><USER12> > out-of-order execution

This broke me. I loved C++, I love pointers and shared memory, synchronization etc but optimisations finally creeped me out enough to switch to Java.

<comment><USER13> I don't get the motivation here. It's all invisible to you, how is it being weird enough to make you not want to use it?

</comment></comment></comment><comment><USER14> Discussed at the time: [https://news.ycombinator.com/item?id=17604402](https://news.ycombinator.com/item?id=17604402)</comment>


Comparing the Closure compiler to Uglify - <AUTHOR> http://www.syntaxsuccess.com/viewarticle/closure-compiler-vs-uglifyjs <comment><USER2> An _enormous_ amount of the shavings and inlining that the Closure compiler is capable of assumes that you write your code according to rules that reduce ambiguity and dynamic features in your code. Variable names get mangled, so things like using string names for properties is out the window, which means invoking methods by string names is out as well. It uses objects for namespaces so things like `Shape.Quad.Square` get renamed to `Shape$Quad$Square` before getting minified to some one-letter variable, so don't use `this` outside of constructors or prototype methods.

There's a larger list of restrictions at [https://developers.google.com/closure/compiler/docs/limitati...](https://developers.google.com/closure/compiler/docs/limitations)

If you _do_ write code obeying these rules (check out the closure library), or you use something like ClojureScript that generates straightforward, monomorphic, closure-compiler-compatible js, the payoff in both file size and parse/execution performance is pretty great.

<comment><USER3> Closure Compiler was indeed written to target Google's very specific rules on how to structure code and name stuff. _However_ , Closure still does a better job than Uglify and other minifiers even if you don't do this. Its basic set of optimizations are generic and won't break code (unless you enable the advanced mode, which has been historically iffy).

The only downside is that it's slow. Like really slow. It takes about a minute to minify our app.

Edit: Looks like Uglify has gotten better lately. I'll submit a separate top- level comment.

</comment></comment><comment><USER4> Clojurescript a lot of its success to the use of the Google Closure compiler, which really shines when you transpile because you can ensure that the resulting js is suitable for the Closure compiler.

<comment><AUTHOR> Yes. Angular is working on a similar approach. Great results so far.

<comment><USER5> I read there was a TypeScript Compiler that would output CC copatible type annotation comments.

<comment><USER6> Tsickle by Angular does that: [https://github.com/angular/tsickle](https://github.com/angular/tsickle)

It wraps the TypeScript Compiler and outputs CC compatible type annotation comments.

<comment><USER7> \- It's being built by a handful of people (I remember seeing the original author complain he doesn't really have the time for it)

\- It's a hack on top of TypeScript compiler

\- It gets broken by TypeScript upgrades and is usually several weeks behind TS version upgrades.

I'd be really wary using it in production

<comment><USER8> [author here]

\- Pretty much everything you use (e.g. Angular or React or Babel or Webpack or equivalents in other languages) is being built by a handful of people

\- It interacts with TypeScript in a way that tends to be more sensitive to changes, but being some weeks behind the latest release of a compiler is not the end of the world, and we do continuously upgrade

I agree you should be wary of using it in production though because it's not really user-friendly yet. Though if you can figure it out it does work and some people are successfully shipping some apps.

<comment><USER7> I sounded curt, but I think tsickle is awesome.

I can't justify bringing it in in our current setup though :(

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> I would love to see it used with real-world examples. There are two main situations IMO where this would be useful:

\- For developers creating websites. The cost of set-up would be _high_ because you'd need concatenation+minification+etc in place, so I'd love seeing some examples to see whether or not is worth it. From what I know, this could be similar to tree-shaking, so there _could_ be huge gains here.

\- For library creators. However the top-most variables would have to be preserved, since other developers need to use them (which seems possible[1]), so I'll be trying it out.

I am also wondering about the performance boost for JS (besides file size) and whether this would be useful for something like Node.js or not (free performance). If anyone has more information please share it.

[1] [http://stackoverflow.com/q/3025827/938236](http://stackoverflow.com/q/3025827/938236)

<comment><AUTHOR> I have a comparison using an Angular app here: [http://www.syntaxsuccess.com/viewarticle/angular- application...](http://www.syntaxsuccess.com/viewarticle/angular-application- bundles)

<comment><AUTHOR> Here is a little bigger app as well [http://www.syntaxsuccess.com/viewarticle/migrating-my- angula...](http://www.syntaxsuccess.com/viewarticle/migrating-my-angular-demo- to-use-the-closure-compiler)

</comment></comment></comment><comment><USER3> Uglify has actually gotten better the last few years, but Closure is still faster on multi-core machines. Here's on one of our apps:

        $ wc -c index.js | grep -v total
        9320511 index.js

        $ cat index.js | time closure-compiler \
          --warning_level quiet \
          --third_party \
          --jscomp_off es3 \
          --compilation_level SIMPLE_OPTIMIZATIONS \
          --language_in ECMASCRIPT5 > index.js.closure 2>/dev/null
        33.54s user 0.93s system 369% cpu 9.336 total

        $ cat index.js | time closure-compiler \
          --warning_level quiet \
          --third_party \
          --jscomp_off es3 \
          --compilation_level ADVANCED_OPTIMIZATIONS \
          --language_in ECMASCRIPT5 > index.js.closure-advanced 2>/dev/null
        33.54s user 0.93s system 369% cpu 9.336 total

        $ cat index.js | time node_modules/.bin/uglifyjs \
          --screw-ie8 --mangle --compress - > index.js.uglify 2>/dev/null
        18.88s user 0.24s system 103% cpu 18.475 total

        $ wc -c index.js.*. | grep -v total
        1750478 index.js.closure
        1515331 index.js.closure-advanced
        1763350 index.js.uglify

        $ gzip -9 index.js.*

        $ wc -c index.js*.gz | grep -v total
         369749 index.js.closure-advanced.gz
         397468 index.js.closure.gz
         387896 index.js.uglify.gz

(Closure 20170218 on Oracle Java 8, uglify-js 2.4.19 on Node 6.8.1, running on MBP Pro 2015).

It's worth noting that Closure is heavily parallelized, and uses 50% of the time to complete by using all 4 cores at almost 100%. If you only have one core, though, Closure will be much slower.

Our apps don't use any of Google's conventions, but Closure is still able to minify as well than Uglify. I don't know if there are any specific Closure or Uglify options that could make a bigger difference.

Also worth noting that we only minify for staging/production, not during development, which would incur too much of a performance hit.

We've always used Closure, and been very happy with it.

<comment><USER10> Exact inverse of my situation- CC is 3-4x slower on our codebase.

</comment></comment><comment><USER11> I wrote about combining Closure and Uglify, for ClojureScript here: [https://blog.jeaye.com/2016/02/16/clojurescript/](https://blog.jeaye.com/2016/02/16/clojurescript/)

The result was about 20% savings ungzipped; 10% savings gzipped.

</comment><comment><USER12> I struggled quite some time with Closure Compiler, and in particular with CG's broken/inofficial support for CommonJS modules. I succeeded by pasting all module code into one file, removing `require()` calls and presenting only the single concatenated file to CG (and the minification and linting results were very good).

Granted, this is only possible if you reference modules/classes uniformly by the same name across your source, rather than using CommonJS "import as", and it only applies if you have no or few external dependencies which isn't realistic in the general case. Supposedly, using ES6 modules fixes this but I haven't checked yet.

<comment><USER3> You should use Browserify or Webpack to bundle code together like that. They will handle the import chains for you and give you a single file that can be passed to Closure without any issues. Browserify is particularly easy to get going with; Webpack requires a bit more config.

Edit: See this comment: [https://news.ycombinator.com/item?id=13910621](https://news.ycombinator.com/item?id=13910621).

</comment></comment><comment><USER10> In my tests on my companys code base Closure Compiler wasn't worth it.

It did however save a few kilobytes - after gzip - but took around 3-4X longer to run (much worse if you use their JS implementation for Webpack)

If time to build is not an issue for you, and you're ok with the java dependency, then it might be worthwhile.

<comment><USER13> What about parse time? This is arguably an equally important metric. Make sure throttle CPU and network to simulate a budget smartphone when you test.

<comment><USER14> If you have customers on ancient smartphones and the engineering budget to manage the complexity ... go for it! :D

<comment><USER13> We're not talking ancient here. The mobile test on Webpagetest ([https://www.webpagetest.org/easy](https://www.webpagetest.org/easy)) uses a Moto G4, which is less than a year old. But this test is punishingly brutal on most JavaScript-heavy websites. If you can make wins on parse time, you absolutely need to be pursuing them.

<comment><USER10> Most JavaScript heavy sites in the real world are that way due to 3rd party ad code (sad fact of the modern web) and Closure Compiler won't affect those

</comment></comment></comment></comment></comment><comment><USER15> Can TypeScript or Flow do similar optimizations? Or is there Type Script to Closure Compiler compiler?

It baffled me a bit that someone in comments on OP site abbreviated Closure Compiler as GCC. Imagine my surprise reading that GCC is written Java.

<comment><USER16> Here is a Typescript discussion on the issue: [https://github.com/Microsoft/TypeScript/issues/8](https://github.com/Microsoft/TypeScript/issues/8)

</comment></comment><comment><USER7> UglifyJS takes about 5 minutes to setup, and it works.

It's impossible to reliably set up Closure compiler if you are outside of Google's infrastructure and/or outside of Google's Closure Library.

End of comparison.

<comment><USER3> Luckily, that's not correct.

Just pipe your JavaScript into Closure and it will minify it as easily as Uglify. We're migrating to Webpack, but we've been using this for about 4 years:

        node_modules/.bin/browserify index.js | closure-compiler \
          --warning_level quiet \
          --third_party \
          --jscomp_off es3 \
          --compilation_level SIMPLE_OPTIMIZATIONS \
          --language_in ECMASCRIPT5 \
          --create_source_map "index.min.js.map" \
          --output_wrapper "%output%//# sourceMappingURL=/index.min.js.map" \
          > index.min.js

This generates a minified file plus a source map.

Part of the magic happens in Browserify [1], which generates a single file from all your inputs, taking care to follow the import chains in the correct order. If you have ES6 code, you'll just install Babel and add "-r babel- register" to the Browserify command line.

I read the rant in your other comment, and I don't understand what it was that you struggled with. You certainly don't need to follow Google's Closure conventions in order for it to optimize and minify your code effectively. We don't; we use React and Babel with all the ES6 bells and whistles, but none of the Google conventions.

[1] [http://browserify.org](http://browserify.org)

<comment><USER7> We moved away from browserify and the need to concatenate everything about two years ago, and we're definitely never going back :)

So maybe concatenating everything works with Closure Compiler. I don't know. We couldn't make it work with their advertised support for node_modules.

<comment><USER3> Why do you need to minify if you're not bundling?

<comment><USER7> We are bundling. That's the last step _after_ all the code has bin babelified etc. So Closure compiler will do nothing, really. And it fails spectacularly on webpack's helper functions that are bundled in (especially if the functions are exctracted to the HTML file)

</comment></comment></comment></comment></comment><comment><USER17> Is a 5-line example really a great basis for a comparison?

<comment><AUTHOR> I kept it simple to try to illustrate the main difference between the two approaches.

<comment><USER17> Babili actually has a pretty complete comparison which compares the compression rates of major libraries.

[https://github.com/babel/babili](https://github.com/babel/babili)</comment></comment></comment>


Show HN: Reddit Top Books – Weekly list of the Most Popular Tech Books on Reddit - <AUTHOR> http://reddittopbooks.com <comment><USER2> Very similar to HackerNews Books: [https://www.indiehackers.com/businesses/hacker-news- books](https://www.indiehackers.com/businesses/hacker-news-books)

At $300/month, it's OK side money, especially if it's automated.

<comment><AUTHOR> Yes, I even mention HackerNews Books in the `About` section as my main inspiration for this site! I wanted to try out Django and this seemed like a fun little project for starting.

</comment></comment><comment><USER3> For a cool writeup of how to automate an Amazon affiliate site (like this one) that scrapes Reddit for links, check out this post: [https://blog.cloudstitch.com/shut-up-and-make-me- money-96c32...](https://blog.cloudstitch.com/shut-up-and-make-me- money-96c322db0c6a)

<comment><USER4> Be forewarned: This is a promotion for a paid service.

</comment></comment><comment><USER5> Similar to [http://toptalkedbooks.com/](http://toptalkedbooks.com/), haha

</comment><comment><USER6> I'd be really interested in this for non-tech books as well. I'd love to have a fast way to find new fantasy books.</comment>


Writing Maintainable Code at Speed - <AUTHOR> https://highgrowthengineering.substack.com/p/writing-maintainable-code-at-speed <comment><AUTHOR> Hello, author here. I've written some thoughts about how to balance speed with maintainability when writing code. Thoughts and feedback appreciated.</comment>


Why Paper Jams Persist - <AUTHOR> https://www.newyorker.com/magazine/2018/02/12/why-paper-jams-persist <comment><USER2> Exciting fact: Similar jams happen in hot steel rolling mills too. The YouTube videos are just prettier: [https://www.youtube.com/watch?v=DVZ1DY0r4y4](https://www.youtube.com/watch?v=DVZ1DY0r4y4)

In general the rolling mills call it a "cobble" when a whole or partial bit of steel escapes the rolling mill. Lots of exciting videos.

<comment><USER3> That's pretty insane. Wow, look at those coils of hot metal. It's interested how much of it is still hot after they clear the jam and run it through.

I remember years ago hearing about how the US mint misprinted over a million and had to destroy it (and on the Colbert Report, he joked about how them destroy it by burning it in front of poor people). We were talking about it at a party and someone asked, "surely they noticed? Why didn't they shut it down?" An engineer in our group said, "Have you ever been in a factory? It's so fast!" He worked in a toothpaste tube factory where you'd see hundreds of tubes come out every minute. If something went wrong, you'd have to wait for the whole pipeline to clear. Fab shops in China are even more insane.

I wonder if the mill would just sell those sheets at a reduced price as low grade/for non-visible construction or if they re-melt them down and run them again.

<comment><USER4> On the speed front, I concur. Back in 1998, when I was on summer break from university, I worked in a wines and spirits bottling plant. One day the labelling machine started applying wonkey labels to the wine bottles and a couple of hundred had gone through before the guy running the machine had noticed.

They weren't wildly misaligned, but far enough from true that we had to wash them off and run them through the line again. Took a couple of us most of an afternoon to sort it out.

<comment><USER5> At what point is it just more economical to sell them at a reduced price to restaurants (where the customer might not see the label)? I'm sure the guys (you) peeling the labels are probably the lowest paid in the factory but a few staff doing the work for the whole afternoon adds up.

<comment><USER6> At $10/hr for 2-3 people, assuming they could clear up 30 bottles an hour you're only talking $1/bottle. I don't think that small of a discount on a bottle of wine would encourage a restaurant to buy a veblen good that didn't look perfect.

[1][https://en.wikipedia.org/wiki/Veblen_good](https://en.wikipedia.org/wiki/Veblen_good)

<comment><USER5> This is totally an n of 1 type story, but perhaps relevant nonetheless.

I worked at a bar during university during a time where the popular beer sale would be "28 bottles for the price of 24". The bar owner would send me and a few guys in a truck to a beer store in another town to buy as many cases as the truck could handle. This was illegal as we would sell it at the licensed bar (all liquor was supposed to be purchased with the license, for which the sale wasn't applicable too). So the owner was willing to risk legal action for 4 free beers (x50 cases or whatever).

The point is... restaurant owners sometimes go to great lengths to save a few dollars.

</comment></comment></comment></comment></comment></comment><comment><USER7> It's even worse in our low-end inkjets, which are made of plastic parts and toy motors and are still expected to duplex-print on the cheapest crap paper imaginable. Our FW devs spend a lot of time perfecting the PID loops and mech sequences to make this happen. But do we get any thanks for that? Noooo...

Love that New Yorker article, though. I grew up reading this magazine in the 80s but drifted away. These great articles straddling tech and culture became too few and far between.

</comment><comment><USER8> This is why I love the New Yorker. You don't see enough of this kind of long form journalism, shedding light on seemingly mundane issues that you'd never imagined could be so interesting.

The historical perspective, in particular, was great. But what took this to another level was detailing just how big the challenges are, and how enthusiastic the engineers are in trying to solve them. Even giving a sense of vicarious excitement from the descriptions of their attempts at problem- solving.

<comment><USER3> I dunno. I think this is one reason I stopped reading the Atlantic/Harpers/New Yorker. I mean, it is better than sensational TV where they take 45 minutes to get to the punch line where they could have explained it in 5 min. It's not even 40 min of interesting facts or history; just mostly commentary and talk to draw things out.

I do realize this article is different; there is a lot of historical fact and context which helps create a narrative. It has its advantages. Maybe I'm just getting old. I read a lot of novels and I'd rather spend the time on that type of narrative in a novel or even a non-fiction book than a news article.

People may criticize the YouTube generation, but it has helped in content creators who get a lot of information over in a very concise way (Kurzgesagt In a Nutshell, Smarter Every Day and Wendover Productions come to mind).

I think the opening of the historic paper jam made me want to fall asleep. The later office space references and Xerox design became more relevant. Even then, I feel like I don't read these articles the way I did back when I bought a physical Harpers from the book store. It's a lot of content, and in the scrollable world we just end up skimming more these days.

<comment><USER9> >People may criticize the YouTube generation, but it has helped in content creators who get a lot of information over in a very concise way (Kurzgesagt In a Nutshell, Smarter Every Day and Wendover Productions come to mind).

Reading the same info (in a non-narrated way) would be much faster. Also it's often concise over exactitude or neutrality. I can't sit through these videos, boring or caricatural. At least the New Yorker is sold as an enjoyable distraction, and I find great pleasure in reading nice writing.

</comment></comment></comment><comment><USER10> Many, many years ago I had a student job with a small company doing industrial document finish, enveloping, and large-scale mailings. Apart from a still eaily induced paper eczema, the one thing I took with me was a rather comprehensive facility with the black magic of paper handling. Not an ounce of explicit science in it, but an awful lot of _feel_ : When and how much to air and flex; where a grounded length of copper wire could work wonders; how much or how little moistening to apply, and where; how too touch the stream of paper and somehow know by the feel of the tip of your finger whether something would probably jam within a minute, and which tiny speed-adjustment up or down would probably forestall the disaster; when to to loosen or tighten this or that set of rollers because nightshift and the air getting cooler et cetera et cetera.

To this day I never just bang a fresh stack of paper in the printer tray. The full gymnastics of airing, flexing, feeling, airing and flexing again. I'm often laughed at. But my papers never jam!

<comment><USER5> I've seen people do this before, I always just assumed it was to make sure the pages weren't stuck together, and therefore reduce the chance of 2 sheets being pulled together.

<comment><USER10> Well, it is, sort of. But in a fast moving production line, it could make a huge difference in jam propensity whether the sheets were fed by somehow with a nice touch or not.

</comment></comment></comment><comment><USER11> We take sheets of dried wood pulp, stack them so loosely you can always see a few that aren't 100% aligned with the rest, then feed them through a series of unlubricated rollers inside a machine that's usually indifferently maintained and clogged with dust, all while deliberately exposing them to heat and static electricity and spraying their surface with goopy ink or powdery toner.

The surprise isn't that they jam occasionally, it's that we ever get anything printed at all!

</comment><comment><USER12> Coincidentally, just last night I was telling my wife how impressed I am with my work's copier/printer machine.

It's about the size of a 1980's copy machine, but my department easily prints a minimum of 5,000 color pages with it each day. Some days it's double or triple that. Sometimes with staples.

We go through five massive toner carts each week. They're about the size of a fire extinguisher.

In six months, I've seen exactly ONE paper jam.

I told her I thought maybe they'd figured out this whole printing thing finally. But I guess TFA says I'm wrong.

<comment><USER13> What's the make and model?

<comment><USER12> Don't know the model, but it's a Kyocera. Before this job, I'd only been exposed to that brand as one of the cheap printers for the Commodore 64. I guess it's come a long way!

</comment></comment></comment><comment><USER14> I enjoyed the article. Just want to point out briefly that the explanation given in the article of how airplane wings create lift is incorrect.

[http://www.explainthatstuff.com/howplaneswork.html](http://www.explainthatstuff.com/howplaneswork.html)

<comment><USER5> I think they just messed up what side is flat, right?

<comment><USER15> No, symmetric airfoils generate lift just fine, and if you were going to spend half your time upside-down, you'd use one.

Making it asymmetrical merely makes it more efficient to generate lift in one particular direction (similar to how glasses lenses are asymmetrical to reduce distortion).

Furthermore, pretty much no airfoils have flat sides, in nature or in engineering[1]

The wing, when placed in airflow, disturbs the air in such a way that the pressure on top of the wing is lower than the pressure below the wing, generating net lift. This isn't a very satisfying description of lift, since it just begs the question of "how/why does it disturb the airflow in such a manner" and the short answer is "we put different shapes in a wind tunnel and measured" with the longer answer being "you don't know enough math to get a good intuition of that"

[edit]

After reading the article, the article _did_ get lift right for the case of the paper though. Jets of air behave exactly as they say, and you can feel something similar by touching the back of a spoon to the stream of water from a sink; it will get pulled towards the stream of water (or just put a piece of paper on a table and blow over it). A few planes use blown flaps[2] to help get a similar effect (the introduction of a jet of air, which "hugs" the wing helps direct the airflow of the larger mass in the direction you want).

1: [https://en.wikipedia.org/wiki/Airfoil#/media/File:Examples_o...](https://en.wikipedia.org/wiki/Airfoil#/media/File:Examples_of_Airfoils.svg)

2: [https://en.wikipedia.org/wiki/Blown_flap](https://en.wikipedia.org/wiki/Blown_flap)

<comment><USER16> >Because the top side of an airplane wing is flat, while the underside is curved, the air above moves faster than the air below, and the wing rises.

That's what the article says, but it's usually the underside that is flat and the top is curved.

<comment><USER15> In reality usually neither side is flat.

<comment><USER17> A flat bottom wing gives you nice stall and landing characteristics. Very small, 2-4 seat, trainer airplanes have them. (Cessna 150, J3 Cub)

<comment><USER15> I wouldn't call the Cessna 150 flat, as it has visible lower-camber, but you are right about the J3 Cub; it's super flat on the bottom.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> I'd like to see another article on why in 2018 every meeting seemingly has to start with 5 minutes of fiddling with the screen projector.

<comment><USER19> Is that still a thing? For small meeting rooms (less than 10 people) our offices have large screen TVs (60 inch maybe?), and for larger meeting rooms it looks like there are NEC projectors (I just checked 1). I don't recall a project issue within the last 6 years.

<comment><USER20> Projector fiddling has been replaced with VTC fiddling. I hate Polycom/Skype with a far greater passion than any printer.

</comment></comment></comment><comment><USER21> I still hate printers, and their jams, but I must reluctantly appreciate the engineering behind them after reading this.

This seems quite clever:

'Corrugating is when we put an intentional wave in the sheet, like in a piece of corrugated cardboard," Vicki Warner explained. "It adds stiffness." The plan was to corrugate the sheet lengthwise by running it over a line of rollers turning at variable speeds before "flying it" into the stacker. If a physical fix was necessary, a part might be 3-D-printed and installed, on- site, by one of the engineers.'

<comment><USER22> I have been a part of this process at Xerox.. it works quite well.. I've been involved in a number of different aspects of it as well. I've been the source of some of these fixes, I've been the source of some of the issues, and I've been involved in the investigations to solve them. Xerox has a few different labs for testing different things.

The "stub point" is a common thing, and can be very, very difficult to pinpoint. They had one specific finisher that kept jamming when you printed to the top tray. It didn't jam 100%, it was pretty intermittent. Well, this finisher had been in another lab for a few weeks or so and they couldn't find the source of the jams or a pattern to them. I had the finisher installed on one of my machines in the 3 days I'd solved it. There was a small stub of plastic on a flag for a sensor. The flag sits in the paper path, and when its moved, the sensor changes state. So this flag has an pretty smooth surface so as to not catch the paper, but somehow this one got a little nick in it. Enough to cause a jam when a sheet ran right into the nick. I filed it down and the machine never jammed again.

We had another issue with a printer at a customer site and the issue dealt with static electricty. a 30kv ESD gun and the inside of a printer.. we still never solved the issue.

</comment></comment><comment><USER23> I'm surprised that Xerox pays engineers to do all this, when so many companies would pay their lawyers to make it someone else's problem when an odd type of paper stock jammed in tropical weather. Making custom parts and flying out to fit them in production machines? I thought technicians only got to do that during wars. I suppose you might do it when the machine is the one that prints the price labels for Walmart, though.

<comment><USER24> I don't know about Walmart but here at Target we just use some random small business Epsons for the signing and Zebras (previously Monarchs) for the price strips and stickers

<comment><USER25> Zebras are indestructible. It's what Amazon uses in their warehouses for everything. I was looking for a label printer and my options were a new dymo label printer from 2015 or a zebra released 15 years prior. The zebra still won.

<comment><USER26> They're also a lot of fun to code against, if you're like me and have a thing for ancient serial cable text protocols designed by electrical engineers.

<comment><USER25> I haven't coded against the Zebras but I have against their counterparts from Epson with ESC/POC and fully concur. It's like a throwback to the 80s or early 90s.

</comment></comment></comment></comment></comment><comment><USER27> > (Before railroads transformed the transportation of lumber, logjams had to > be addressed by "jam breakers"—experts who spotted and removed the "key > logs" jamming up the river.)

River transportation of lumber kept going long after railroads came along. Jam would be broken using dynamite sticks.

Here's a movie on the driving of logs on a river in the 1950s: [https://www.nfb.ca/film/drave/](https://www.nfb.ca/film/drave/) Driving only stopped in the 1980s on that river.

<comment><USER6> Rivers are still in use for moving log booms today - you can see them on the Fraser river and other places in and around Vancouver BC - although they tend to be more orderly, with strict regulations around the logs being properly boomed and contained..

</comment></comment><comment><USER28> The "Secret Life Of Machines" episode about the photocopier is also illuminating: [https://www.youtube.com/watch?v=S2NIAD5qn7E](https://www.youtube.com/watch?v=S2NIAD5qn7E)

<comment><USER3> Wow, that's really interesting. I didn't realize that's where the term "blueprint" came from.

</comment></comment><comment><USER29> I work for a major ICT provider that sells about everything enterprise related, from servers to storage systems, laptops, scanners, etc. In terms of customer support the printers are the absolute worst: usually it's always a critically important since they're used to print the labels for factory outgoing and if they stop for one hour it's millions of euros lost. This means the ticket will be Priority 1 and everything needs to be solved within minutes or else people will freak out since there's a whole factory plant jammed with cars, tires, whatever, that can't leave the factory without the printed stamp.

</comment><comment><USER30> I wonder if we could go jam-free with Continuous Stationary ( [https://en.wikipedia.org/wiki/Continuous_stationery](https://en.wikipedia.org/wiki/Continuous_stationery) ). That paper with the holes on both sides from the 80s, and some legacy systems today.

It seems really helpful, but I'm not sure which problems discussed it would actually solve.

<comment><USER31> Had a dot matrix printer that used continuous paper. Notorious for jamming. Usually something getting stuck on the little holes, or the perforated sides tearing mid-print.

<comment><USER32> The worst was when it lost traction, shredded the holes, usually in a tangle of paper.

There'd also be cases where it kept pulling on the holes but those separated and got gummed up really badly.

When you try and tug the pages out they're all perforated so you get, at best, a single page. It can be a lot of work to clear a jam.

Most people think of dot matrix printers as slow, lumbering things that would take measurable time to print a single line. The industrial ones, enterprise grade, made by companies like IBM were dizzyingly fast, pages per minute, so if a jam happened it was usually severe. Most had multiple print heads to speed up printing.

These also used much wider paper than normal for things like accounting reports. When they jammed, they _jammed_.

</comment></comment></comment><comment><USER33> Inst this easy to solve by not feeding sheets, but from a role and cut after printing? Cheaper production and transportation.

</comment><comment><USER34> Page wide, Precision core.</comment>


A 'self-eating' rocket engine could put satellites in orbit more easily - <AUTHOR> https://phys.org/news/2018-05-aim-stars-rocket.html <comment><USER2> Here's the paper, complete with a cutaway diagram of the engine: [https://eprints.gla.ac.uk/155610/7/155610.pdf](https://eprints.gla.ac.uk/155610/7/155610.pdf)

<comment><USER3> Much more sane than the phys.org write-up. The advantage of this isn't "would consume its own structure during ascent" (what does that even mean??), it's that this would have the simplicity, cost, and storability of a solid rocket with the throttleability of a liquid rocket.

(Side note: Great caption on figure 5. "Second firing. The engine was extinguished by an explosion at 142s.")

<comment><USER4> Phys.org is a low value website that republishes press releases, in this case this one: [https://www.gla.ac.uk/news/headline_586616_en.html](https://www.gla.ac.uk/news/headline_586616_en.html)

<comment><USER3> Aaaah. Didn't know the source.

Also, I find it funny that it's the UK partner that published the press release and the paper, even though the actual research was done in Ukraine (where there's a lot of Soviet space industry legacy) and the paper seems to indicate that the Glasgow contribution was just to give them modern instrumentation.

</comment></comment></comment></comment><comment> chroem- This is pretty neat. It would make staging and reusability a moot point if the entire launch vehicle was an engine attached to an expendable fuel rod with a payload adapter on top. You could recover the engine fairly easily since it's so compact. Not sure about the Isp of polyethylene fuels though.

<comment><USER5> Aluminium is decent fuel as used in NASAs solid boosters. Now if they could just find a way to grind up the structure and stick it in the engine.

</comment></comment><comment> IX-103 How strong would the fuel rod and motor have to be? Since they are the only structural components it seems like they would have to bear the full thrust of the rocket:

The fuel rod is not bolted to engine, so the pressure in the combustion chamber is transmits the force upward. The motor must be attached to combustion chamber so the interface between the motor and fuel rod must counter all that force to keep the rod in the chamber.

<comment><USER6> The text repeatedly talks about small satellites/cubesats.

I think that's essential.

<comment><USER7> Where is the satellite? Is there a framework that holds it above the fuel rod, or what?

</comment></comment></comment><comment><USER8> This seems to be a solid rocket booster with moving parts. Isn't that the worst of both worlds? Lower ISP than liquid fuelled rockets due to the propellant choices and higher manufacturing complexity than a solid rocket booster...

<comment><USER9> The number one thing you worry about with a launch vehicle is not ISP, it's the tyranny of the rocket equation. We have tech with VERY high ISP (ion drives, for example), but we can't use them until our vehicles hit space because of the extremely low maximum thrust.

Meanwhile the high thrust options we have are all very heavy, which means we have to carry more fuel, which means we need a bigger rocket, which means have to carry more fuel, and so on. The sum of this infinite series is finite, but it is still large.

If this tech lowers the weight of the first stage, it might actually RAISE the ISP of the rocket overall, even if it lowers the ISP of the engine itself.

<comment><USER10> >The number one thing you worry about with a launch vehicle is not ISP, it's the tyranny of the rocket equation.

The rocket equation doesn't account for thrust. It's terms are mass and ISP (or exhaust velocity).

>If this tech lowers the weight of the first stage, it might actually RAISE the ISP of the rocket overall, even if it lowers the ISP of the engine itself.

ISP is depends _only_ on exhaust velocity. Changing the mass of the rocket cannot effect it.

<comment><USER11> > The rocket equation doesn't account for thrust. It's terms are mass and ISP > (or exhaust velocity).

Only sort of true. If you naively apply the rocket equation like you're imagining, you would predict a nonzero final velocity for a hypothetical rocket that has enormous ISP but thrust less than its weight. This is true if the rocket is starting out in orbit, but it's totally wrong when you're on the ground. Starting from the ground, you also have to fight gravity, so you care more about (thrust - weight) / mass.

<comment><USER12> Sure, but "the rocket equation" is 100% talking about the classic ideal rocket equation, which I just discovered is also called the Tsiolkovsky rocket equation.

[https://en.wikipedia.org/wiki/Tsiolkovsky_rocket_equation](https://en.wikipedia.org/wiki/Tsiolkovsky_rocket_equation)

If you want to be more specific, e.g. include gravity then you can't say "the rocket equation".

<comment><USER13>
        > If you want to be more specific, e.g. include gravity
        > then you can't say "the rocket equation".

You may not be able to say "the rocket equation" in that context, but NASA does. [1]

[1] [https://www.nasa.gov/mission_pages/station/expeditions/exped...](https://www.nasa.gov/mission_pages/station/expeditions/expedition30/tryanny.html)

<comment><USER10> Despite Don mentioning gravity along with deltaV he is obviously attempting to describe the classic rocket equation without scaring people away with the math.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> How are they going to get a good seal around the rod at it was being consumed? That sounds like it would limit the thrust the engine can achieve.

<comment> mark-r The engine is exerting tremendous pressure against the rod, wouldn't that help?

</comment></comment><comment><USER15> This article doesn't answer the question every Kerbal Space Program player wants to know: what's the I_sp?

<comment><USER3> At the engine design phase, they care about a different number: chamber pressure.

</comment></comment><comment><USER16> Only slightly related, but are there news on the concept of not taking the energy necessary along at all?

[https://en.wikipedia.org/wiki/Beam- powered_propulsion](https://en.wikipedia.org/wiki/Beam-powered_propulsion)

This was hyped for a time, but then silence returned. Anyone got insider infos?

</comment><comment><USER17> It's a giant round of caseless ammunition? Neat!!

</comment><comment><USER18> how would the shrinking "body of the rocket" ie fuel be able to withstand/transfer the thrust/load/accelleration force safely to the rest of the rocket stack?

i mean to say its a 3 to 5-ish G load or something like that, and vibration alone would be...interesting...

<comment><USER14> One thing i saw was that the rocket can throttle, presumably by changing the rate at which the fuel rod is moved inwards.

</comment></comment><comment><USER19> How hazardous would igniting the fuel-shell be? How much larger do the engines have to be, if they have to be at all, to consume two different types of fuel?

<comment><USER20> It's not two different types of fuel and all rockets do this. It's an oxidizer and a fuel. For instance a common rocket fuel is liquid hydrogen and liquid oxygen. React the two and you get energy in the process... and water. So for instance most of the space shuttle's main engine exhaust was water vapor! Quite counter intuitive.

<comment><USER21> Yeah, water is hydrogen dust :)

<comment><USER22> Hydrogen rust

<comment> mark-r Hydrogen ash?

</comment></comment></comment></comment></comment><comment><USER23> It's all about self-refueling self-replicating water-burning probes. Map the Oort Cloud like that and you'll make a penny!!

</comment><comment><USER24> I was hoping this would be about an aerospike engine.

</comment><comment><USER25> What about the environmental impact? What are the wAste products of the plastic solid fuel and oxidizer combustion?</comment>


A road map collection that could help researchers - <AUTHOR> http://news.nationalgeographic.com/2016/11/robert-berlo-map-collection/ <comment><USER2> > "He could read them while driving and fold them back up while driving."

For maps from the 80's or older, that's actually a feat.

Most recent maps fold up in an accordion-like or zig zag pattern. But not older maps! The folding patterns were inscrutable. You made a horrible mess unless you remembered the exact steps with which you unfolded it.

Given the diversity of people on Hacker News, I'm hoping there's a printing press operator who can explain why paper folding machines of the olden days didn't use a logical folding pattern.

<comment><USER3> I wonder if the machines back then were just as capable of using an accordion pattern, but mapmakers and printers thought there were advantages to the patterns they used, either practical or aesthetic?

When I was a kid, family and friends marveled at my uncanny ability to fold up a map perfectly. The secret was simple: I let the map fold itself.

I'd find the one fold that went the same direction all the way across the page, and start there. Then the one fold that went in one direction across the folded map, and fold it next. And so on.

As long as no one had mis-folded the map before, it seemed pretty easy. But I'd see everyone else ignoring what the map was telling them, just going at it arbitrarily and making a mess.

Later I got into ham radio and applied the same principle to my wiring, especially when I wound my own transformers. Instead of pulling and twisting the wire every which way, I'd let the wire show me where it wanted to go. And instead of holding the transformer core still and forcing the wire around it, I would rotate the core like a spool to take up the wire.

This principle still serves me today, as I seem to be one of the rare people who never has any trouble with MacBook Pro power supply cords!

I cringed when I watched a colleague wind up the cord for a brand new MBPR. He opened the ears on the charger, grabbed the cord and pulled it hard around them all the way. So he was not only stressing the wire from the extra force, he was putting a twist into it through its whole length.

Instead, I wind it the way I used to wind transformers: I let the wire dangle loosely, and then I rotate the power block like a spool with one hand, gently guiding the wire with the other so it wraps loosely and without any longitudinal twist.

So that's how map-folding saved my power cords.

<comment><USER4> I winced at your description of your colleague - and am reading this on a phone with an attached power cable that is frayed, taped up and then re-frayed with exposed wires. I still maintain that strain reducers would help.

</comment></comment></comment><comment><USER5> I would love to be able to see the data on the population of unincorporated towns. Stories of boom and bust, or something else?

</comment><comment><USER6> The kind of thing a lot of people around him while living likely dismissed as "having too much time on his hands". (I'm not saying that, but it often frustrates me when I hear that)

<comment><USER7> My thought for people who say that is "Sad that you either don't have any or are unable to pursue your passion(s) and instead waste your time, on what? Being productive?"</comment></comment>


Gbatteries (YC W14) Launches BatteryBox, A 50Whr Backup Battery For MacBooks - <AUTHOR> http://techcrunch.com/2014/03/24/gbatteries-batterybox/ <comment><USER3> They're making some pretty strange claims about capacity and number of cycles.

In electric RC heli circles, batteries come along once in a while claiming to use previously unknown techniques to improve the performance of existing cells and a few gullible people buy them. They never deliver on the promises.

People who make (established) battery management circuits understand very well how to care for the cells, and claiming to beat the numbers published by the battery manufacturers by a wide margin is close to announcing an "Ambient Energy" device.

[Edited to poke fun at idea, not person/company.]

<comment><USER4> Yeah, it's obviously snake oil. If you had a technology that increased the charge-cycle lifetime of a battery by any substantial amount, you wouldn't be marketing a stupid plastic box for mactards. You'd be cashing billion-dollar checks twice a day.

<comment><USER5> if you read the article, you'd see they're working on OEM deals to get the tech into batteries across the board. The Box is just a nice consumer demo so people can get their hands on it now. Actually a pretty smart PR move.

Also, the patent: [https://www.google.com/patents/WO2013142964A1](https://www.google.com/patents/WO2013142964A1)

<comment><USER4> That's a patent application, yes. Are you aware that the USPTO gets so many applications for perpetual motion patents that they have regulations forbidding them? Patent application does not in any way indicate feasibility.

<comment><USER6> I believe the point was for you, with all of your infinite battery wisdom, to review the patent and possibly even use that to back up your hyperbolic "obviously snake oil" claim, but I'm not holding my breath.

</comment></comment></comment></comment></comment><comment><USER7> Here is a classic example of a startup launching an Altair Basic with the potential produce a Microsoft-like giant. Incidentally, I think this is also the first father/son team we've funded.

<comment><USER8> What is the strategy for when Apple disallows sales based on the Magsafe adapter?

This happened to HyperMac (now HyperJuice) batteries back in 2011. I still have mine, ordered before Apple lawyers went after them. It's wonderful.

Edit: Adding link to Wired article: [http://www.wired.com/gadgetlab/2011/01/hypermac-is-back- with...](http://www.wired.com/gadgetlab/2011/01/hypermac-is-back-with-cable- chopping-magic-magsafe-adapter/)

<comment><USER7> I don't remember the details, but IIRC they are Apple proof.

<comment><USER9> Hopefully, but color me skeptical. I don't see how _anyone_ can be X-proof, where X is a company that has over $100 billion in their bank account.

<comment><USER10> HyperMac literally bought Apple adapters and chopped off the cable. I'm not sure how much more Apple-proof you can get than that. What you need to be is "lawyers on retainers who can keep draining your law funds"-proof.

edit: another comment suggest a MagSafe-MagSafe2 adapter is used. That's an interesting solution that may very well work if they require the customer to buy it themselves, as I believe the Apple patent hinges on using a magnet. Of course, they may want to argue that in court. For years and years.

</comment></comment></comment></comment></comment><comment><USER11> Maybe this feature was a bit underreported: the current line of _Lenovo_ 's Ultrabooks, the _ThinkPad X240 /T440s_ allows for hot swapping the battery pack while running on a secondary built in battery. Adding up to 23.5 Whr built in plus up to 72Whr per battery pack.

[http://shop.lenovo.com/us/en/laptops/thinkpad/t-series/t440s...](http://shop.lenovo.com/us/en/laptops/thinkpad/t-series/t440s/#features)

<comment><USER12> Yep. I could do this on my circa 2005 IBM T43.

<comment><USER13> Great. So why can't you do it on a MacBook Pro?

<comment><USER14> Because they valued more the engineering advantage of a built-in battery: thinness, weight, individually connected cells for power management.

Those attributes of design are more appealing to the majority than are interchangeable batteries.

My MBP and MBAir, even with the single built-in battery, gets more runtime than a 1996 laptop with two battery packs.

</comment></comment></comment></comment><comment><USER15> I suspect the 100% charging time was miscalculated. USB power is 5volts, so a 1A charger meants 5W of continuous power. Battery charging, especially past 85% is not very efficient, so I suspect total charging time will be more in the neighborhood of 20 hours.

<comment><USER16> My guess is those times are assuming a 2A charger, which isn't particularly uncommon nowadays.

<comment><USER15> They call that out as taking half as long. My guess is they calculated the charge time using 1A but the voltage from the output (17v?)

<comment><USER17> >nine hours for 100 percent charge on a 1A power supply

They are simply LYING, probably learned from the same Chinese that will build it for them using 5000mAh* Ultrafire 16850 cells ;)

*400mAh when tested

</comment></comment></comment></comment><comment><USER18> Why Macbooks?

Is Apple friendly towards people who replicate their connector interfaces?

Or are Macs the only popular device out there where people wish "I wish I could carry an extra battery!"?

<comment><USER19> If you wanted to cover as much current and future market share as possible (at least in the market they're targeting) I can't think of a better current combination than magsafe2 + usb.

Other than, maybe, a portable power outlet.

<comment><USER20> You surely mean magsafe 2, here.

</comment></comment></comment><comment><USER21> Love it. Actually sitting next to my own "battery box" \- a wheeled backpack with a 55 amp-hour AGM (lead acid) battery and inverter. I think I can get 3 work days out of that, but it's a lot bigger than this. Great for taking to the park though.

</comment><comment><USER22> This has almost nothing at all to do with Apple.

I'm a little sad that folks can't get past the proof-of-concept product.

The game-changer is BatteryOS, not BatteryBox. Who cares about BatteryBox itself?

Think bigger, people, come on.

<comment><USER10> There's not much to discuss about BatteryOS until it's been verified by third parties. Every 4 months or so we get a news article about some amazing breakthrough in battery technology, and they never ever seem to pan out.

</comment></comment><comment><USER23> This technology, if legit, is I think a very good example of where software patents can add value. The future of this technology isn't a little $139 backup battery for Macbooks. Rather, its licensing the charging algorithms to every battery charging controller manufacturer on the planet. One can imagine that over time it might be a good idea for a company like this to vertically integrate and start producing its own batteries, but it's going to be a long time before they have the capital to take on the Korean/Japanese companies currently playing in that space. The alternative might be to angle to get bought by an Apple or Samsung, but that's probably not what's best for the industry. There's a lot of value to R&D companies like this that can focus on a specific niche without having to rely on some vertically-integrated conglomerate to get anything done.

</comment><comment><USER24> My laptop has swapable battery. I can also swap HDD bay from my desktop when I am traveling.

It is really funny to see Mac fans excited about simple external battery. This stuff is around for decades!

<comment><USER25> What laptop do you have? Macbook Pro's are so thin now even a RJ45 hole is too tall. I can forgive them for not having a replaceable battery for size/weight and noise reduction having everything so tightly integrated.

<comment><USER26> The ThinkPad x240 is thinner and lighter than a MacBook Pro and still manages to find space for an external battery, an RJ45 jack, and a VGA connector.

<comment><USER27> Its not thinner. The x240 is 0.8 inches thick [1] and the MacBook Pro is 0.71 inches thick. [2] Not trying to fanboy here having used both of those laptops recently.

[1] [http://www.laptopmag.com/reviews/laptops/lenovo- thinkpad-x24...](http://www.laptopmag.com/reviews/laptops/lenovo- thinkpad-x240.aspx)

[2] [http://www.apple.com/macbook-pro/specs- retina/](http://www.apple.com/macbook-pro/specs-retina/)

<comment><USER26> Thanks, and sorry about the misinformation. I got my info from [http://www.apple.com/macbook-pro/specs/](http://www.apple.com/macbook- pro/specs/), which was the first result for a search for "Macbook Pro dimensions". Didn't realize that was apparently obsolete info.

</comment></comment></comment></comment></comment><comment><USER28> Wow this seems to be a very clear-cut value add.

Question on how the technology works: I don't really understand what a "battery OS" is. Do they have circuits that somehow manage the battery better or something?

<comment><USER29> They say they have a patent pending, that should have more details. I would like to read it, can anybody find the filing?

[http://www.gbatteries.com/technology/](http://www.gbatteries.com/technology/)

<comment><USER5> pretty sure it's this one: [https://www.google.com/patents/WO2013142964A1](https://www.google.com/patents/WO2013142964A1)

basically the technique involves pulsing the current during (dis)charging, and optimising the length and timing of the pulsing in real-time, because the optimal settings change through the life of the battery.

<comment><USER30> I'm kind of a battery nut. I've been building various pulse chargers and capacitive current limiting chargers for years. Without fail all of my most promising pulse charge/bleed schemes that yielded faster charges and greater runtimes have done so at the expense of cycle numbers. Usually by a factor of 10 or more. I hope they've outsmarted this, but I have my doubts.

</comment></comment></comment></comment><comment><USER31> Mentioned in passing in child comments below, but worth highlighting - <USER2> HyperJuice Battery range of products (eg [http://amzn.to/1mqK9ap](http://amzn.to/1mqK9ap)) already does this, at a similar price point, and is available for purchase today.

In fact they're already onto the second generation of the product, with minor bugs and issues with the first gen already ironed out. I get this GBattery has a new "BatteryOS" management feature but right now that's vaporware and unproven, and unavailable for purchase - thus I don't really understand the excitement vs what you could already buy today.

<comment><USER32> We bought a HyperJuice 2 for use on trips. It's terrible. It'll charge a 15" rMBP about 10-15% before it's completely dead.

<comment><USER33> It's not made to charge the laptops. It's made to keep them running. The rmbp will suck any battery dry trying to charge and run at the same time. Keep the rmbp at 100% and plug in the battery and let me know how long it lasts.

</comment></comment></comment><comment><USER34> They claim that their 50 Whr battery can power a MacBook Pro for 6 hours, a MacBook Air for 12 hrs. By my math, that would mean that the MacBook Pro would only be consuming an average of around 8.3 watts an hour, the air only around 4.2 watts an hour.

That seems absurd to me, considering the power supplies that ship with the MacBook Pro and the MacBook Air are 85-watt and 45-watt respectively. They are assuming that each only draws about 10% of the power that the official power supplies are rated at. Anyone have a Kill-A-Watt to see the actual draw of their device?

<comment><USER23> The Air has I think a 50 WHr battery and will last 11-12 hours for Wi-Fi surfing. I think the idle load is just a couple of watts. Peak load is of course higher.

<comment><USER34> Good point, I didn't think to check the capacity of the Air's internal battery.

</comment></comment></comment><comment><USER35> Would love to see a battery built in to my MBP's power brick. Charge, and provide power, when it's plugged in. Run off the battery when it's not.

</comment><comment><USER36> Many companies have been trying to produce external Macbook batteries (e.g. [http://www.hypershop.com/HyperJuice/External-Battery-for- Mac...](http://www.hypershop.com/HyperJuice/External-Battery-for-MacBook-iPad- iPhone-USB/)), but the major stumbling block has been that Apple does not allow third parties to use the Magsafe interface. Has Gbatteries found a way around this problem?

</comment><comment><USER37> Come on pg. This isn't real tech. This is just a battery in a box with a $1 microcontroller. We could hack this together in a day in my basement.

</comment><comment><USER38> It was about time someone optimized charging/discharging of batteries. I didn't know ordinary batteries have such a potential for optimization, I thought that would be the batteries in UPSes. Current UPS batteries die in 3 years, having been used just a dozen times, apparently because the UPS insists to keep them fully charged at all times. Someone fix this, please.

</comment><comment><USER39> Pre-ordering hardware that makes promises of substantial improvements over the status-quo that will only be testable by the buyer a few years down the line is a recipe for disaster.

Do yourself a favour and hold on to your money until there are actual units that have been tested rigorously (as in, in an independent lab unaffiliated with the company) to see if the promises are delivered on.

<comment><USER40> Would have been nice if TechCrunch did some testing / reporting, instead of accepting / repeating. Not that I'm surprised, just would have been nice in this area.

</comment></comment><comment><USER41> Does Apple allow licensing of MagSafe now?

<comment><USER42> That was my first thought. I remember reading a few years ago that a company actually had to stop making Macbook compatible external batteries because Apple threatened to sue them over use of the MagSafe connector.

EDIT: I found the article, and apparently the company was sued for using actual recycled connectors, not just using the design.

[http://appleinsider.com/articles/10/09/21/apple_sues_hyperma...](http://appleinsider.com/articles/10/09/21/apple_sues_hypermac_accessory_maker_over_magsafe_ipod_cables)

<comment><USER43> But they used recycled connectors as a way of using the legal argument their product was a "customer modification" of a licensed and paid for product. You sent them YOUR charger and they modified it to work with their device.

They STILL got shut down by Apple because the Mag Safe also used circuitry inside the brick that they "hacked" to make their brick work like.. Basically DRM and DMCA for power bricks shut them down.

<comment><USER33> I have one of the original cables before they got shut down. It's just a magsafe end with a barrel connector on the other. No DRM voodoo.

<comment><USER17> DRM voodoo is in the charger, it speaks 1-Wire telling computer its make model and power. Most likely can also be controlled over 1-Wire.

<comment><USER44> The magsafe connector talks 1-wire, not the charger itself. It provides serial number and version info but no DRM/crypto. The Mac also uses the 1-wire to control the LEDs on the connector. See my teardown for the details: [http://www.righto.com/2013/06/teardown-and-exploration-of- ma...](http://www.righto.com/2013/06/teardown-and-exploration-of-magsafe.html)

<comment><USER17> Nice, thanks. What about magsafe2? same deal? DELL also uses serial connection with the charger, with chip inside the charger. Kinda surprising Apple didnt lock it down like they are used to do.

</comment></comment></comment></comment></comment></comment></comment><comment><USER45> BatteryOS seems to be the most important aspect here. Consumer electronics manufacturers have different goals than this class of product, which may not always align with every consumer. So if they are abstracting all that logic into their own MCU OS, that is pretty smart. I can see an iPhone/Mac app to tune your BatteryBox to charge faster at the cost of life time/cycles(?) (clearly telling you this!) or vice versa...allowing you to tailor the solution to your needs. This is different to what Apple would offer as they need to find a one size fits all solution and that is usually some sweet spot for high cycle count + low charge time and long battery life.

Going one step further, possibility for some ML to learn your use case and charge your MacBook accordingly. Regardless, the battery is irrelevant, the OS is key.

</comment><comment><USER46> Get a new industrial designer onboard. Yesterday. Seeing the thing, I'm inclined to believe that that "new" in previous sentence is superfluous.

Plugging this into my MacBook Air would make me feel like getting a $20 prostitute. And paying her $200 afterwards nonetheless.

</comment><comment><USER47> The Air's battery already lasts 12+ hours. How much demand could there possibly be for people to stretch it out even further? HyperJuice (and I would guess others) is already out there and I've never even seen one of those things in the wild.

<comment><USER48> The latest Air in ideal conditions does 12hrs. My friends couple of year old one managed to run out fairly promptly when using by the swimming pool where there were no sockets. He could be a customer if the gadget's good.

</comment></comment><comment><USER49> I would love if this had some sort of a universal plug on it so you can power other laptops besides Macs. Then you can plug some sort of adapter in so you can charge Dell, Sony, etc. laptops as well.

</comment><comment><USER50> This is really exciting, and a real problem solver, than good-for-nothing social apps popping up every other day. I wonder do they ship 'internationally'?

on a second thought, why not make the color of the box, say like mbp body color, or other light grayish colors, when it's intended for apple products. the green color does not seem a right fit for an accessory of apple products.

>and a total of 9 hours for 100% charge

yikes! But i guess it's okay since it's a 'standby' battery.

</comment><comment><USER51> If this works, it seems pretty strange to build their own devices with it. With a patent on the methods they could make a fortune licensing the technology to Si companies. They would reach the market much quicker too.

However, having worked on BMS systems for lithium batteries this sounds very fishy. Maybe they've hit on something spectacular, but it seriously looks like snake oil based on the info they've provided thus far.

</comment><comment><USER19> I really like the end of their FAQ. Almost made a call.

[http://www.getbatterybox.com/#faq](http://www.getbatterybox.com/#faq)

</comment><comment><USER52> Pre-ordered. Unfortunately when traveling - device power is a constant pain point for me. very excited about utilizing for both Macbook & phone.

</comment><comment><USER53> As a product, this doesn't seem to offer all that much over competitors besides the claimed reduction in degradation. Otherwise, something like this seems better and cheaper: [http://www.amazon.com/20000mAh-Multi-Voltage- External-Netboo...](http://www.amazon.com/20000mAh-Multi-Voltage-External- Netbooks-Notebooks/dp/B00B45EOYS/ref=pd_cp_pc_3)

</comment><comment><USER54> How does a YC backed company create a video with audio that's clearly watermarked. Presumably they could afford the $17 license...

</comment><comment><USER55> I think all laptops can extend the battery life-span significantly with just smarter software. I manually cycle my laptop battery regularly & do not keep it charged at 100% all the time even if the laptop is plugged in (some Thinkpad models allow that). Even after 2 years of daily use, I've got greater than 80-90% battery capacity left.

<comment><USER56> I do absolutely nothing special to try to prolong the lifetime of my 3-year- old MacBook Pro battery and it's still got 92% capacity.

<comment><USER55> My experience with Windows laptops is totally different

</comment></comment></comment><comment><USER57> Somewhat odd to target a computer that already runs for 12hours to run 'another 12 hours' with a big bulky external battery pack. Would make more sense to target something like an iPhone or others that run way too short to last a day. Problem is: battery packs for those are a dime a dozen. I do wish them best of luck though!

</comment><comment><USER58> Their battery technology sounds great but, honestly, I am a consumer so my point of view is "do I want to buy this for $139?"

Yes, I do want it, mostly so that I can set it next to my Macbook Air (mid-2012) for a full day's worth of power, as is the use case shown so prominently on the web site.

Take away the MagSafe 2 and I don't want it.

</comment><comment><USER59> This looks like a great idea. We are applying to the upcoming class with a different approach though. Instead of owning batteries (however spectacular they are), we think it's about creating a network to share batteries. Think bike share for batteries.

Would love to chat about using Gbatteries in such a network.

</comment><comment><USER60> > note it does not charge the internal Macbook battery. Instead BatteryBox > feeds power directly to the Mac in an effort to minimize the number of > cycles (and stress) on the internal battery.

Is this something that any power adapter does? Is there something in the way they have it connected that does this?

</comment><comment><USER61> I don't know why many people are focus on Apple or protable battery. With such tech, the potential could be anywhere need an efficient energy solution. The BatterBox might be the first appliance. Are you willing to buy something cost you 10 bucks while it saves you 20 bucks?

</comment><comment><USER62> How is this different from my HyperJuice? That gives me 50Whr, too, and also has a USB port. It pretty much doubled the life of my Air, and slightly less for my 13" rMBP (Haswell i5, with 16GB).

</comment><comment><USER48> Their patent I believe: [https://www.google.com/patents/WO2013142964A1](https://www.google.com/patents/WO2013142964A1)

</comment><comment><USER63> Nice though would not a A4 (laptop sized) slab instead of a box be better as could then sit under the laptop and also easily fit inside the laptop case.

Just a thought.

<comment><USER10> It's a lot more expensive to make custom-shaped cells than to pop a couple of standard cylindrical cells into a square box.

<comment><USER63> True, though more production of flat cells than round, mobile phones case in point - they are all flat in shape. Actualy not really come across flat LiOn cells personaly in any form. Capacitors - yes.

</comment></comment></comment><comment><USER64> Curious why they didn't go with Kickstarter for the BatteryBox. The product looks really interesting, and I think I'll order some.

</comment><comment><USER65> Take my money already! This is going to be a life saver - it's like a mophie juice pack for my MacBook, but smaller and more powerful.

</comment><comment><USER66> Why the capacity sometimes goes higher on the graph as the battery ages? Can anyone explain, or is this just a marketing crap?

</comment><comment><USER67> The desk in the Savannah-like setting + shades + call the founder at his cell = Take my money.

</comment><comment><USER68> Pre-ordered a while ago ... can't wait to live in a jungle and not worry about juice :)

</comment><comment><USER69> This could be huge...wonder if Tesla/Solar City would be interested in buying them?

</comment><comment><USER70> For anyone from the metric world too lazy to look it up: 9 ounces equals 255.146 gramms.

</comment><comment><USER71> Would this be useful for Tesla?

<comment><USER60> Absolutely. And Apple, and Dell, and anyone else that uses rechargeable batteries that degrade over time. This solves the degradation aspect of batteries, so it would improve the longevity of devices.

<comment><USER71> But I've read so much about Tesla being really intelligent with charging. Wouldn't they have already thought of this?

(Or at least be doing enough intelligent things already that they wouldn't get much additional improvement?)</comment></comment></comment>


IDE vs. Text Editor: Choosing the Right Tool at the Right Time - <AUTHOR> https://spin.atomicobject.com/2015/12/22/ide-vs-text-editor/?utm_source=hacker_news-ao&utm_campaign=ide-vs-text-editor&utm_medium=referral <comment><USER2> I use a text editor for everything but:

RStudio for doing statistics with R (Awesome tool, Python has Rodeo) Mostly using RNotebooks nowadays.

Jupyter Notebooks (When programming in Python when a repl with cells makes sense)</comment>


Twister: P2P micro-blogging with accounts on the blockchain and messages in DHT - <AUTHOR> http://twister.net.co <comment><USER2> What is the motivation of twister over bitmessage + namecoin. Namecoin is already a decentralized authorization/registration crypto network and bitmessage is a POW based P2P messaging system. The use of DHT seems novel, and it may be interesting to see if the bitmessage community had a reason not to use it.

I'm not trying to attack the idea. I just want to understand what novel work is being done here. Cheers.

<comment><USER3> >What is the motivation of twister over bitmessage + namecoin.

Bitmessage is to mail what twister is to twitter ?

<comment><USER2> Bitmessage is for any messaging system. You can broadcast (twitter), send private message (email), or start a channel (IRC). The key in bitmessage is that to send a message you have to do a POW according to the size of the message you are sending.

Even then you still have massive data bloat problems, which I dont see DHT alone solving.

<comment><USER4> Reading Bitmessage broadcasts requires following the user, so you can't see replies if you're not subscribed to the replying user. Twister feels more like Twitter, including searching, hashtags, etc.

Though I guess you could leverage BM's protocol and infrastructure to do that too (broadcasts are public you'd just have to filter the noise).

</comment></comment></comment></comment><comment><USER4> I can't find the whitepaper anywhere! Am I missing it?

EDIT: it's under "Development" at the menu (I thought it was just a dropdown!)

[http://arxiv.org/abs/1312.7152](http://arxiv.org/abs/1312.7152)

</comment><comment><USER5> Erm, wow. Mind blown, even if post-Telegraph the reflex is to assume the crypto is somehow broken.

I guess we're starting to see bitcoin acting as a source of inspiration for others with increasingly amazing results. Namecoin is obviously the main project in that category, but I wonder what other applications of these concepts will emerge.

</comment><comment><USER6> Interesting. Rather than a coin resulting from the block chain you get the right to inject advertising. I'm not sure that will work as well (but partly just because it doesn't inspire me to mine), but it's an interesting avenue.

<comment><USER7> "Developers must not implement hiding of spam messages"...I can't see that working out at all. Namecoin's solution of just paying currency to the miners seems safer.

Lots of other interesting ideas here though.

<comment><USER6> Agreed. I haven't looked hard enough to know, but is it possible you could trade this opportunity for coin elsewhere? Still, the fact that it relies on good will on the client's part is really problematic. But it is good that people are experimenting with different rewards even so, I think.

</comment></comment></comment><comment><USER3> It seems like once complete (more polished and easier to "get running") it might be, to casual users, more portable than tent.io regarding user data.</comment>


AG may prosecute telecommunication use to "participate in" or "encourage" riots - <AUTHOR> https://www.youtube.com/watch?v=psyE8NMcPR8 <comment><USER2> Can the administration try doing something useful instead of punitive, like say trying to help improve police training so it has less 'kill the public' in it? Maybe being less hostile to scary liberal things like keeping accurate statistics of police actions?

</comment><comment><USER3> I don't think this is particularly newsworthy, nor that it reflects poorly on the Trump administration.

18 U.S. Code § 2101, the relevant law, clearly stipulates:

As used in this chapter, the term "to incite a riot", or "to organize, promote, encourage, participate in, or carry on a riot", includes, but is not limited to, urging or instigating other persons to riot, but shall not be deemed to mean the mere oral or written (1) advocacy of ideas or (2) expression of belief, not involving advocacy of any act or acts of violence or assertion of the rightness of, or the right to commit, any such act or acts.

They aren't barring your freedom of speech. This isn't some obscure twist of a law, this is the intended usage of that law. There are plenty of legitimate things to criticize about the response, but this isn't one of them.

It's also worth noting that this law is superceded by a state conviction/acquittal for rioting charges. You can't be charged under both state and federal law for it.</comment>


Notifications and Usability: Skype - <AUTHOR> http://www.jvandenbroeck.com/2012/09/skype-notification-and-usability/

<comment><USER2> Tools / Options ... / Notifications / Notification Settings</comment>


Show HN: Publish and find the last meetup slides and useful links - <AUTHOR> https://meetfeed.co/ <comment><AUTHOR> Hey HN! I'm Kirill, founder at Meetfeed the place to help event organizers and their community don't lose important info from the past meetups in expanses of chats or emails.</comment>


Have Indian investigators been duped into using highly suspect brain-mapping technology? - <AUTHOR>

I was intrigued by this snippet in a article about the recent bomb blasts in India.
"Haywood, who underwent lie detector and brain mapping tests, fled from..."
Article: http://www.rediff.com/news/2008/aug/18ahd3.htm
Brain mapping? I'd never heard of fMRI or PET scans being approved for forensics, so digging further I was rather shocked to see that they have been in use in India for a while.
Article: http://www.rediff.com/news/2006/jul/19george.htm
Brain mapping or brain finger-printing is being peddled by http://brainwavescience.com/ (Their website's definitely worth browsing)
A search on scholar.google.com turned up this review article, which describes most of the grandiose claims made about the technology as "florid" and highly exaggerated. PDF: http://cns.bu.edu/~gsc/Articles/Brain_FingerPrinting.pdf
Having failed to get the technology employed in the US, this company seems to be targeting other countries. Good strategy, even if ethically suspect and porous! <comment><AUTHOR> The links seem to show up as text above:

I was intrigued by this snippet in a article about the recent bomb blasts in India. "Haywood, who underwent lie detector and brain mapping tests, fled from..." Article: <http://www.rediff.com/news/2008/aug/18ahd3.htm>

Brain mapping? I'd never heard of fMRI or PET scans being approved for forensics, so digging further I was rather shocked to see that they have been in use in India for a while. Article: <http://www.rediff.com/news/2006/jul/19george.htm>

Brain mapping or brain finger-printing is being peddled by <http://brainwavescience.com/> (Their website's definitely worth browsing)

A search on scholar.google.com turned up this review article, which describes most of the grandiose claims made about the technology as "florid" and highly exaggerated. PDF: <http://cns.bu.edu/~gsc/Articles/Brain_FingerPrinting.pdf>

Having failed to get the technology employed in the US, this company seems to be targeting other countries. Good strategy, even if ethically suspect and porous!</comment>


iCheck - Super customized checkboxes and radio buttons with jQuery - <AUTHOR> http://damirfoy.com/iCheck/

<comment><USER2> This is very cool. Thank you for sharing!</comment>


Calculating π by Bouncing Balls in Phase Space - <AUTHOR> http://aperiodical.com/2015/03/%cf%80-phase-space-and-bouncing-billiard-balls <comment><USER2> Looks like this method converges at root(N) same as a direct monte-carlo [1]

Anyone got a stochastic method that converges quicker?

[1] [http://sohcahtoa.org.uk/pages/maths_montecarlo.html](http://sohcahtoa.org.uk/pages/maths_montecarlo.html)</comment>


Ask HN: Hacker tips for a good love life? - <AUTHOR> I believe folks here on HN are mostly problem solvers and are data-driven and fact-driven and of course have their own drawer of heuristics accumulated from problem solving. I wonder what tips the folks on here might give based on their experience on handling their love life based on above mentioned qualities <comment><USER2> 1\. The Pan flute will let you dance with the gods and make you irresistibly sexy:

[http://www.catb.org/~esr/writings/dancing.html](http://www.catb.org/~esr/writings/dancing.html)

2\. Study the master of seduction and technique:

[http://www.catb.org/esr/writings/sextips/](http://www.catb.org/esr/writings/sextips/)

</comment><comment><USER3> Listen</comment>


Goldman Sachs Tech Internship - <AUTHOR>

Will this be as valuable as interning at a startup in Silicon Valley in terms of knowledge and networking? <comment><USER2> That depends on what you want to do with your career.

Generally, internships at startups are more flexible and open-ended. Internships at BigCos can be more rigid and less interesting.

If you believe you're going to spend your career in startups, you're obviously better off interning among startup people.

But, be careful: a serious internship at a large, technology- driven company (GS qualifies) is better than a poorly- managed internship at an inept startup.

Also, be aware that an internship at GS carries weight among SFBA startups, but an internship at a random SFBA startup probably carries no weight on Wall Street.

</comment><comment><USER3> I've got a friend going to NYC for either Goldman or some other big firm; I can't recall which. He's super excited and for good reason! It's an awesome opportunity.

When it comes to connections/networking, what more could you want? Plenty of people with money, people in charge of money, people that will be hiring programmers for years; the lot!

As for knowledge or programming experience, I don't exactly know if it'll be more "rewarding" than a startup. It really depends on what you consider rewarding. You'll learn plenty about surviving a workforce and meeting deadlines in a work environment, that's for sure. I don't think you'll learn much, if anything at all, about web-development unless you're specifically working on some proprietary web-app that handles client interactions.

Can you give us a little more info on what division of the business you'd be working in?

</comment><comment><USER4> Depends on the startup. There are top-tier startups, promising startups, and then there are random startups. Some "startups" like Pinterest, Airbnb, Dropbox, Quora, etc. have extremely strong engineering cultures and would probably be a ton better than GS.</comment>