Dalvik patch for Facebook for Android - <AUTHOR> https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920 <comment><USER3> Uninstalled. I checked, and Facebook took up more memory than any other application I have installed, even more than TSF Shell. (By the way, a MUCH more "feature-rich," useful, and snappy app than facebook!) Facebook isn't doing anything comparable to what TSF Shell does, not for me anyway. I bet this is why my phone recently started taking 30 seconds to make a phonecall (!).

I can't believe an app requires 8M RAM just for method names! That's 3% of my entire usable memory (what's left after Motorola Blur takes its share) -- just for the method names for a single app. Surely I must be misunderstanding what goes into that buffer. It's unimaginable to me that they really need such a vast amount of space. It's unimaginable that they really expect their app to work at all on an old phone without choking it to death.

If I grasp this correctly, printing just the method names would create a book double the size of the King James Version of the Bible. Maybe you are going to argue having so many methods is good programming practice, not bloat. But don't argue that you "support" a system when just the method names total around 3% of usable memory for that system. And there are a lot of devices with considerably less memory than what I've got.

Why don't you release a stripped down, "lite" version of the app that works on an Android 2 phone even if it has more than 5 applications installed? Some phones don't even allow uninstalling facebook. They are simply stuck with the bloat (I mean, good programming practices :-).

<comment><USER4> Yes, I'm in the same boat. On my Android 2.2 phone (HTC Legend) it is hard to fit some current apps and facebook is a system app so I can't uninstall it. However I can uninstall the updates, so my facebook is the original factory version. I won't be trying out this latest version.

It would be interesting to know what it is doing to be that complex. I'm guessing lots of third party libraries for ads, logging, etc?

</comment></comment><comment><USER5> The first paragraph is just rampant self praise. Basically these engineers decided to be really clever, painted themselves into a corner, smashed a hole in the wall so as to escape from said corner, and then bragged about how great they are.

<comment><USER6> Hitting an arbitrary (and undocumented?) platform limit on the number of methods your app is allowed to have is hardly "painting themselves into a corner".

<comment><USER7> I'm not sure if it is listed in the official documentation but it was talked about by the Android team on their blog:

[http://android-developers.blogspot.com/2011/07/custom- class-...](http://android-developers.blogspot.com/2011/07/custom-class- loading-in-dalvik.html)

<comment><USER6> This appears to discuss the per-dex method limit but makes no mention of the per-process limit.

</comment></comment></comment></comment><comment><USER8> No, that is not cool, that is an admission that

1\. They bloated the app so badly, they would have had to monkey patch the OS to let it run at all.

2\. They actually did have the stonkingly huge arrogance to monkey patch the OS.

What they should have done is shattered it down into a constellation of related apps and background processes. This app is FB news, that app is FB messaging, and so on. Bonus: people could pick and choose the parts of the system they cared for.

But that last is what they wanted to avoid, I think. Facebook _à la carte_ means that they can't foist unwanted "services" on you.

And so they hacked.

</comment><comment><USER9> According to <http://techcrunch.com/2013/03/04/facebook-google-dalvik/> and <http://venturebeat.com/2013/03/04/google-facebook-android/> , the specific limit being hit was a cap of three million methods per instance of the Dalvik VM.

Wisdom of a three-million-method app aside, I wonder why they didn't fix this in the compilation toolchain rather than by poking around in native memory areas during app startup. Facebook wrote a PHP->C++ compiler; changing the Dalvik compiler to more aggressively inline small methods seems trivial in comparison.

<comment><USER10> Three million methods? Having both programmed for Android and having used the Facebook App for Android, I find it very difficult to believe that app has anywhere near 3 million methods, even if each one is basically a one-liner. If the number is correct, that really is some kind of crazytown code.

<comment><USER11> I think the actual number is 65536 or similar — the 3 million may have been a misquote by TechCrunch.

<comment><USER10> Still seems like a ridiculous number, though of course far less ridiculous especially for Java code with its legacy of setters and getters for even basic properties and FactoryOfFactoriesFactory classes.

<comment><USER12> Trivial getters and setters shouldn't be a problem because the Facebook blog said they tried using ProGuard, which can inline Java methods.

</comment></comment></comment></comment></comment><comment><USER13> I really love reading recounts like this. Seeing other developers try, fail, and try again to come up with creative solutions for difficult problems, and then finally arriving at a solution, is so satisfying. It really demonstrates how creativity is manifested in programming, and is truly inspiring.

A favourite of mine is Jari Komppa's article on his process of porting Death Rally from DOS to Windows: <http://sol.gfxile.net/dr_gdm.html>.

Does anyone have any other articles along the same lines? I'd love to read them!

<comment><USER14> Thanks, that was indeed a great read. You might also enjoy this, which is fairly recent: <http://fabiensanglard.net/duke3d/index.php>

And the article links to other promising articles at the top, though I haven't checked them out.

The general question remains: how would we go about finding similar stuff?

Oh, one more thing, if you don't know yet, you will find great gems in Raymond Chen's blog, <http://blogs.msdn.com/b/oldnewthing/>

Not everything is archeological (a lot is still interesting though), but the articles often link to a whole bunch of other articles, which in turn do the same. I suggest, for example, [http://blogs.msdn.com/b/oldnewthing/archive/2012/06/29/10325...](http://blogs.msdn.com/b/oldnewthing/archive/2012/06/29/10325295.aspx) . I deliberately chose a later article in the series, since it also links to previous ones.

</comment></comment><comment><USER15> Unfortunately TechCrunch reported incorrectly and no one at Facebook cared enough to correct them (OR thought its cool to boost 3M Methods in an app).

The limitation in older Dalvik VM's is 64K Methods and not 1 Million methods which is realistic count that a large app would hit (even decent sized app with high number of third party libraries).

This limitation is known for a while and Google Engineers talked about it multiple times.

</comment><comment><USER16> Certainly if there's a lot of small methods, they could have an optimization pass that inlines some of them and bring their overall method count down. I wouldn't be surprised if that was a small performance gain, too.

<comment><USER17> I thought of that, then the pragmatic engineer in me observed that they only discovered this _after_ cracking their app into so many small methods. Given the time choice of 1. uncracking their app into small methods (which presumably wasn't atomic, so now that's all mixed in with other development, so it's not like it can just be reverted) or 2. hacking the system to handle more methods, I am forced to admit that choice 2 is two or possibly three orders of magnitude _faster_ , in man-hours. (Probably two or three of their best engineers for a couple of weeks, vs. "the entire team", from dev to QA, tasked for months, on work that results in no new features). Not better in all possible ways, but it's hard to justify "do it right" against that sort of cost/benefit ratio.

Then I was going to say "I hope they move towards a more permanent solution" when again my inner pragmatist popped up and said "Yes, they did; unsupport Android 2 in the future." So... yeah.. nasty, _nasty_ hack, probably an enormous win almost all the way around. So the wheel turns.

<comment><USER18> I think GP meant something like a build process that inlines the bytecode, not the source code itself. I don't see why this is unreasonable, especially compared to what they actually did.

<comment><USER17> For as nasty as the hack is, it still boils down to twiddling with a few numbers.

Also, inlining is probably easier said than done. It's not enough to inline the methods, you need to make them entirely disappear, and ISTR reading within the last few days somebody else commenting that Java still has to keep the metadata about the methods around (which is the problematic part, not the methods themselves, if I'm reading this right) because reflection may demand them. You'd need something more sophisticated to do it at the source level, and with an imperative language with unrestricted side effects, while that is certainly possible, it's also very much easier said than done. That's not a weekend hack either.

<comment><USER16> I'm not sure inlining is that difficult. Java bytecode is a relatively straightforward language is it not? Especially if it doesn't have to be for all cases, which, if you're looking at eliminating small methods, it does not have to be.

Assuming Java has something like the Cecil library for MSIL, it should be a fairly straightforward task. Although, as you point out, so is fixing up a number.

<comment><USER19> In order to elide the out-of-line method the compiler must statically prove that it is impossible call outside the visibility of its optimization scope.

I'm not familiar with Java compilers but I'd hazard a guess that to exploit this optimization (if it were possible at all) they would probably have to significantly rework their code.

<comment><USER16> For a shipped app it shouldn't be too hard to perform it across all packages involved, right?

<comment><USER19> The compiler would have to see all code that is linked with the app, including the Android runtime that calls into the app's code in various ways.

In Java land these kinds of fancy optimizations usually happen in the JVM JIT at runtime. Would this help the size of those tables in Android's Dalvik/dexopt setup? In any case you can't ship a custom version of Dalvik with your app.

<comment><USER16> Maybe I'm not explaining well.

You've got class foo, with methods "DoBar" which calls "DoBazStep1(), DoBazStep2(), SomeHelper.CalcPosition()".

You use a Java bytecode toolkit and identify leaf functions, small functions, whatever the criteria needs to be. Then you check every callsite for those functions, and if found, remove the call, and inline the code, doing fixup on locals and parameters. Now, "DoBar" has a lot more bytecode in it, as the bodies of DoBazStep1 and the others are now contained in it. The small functions are completely removed.

This process can be done totally offline, on the compiled Java code. The runtime just sees that you wrote one big function, versus a bunch of small ones.

The only real work is making sure you got everything, and perhaps being clever with stack local allocations. As the FB team says they moved to a new style with lots of small functions, I'm assuming they aren't doing all sorts of metaprogramming and inheritance, but have just split things up at the function level.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> It's interesting to see the parallels between Android and Windows in this regard.

Here's a story from my past, copied from a blog post I wrote last year:

My first job at Microsoft was providing developer support for the early Windows SDKs. To do my job well, I spent hours studying the Windows SDK documentation, the Windows source code, and writing sample applications. I then spent hours poring over customers' (such as Lotus, WordPerfect, and Computer Associates) code helping them figure out what was not working.

This gave me a deep appreciation for API design early in my career. I saw clear examples of elegant APIs as well as horrific monstrosities. I once created a sample for selecting a font in GDI that I called "ReallyCreateFont" because both of the built-in Windows APIs (CreateFont() and CreateFontEx()) were basically broken.

The CreateFont case taught me first hand the pain resulting from exposing an API publicly, having customers use it in ways not expected, and then having to do unnatural acts to avoid breaking backwards compatibility.

I was supporting WordPerfect's development of WordPerfect for Windows. This was sometime in early 1991 if I remember correctly. I had the WordPerfect engineer on the phone. He had given me access to the WordPerfect source code, but I couldn't give him access to the Windows code. So we were each stepping through WordPerfect in the debugger, him in Utah and me in Bellevue. I could see what his code was doing and what Windows was doing, but he could only see disassembly for Windows.

The problem he was seeing had to do with font rendering. In the debugger we stepped into CreateFontEx(), which calls into CreateFont(), which calls into some internal GDI function, which calls into the device driver's Escape() function (I can't believe I actually remember all this crap like it was yesterday). Somewhere in this call stack I came across a block of code in Windows with comments that read something like

        // This is a hack to deal with Adobe's Type Manager.
        // ATM *injects code* into GDI replacing our code with their own.
        // In order to retain backwards compatability we detect
        // ATM's attempt to do this, let it do it, and then trick it
        // into thinking it actually hacked us this way.

I am not making this up (although that comment is paraphrased from my memory).

It turns out that the way WordPerfect was using CreateFontEx() was reasonable, but pushing the envelope of what anyone had done before, effectively exposing a bug caused not by the original API design or implementation, but something the API provider had to do to ensure app compatibility because of something another 3rd party had done!

Holy-shit! Let me get this straight:

* A 3rd party app (Adobe Type Manager) used CreateFontEx() in a way the API designer failed to anticipate.

* The API designer needed to retain backwards compatibility so it had to resort to putting 3rd party app specific code in the API implementation.

* Another 3rd party comes along and the complexity of the 'fix' caused another bug to surface.

Welcome to the world of a true virtuous platform...

<comment><USER21> Parallels?

> I had the WordPerfect engineer on the phone. He had given me access to the > WordPerfect source code, but _I couldn't give him access to the Windows > code_. So we were each stepping through WordPerfect in the debugger, him in > Utah and me in Bellevue. I could see what his code was doing and what > Windows was doing, but _he could only see disassembly for Windows_.

FTA: Instead, we needed to inject our secondary dex files directly into the system class loader. This isn't normally possible, but _we examined the Android source code_ and used Java reflection to directly modify some of its internal structures. We were _certainly glad and grateful that Android is open source_ —otherwise, this change wouldn't have been possible.

Facebook are not saying that Android/Dalvik has a broken API. They are saying that that due to the size of their app they hit an interna limit, this buffer limit increased between platform versions and they needed to create a robust hack to get their code working on older platforms, They were able to do this by taking advantage of the open-source nature of the platform and they did not need a Google engineer on hand to help them though they did get to use a Google test lab (which is not fair on smaller companies). Also Google have not inserted code into Android/Dalvik to deal with the Facebook trickery.

<comment><USER20> As far as I know Google has not inserted code to deal with backwards compat. Yet.

</comment></comment></comment><comment><USER22> _"choose between cutting significant features from the app or only shipping our new version to the newest Android phones (ICS and up)"_

The ICS move wouldn't have been a bad option. It would've helped a lot of users convert to ICS+ devices, which Google probably would've loved.

The APIs from 4+ are much more robust than pre-ICS, and it probably would've saved more headaches while building the new version in addition to the one already described in the post.

<comment><USER23> Android 2.2 and 2.3 devices are still being released on low end phones, especially in developing countries, so the number of pre-ICS users are actually growing, not shrinking.

<comment><USER24> Bought one a year ago (2.3.3, I think). It's a Wildfire S, very small and lightweight, has a web browser. Can make calls and probably can send short messages. I was using Windows Mobile 2003 before that and thought I was finally on the "bleeding edge" of mobile technology, only to find out a month later that Android 2.3 is considered "legacy" and they are talking about not supporting it? What, are we supposed to buy new phones every five years now?

<comment><USER25>
      are we supposed to buy new phones every five years now?

No. Every two.

</comment></comment></comment></comment><comment><USER26> Honestly, even on my far more powerful Nexus 4, running modern Jelly Bean, the Facebook app is worse than the Web app. I think their problems are way bigger than they appreciate.

</comment><comment><USER27> This seems like it will paint the Android core developers into a corner, supporting this particular hack for years to come, like the way Microsoft had to for Windows. If I were android core developers, this would not be a good day.

<comment><USER28> This hack is specific to ancient versions of Android, and is not used on current or future versions. So there is no need to deal with it in any codebase that isn't completely dead.

<comment><USER29> > _"specific to ancient versions of Android"_

Ancient _but still shipping_. I can go into a store and pick up a Samsung Galaxy Ace running 2.3 today. A significant minority of 2.3 based phones are still being sold, especially for budget/Pay As You Go users.

This hack will need to remain in the codebase for a significant time.

</comment></comment></comment><comment><USER30> Is this me or Facebook tends to self-celebrate itself in most of its tech blog posts? I remember them posting a similar piece a few years back on their memcached scaling hacks - the article had a very similar tone, it was equally modest (e.g: not), and was actually nothing but software engineering imposture aimed at impressing a non-tech audience.

</comment><comment><USER31> I can't tell if I should be excited for the developers to have been so clever, or horrified with all the hacks they had to incorporate to make it work. Either way, the new FB app is definitely an improvement over the older version (lag central!). Is it reasonable for the OS to make such a low-level component configurable so this type of convolutions aren't required?

<comment><USER32> You should be angry that they have managed to persuade you that theirs was the only way out. The odds that properly modularizing their source tree such that they didn't provoke the limitations of the VM they were running on was impossible are vanishingly small, and the odds that they correctly hacked the VM are also vanishingly small.

Facebook's Android Engineers chose the ego stroking solution which involved clever hacks. This only reinforces my being happy to have uninstalled the FB android app 2 years ago.

</comment></comment><comment><USER33> _"We were certainly glad and grateful that Android is open source—otherwise, this change wouldn't have been possible."_

In return, maybe you could open-source some of your app, for example?

<comment><USER34> We do already open source a wide variety of projects, for those who aren't already aware: <https://github.com/facebook>

<comment><USER35> We use flashcache on one of our build servers. It has been good so far. Thanks!

</comment></comment></comment><comment><USER36> From my experience the FB app is one of the worst apps on my phone. The messaging notifications are crap, the reloading of my feed is crap (aka doesn't load notifications or in an unpredeictable manner). I have much more complex apps on my phone which show no such behaviour, yet it somehow is a Dalvik problem? Mhhh... How many Twitter apps and FB apps are there that are snappy and behave well ( = much better then the FB app!)..

</comment><comment><USER37> >>> It seemed like we would have to choose between cutting significant features from the app or only shipping our new version to the newest Android phones (ICS and up). Neither seemed acceptable. We needed a better solution.

 _This_. "There has to be a better solution", a quality which defines hackers - is it not? It's that pushing the boundaries for the sake of getting things done that drive progress, isn't it? It's tempting to take the easy route out. In this case they could have justified supporting devices ICS up, Gingerbread and down does not have a lot of market share I assume. But they chose to persist.

It's that persistence that we need to cultivate to become successful hackers.

<comment><USER38> Problem: You can't develop your film outside at night because the moon is too bright.

Solution: Destroy the moon.

</comment></comment><comment><USER39> Should we be worried that they are able to override things in the OS like this? I assume there is no built in "permission" prompt for this type of access.

<comment><USER40> It's not in the OS, it's in the individual VM that Facebook is running in. Every Android app gets it's own VM - if they mess it up badly enough then it'll just crash.

</comment></comment><comment><USER41> I don't get it. FB is so proud of "hiring the best engineers" and then they have to resort to this kind of hacks to run their app?

</comment><comment><USER42> This issue has been a colossal pain in the ass! I need this! Are they planning on releasing this code to replace the buffer?

<comment><USER43> I am working on a product that may solve this problem for you. The product is designed for a different purpose but it should work for you as well. The only caveat would be the need to break your app into multiple pieces that run in separate processes. Give me a shout at email@example.com if you are interested.

</comment></comment><comment><USER44> it's great for employees at facebook that the company allows their engineers such tinkering (to an absolute extreme in this point). but I think fb engineers should work on bigger problems than hacking the dalvik vm - <USER2> stopping the erosion of their younger user base.

</comment><comment><USER45> ...too bad they reinvented the wheel with Dalvik. It'd be awesome to be running this stuff under openjdk or hotspot</comment>


Computer science major is cool again - <AUTHOR> http://www.networkworld.com/cgi-bin/mailto/x.cgi?pagetosend=/export/home/httpd/htdocs/news/2009/031409-computer-science-majors.html

<comment><AUTHOR> "The latest unemployment numbers for 2008 for computer software engineers is 1.6%...That's beyond full employment," says Josh James, Director of Research and Industry Analysis with TechAmerica. "Computer programmers' unemployment rate has gone up from 2.5% in 2007 to 3.7% in 2008. That's a sign that programming skills are easier to do from anywhere in the world. But the high- growth jobs include skills that are hard to send abroad such as systems integration and IT managers."</comment>


Coley's Hacker News - Chrome Extension for Pinned Tabbed HN Browsing - <AUTHOR> https://chrome.google.com/webstore/detail/bcgdbcckfanmicanflmdmclgcedgeobk?hl=en&gl=US

<comment><USER2> Very nice! An option to set the refresh frequency would be useful.

<comment><AUTHOR> Indeed. I hope to add the option to toggle each tweak as well.</comment></comment>


Arduino-Powered Wire Bending Machine - <AUTHOR> http://blog.makezine.com/2012/05/03/arduino-powered-wire-bending-machine/ <comment><USER2> How does it know how not to bend the wire so it doesn't interfere with its own operation? And if it doesn't know, are there are set of heuristics used to know when the design you make isn't possible?

<comment><USER3> I was waiting to see exactly how this was handled on the octothorpe, but he strategically cut it short. Also, it seemed a little hand-wavy placing a simple spring among a collection of far more complex 3d objects.

It's an awesome project, but I appreciate when engineers either show how they addressed the edge cases, or are more honest about its failure points.

</comment></comment><comment><USER4> Here is a youtube video of same: <http://www.youtube.com/watch?v=ve1zzDXlJoA>

(For some reason Firefox + linux doesn't like Vimeo most of the time)

This is a cool device. And wire bending is used in a _lot_ of things, from making holders to support frames. These things tend to be tuned to a particular wire gauge and minimum radius so some tool and die shops will have either multiple benders or various dies for a configurable bender.

Cool things you can make with these are baskets for catching/holding parts, springs, latch returns, awesome bubble wands, and artistic lettering.

</comment><comment><USER5> So cool -- out of curiosity, is this emulating the actions of a pre-existing, "professional" machine or is the concept brand new?

<comment><USER6> There are expensive machines you can buy that do this: CNC wire benders. From the first page of YouTube hits: <http://www.youtube.com/watch?v=mwygMdpQ8SU>

<comment><USER5> Cool, thanks. I just noticed they allude to these machines in their blog post: <http://blog.pensanyc.com/tagged/DIWire>

</comment></comment></comment><comment><USER7> Awesome!! However, I couldn't help notice that if you have a 3D object, it seems that it keeps spinning the chord around the machine - at one point it would unplug itself - should be an easy fix though.

</comment><comment><USER8> it will be hours of fun

somebody should create a online shop where we can get these gadgets built and shipped

<comment><USER7> Yeah, that'd be awesome! Or at least make some IKEA-like instructions on how to assemble them - as a programmer I have no idea how to put these things together. I would totally pay for that, like an arduino device, packed IKEA style.

</comment></comment><comment><USER9> This is great! Very ingenious design. How would it fare with thin wire?

</comment><comment><USER10> Wow nice prototype, does it make sense to use Arduino production?

<comment><USER6> If you have code for an Arudino, you can make a board that uses an AVR microcontroller (made by Atmel[0]) with that same code. It may be possible to use a cheaper AVR if you don't need the same functionality (eg, if you aren't using hardware pulse width modulation, there are cheaper chips) with only slight code modifications.

[0] <http://www.atmel.com>

</comment></comment><comment><USER11> Is there a 3d LOGO?

<comment><USER12> Not sure if you mean purely software, but generally CNC machines are instructed in a language called G-Code which is basically 3D LOGO (move absolute/relative on a number of axis and some extra instructions to start/stop spindle, etc)</comment></comment>


Berkeley: Four-story building built in four days - <AUTHOR> https://sf.curbed.com/2018/8/6/17656118/fast-apartment-residential-building-berkeley-patrick-kennedy-prefab <comment><USER2> I'm glad they finally got this technology to work. They attempted something similar in a (far larger) Brooklyn development, and all that happened was that it took 4 times as long to assemble as other buildings of similar size in the same neighborhood, AND was plagued with problems like leaks and difficulty hooking up plumbing due to poor alignment.

</comment><comment><USER3> I followed this company a while back. And while this is great that the building went up in such a short time, but this will do little to nothing to housing costs. At leasrt not unless ___thousands_ __are made..</comment>


What the Apps That Bring Food to Your Door Mean for Delivery Workers - <AUTHOR> https://www.nybooks.com/daily/2019/09/20/what-the-apps-that-bring-food-to-your-door-mean-for-delivery-workers/ <comment><USER2> It's sad to me that TFA can paper over what a massive step-up these apps are from the previous status quo, and how much better they will continue to become, in large part because of the independent contractor nature of the delivery people.

What was once an entirely untracked and mostly underground exploitation of illegal immigrants is now an app which tracks every minute worked, every task completed, which workers can turn on and off at their own whim. Somehow the fact that workers have to provide a social security number is spun as a negative.

Any app that can create features which make the service better will result in higher wages and tips per delivery, and riders/drivers can shift from app to app (sometimes within a single day) to follow these trends.

Talk to the actual couriers and they don't want to be employees, because this very frequently is not a full time job. For the people it _is_ a full time job, conversely, they are the ones least likely to be hired if shoe-horned into employment status.

Last week I had dinner delivered by a young woman driving while her son did homework in the passenger seat. This was apparently someone who needed to make some extra cash for a few hours each evening, and the cost of child care would obviously significantly reduce (if not eliminate) any income. The flexibility of being able to jump in the car and earn crucial dollars without the massive overhead of an employment contract is very valuable, and helping a lot of people.

I think we need to keep perspective that food delivery is just about the least skilled (lowest training required) job you can find in the US, and these apps are upending a traditionally extremely exploitative market with _software_ that can never steal the driver's wages, or racially discriminate against the driver, or be verbally abusive, etc. while at the same time providing potential work for millions of people at the click of a button.

<comment><USER3> Here's the problem. Rather than actually solving the underlying problems of lack of good jobs, training, and support networks for these people you're just giving them a slightly less-shitty "job", rationalizing away all the bad parts by saying it's "flexible" now, checking the box for employment, and calling it good until automated delivery completely destroys these jobs in a few years.

I would personally argue that this is worse in many ways than if we could point to high unemployment and people marching in the streets as reasons we need to change the status quo in more meaningful ways.

<comment><USER2> I mean, if you need people starving and rioting in the street to obtain your policy goals, maybe that's a good point to stop and rethink?

<comment><USER4> This comment is wildly out of touch with how power works and change happens in this world

<comment><USER2> I'm not taking the flame bait. TFA is discussing the app economy for last mile delivery, a market which TFA admits was previously largely exploitative of illegal immigrant labor paid under the table and often abused in the process.

The is a prime example where the world has changed for the better through software. The job is now above board, tracked, and accounted in ways that make it better paying, more reliable and even safer work.

The competitiveness of the marketplace will only ensure these jobs become even better paying and safer over time.

Exceedingly low job switching costs is a _massive_ contributor to the competitive forces which lead to these advances, which in fact serve to protect low skilled workers from otherwise abusive employers.

Every delivery app platform lives in absolute fear of all their contractors switching to the competition because they found a way to more efficiently schedule, queue, route, deliver, fulfill their customers and therefore can pay the couriers a higher rate or ensure them more profitable routes or a larger tip share.

</comment></comment></comment></comment></comment><comment><USER5> I delivered food while in college before the rise of delivery apps and it was _awful_. Even with grubhub - each restaurant was responsible for hiring and managing its own delivery staff.

If the restaurant I was delivering for wasn't busy? I made bad less money (the people I worked for were pretty solid; you made tipped hourly + tips or non- tipped hourly during the shift, which ever was greater). If it was too busy I would be run ragged and my tips would go down as it took longer to complete orders.

To make more and more consistent money, some friends and I would 'game the system' to a degree and each be working 1-2 restaurants in the same business district at the same time. We would trade orders back and forth based on where we were going to make trips more efficient and split the payout pretty much evenly (if someone had a hard delivery or something, they might be given a bit extra).

If the restaurants knew we were doing this they would probably have fired us.

My shifts were fixed; ie I had the sunday evening and tuesday evening shifts every week. I was at the whim of overall demand; slow nights means less money. Most importantly; I could be fired.

</comment><comment><USER6> This article is refreshingly balanced, overall talking about the challenges of the workers in this space but also observing that the prior condition wasn't unlimited milk and cookies either.

</comment><comment><USER7> Companies of that type should be cooperatives.

<comment><USER8> It would be doomed to fail. These business models run on VC funny money. They lose millions even when already paying garbage wages to couriers.

Maybe way in the future once automated delivery is much more mature (and cheaper), could a co-op be possible. But we're talking decades later. And also talking about a completely different world by then.

<comment><USER9> >It would be doomed to fail. These business models run on VC funny money.

No reason a VC couldn't invest in a co-op. Or if they feel they aren't getting the unicorn returns they want, then instead of a co-op it could be organized as an employee owned and operated entity.

I think that is the future, and the disruption SV needs at this point...stop the madness of centralizing the wealth among founders and investors, and distribute it to the workers.

<comment><USER10> Why would the investors invest in something where they wouldn't get a large part of the returns?

They're not investing their own money, they have investors (things like pension funds) that they have to answer to. And honestly, the majority of VC funds don't do very well, even taking the large stakes they do. It's a hits driven business, and if you don't get those one or two breakout successes, you probably don't make back your fund.

<comment><USER9> >Why would the investors invest in something where they wouldn't get a large part of the returns?

Why would you think the investors would get any less returns if the entity (say uber) was driver owned?

They wouldn't everything remains the same, except instead of a concentration of ownership in a small group of founders, that same percentage of ownership would be distributed among a larger group of workers.

So the real question is why are investors so adverse to employee owned enterprises and invest in small groups of founders.

<comment><USER10> >stop the madness of centralizing the wealth among founders and investors, and distribute it to the workers.

This seemed to imply that the investors would take less of a stake.

Are they adverse to funding employee owned enterprises? I've never looked into it.

Maybe they think that companies with dictatorial management are more effective at competing?

For the record, having been a founder, I agree that equity tends to be overly concentrated with the founders.

</comment></comment></comment></comment></comment></comment><comment><USER11> Interesting article but deceptively titled. I guess for the publication it is in it makes sense. This article is almost exclusively about immigrant bike- based couriers in New York City and basically does not mention car based delivery, delivery apps or delivery workers outside of the NYC area.

It was interesting to learn about the NYC delivery scene and how fresh immigrants who don't even know english have a long history of being bike couriers.

But in my top 10 American city I've never had a Postmates or UberEats driver that wasn't Americanized and speaking good English. Not that it matters at all, food is food and a job is a job, but the article basically describes nothing at all similar to food apps and delivery workers in the rest of the country.

<comment><USER12> I guess this is how people outside the US feel when they read an article that doesn't specify "in the US".

<comment><USER11> I was unaware non-Americans went to American websites and didn't like that the American content was American. I've personally never gone to a .co.uk or .ca website and felt bothered that the content was British or Canadian, myself.

<comment><USER13> I agree. That's why I never visit .us domains, I generally limit myself to the international domains.

<comment><USER14> Even though .com isn't specific to the US, it is by default. eg. amazon.com vs amazon.co.uk</comment></comment></comment></comment></comment>


Show HN: Speed: a golang client for the Performance Co-Pilot instrumentation API - <AUTHOR> https://github.com/performancecopilot/speed <comment><AUTHOR> Hi HN,

This is Suyash, and this year I was lucky enough to be selected for the prestigious Google Summer of Code program with the Performance Co-Pilot organization ([https://summerofcode.withgoogle.com/projects/#61781860941824...](https://summerofcode.withgoogle.com/projects/#6178186094182400)).

As part of my project, I have been building a go library that implements the instrumentation API for PCP and we just tagged the initial 1.0.0-alpha release for the project and would like some feedback for our work.

Some examples to demonstrate the features available in the initial release are in the examples subdirectory of the package at [https://github.com/performancecopilot/speed/tree/master/exam...](https://github.com/performancecopilot/speed/tree/master/examples).

Please note that I am a new gopher and may have missed out on some things, and any feedback related to the API design or the source code would be extremely helpful.</comment>


Linux Kernel Is Still Seeing Driver Work for the Macintosh II - <AUTHOR> https://www.phoronix.com/scan.php?page=news_item&px=2020-Linux-Macintosh-II-ADB <comment><USER2> The m68k port is well maintained and is one of the oldest Linux ports of all.

There are multiple active kernel maintainers and the port is regularly seeing improvements and new drivers such as for the X-Surf 100 ethernet card for the Amiga or the ICY board (an I2C board) for the Amiga.

There is also ongoing work to support LLVM [1] and consequently Rust [2] on Motorola 68000.

Disclaimer: I'm Debian's primary maintainer of the m68k port and I'm supporting a lot of these efforts directly or indirectly.

> [1] [https://github.com/M680x0/M680x0-mono- > repo](https://github.com/M680x0/M680x0-mono-repo)

> [2] > [https://github.com/glaubitz/rust/tree/m68k-linux](https://github.com/glaubitz/rust/tree/m68k-linux)

<comment><USER3> I have a hardware question. Seeing that the heyday of the Motorola 68000 series was in the early nineties, aren't modern Debian's storage and memory requirements getting to be very prohibitive, even for a minimal headless install?

I'm just curious what kind of hardware setups are used for running and developing Debian on these systems. What are you running on/developing with? Is a desktop computer with qemu the fastest practical 68k computer you can have?

<comment><USER4> wasn't the heyday of the Motorola 68k the 80s? by the time the 486/040 came about it was already starting to show that motorola was not able to match intel's mhz push.

<comment><USER5> > wasn't the heyday of the Motorola 68k the 80s?

It depends on the market. For PC/workstation class machines, the 80's into the early 90's were 68k's moment in the sun. But I distinctly remember doing new embedded development work on 68K in the late 90's and and Palm Pilot (1997) had a 68K core also. So even though they had to retreat from one market, they stayed active in the embedded space. (Of course, so did Intel... that same project with the 68K also ran on an 80188EB, 386SX, and an AMD Elan SC400).

> by the time the 486/040 came about it was already starting to show that > motorola was not able to match intel's mhz push.

Intel had a few more minor growing pains too. The 486/25 and /33 chips were easily accepted into the market, but the /50 was not. There were problems at the time getting a 50MHz motherboard to work correctly and not cause too many problems with radio interference. So the 50MHz part wound up being limited to the high end of the market. The step beyond 33 for the 'mainstream' PC market was the DX2/66, which left the bus/motherboard at 33MHz and used the on-chip cache to run the CPU itself at 66. So faster CPU than a DX/50, but less bus bandwidth, which turned out to be a reasonable tradeoff. (Particularly given that I/O was often very slow, anyway, being forced through a 16-bit 8Mhz AT bus.)

The Pentium, of course, brought the >=60Mhz motherboard back into the PC mainstream, and there was also a 486/DX4 part around the Pentium timeframe. Contrary to its name, the DX4 was a clock tripled CPU that would run 33/100 (with an option for a doubled 50/100 as well). Clock multipliers came to the Pentium with the second revision... the original P5/60 and /66 ran 1:1, but the subsequent P5/90 and /100 ran 1.5:1.

<comment><USER6> VME bus 680x0 servers were in pretty wide use in the appliance market through the 90's as well. Things like firewalls.

<comment><USER5> > wide use in the appliance market through the 90's as well. Things like > firewalls.

Thank you for clarifying with that bit... I was (very briefly) trying to imagine how a 90's era dishwasher or something might use a 68K CPU in a VME cage.

<comment><USER6> Funny enough, the Coldfire series of 680x0 derivatives were marketed at "smart home appliance" manufacturers.

<comment><USER5> Seems like a natural fit, if maybe even a bit overpowered.

That said, the embedded 68K project I was on was for an industrial process control device. (We were making hardware that would fit in a valve or sensor in the field and connect it to a network.) Because of various safety requirements, total power dissipation was very, very low. (draw on the order of mA, IIRC, and fairly low voltage.)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> _"Apple Desktop Bus is the proprietary interface used by Apple in the late 80 's and 90's for connecting devices like keyboards and mice to the system rather than a PS/2 interface."_

The implication (between the lines) that Apple went with a proprietary solution while an open one was available bends history a bit. Judging by release date, ADB predates PS/2 by half a year or so.

Also, was the PS/2 keyboard/mouse interface any less proprietary than Apple Desktop Bus at time of initial release?

<comment><USER8> > Also, was the PS/2 keyboard/mouse interface any less proprietary than Apple > Desktop Bus at time of initial release?

Not really. They were both proprietary. ADB was Apple's solution, and PS/2 was IBM's solution.

ADB was rather nifty from a technical perspective -- it was a multidrop bus which could support multiple devices, as opposed to PS/2 which could only support a single device per port. It was common for mice to be chained off of keyboards, for example, and there were a number of third-party peripherals which could be connected to ADB as well, like graphics tablets.

<comment><USER9> ADB was basically USB 0.1: 5-volt multi-device serial bus for desktop peripherals, polled by the host, with dynamic addressing and standard device classes. The only thing it was missing was hot-plugging. (The protocol could handle it, but there were mechanical/electrical issues that made it hazardous to try.) They even had a connector that made it hard to tell if you were trying to plug it in upside down!

<comment><USER10> With the connector itself, it was hard to tell, but the plastic part you held in your hand (molded plastic plus strain relief) wasn't symmetrical.

You could thus develop a habit of putting, say, the flat part next to your thumb, and then you'd know the alignment of the cable. So if you knew the alignment of port, you could do reliably on the first attempt.

USB makes a slightly worse mistake, which is that the plastic part you hold in your hand feels the same way if you turn it around 180 degrees. So you have to point it at your face and look at it if you want to know which way you're holding it.

<comment><USER11> I think all of the USB-A jacks i have are made out of a sheet of metal folded over on itself, with the join on the bottom. You can tell which way up a jack is by looking for the join. See this picture of some random bitcoin gizmo:

[https://www.ccn.com/wp-content/uploads/2014/11/usb-top- botto...](https://www.ccn.com/wp-content/uploads/2014/11/usb-top-bottom- together.png)

It's certainly not as easy as with ADB, but it only takes a quick glance to orient a USB jack. I can't be the only person to have noticed this.

<comment><USER12> The part that screws me up is whenever the USB port is upside down, meaning the plug goes in with the retention holes facing down.

</comment></comment></comment></comment></comment></comment><comment><USER13> Back in the early 2000s I did not have much money and but was able to get my hands on all sorts of slightly exotic and out of date computers for free. People just gave them away. I really enjoyed running Linux on old SGI or Apple computers. Over time however the novelty wore off and I realized that even old x86 hardware was cheaper and faster. Any people running Linux on some rare old hardware care to share why?

It can be a great learning experience though.

<comment><USER2> > Any people running Linux on some rare old hardware care to share why?

It's called retro-computing and it's simply a hobby. You could also ask why people are fixing, maintaining and driving around with cars that are decades old.

It's also a very good method to learn everything about kernel development and maintenance. On x86, there are enough people looking at and working on the code, so you will have a hard time to find things for improvment.

The m68k port, on the other hand, has many places where you can help with improving the code and therefore get your feet wet with kernel development.

<comment><USER14> Maybe some companies are interested in this as well. As I know from work, the PLC manufacturer Pilz [1] e.g. uses 68k type CPUs in some of the products.

[1] [https://www.pilz.com/](https://www.pilz.com/)

</comment></comment></comment><comment><USER15> Does the kernel ever remove support for devices or does this stuff just bloat up the codebase for eternity?

<comment><USER16> Yes, linux removes support for stuff over time. But most drivers for old simple peripherals are considered not a problem - as long as they are clean optional components of their respective subsystems, they don't bother anyone.

One example of support being removed includes old intel 386 processors, due to multi-core support complications apparently: [http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html](http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html) (that left intel 486 and later still supported)

A bit more recently, a bunch of obscure architectures were removed, mostly because the last compilers to support them are too old or buggy: [https://lwn.net/Articles/748074/](https://lwn.net/Articles/748074/) (Linux is in general really great about supporting a range of gcc/binutils versions going back about 7 years ... compare to some other popular projects these days which require a Go or Rust toolchain from just a few months ago.)

And occasionally a driver is moved to "staging" to see if anyone complains, before being removed, because it is being a bother and no one seems to be maintaining it: [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea2e813e8cc3492c951b9895724fd47187e04a6f)

This is related to why "upstreaming" a driver can be very different from just releasing the source. Making a driver acceptable for merging into the mainline kernel, means making it clean enough that maintenance costs will be extremely low, for the next 5 to 10 years, even as the linux kernel sustains a surprisingly large amount of change in every single 3 month release cycle.

<comment><USER17> _they don 't bother anyone_

Well, it's been like 2 decades since I last compiled a kernel myself, but back then I was definitely bothered with the pages of obsolete hardware which could be selected from when running _make menuconfig_. Not sure if/how people configure kernels these days but I assume it didn't get better?

<comment><USER2> What's wrong with the kernel supporting a wide variety of hardware?

As long as the stuff is actively maintained, I don't see a problem as this means it's actually being used.

Linux always has had a very wide hardware support and if you are bothered about that, you can either use the make target "localmodconfig" or just don't build your kernels yourself.

<comment><USER17> _What 's wrong with the kernel supporting a wide variety of hardware?_

I think you misunderstood my reply. I'm not saying the kernel should drop support, I'm merely replying to the 'doesn't bother anyone' with a practical example of why it might bother someone on a particular level.

<comment><USER18> It bothers you that the kernel supports hardware you don't have?

<comment><USER17> Again, no, that is not what bothers me. I'm not sure if I was really that unclear - twice - or if it's just because it's monday :)

So here it goes, in full (similar to sibling poster cesarb's story): once you could, spending some time, just go over pretty much every possible option and select what you needed. Which mattered back then (at least to me), because compilation already took half a day on my machine so the less things to compile the better. Now over the years came more and more support for different hardware. That fact by itself obviously did not bother me, also because it meant I could finally hook up my _insert not too common device_ here. What started to bother me was just that it took more time to go over all options. Whishful thinking because hard to implement, but I would have liked a flag like "ok you can just skip everything for harware which only existed before 1995 because I don't have that". So, reflecting on that period, I'm simply wondering what it must be like today to go through all options. I.e. I wonder if others might be bothered by the sheer amount of options out there.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> I had been meaning to see if anyone was interested in some fixes to the IOP ADB driver for the IIfx and some Quadra machines.

Apple had provided some internal documentation for the IOP controller but it is incorrect. The Linux driver for it just polls any ADB device for data directly instead of letting the IOP process it and just interrupt the CPU when there is a complete ADB message. I have got a working IOP driver for NetBSD/mac68k that the Linux people might like to copy.

</comment><comment><USER20> Why is Macintosh II still being worked on but 386 support got killed? I genuinely want to know. I suppose it might be because 386 requires more gymnastics around systems programming for memory management, etc.

<comment><USER21> My speculations:

(1) there are people who are so keen on keeping 68K/Macintosh/etc support alive that they keep on working on it, while maybe no one displayed the same keenness when it came to 386

(2) 386 complicates code paths for 32-bit x86, which people still care about (even if only a little) for real world production use. By contrast, 68K stuff sits in its own directory tree and has little impact on the rest of the kernel

<comment><USER22> > (2) 386 complicates code paths for 32-bit x86, which people still care about > (even if only a little) for real world production use.

I don't know how much of a concern this is IRL, given that one could hide essentially all 386-specific workarounds behind #ifdef's.

<comment><USER23> 386 specific workaround code still needed to be updated if relevant part of the code is updated.

If you look at the patch the remove 386 support ([http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html](http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html)), you can already see that it's already under #ifdef. There are quite a number of atomic instructions not available for 386 which all requires workaround.

<comment><USER22> Looks like that code could have been refactored to be better self-contained. Though I suppose removing it altogether is a fine way to go about it; it can always be reintroduced in the future if folks commit to maintaining the support going forward.

</comment></comment></comment></comment></comment><comment><USER24> I was amusing myself with using obsolete tech with a modern computer this weekend when I needed a video card for a server. Not wanting to waste power on an unnecessary GPU I looked around for the least capable card I had and found one from 1997[1]. It still works fine with a processor made in 2017. And Linux had no complaints using the generic VESA X.org driver. Though there is a native Tseng driver still there, the particular live USB I had would segfault. Actually it looks like the last two bugs filed against it were marked WONTFIX in 2011 so I'd say the driver is unmaintained and Xorg should consider removing it.

(I wonder if the new ADB driver would be useful with the USB-to-ADB adapter I have. Although the only thing I could plug into it is a trackball.)

[1] [http://www.vgamuseum.info/index.php/component/k2/item/465-ts...](http://www.vgamuseum.info/index.php/component/k2/item/465-tseng- et6000)

<comment><USER25> USB->ADB adapters are more like ADB->USB translators than ADB on a USB bus, though. They'll only support some peripherals, and they'll show up as normal HID devices. You won't be able to connect your PageMaker dongle, unfortunately.

</comment></comment><comment><USER26> So is someone running the kernel on their Macintosh II... to do a thing (obviously as the article notes it was tested on a Centris 650) or is this just an awesome thing to do because it could be done?

</comment><comment><USER27> Here's a fun story about the creation of ADB by Woz: [https://eggfreckles.net/2013/12/27/adb-the-epitome-of- early-...](https://eggfreckles.net/2013/12/27/adb-the-epitome-of-early-apple/)

</comment><comment><USER28> I have a question: doesn't all this extra (basically useless) driver code just increase the security risk for Linux?

Like aren't you just increasing the attack surface? Since all these drivers exist in kernelspace.

So there's three levels, as I understand it that driver code like this could be included (or not) in the kernel. This is not my area of expertise so please excuse me if I'm mistaken here but you have:

1\. Not included in the kernel and not included as a module. This is obviously excluded at source and is the safest;

2\. Available as a module but not loaded by default; and

3\. Included in the kernel. I'm not 100% sure if there even is a distinction between this and (2) anymore. I remember at one point you could include code as part of the configure process during compilation and this was distinct from modules (at least for a time).

Either way, there doesn't seem to be a difference philosophically between (2) and (3), right? A vulnerable module can be loaded from userspace, generally speaking.

Also, I'm actually curious how often drivers are the source of security vulnerabilities? Is this a common or rare vector?

<comment><USER8> The driver in question can't even be compiled for x86 systems, either as a module or otherwise. Having it in the source tree is completely harmless.

<comment><USER28> That misses the point entirely. It's not about this driver specifically but concerns the thousands of other "dead" drivers and similar that could be loaded.

<comment><USER29> Most people use their distro's default kernel binaries, which tend to include only modules that are at least somewhat likely to be used by that distro's target audience. Nobody ships kernels with _all_ modules compiled.</comment></comment></comment></comment>


Fairway Was Mismanaged and Looted by Private Equity - <AUTHOR> https://www.bloomberg.com/opinion/articles/2020-01-23/fairway-was-mismanaged-and-looted-by-private-equity <comment><USER2> Who is the victim here? The owners cashed out to buyers who were presumably the ones offering the best exit, the buyers funded the purchase with debt, and their longterm plan failed. The banks who lent the debt took the risk and believed in Sterling, which was a bad bet. It seems like everyone got what they deserved.

What is the alternative? Legally forcing owners not to sell? Preventing owners from trying to expand "too quickly"? Outlawing poor management? None of this is feasible.

</comment><comment><USER3> The real issue is the debt issuers. Why would you allow cash to leak out to equity holders when the business is doing poorly? Too much leverage and unrealistic growth expectations caused these issues.

</comment><comment><USER4> > In the ensuing buyout, Sterling put $150 million into the company in return > for an 80% ownership stake. The majority of that was debt. Needless to say, > the debt landed on Fairway's books, not Sterling's.

WTF?

</comment><comment><USER5> Excerpt:

"On a per-square-foot basis, the four Fairways were among the highest grossing grocery stores in the country."

Interesting!</comment>


Markets are Efficient if and Only if P = NP - <AUTHOR> https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1773169

<comment><USER2> Discussed at considerable length a month ago:

<http://news.ycombinator.com/item?id=2895474>

At that time I said this:

        It feels to me that all he's done is show that the
        "instantly" in the usual definition of markets being
        "efficient" is a nonsense. Prices must take time to
        compute, you can't know the correct price instantly
        even with access to all the past information.

        He proves that, but it doesn't seem that surprising
        to me.

<http://news.ycombinator.com/item?id=2895531>

That was expanded on a great deal, and other observations made.

There was also an earlier version of the paper submitted some 19 months ago, also with a great deal of discussion:

<http://news.ycombinator.com/item?id=1144548>

<comment><AUTHOR> Thanks for this, I should have searched before posting.</comment></comment>


How to Write with Style (1985) - <AUTHOR> http://peterstekel.com/PDF-HTML/Kurt%20Vonnegut%20advice%20to%20writers.htm

<comment><USER2> The Elements of Style is both dated and largely self-contradictory. Vonnegut judged his own work by slightly different metrics:

1\. Use the time of a total stranger in such a way that he or she will not feel the time was

2\. Give the reader at least one character he or she can root for.

3\. Every character should want something, even if it is only a glass of water.

4\. Every sentence must do one of two things—reveal character or advance the action.

5\. Start as close to the end as possible.

6\. Be a sadist. No matter how sweet and innocent your leading characters, make awful things happen to them—in order that the reader may see what they are made of.

7\. Write to please just one person. If you open a window and make love to the world, so to speak, your story will get pneumonia.

8\. Give your readers as much information as possible as soon as possible. To heck with suspense. Readers should have such complete understanding of what is going on, where and why, that they could finish the story themselves, should cockroaches eat the last few pages.

<comment><USER3> > The Elements of Style is both dated and largely self-contradictory.

That's a bold statement. Care to back it up?

<comment><USER4> I don't know what the OP meant, but I remember reading it and noting that the section on not using the passive voice used the passive voice. There were probably more things like that.

Unrelated, but in general I think the advice of Nassim Taleb is good: most people looking to improve their writing style are really lacking something to say.

<comment><USER5> > I don't know what the OP meant, but I remember reading it and noting that > the section on not using the passive voice used the passive voice. There > were probably more things like that.

Are you sure that wasn't a joke? I recall that the writers often would cleverly break their 'rules' to make them examples of what to avoid.

<comment><USER4> No, they gave examples of the active voice that were actually passive voice, just better written.

</comment></comment></comment></comment></comment><comment><USER6> The Elements of Style - W. Strunk Jr. and E.B. White

[http://faculty.washington.edu/heagerty/Courses/b572/public/S...](http://faculty.washington.edu/heagerty/Courses/b572/public/StrunkWhite.pdf)

</comment><comment><USER7> i read this and liked it, only after I scrolled up did I realize it was Kurt Vonnegut.

Also, I really love this video of his, on the shape of a story [https://www.youtube.com/watch?v=oP3c1h8v2ZQ](https://www.youtube.com/watch?v=oP3c1h8v2ZQ)

As a side note I found the formatting, or lack of formatting, interesting. It felt very much like a document, or a piece of paper, than a web page. That surprised me.

</comment><comment><USER8> I can thoroughly recommend "The Book on Writing: The Ultimate Guide to Writing Well" by Paula LaRocque

([http://www.amazon.com/The-Book-Writing-Ultimate- Guide/dp/098...](http://www.amazon.com/The-Book-Writing-Ultimate- Guide/dp/0989236706))

</comment><comment><USER9> I remember reading this in an advert for International Paper when it first came out. It's absolutely wonderful, and one of the most readable things I've ever seen from Vonnegut.

</comment><comment><USER10> This reminds me of many good principals of writing code.

</comment><comment><USER11> This is wonderful, thank you.</comment>


Obama's secret struggle to punish Russia for Putin's election assault - <AUTHOR> https://www.washingtonpost.com/graphics/2017/world/national-security/obama-putin-election-hacking/?tid=sm_fb&utm_term=.fc7efe1acdf9 <comment><USER2> Hugely unpopular opinion time, especially on HackerNews, but I'm just going to say it: I don't believe any of it. I don't believe WaPo, I don't believe the/their "Russian interference with the elections" narrative, and in fact, if there is one country that has interfered with elections all over the world, the USA would be it. Now the narrative has been shifty to an extreme, but this attempt to - again - make Obama appear to almost be some kind of fantastic leader, is just another poor and perverse attempt to turn history and current events into something it isn't.

<comment><USER3> Well, you can't argue with the existence of the "troll factories". There definitely are paid people online who pursue the Kremlin propaganda, sometimes in not-so- subtle way. Were they in favor of Trump rather than Clinton? Probably, as the former expressed some surprisingly positive words towards Puting and the future relationship with Russia. Did they actually manage to interfere that much the public opinion? I'm not sure. I talk to Trump supporters almost every day. Their views don't seem much to do with Russia- sponsored propaganda. They are just unhappy with something (and this "something" is usually "the left" as a whole, or some aspect they don't like).

<comment><USER2> There are all kinds of troll factories, so from Russia too, sure. No problem with that. I just think WaPo and NYTimes are also troll factories. And there are many others. Especially with the word 'troll' being used in increasingly broad senses and increasingly more often.</comment></comment></comment>


React switches to the MIT license - <AUTHOR> https://facebook.github.io/react/blog/2017/09/25/react-v15.6.2.html#changelog <comment><USER2> [https://news.ycombinator.com/item?id=15316175](https://news.ycombinator.com/item?id=15316175)</comment>


How the Consumer Product Safety Commission Is Behind the Largest DDoS Attacks - <AUTHOR> https://blog.cloudflare.com/how-the-consumer-product-safety-commission-is-inadvertently-behind-the-internets-largest-ddos-attacks/ <comment><USER2> "How the Consumer Product Safety Commission Is Behind the Largest DDoS Attacks"

=>

"How the Consumer Product Safety Commission's DNS Records Are Used in the Largest DDoS Attacks"

FTFY

<comment><USER3> Very good article with the unnecessary click bait headline.

</comment></comment><comment> _-- "Consumer Product Safety Commission is behind...DDoS"

This sort of title suggests that intent is not important.

If we accept that as true, then we can make a few more observations.

 _DNSSEC is behind DDoS._

The large responses mandated by DNSSEC allow DNS to be used to DDoS.

People warned the DNSSEC proponents about this.

They ignored the warnings.

Because the intent of DNSSEC is something else besides DDoS. (What that something is could be a controversial topic in itself.)

If DNSSEC and its users are behind DDoS, then _who is behind DNSSEC?_

What are they trying to achieve, what is the problem they hope to solve with DNSSEC? Besides making DDoS easier.

A small group of people gets to ultimately decide what is and what is not a "valid" or "authentic" domain name?

Why would anyone need something like that?

"DNS experts" over the years have been increasingly willing to admit that it's reasonable to acknowledge that users could choose not to share a DNS cache with anyone else. They could run their own cache bound to the loopback.

When this happens, does the user still need DNSSEC?

</comment><comment><USER4> Well, that title was a little misleading, but it's still not an encouraging tale. What's the fix here?

<comment><USER5> Maybe limit DNS queries with long answers to TCP. DNS servers speak both TCP and UDP. With a UDP query, the source address can be faked, which causes the results to be sent somewhere else. With TCP, the attacker can't make it through the TCP handshake with a fake source address, because the attacker isn't getting the replies.</comment></comment>


Video transcoding, resizing, cropping and manipulating made easy - <AUTHOR> http://cloudinary.com/blog/video_transcoding_resizing_cropping_and_manipulating_made_easy

<comment><AUTHOR> More and more sites and apps include user uploaded videos, which raise new challenges for web and mobile developers. This article describes how to transcode, convert, resize, crop and manipulate videos to best match the graphic design of your application on any device, browser and resolution. All video processing takes place in the cloud.</comment>


"I Am the Very Model of a Modern Major Googler" (Song) - <AUTHOR> http://mindrosity.blogspot.com/2007/07/i-am-very-model-of-modern-major-googler.html

<comment><USER2> (from <http://lauren.vortex.com/googler-lyrics> )

"Our data store of your actions makes NSA's look just like toys,"

bet their pr folks love that one.</comment>


Interactive Interpreter Undo (2016) - <AUTHOR> http://ballingt.com/interactive-interpreter-undo/ <comment><USER2> Fun fact - a lot of this is kind of stuff is used in SQL databases! Before you finish a transaction (i.e. a sequence of commands), you can rollback the transaction. This will undo the effects of every command ran as part of the transaction. It's interesting to take a look at how different production databases implement undo:

MySQL and Oracle use the "reconstructing previous states from the current state" strategy. As commands are ran, they keep track of how to undo those commands in the "undo log". If you rollback a transaction, all they do is run the commands in the undo log.

Postgres uses a different strategy. When Postgres modifies a row, it marks the old row as deleted and inserts a new row. Furthermore these changes are associated with the current transaction and considered to be pending until the current transaction completes. If the current transaction fails, Postgres will use the original version of the row because the transaction that modified it never actually completed.

SQL databases have a completely separate form of undo used for point in time backups. This is the ability to restore a copy of your database from any point in time in the past. As far as I know, use a combination of the "recording each state" and "reconstructing previous state from initial state". There's two parts to your typical database backup. There's the base backup which captures the state of your DB at a specific point in time. Separately there's a redo log that captures every change made to the data after the base backup was created. By replaying the changes made before a certain time, you can restore the DB to any state after the base backup was created.</comment>


Show HN: Gitern is a Git host for hackers - <AUTHOR> https://gitern.com <comment><AUTHOR> Hello! I'm Keyan and I'm building [https://gitern.com](https://gitern.com)

Perhaps I'm an odd duck (I am) but I think current git hosts are no longer meant for hackers and I really wanted a git host that is and that's why I'm building gitern.

Gitern is just getting started and only has essential features today but we already have a few differentiators: \- all auth is done with ssh keys (no password or email required) \- arbitrary repository paths allowing for (1) familiar namespacing and (2) access control (eventually) \- a cli-first ui \- private repos are default

I think better tools make for better hackers and I think git hosts can be a lot better.

I'll be in the comments if anyone wants to ask questions or scold me or something :). Very very open to feedback!

Cheers everyone

<comment><USER2> Hey, I know gitern is cli based, but I wanted to compliment you on the design of the gitern.com site. Love the colors, artwork, everything. Very minimalistic and tasteful.

<comment><AUTHOR> Thank you! That makes me feel so good, thank you

</comment></comment></comment><comment><USER3> Funny, just a while ago was pondering on what a "github for hackers" would look like.

My personal answer would be: it should be a _hackable_ webapp, where users can implement or tweak features at will.

The ingredients being the usual:

\- a plugin system

\- a function hooks system

\- many, many available options that are _never_ taken away (i.e. breaking API changes).

When was the last time you used a webapp even remotely like that?

<comment><AUTHOR> Yep, we're thinking about this alike! My answer _will_ be: an emacs-like git hosting experience.

<comment><USER4> > emacs-like git hosting experience

Sounds like git heaven for hackers ;)

</comment></comment></comment><comment><USER5> Any reason I'd use this instead of Sourcehut [1] ?

[1] [https://sourcehut.org](https://sourcehut.org)

<comment><AUTHOR> I'm not familiar with sourcehut but thank you for sharing. I'd say if you're using a git host you're already happy with you should keep using it for sure.

<comment><USER6> You seriously want to play with sourcehut.

It has its own very hacker-oriented aesthetic and tries to keep the various components it provides separated so for things that are "close enough" you might be able to bootstrap off their tools.

Also, the concept of a CI system where a failed build sticks around for a while and lets you ssh in to figure out what went wrong is -way- cool.

<comment><AUTHOR> Thank you for the extra push. I definitely will

</comment></comment></comment></comment><comment><USER7> I'm not really looking for a new git repository hosting service but this seems cool. I was a bit disappointed that I had to download a cli tool after signing up. It would be cool if you could do all the management non-git operations via ssh and without any additional client software

<comment><AUTHOR> You can actually! The cli is just a really dumb wrapper around ssh execs.

create: ssh firstname.lastname@example.com gitern-create <path>

delete: ssh firstname.lastname@example.com gitern-delete <path>

list: ssh email@example.com gitern-list [<path>]

pubkey add: ssh firstname.lastname@example.com gitern-pubkey-add <account> (pubkey on stdin)

pubkey remove: ssh firstname.lastname@example.com gitern-pubkey-remove <SHA256 fingerprint> <account>

pubkey list: ssh email@example.com gitern-pubkey-list

Edit: Eventually the cli will provide a lot more (and self document what's available) so I do recommend using it, but you can happily get along with these "raw" commands for now.

<comment><USER8> I love it. Would feel more comfortable with a bash source-file I could copy than an installer tbh.

This reminds me, as I suppose you expect, of a lovely ssh-based chat service i saw on here a while back: [https://news.ycombinator.com/item?id=8743374](https://news.ycombinator.com/item?id=8743374)

<comment><AUTHOR> Thanks! I agree. I want to provide more client-side options eventually (e.g. a static binary or pick your language flavor cli), but had a bunch of tradeoffs to consider for first pass. I'll likely open source the client side and keep the ssh api backward compatible, so perhaps this can happen soon.

Re: ssh-based chat. I found that post very very early on while exploring gitern as just an idea! Very formative of gitern.

<comment><USER6> For a hacker's client to github, I'd recommend having a look at ingydotnet's git-hub which is bash + his json-bash thing.

Interesting prior art and maybe some stealable concepts :D

<comment><AUTHOR> Wonderful!

</comment></comment></comment></comment></comment></comment><comment><USER9> Hey, first of all, cool project! Although I certainly see the romantic appeal of "no email or password, just ssh key" and "the cli is the ui", other than for solo hackers I think you need a way to visualize the changes of a Pull Request (or Merge Request like in Gitlab) and do a code review, add comments, etc. Or at least Patch Review like in sr.ht I actually think that would be useful even for a solo hacker. Other features would also be welcomed, like CI/CD and tickets to track new features and bugs, but you can always integrate with a third party service for that. Also, unless I'm missing a key feature, I think for the use case you're appealing to you could just have a repo in a VPS or rsync.net. And the comparison with Dropbox doesn't apply here because dropbox is for the masses, and gitern ia for hackers, any hacker would know how to set that up. Finally with keybase you can create encrypted git repos. You can, manually set encrypted git repos on a VPS but it's difficult, keybase does it hassle free. You can also self-host something like gitea/gogs or gitbucket, or even gitlab.

<comment><AUTHOR> This very thorough and great feedback. Thank you!

</comment></comment><comment><USER10> I was expecting a static binary when I downloaded the CLI, but I got a huge load of node.js files and modules. Consider packaging your node.js application up, I haven't tried it but [https://github.com/nexe/nexe](https://github.com/nexe/nexe) looks promising.

<comment><AUTHOR> Thanks for the link. v0 cli was written in gerbil scheme ([http://cons.io](http://cons.io)) but I couldn't get it to statically link on linux so I'd still have deps in the form of dynamic libs. Then I found oclif which while depending on node has a lot of what I need and will allow me to ship/iterate faster ... If the spec/features/api was fixed, I'd write the thing in golang if only for the static binaries and cross compiling but it's a relatively joyless/cumbersome language IME, so node for now at least.

<comment><USER11> I was writing a similar cli tool [1] to manage the git repositories on my own server. If you want portability, it should be fairly easy to write the cli interface in plain sh or bash, especially when most of the operations could be done on the server side. I am not sure if there is a reason to use a compiled language for this.

[1]: [https://0x0.st/8zs0](https://0x0.st/8zs0)

<comment><AUTHOR> Thanks for sharing that's awesome!

Bookmarked. I'll think more about implementing it as a shell script.

</comment></comment></comment></comment><comment><USER12> Very cool, I've had this same idea sitting in the back of my head too, instead of user names there are just ssh keys

Honestly we've seen a ton of cool side projects like this on HN because of quarantine

</comment><comment><USER13> As one of those odd people who actually knows someone who plays a Gittern; I love the name and the medieval theme to the site :D

<comment><AUTHOR> lol I wasn't expecting anyone to get the reference! I listened to this approximately a million times during development [https://www.youtube.com/watch?v=qQbfcTIRFxA](https://www.youtube.com/watch?v=qQbfcTIRFxA)

</comment></comment><comment><USER14> What is the fallback if you lose your SSH keys?

<comment><AUTHOR> At the moment, it's left to the user to add other ssh keys, perhaps from another machine, or back them up.

I'm currently working on a way to optionally add an email address for recovery.

</comment></comment><comment><USER15> I'm so into this. I love the aesthetic and the hacker values. Do you have a blog or anything?

Edit: scrolled to the bottom, nice Twitter :)

<comment><AUTHOR> Thank you! I have a mostly empty blog [http://keyankousha.com](http://keyankousha.com) (I have some drafts in the pipeline but I don't have a good writing habit yet). Twitter is a little more active @k00bideh

</comment></comment><comment><USER16> This is really nice!

I wonder if some of the cli commands like create can be auto-executed on first git push.

Is this open source? Would love to hack onto it.

<comment><AUTHOR> I will likely open source the client side. So stay tuned :)

Edit: Meant to add I've had a similar idea but it should probably be optional and configurable in a git config type way.

</comment></comment><comment><USER17> This is soooo comfortable, thank you!

<comment><AUTHOR> Awesome! That's EXACTLY what I'm going for. I kept using github and having this feeling of "this doesn't feel like it was built for me."

Current git hosts don't feel like they were made for programmers which is nuts! Even for the most essential and basic actions (all of what gitern provides at the moment), they feel kludgy. My intent is to carry a programmer- first approach for all needs programmers have around git hosts. I have SO many ideas on how to do this.

If you couldn't tell, I'm very happy to hear you had a positive impression lol. Thank you!

<comment><USER17> Yes, it is encouraging to see that people are still interested in creating brutalist interfaces.

I'm not sure how it would fit a professional workflow, since that would require your server to call a web hook whenever somebody merges to a given branch, but it would do fine in an amateur workflow where I set up my own CI/CD using local hooks.

<comment><AUTHOR> Right, not fit for a CI/CD ... yet. Web hooks will be added soon.

<comment><USER18> Are read-only keys on the roadmap too? CI/CD pipelines don't really need write access in most cases.

<comment><AUTHOR> Absolutely fine grain access control is a must have

</comment></comment></comment></comment></comment></comment><comment><USER19> Love the concept and design.

Where are repositories stored and do you use any sort of backup or replication?

<comment><AUTHOR> Thanks. Repositories are stored on an ext4 filesystem. I do backups every 12 hours currently. No additional replication is performed but it is something I want to do.

<comment><USER20> You'll probably want to look into using CEPH/similar when/if the service starts to get busy. Partly for redundancy but also if all your repositories are on a single shared disk you're gonna hit I/O contention if many people are pushing/pulling at the same time - even more so if you get any CI system wired up.

</comment></comment></comment><comment><USER21> Meh, I host my git repos on a vps and use cgit for web ui.

</comment><comment><USER22> Is this for script kiddies that just want to be called a hacker? All the hackers I know realize Git is already decentralized and all you need is an SSH server.

<comment><AUTHOR> Someone: _opens a dumpling restaurant_

You: Is this for food kiddies that want to be called foodies? All the foodies I know realize dumplings are just sheets of dough wrapped around a filling.

<comment><USER23> Except wrapping dumplings is a pain in the ass while sshd comes pre-installed on most VPSs and you can just point a git remote at that.</comment></comment></comment>


The incredible shrinking OS - <AUTHOR> http://www.infoworld.com/article/09/02/09/06FE-shrinking-operating-system_1.html

<comment><USER2> One of the coolest JeOS things to check out is rbuilder: <http://www.rpath.org></comment>


12 hours left for MongoFR2011 early bird price - <AUTHOR> http://www.10gen.com/conferences/mongofr2011

<comment><AUTHOR> There is a -10% coupon as well: "fr10".

Just got the information as I do a presentation there, thought I would pass it along.</comment>


Your infographic isn't an infographic. It's just a crappy graphic. - <AUTHOR> http://www.portent.com/blog/design-dev/10-reasons-your-infographic-isn.htm

<comment><USER2> Title makes it sound like he's going to delineate the difference between "infographic" and "non-infographic", but it seems to run into the "real Christians" problem where anything he doesn't like "isn't an infographic". Apparently it's categorically impossible for an infographic to be less than fantastic, which is an odd definition of infographic.

<comment><USER3> Let's not pretend there's more controversy here than there really is. If anything, the point he's making is too banal. Almost the whole of _The Visual Display of Quantitative Information_ argues against the style of visualization this post argues against.

Virtually all infographics are indeed terrible visualizations of information.

<comment><USER4> > _Virtually all infographics are indeed terrible visualizations of > information._

I do not agree. I've seen quite a bunch that – although obviously not a definitive source of information – give a good sense of perspective. Here's one [0] that came back to mind.

[0] <http://mozy.com/blog/misc/how-much-is-a-petabyte/>

<comment><USER5> Really? Most of that chart is just big text. Big text is not an infographic. I would say the most interesting one I've come across recently is <http://xkcd.com/radiation/>.

<comment><USER3> Is that a particularly effective graphic? Look at how the green doses transition to the orange ones (with a legend "all green doses combined" corresponding to an irregular number of orange boxes), and then look at the transition from orange to yellow; are all the orange doses equivalent to 50sv, or are all the orange doses equivalent to one box?

I agree that the XKCD "radiation" chart is an instance where an XKCD-style comic does a better job of explaining something than an equivalent well- written paragraph. But I don't agree that it's a particularly great visualization.

<comment><USER5> I would definitely agree that it isn't the _best_ graphic, but I think it does an admirable job of portraying the primary thing it was created to portray (I assume) -- the context of radiation dose levels. I can very quickly eyeball the order of magnitude difference between a plane flight and a chest X-ray, while I could also dial down to the more precise differences if necessary.

The "radiation doses combined" transition seemed fairly clear to me. In every case the collective doses are measured in the new SI-prefixed unit delineated by the scale on the left. If I were to criticize anything I would be a little more wary of the color choices and the box labeling. The = sign and parenthetic dose notation seems a little confused (the blue box dose size uses a different convention from the others).

While the chart could layout some things a little more clearly, I think that Minard's chart shows that one shouldn't reduce information content solely for the sake of simplicity.

<comment><USER3> I think the chart would do better if removed from the arbitrary constraint of XKCD's page framing; if, for instance, a suitably large canvas was used, so that the eyes could immediately grasp the comparatively minimal exposures from common radiation sources to (say) the gigantic exposures from Chernobyl.

It's clearly within Munroe's capability to make such a graphic; he did this one on a deadline. I'm not criticizing Munroe (though: not an XKCD fan), just making an objective assessment of the graphic.

And, like I said: here's a case where a graphic, even an imperfect one, probably communicates rich information more effectively than prose. Unlike the "relative sizes of data" infographic upthread.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I really wish he (Ian Lurie) spend more time giving examples of great information (/data) graphics and what strategies to take when designing such graphics. To me, this comes off as a mere complain.

Lurie links to Mark (Mapstone?) who, also, complains about infographics. I'd like to take a shot at how they could make better infographics. Especially a graphic by Mashable Infographics about the 1.8 zettabytes of data produced every year.

The "1.8 zettabyte"-graphic from Mashable shows a lot of (meaningless) comparison, but absolutely no causality. Imagine if they instead talked about all the different sources of information, adding up to the enormous quantity of 1.8 zettabytes. Like the amount of video uploaded to YouTube everyday, the number of Tweets and there size in gigabytes per day, the increasing number of cameras being bought, growth on Wikipedia and probably many more.

</comment><comment><USER7> For actual depth and substance regarding information visualization, you should just read Tufte, since much of this article is obviously informed by it: <http://www.edwardtufte.com/tufte/books_vdqi>

<comment><USER8> +1 million. That book changed my life, at least as far as information presentation is concerned. It's that good. If you ever make a chart or a graph, you owe it to yourself and your viewers to read that book.

<comment><USER9> Was there a specific book you had in mind? There are 8 at the link.

<comment><USER10> Of those, _Visual Display of Quantitative Information_ and _Beautiful Evidence_ are my favorites.

<comment><USER11> Accompany those with the classic _How To Lie With Statistics_.

</comment></comment></comment></comment></comment><comment><USER12> As a designer I'd like to thank you for this post. This recent fad of "infographics" (some text in rectangles + pie chart) is quite sad. These things are information graphics about as much as fake lens flares were graphic design in the 90s.

Side note: are you serious about people paying for this?

<comment><USER13> Well said.

I contribute to a site that does a lot of interactive visualizations and works with artists that do more static infographics.

Because we display them time to time we get massive amounts of email from companies that paid to have an infographic made (usual on a subject not related to their biz) and slap ads on the bottom. I've never posted one and can't for the life of me figure out why any legit business (maybe that's my answer) would do that.

The data part seems to be the biggest thing people fail to understand. If you don't have compelling data or the graphic doesn't lend itself to understanding the data... then what's it for?

<comment><USER14> _can't for the life of me figure out why any legit business (maybe that's my answer) would do that_

I think they're hoping it'll "go viral". And they pronounce that _with_ the quotes.

<comment><USER13> I will say... I've had lots of success with some of the visualization projects I've worked on (TOOT TOOT!)... but none had ads and I had no service to sell... so that makes things a lot less complicated.

</comment></comment></comment></comment><comment><USER15> If you're going to use a flashy javascript popup mechanism to view image links, please make sure at the very least that people whose screens aren't as wide as the image can access the close button!

</comment><comment><USER16> Maybe instead of bashing infographics designers would benefit from figuring out why they are so popular? This "Cult of Tufte" stuff is kind of grating. Minard's map showing Napoleon's march into Moscow is a great example. It is an elegant chart that shows 6 key bits of information (# of troops, location, direction, temp, time, attrition), but it's a bore to look at.

It might be the greatest piece of info design ever, but it will draw less attention than a lame "infographic".

I think "Infographics" have huge potential, just like blog slide shows do. Both are universally reviled by "serious" thinkers, but are incredibly popular. I see them revealing a need for more condensed, actionable information, not a scourge. There is signal in that noise.

<comment><USER17> Flashy > Informative?

<comment><USER18> I'm not sure I'd have used the term "a bore," but I think the parent poster's point is that the Napoleon graphic doesn't immediately draw you in. If you study it for a while, it manages to accumulate a great deal of information in a remarkably integrated way but it takes study to appreciate what is being communicated. While that graphic is rightfully famous, it wouldn't IMO work especially well in, say, a conference presentation setting or even a newspaper.

<comment><USER17> Why does it need to draw you in?

If you don't need the information that it conveys, there's no reason for you to study it. If you do want the information, then you'll take the time necessary to understand it.

To me, if your graphical elements are running the show in a conference presentation setting or in a newspaper, you're already doing something wrong. Those aren't the right media for infographics (well, newspapers would sometimes find them useful).

Don't conflate media unnecessarily. If you need something flashy, make something flashy. If you need something informative, make something informative. Don't repudiate something meant to be flashy for being uninformative, nor something meant to be informative for being insufficiently flashy.

</comment></comment></comment></comment><comment><USER19> It's not even a crappy graphic. It's just eyecandy for social news sites and blogs to generate traffic and backlinks.

</comment><comment><USER20> My biggest beef with infographics is that they are almost always a static image. This is 2012. Why not make something interactive? It could help address several of the author's points as well.

<comment><USER21> Static images are easier to share.

<comment><USER22> Links are difficult to share?

<comment><USER23> Static images being easy to share does not mean links are difficult to share. It means static images are easier to share.

<comment><USER22> Are they? Save an image to a file, attach to an email. Cut and paste a link into an email or an IM. Or provide a link to a page with the image: same exact work as a link to a non-image. This is, at the very least, the same amount of work.

</comment></comment></comment></comment></comment><comment><USER24> Has the quality of links on HN declined the last months?

<comment><USER25> Yes. This is obviously link bait, SEO content.

<comment><USER26> I'm not sure that's fair, Ian Laurie has been a solid blogger for years and is often critical of current trends. He ventures into technical topics from time to time too.

He may not be your cup of tea but he's certainly not the cheap PR stunt kind of internet marketing guy (I'm not sure you're insinuating that, just wanted to let folks who are interested in web marketing topics that he's worth paying attention to IMO).

<comment><USER27> >is often critical of current trends

I'm seeing more and more of this kind of article on HN recently. Solid blogger or not, if I had a penny for every "$current_trend sucks" screed posted here and frontpaged, I'd be retiring by now.

Honestly, it gets old hearing people complain about everything under the sun after a while. (And I say this as someone who complains a hell of a lot on his own blog, but then again I've never been posted here..)

Did we really need a breathless blog article to tell us that some infographics suck? Stop the presses!

<comment><USER28> _I'm seeing more and more of this kind of article on HN recently. Solid blogger or not, if I had a penny for every "$current_trend sucks" screed posted here and frontpaged, I'd be retiring by now._

Isn't the quoted statement from your comment a "$current_trend sucks" statement? I guess you see the need to decry some current trends, just as all of us do from time to time.

<comment><USER27> Heh. Kind of funny that I didn't see that.

I guess what I was getting at is that seeing the same thing over and over again tends to get old.

</comment></comment></comment></comment></comment></comment><comment><USER29> The wide proliferation of really terrible ones seems to tie into some murky SEO tactic of getting a designer to whip you up something 'viral', stick it on the www.totallylegitadultdiplomaswithfreeviagra.com root, and then have a cute little 'share this' link that gives you the url along with a blob of html stuffed with invisible SEOjunk keywords, and rely on people's laziness and stupidity to get the backlinks flowing.

I recall reading a good article on it a while back, but oddly enough, "SEO infographics" is now a sufficiently desirable niche that there are junk infographics just waiting to take your call.

</comment><comment><USER30> I disagree. I now mentally associate the word "infographic" with "poorly- thought-out blog post that the author wrote in Photoshop in order to familiarize himself with all of its features." As for a graphic that conveys information, well, those don't exist anymore.

</comment><comment><USER31> I agree completely but unfortunately I doubt people will do them right until they stop attracting eyeballs. To the well informed, bad info graphics are a plague on the web. To my sister's teenage friends and my mother's circle of friends they're "oh cool, I don't have to read!". Self respecting graphic designers won't create these awful "info graphics" but anyone who's looking to attract some eyeballs in the hopes of getting an ad or two clicked or a new rss subscriber will keep polluting the web with them until we stop looking.

<comment><USER32>
        Self respecting graphic designers won't create these awful "info graphics"

Disagree! Kelli Anderson is a fantastic designer and makes all kinds of infographics (although I imagine they cost a lot more than $200): <http://www.kellianderson.com/projects/infographics.html>

<comment><USER33> Andersen is a great example, as is Feltron!

</comment></comment></comment><comment> jack-r-abbit Why does the URL say "10 reasons..." but the article title says "11 reasons..."? Honestly, that bothers me enough to not even read the rest.

<comment><USER34> People rename articles, but URLs are not supposed to change, and should never break.

<comment> jack-r-abbit So the article was published before it was done? Clearly it was 10 when it got published... then it was increased to 11. I just think that if a person is going to publish something like this and expect people to listen, they should show that a certain amount of thought was put into it before releasing it into the wild. But I guess mine is an unpopular view.

<comment><AUTHOR> It wasn't 10, honest. I just can't count. Which is why I use computers and stuff. They count gooder than me.

<comment> jack-r-abbit ya, they do count gooder... but they lack a sense of humor. ;)</comment></comment></comment></comment></comment>


[Ask HN]:Your recommendations on ecommerce/cart software - <AUTHOR>

Hey there,
So I have a side project that I'm going to be starting when I go away next week and it's going to need some cart software.
I've narrowed down 3 selections so far, xcart (free, PHP), bigcommerce (paid, $30-80/month) and shopify (paid, $30-80/month).
So my questions are as followed: Have you any experience in eCommerce, if so how did you find it overall, what cart software did you use and would you recommend it?
Out of the 3 listed above, would you recommend 1, none or another?
How easy was it to integrate a custom theme, blogging software & code additional plugins?
I think that's about it although I probably have another half a dozen questions, when they come to me I'll edit it this.  I've not yet met my minimum operating caffeine threshold, so coffee time.
Thanks. <comment><USER2> I'd be curious as to some of the opinions in this space as well.</comment>