Jury Finds Marvell Must Pay $1.17 Billion in Patent Case - <AUTHOR> http://allthingsd.com/20121226/jury-finds-marvell-must-pay-1-17-billion-in-patent-case/ <comment><USER2> I find it interesting that here, when a university is doing the patent-suing, HN errs on the defensive side:

"Accusing Carnegie Mellon of patent trolling is probably not the most effective way to advocate for patent reform."

"Universities have been among the biggest producers of patents for 50+ years now."

"The internet needs more details so we can make an uninformed opinion and collectively decide to be impotently pissed off at the university or not."

However, when a large commercial entity is suing (e.x. Apple v. Samsung [1]), HN bashes the patent system:

"these cases set a chilling precedent for the platform that looks likely to dominate the computing industry for at least the next decade."

"It will hurt innovation because every damn thing is going to have to go through a committee of lawyers before being approved, and it will hurt innovation because the idea that innovation always involves making something brand-new and from whole cloth is fucking retarded."

"Apple's successful use of the broken patent system sends exactly the wrong signal."

Are these entities (Apple and CMU) really all that different? Both spend a lot on R&D, and both want to protect their property. In a sense, there are better reasons to support Apple filing patent lawsuits (forgetting about the specifics of either suit) than CMU. CMU receives a large fraction of funding from taxpayer-funded sources, and produces no real products, just IP. By contrast, Apple receives very little taxpayer money, and uses the patent system to defend its real products.

[1] <http://news.ycombinator.com/item?id=4430101>

<comment><USER3> It's almost as though these are different commentators (only about 20 of HN's thousands of users have commented on this story so far), different entities (yes, Apple Inc. is very different from Carnegie-Mellon University) and completely different patents (one covers a user-facing software feature and the other appears to deal with circuit design).

</comment></comment><comment><USER4> An article with more details - [http://www.insidebayarea.com/business/ci_22263081/marvell- sl...](http://www.insidebayarea.com/business/ci_22263081/marvell- slammed-1-2-billion-patent-infringement-judgment)

</comment><comment><USER5> The internet needs more details so we can make an uninformed opinion and collectively decide to be impotently pissed off at the university or not.

<comment><USER6> Another patent troll hurting innovation.

<comment><USER7> If we're just ignoring the details of the article, we can just as easily characterize it as ripping off someone else's work and making lots of money on the resulting products.

<comment><USER6> I was being sarcastic.

</comment></comment></comment></comment><comment><USER8> News stories are blindly passing information free snippets around based on the article from Reuters.

There's a bunch of specific information about the case here, for the curious: [http://dockets.justia.com/docket/pennsylvania/pawdce/2:2009c...](http://dockets.justia.com/docket/pennsylvania/pawdce/2:2009cv00290/90950/)

-_- the uspo has terrible links, but here are the links to the patents themselves too, they're pretty specific.

[http://patft.uspto.gov/netacgi/nph- Parser?Sect2=PTO1&Sec...](http://patft.uspto.gov/netacgi/nph- Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search- bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/6201839)

[http://patft.uspto.gov/netacgi/nph- Parser?Sect1=PTO1&Sec...](http://patft.uspto.gov/netacgi/nph- Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=6,438,180.PN.&OS=PN/6,438,180&RS=PN/6,438,180)

</comment><comment><USER9> I don't know anything about the merits of this case, but there is something disquieting about a taxpayer financed non-profit entity, supposedly pursuing truth in a disinterested way, doing this. If CMU wants the freedom to pursue its self-interest, it should not be accorded any special taxpayer funding and be stripped of its non-profit status. You cannot have it both ways.

Next time a venture capitalist tries to talk me into taking venture capital because "our funds come from University endowments" - it is sacred money because you know it is sprinkled with the holy water of "education" - I know what I would say.

CMU should be at liberty to pursue its self-interest. Let's just not allow it to claim a sacred disinterested pursuit of knowledge.

Let me disclose my bias here. I have come to believe that the University system as it exists today is not true to its original mission. This case serves to reinforce my bias.

<comment><USER7> You're missing the fact that the university is not profiting here. This money doesn't go into shareholder pockets, it goes back into the university to support further research activities, reducing the need for government subsidy. This isn't a debate about whether universities should pursue their self- interest, but rather about how R&D costs for fundamental research are allocated among the government and industry.

The fact that universities are publicly subsidized does not mean that Marvell should get to use the technology they develop for free. My tax dollars pay for the NYC subway system, but I still have to pay a fare to take a ride.

Indeed, there is a very strong argument in favor of "charging fare" to companies that use publicly-funded technology. The university system is a huge subsidy to companies, particularly technology companies,* that benefit from the free R&D and free training of high-skill engineering workers. Requiring those companies to pay for access to that technology reduces the amount of government subsidy necessary to support the same level of R&D activity.

*) Next time a Microsoft or Google publicly complains about the "shortage of engineers" and how the U.S. needs to educate more people in STEM, realize that they are literally asking for an increase in the subsidization of their labor costs.

<comment><USER10> > This money doesn't go into shareholder pockets, it goes back into the > university to support further research activities, reducing the need for > government subsidy.

This is a reasonable intuitive expectation, but it's simply not the case in reality (former academic from an academic family here).

The vast majority of research, including graduate student stipends and professors' summer salaries, comes from sources outside the university's budget (this is complicated for the first few years of a professor's career during which they usually get "start up" funds from the departmental budget before they get their first external grant, but it is true over the long haul).

A professor can almost never go to the university and say "I'm doing great research. You just made $X million from patents, so give me money to continue my work." In fact, nearly the reverse is true; when the professor finds outside funding, the university takes a cut. So, if Professor X gets $100k from the NSF to study mole rats, the university will claim as much as $50k of that grant and put it into the university's general fund.

Now you might say, "Hey _dps that's fine first-order thinking, but if a university gets enough patent royalties they can reduce their demanded overhead percentage." In practice, overhead percentage at the best universities are set not by budgetary need but instead are set indirectly by the funding agencies themselves (e.g. the NSF has limits on overhead charges that institutions take very seriously in setting their internal schedules). The reason for this is that the academic employment market is _extremely_ illiquid because transferring your entire research program from one school to another is a huge hassle; thus professors have comparatively little negotiating power in setting the university's overhead policies.

Having said all that, it's not clear that there's an obviously better system. I recognize the need to cross-subsidize university activities that aren't easy to fund externally. But it's important to remember that universities, in practice, make profits just like corporations. It's just that the profits go back into the endowment, capital expenditures like new buildings (though rarely capital expenditures like new research equipment), or at some institutions, administrator bloat. These profits are almost never directly pushed into new research, or used to reduce grant overhead rates.

</comment></comment></comment><comment><USER11> CMU CS alum and Pittsburgh resident here. While $1.17 billion would more than double the university's endowment, it's hard to be excited about this. I don't understand how this settlement is remotely proportional to the damage Marvell could have done to CMU.

This case was also decided by a Pittsburgh jury, which doesn't seem right.

<comment><USER7> The patents in question covered technologies used in billions of chips over a number of years. I think it is quite conceivable that the rights to those technologies could have been worth $1.2 billion if Marvell had licensed them.

</comment></comment><comment><USER12> "[Marvell] argued in the case that it didn't infringe the patents, which Marvell alleged were obtained improperly by withholding information about prior inventions from the U.S. Patent and Trademark Office." [http://webcache.googleusercontent.com/search?q=cache%3Aonlin...](http://webcache.googleusercontent.com/search?q=cache%3Aonline.wsj.com%2Farticle%2FSB10001424127887323984704578203751185147598.html)

The way I read this, Marvell is claiming that CMU filed for the patent without having done a proper search for prior art? Can anyone dig up the relevant court docs? My legal-fu is not that strong.

<comment><USER3> Marvell was essentially trying to recite the incantation to get a patent invalidated. In order to get a patent thrown out, you need to show that it is not substantially different from prior art, so Marvell unsurprisingly argued that there was prior art which was substantially the same as the patented invention. Assuming they agreed that their products used the technology in the patent, AFAIK this is pretty much the only defense they could have made.

<comment><USER13> No. This is incorrect, assuming the newspaper quoted that part right.

When you file for a patent, you are required to file all sorts of info, and applicants have a duty to disclose prior art or background information that may be relevant to the patentability of the applicant's invention that they know about. Search for "invention disclosure statements" if you want to know more So, withholding information would be something like "knowingly failing to alert the PTO that you had a previous publication or patent app on the same technology that was abandoned and is now prior art", etc.

Again, i'm assuming the newspaper used the right terminology, which is of course, dangerous. Sadly, the federal circuit has set a pretty ridiculously high standard for what constitutes misconduct that would cause you to lose a patent.

You are, IMHO, much more likely to get disbarred by the PTO than you are to lose a patent.

<comment><USER3> Hrm, you might be right. My usual reporterese-to-actual-reality heuristic gave me "They said there was some prior art that wasn't noted at the time of the filing," and that is a commonplace situation — but your interpretation makes sense as well. My bad for autopiloting it.

</comment></comment></comment></comment><comment><USER14> Note to the value investors out there: Marvell is an undervalued company (even after taking into account this $1.2 billion penalty.) Their stock price declined by 10% today, making it even more attractive.

<comment><USER15> uncertain. it is widely recognized that they are getting killed in all their main business segments and revenues are declining precipitously. the major silver lining was that their cash position would their cash and income streams to aggressively buy back stock to keep the share price higher even as they downsized their business.

guess what, their cash hoard is more than halved today alone. that brings shareholder equity to 3.4 (taking a straightforward look at the balance sheet) and cuts cash on hand by over 50%. And it could get worse if the judge increases the fine. that means less for buybacks.

working our way down their balance sheet, we see that 2 bil of the equity is in goodwill. this is usually overpayment for acquisitions and other pretty illiquid assets that don't fetch much value (high level generalization) so lets take that out just to be safe.

you have a company with shareholder equity of 1.4 billion in a shrinking market with earnings of...lets assume 200-300 million figuring that they somewhat arrest their astonishing decline.

this is trading at 3.6 billion right now. its not the worst bet but it is more than somewhat dicey. the semiconductor industry is winner take all and extremely competitive. this means value investing isn't the best strategy. value investing requires that you can reliably predict future income streams.

i've been looking at MRVL as well. i'm just saying its not straightforward

<comment><USER14> Interesting. I would like to know your source for the fact they are "getting killed".

MRVL gets a significant fraction of its revenues from the HDD industry (disk controllers, HBA controllers, etc), and AFAIK they are maintaining their position of a leader, especially in the consumer SATA market.

</comment></comment></comment><comment><USER16> Iron Man is real?!

</comment><comment><AUTHOR> More and more, I think patent trolling is a great business for startups. No need for expensive sales, marketing teams at all. You only need devs and patent attorney.

<comment><USER17> Even universities can get on board now!

<comment><USER18> This is where a lot of R&D happens.

<comment><USER17> Then it's not patent trolling as they're actually designing things, not just sitting on their patents and waiting to pounce.

<comment><USER19> Development costs in EE are typically smaller than those in medicine. In software engineering development costs are minimal.

<comment><USER7> It depends entirely on the kind of software in question. The R&D cost for advanced vision processing technologies, advanecd radio technologies, robotics technologies, etc, are not at all minimal.</comment></comment></comment></comment></comment></comment>


The Ultimate List of Programming Books - <AUTHOR> https://startupcountryblog.wordpress.com/2016/10/19/the-ultimate-list-of-programming-books/ <comment><USER2> I am glad the author mentioned Code complete > This book is the encyclopedia of good programming practice, Code Complete focuses on individual craftsmanship -- all the things that add up to what we instinctively call "writing clean code." This is the kind of book that has 50 pages just talking about code layout and whitespace

</comment><comment><USER3> I have a different choice -- I really liked Joel's Best Software Writing I.

Maybe that's just me... but that collection opened my eyes to the "bigger picture" and inspired me to think of my programming as an art/craft.

</comment><comment><USER4> I'd suggest "Modern C++ Design" by Andrei Alexandrescu, a really astonishing book about the awesome tricks and patterns you can achieve with C++, preprocessor directives and templates.

</comment><comment><USER5> Programming from the ground up. It's free on the internet. This book taught me AT&T asm. It is very easy to read.

</comment><comment><USER6> I'm surprised no one's mentioned the Dragon Book by Aho et al. (or if it has been mentioned, I missed it).

</comment><comment><USER7> My career as a developer is just starting and i found this list very helpful. Thanks a lot !

</comment><comment><USER8> I'm amazed that no one has suggested The Story About Ping yet.

</comment><comment><USER9> You forget the mention of "The Inmates are Running the Asylum" by Alan Cooper - an eye opener for certain, any developer that has worked with me since I read that book has heard me mention the ideas it espouses.

</comment><comment><USER10> There really is a lot of interesting information in here that can get you thinking about problems in different ways. It's handy to have, just to pick up once in a while to learn something new.

</comment><comment><USER11> One of my personal favorites is Hacker's Delight, because it was as much fun to read as it was educational.

I hope the second edition will be released soon!</comment>


Tales - a block tolerant web scraper that runs on top of aws and rackspace - <AUTHOR> https://github.com/calufa/tales-core

<comment><USER2> >> Tales is design to scrape the web continuously, even when the domain being scraped blocks the scraper server ip; it goes around this problem by fail- overing to a new node (server).

And people wonder why the AWS machines get filtered.

<comment><AUTHOR> this is why jcoulds will be supported soon.

<comment><USER2> And people will wonder why the jclouds machines get filtered.

It's not the "where". It's the "what".

<comment><AUTHOR> I am just enabling. For me it's not the "what". Its the "who".</comment></comment></comment></comment>


RIP to the Perfectly-Sized iPhone - <AUTHOR> https://www.popularmechanics.com/technology/gadgets/a23105271/iphone-se-perfect-size-discontinued/ <comment><USER2> My LG Zone 4 cost me $115, it's the perfect size and speed and weight. I used to run an iphone5.

Long may it live!

<comment><USER3> I still have my iPhone 5, and the size is surely one of the reasons I keep it. That and I figure why bother upgrading before there's 5G phone service.</comment></comment>


Show HN: Brök – Find broken links in text documents - <AUTHOR> https://github.com/smallhadroncollider/brok#brök <comment><USER2> Interesting, when I saw the headline, I immediately thought it was something else that I want: I keep all of my notes as plain-text Markdown files, and I use Wiki-style links between them, like `[Another File](another-file.md)`. One of the pitfalls of this approach is that if you change a filename, then all the links referencing that file will then be broken. So I'd love a tool like this that can be used to clean up a directory full of these documents.

<comment><USER3> I used to do that, but I switched to wiki-style [[links]] instead. But I can go back and forth with a regex.

There's some really interesting discussion about interlinked notes here: [https://news.ycombinator.com/item?id=22767658](https://news.ycombinator.com/item?id=22767658)

<comment><USER2> Love to hear any more commentary about the pros and cons of this approach? I assume the main reasoning is that it's easier to make a link?

The nice thing about the `[File](file.md)` method is that it's markdown native, e.g., you can follow them in GitHub, if you have a way to render file URLs HTML, you're links will just work in the browser too, and many txt editors can follow them by default.

<comment><USER3> The only time I would use the `[File](file.md)` syntax is if I'm specifically making documentation that will be published for other people.

Also, Github uses Gollum, which actually supports wiki style links anyway.

If you are maintaining a knowledge base, it gets really tedious to do that, if 99% of your links are just going to have the same caption as your filename. So being able to make links as quickly as possible facilitates efficiency. Besides, there are alternative syntaxes for being able to specific a custom caption for a wiki-style link.

Another thing to consider, is that in most mediums that I use my knowledge bases in, they are not styling my links anyway. I can still of course follow them automatically, but they are just presenting them as [[Links]]. Most people prefer that.

My different wikis have gone through many different iterations, and most of these engines are fairly compatible-ish with each other. They are similar enough that any migration required could be done with a few lines of Perl on my set of md files.

<comment><USER2> Huh, ok I just tried this out and it doesn't work as well as I was hoping. It appears that that `[[A file]]` style works on GitHub Wikis but doesn't work in the repo browser itself (e.g., from the `README.md`)? That's a major limitation to me, because one of the big benefits of my approach is I get a free web version of every local Wiki that I have on GitHub.

I'm curious if you have another solution for actually publishing a `git` repo on the web using the `[[a file]]` link style?

<comment><USER3> Oh sorry, if you want it to work in your README.md, you have to specify the org-mode syntax. BTW it supporst org-mode syntax. Just have a README.org.

</comment></comment></comment></comment></comment></comment><comment><USER4> If you're not into Haskell, you might want to give my Python project a try:

[https://github.com/jwilk/urlycue](https://github.com/jwilk/urlycue)

<comment><USER5> Why would anyone care if `brok` is implemented in Haskell?

</comment></comment><comment><USER6> The name is a pun on "broke"? (I first thought it was Swedish for "brøk" (fraction/ratio), but it turns out Swedes don't say "brök" but "bråk", which just means "noise" in Norwegian&Danish. But that's way too convoluted a pun, even for Haskell).

<comment><USER7> Bråk means fight in Swedish in the noun sense!

<comment><USER8> Or "division" in a mathematical sense

<comment><USER7> Why would anyone downvote my comment? It's clearly relevant, entirely accurate, and charmingly polite.

<comment><USER8> I have no idea and I didn't so =\

</comment></comment></comment></comment></comment><comment><USER9> Amazing! I made a shitty version[0] of this last year. I guess great minds think alike, but greater minds execute better!

[0] [https://github.com/alexpapworth/detect-broken- links](https://github.com/alexpapworth/detect-broken-links)

</comment><comment><USER10> Really cool! This could be implemented in wikipedia to detect and fix broken links easier.

</comment><comment><USER11> This is cool although for practical purposes, I think most people who need such a tool will not be using Haskell. It is tempting me to add Haskell to my CI just because it looks so nice and easy to use.

<comment><USER12> interesting. is haskell that big? don't they have a docker image you can pull in?

i know python and node and other languages have small images you can get for the CI situation you describe.

<comment><USER13> I started installing haskell a lil while ago with macports but I got as far as

bash$ port rdeps ghc

The following ports are dependencies of ghc @8.8.3_0:

gnupg2 pkgconfig libiconv gperf gettext ncurses zlib xz bzip2 libassuan libgpg-error pth libksba libgcrypt readline gnutls autoconf automake libtool xattr unzip gtk-doc glib2 libxml2 icu libffi pcre libedit libxslt perl5.28 db48 gdbm docbook-xml xmlcatmgr docbook-xml-4.1.2 docbook-xml-4.2 docbook- xml-4.3 docbook-xml-4.4 docbook-xml-4.5 docbook-xml-5.0 docbook-xsl-nons itstool gawk py27-libxml2 python27 expat openssl sqlite3 python_select python2_select python38 python3_select py38-anytree py38-setuptools py38-six py38-pytest py38-setuptools_scm py38-py py38-packaging py38-attrs py38-hypothesis py38-sortedcontainers py38-zopeinterface py38-parsing py38-more-itertools py38-pluggy py38-wcwidth pytest_select py38-nose nosetests_select py38-lxml py38-pygments pygments_select py38-mock clang-9.0 cmake libcxx curl libidn2 libunistring perl5 texinfo help2man p5.28-locale- gettext libpsl curl-ca-bundle libarchive lzo2 lz4 zstd libuv libomp llvm-9.0 xar llvm_select clang_select ld64 ld64-latest libmacho-headers libtapi gmp libtasn1 p11-kit nettle libusb-compat libusb npth pinentry-mac openldap tcp_wrappers cyrus-sasl2 kerberos5 libcomerr coreutils alex stack happy HsColour python37 py37-sphinx py37-docutils py37-roman py37-setuptools py37-alabaster py37-babel py37-tz py37-pytest py37-setuptools_scm py37-py py37-packaging py37-attrs py37-hypothesis py37-sortedcontainers py37-six py37-zopeinterface py37-parsing py37-more-itertools py37-pluggy py37-importlib-metadata py37-zipp py37-toml py37-wcwidth py37-freezegun py37-dateutil py37-pytest-cov py37-coverage py37-mock py37-imagesize py37-jinja2 py37-markupsafe py37-pygments py37-requests py37-chardet py37-idna py37-urllib3 py37-certifi py37-snowballstemmer sphinx_select py37-sphinxcontrib-applehelp py37-sphinxcontrib-devhelp py37-sphinxcontrib- htmlhelp py37-sphinxcontrib-jsmath py37-sphinxcontrib-serializinghtml py37-sphinxcontrib-qthelp texlive texlive-basic texlive-common texlive-bin fontconfig freetype libpng ossp-uuid libzzip cairo libpixman xrender xorg- libX11 xorg-xtrans xorg-xorgproto xorg-util-macros xorg-libXdmcp xorg-libXau xorg-libxcb xorg-xcb-proto xorg-libpthread-stubs xorg-libXext xorg-xcb-util graphite2 fonttools py37-unicodedata2 py37-brotli harfbuzz harfbuzz-icu libpaper mpfr potrace xorg-libXp xpm xorg-libXt xorg-libsm xorg-libice xorg- libXaw groff ghostscript jbig2dec jpeg libidn tiff lcms2 psutils netpbm jasper jbigkit libnetpbm xorg-libXmu xorg-libXi xorg-libXfixes texlive-bin-extra latexmk texlive-latex detex latexdiff p5.28-algorithm-diff pdfjam texlive- latex-recommended pgf dvipng gd2 webp giflib t1lib dvisvgm asciidoc fop brotli woff2 texlive-context texlive-metapost texlive-xetex texlive-plain-generic texlive-fonts-recommended texlive-math-science texlive-fontutils lcdf- typetools ps2eps t1utils texlive-lang-czechslovak texlive-lang-english texlive-lang-european texlive-lang-french texlive-lang-german texlive-lang- italian texlive-lang-polish texlive-lang-portuguese texlive-lang-spanish texlive-luatex texlive-fonts-extra texlive-latex-extra texlive-pictures

And decided to give it a miss.

<comment><USER14> That seems to be a packaging issue with MacPorts. It looks like it's including _build_ dependencies, too. It's pulling TeX Live and the Sphinx Python bindings for formatting documentation. I'm not sure what Perl is for, or why it needs 3 different versions of Python.

The Debian package doesn't require any of those. The Homebrew package has no dependencies at all (and only "python" and "sphinx-doc" as build dependencies).

<comment><USER15> On Arch Pandoc "only" requires a few dozen or so Haskell packages. Installing it does kind of mess up pacman's output when updating etc, but that's a very minor annoyance for a pretty useful tool to me.</comment></comment></comment></comment></comment>


Writers Feel an Amazon-Hachette Spat - <AUTHOR> http://www.nytimes.com/2014/05/10/technology/writers-feel-an-amazon-hachette-spat.html

<comment><USER2> This isn't the first time this has happened. They whacked on Hachette a couple of years ago in the UK (delisting titles on amazon.co.uk) -- I'm told that what made Amazon back down was Charlaine Harris's Sookie Stackhouse series of all things. (The TV series was running, all the books were in the top 30 bestsellers, and it wound up costing Amazon a fortune.)

They've also done this to Macmillan and Penguin, to my knowledge.

It's worth noting that the Big Five publishers in the US have a combined turnover about a fifth of Amazon's, and individually none of them are even 10% of Amazon's size. Amazon's behavior towards its suppliers is basically bullying -- this isn't just in publishing -- and they're also tax dodgers (although I note the UK treasury has finally taken steps to close the VAT loophole they were exploiting to charge their suppliers 20% VAT while paying out only 3% to the Luxembourg government).

</comment><comment><USER3> This sounds reminiscent of similar accusations regarding books from Lightning Source being sold on Amazon being given long delivery estimates.

Lightning source is a print-on-demand publishing service from Ingram that competes with Amazon's CreateSpace PoD service.

[http://www.thebookdesigner.com/2011/09/amazon-and- lightning-...](http://www.thebookdesigner.com/2011/09/amazon-and-lightning- source-the-end-of-an-era/)

</comment><comment><USER4> really, Amazon placed a BANNER saying "go buy other books"... the editor needs to realize that changing up words and terminology can really make a huge difference on how people perceive a story...

</comment><comment><USER5> Amazon need to increase its profit. The best way without increasing price from the already steep discount compared listing price are have better discount from huge volume publisher. Publisher balk as their profit margin will be affected. Amazon increase price due to no better term. That is purely logical business decision.

However, the extending shipping time as a punishment part from amazon is not.

(Disclaimer: i work for publisher and a writer myself)

(Edit:typo)

</comment><comment><USER6> The TL:DR version

Among Amazon's tactics against Hachette, some of which it has been employing for months, are charging more for its books and suggesting that readers might enjoy instead a book from another author. If customers for some reason persist and buy a Hachette book anyway, Amazon is saying it will take weeks to deliver it.

The scorched-earth tactics arose out of failed contract negotiations. Amazon was seeking better terms, Hachette was balking, so Amazon began cutting it off. Writers from Malcolm Gladwell to J. D. Salinger are affected, although some Hachette authors were unscathed.

</comment><comment><USER7> Luckily the justice department protected competition in ebooks so this will take care of itself...

Oh.. wait.

</comment><comment><USER8> Reads like a hit piece. People involved in legacy media perceive that they lack the nimbleness and cleverness of the technology industry, and they (rightly) feel threatened.

<comment><USER9> I'm as pro-tech and pro-disruption as the next entrepreneur, but come on. Amazon is an 800lb gorilla, not a start-up struggling to find traction, and if the acusations in this piece are true (and what I can find suggests they are), then that's anti-consumer behaviour: Amazon own 1/3 the entire market for books. This affects us, the consumers, and hurts authors, all because Amazon pushed for better terms and Hachette didn't want to give them.

Regardless of the company, I dislike it when tactics like this are used. Comcast's net neutrality issues are another great example.

<comment><USER10> This seems to be a very positive interpretation for Hachette, which is incidentally exactly what the article seems to push for, while claiming Amazon is acting maliciously.

The interest of authors is very clear: sell as many books as possible. They are paid a meagre sum per book (a dollar, maybe?) so they really don't care about the price other than that it is as low as possible to stimulate sales, but they have no control over pricing regardless.

Hachette, meanwhile, needs to keep prices up since any reduction would come directly from their margin, given that they pay authors a very low and fixed sum.

Amazon of course, as any other distributor, wants to get better conditions from Hachette and naturally uses its customer base to put weight behind what they are asking for. When the deal failed, they presumably had to continue buying books under, to them, unacceptable conditions, so they did two things to consolidate their losses:

1) slash discounts from Hachette books 2) buy less Hachette books

I'm not including the recommendations for other books, because if you have used Amazon at all in the last 10 years, this is just how their website functions regardless if the product at hand is a book from Hachette or a sponge.

If you want to blame someone here, blame Hachette or the relationship between traditional publishers and authors. As I've pointed out above, the interests of the two parties are not well aligned at all. Maybe it is true that Amazon pushes for deals hard to swallow for publishers, but if they are paying authors a dollar on a $10 book sale, that is hard to believe. If their overhead is that large, capitalism demands they are put out of business, and this time it is just Amazon picking up the slack, when it could have been any distributor.

<comment><USER2> _They are paid a meagre sum per book (a dollar, maybe?) so they really don 't care about the price other than that it is as low as possible to stimulate sales_

Wrong.

We are paid a royalty which is a _percentage cut_ of the sale price. Often a percentage of the net receipts the publisher gets for the books. So amazon's tactics come _directly_ out of our pockets.

Hachette do not pay authors "a very low and fixed sum". We're in a profit- sharing arrangement with them. No profits for Hachette? No profits for the authors, either.

Please refrain from disseminating information on HN about a business you aren't actively involved in without first engaging in some fact-checking.

(Disclaimer: I am a full-time professional author and Hachette is one of my publishers in the UK.)</comment></comment></comment></comment>


Ask HN: If a domain looks like spaghetti, should the code look like spaghetti - <AUTHOR> http://250bpm.com/blog:36 This turned into a long discussion about whether or not it's possible to write clean code when the domain itself is not clean. I think it's analogous to a map that has to be so detailed it ends up being the same size as the terrain. <comment><AUTHOR> This seems to describe it well: "with biz apps one is generally modeling a manager's, owner's, or lawmaker's mind(s) rather than say the laws of physics or math" [http://c2.com/cgi/wiki?WhyIsPayrollHard](http://c2.com/cgi/wiki?WhyIsPayrollHard)</comment>


Ask HN: What are your thoughts on UnaOS/UnaPhone? - <AUTHOR> https://unaos.com/ <comment><USER2> I'd like to think that the 5.5" screen is a design mistake. Now that Apple, with the iPhone SE, has shrunk the phone to 4" we could hope that smaller phones are gonna trend soon.</comment>


The Enigma of Gloom: On George Scialabba's "How to Be Depressed" - <AUTHOR> https://lareviewofbooks.org/article/the-enigma-of-gloom-on-george-scialabbas-how-to-be-depressed/ <comment><USER3> I think the last paragraph is worth quoting in full:

> The book ends with Scialabba's own advice for depressives. In contrast to > the political and economic themes set forth in the earlier sections and the > clinical diagnoses of the documentia, this last chapter is personal, with > deeply compassionate advice both to the suffering and those who live with > and care for them. Friends, food, water, rest, exercise, caregivers, and > reading are ways to take control, and if all else seems lost, remember what > he calls a truth "close to a scientific certainty; depressions virtually > always end."

<comment><USER4> does anybody have a link to amazon product page for caregivers?

i seem to have run short on these

</comment></comment><comment><USER5> See also CGP Grey's _7 Ways to Maximize Misery_ :

[https://www.youtube.com/watch?v=LO1mTELoj6o](https://www.youtube.com/watch?v=LO1mTELoj6o)

</comment><comment><USER6> It is difficult, perhaps impossible, to describe the experience of severe clinical depression to anyone who has not had it. Gerald Russello's review of George Scialabba's book makes a valiant start.

For those who are not moved by this, and wonder to themselves why George didn't just take a pill, consider also reading another book, written in a different mood, mode, and format by Robert Whitaker, an American journalist and author, who writes primarily about medicine, science, and history.

Anatomy of an Epidemic: Magic Bullets, Psychiatric Drugs, and the Astonishing Rise of Mental Illness in America [https://www.goodreads.com/book/show/7799587-anatomy-of-an- ep...](https://www.goodreads.com/book/show/7799587-anatomy-of-an-epidemic)

During the past fifty years, when investigators looked at how psychiatric drugs affected long-term outcomes, what did they find?

<comment><USER7> > what did they find?

IDK, what did they find? Why not post some links?

Looking at your reference, here's the top liked review (in part)

"

I would have given this book four stars if not for the fact that I felt the Mr. Whitaker was overly antagonistic in his writing, and at times even dishonest in his presentation of "facts."

His citations are frequently careless, and he cherry-picks not only the studies he presents, but also the which ones he provides access to through his website. At one point I checked a cited quote to find that he found it in a blurb on a book jacket! Unprofessional. " (reviewer gives 2 stars out of 5)

"

As for my depression, I was prescribed pills and they worked. They weren't a cure but they were the first and very major step out of the blackness. I presume you're taking an anti-medication stance, well please be aware that they work for some people. Sure they have a cost but it's probably a lesser cost than killing yourself.

<comment><USER6> For a synopsis, see wikipedia:

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

"Whitaker begins by reviewing the discovery of antipsychotics, benzodiazepines and antidepressants. These were discovered as side effects during research for antihistamines (specifically promethazine), gram negative antibiotics (specifically mephenesin) and the anti-tuberculosis agents isoniazid and iproniazid respectively. The psychiatric mechanisms of action of these drugs were not known at the time..."

He goes on to show, by citing studies, that the drugs were not efficacious in treating depression - quite the opposite. The mechanisms cause disease and chronic dependencies. But the drugs earn billions for big pharma, who covered up the studies and spent millions on spin and obfuscation. The story is akin to the corporate tobacco experience.

<comment><USER7> They worked for me and they prescribe them because they work - or can. They aren't THE answer, they are AN answer - for some people. Please don't dismiss them.

> But the drugs earn billions for big pharma, who covered up the studies and > spent millions on spin and obfuscation

Having worked in the area, this is something I have no trouble believing. And believe me, the side effects of anti-depressents are something I am aware of acutely. They could be very tough indeed.

Edit: from your link (and thanks!): "Whitaker acknowledges that psychiatric medications do sometimes work but believes that they must be used in a "selective, cautious manner. [...] And honestly, they should be used on a short-term basis."[12]"

This is something that makes acute good sense to me.

Edit: let me draw a comparison with painkillers for the body (antidepressants might perhaps be likened to painkillers for the mind). Body painkillers are good, they're useful, but if you need them long-term, someone needs to start looking for some root cause. Some unfortunate souls will develop chronic persistent pain that will need them to take physical painkillers for a long period or even their whole lives, but these should be the rarity. Same with antidepressants.

<comment><USER6> > They worked for me and they prescribe them because they work - or can. They > aren't THE answer, they are AN answer - for some people.

I'm glad you got a constructive result! Thank you for clarifying, throwaway_pdp09. As with many medications, efficacy is specific to (in this case unknown) personal aspects of biology. If they knew how to test for who would be helped and who wouldn't be, the drug therapies could be targeted to exclude the patients who would be harmed.

> Some unfortunate souls will develop chronic persistent pain that will need > them to take physical painkillers for a long period or even their whole > lives, but these should be the rarity. Same with antidepressants.

The striking differences between those and the drug studies reported in Whitaker's book are (a) the percentage of subjects who obtain negative results; and (b) the rapidity and irreversibility with which these drugs induce dependency.

Whitaker details and examines the ruse peddled by drug companies - <USER2> depression and bi-polar are the result of "chemical imbalances" which are "restored" by the drugs. If only it were that simple! But there is no evidence to support that global advertising myth.

In fact, the drugs induce upregulation of neurotransmitter receptors within weeks, which is responsible for chronic dependency, confusion, and tragically in some people, psychosis upon withdrawl. For a better, more detailed and nuanced response, read the book (which quotes the studies).

<comment><USER7> Yeah, I'm glad they worked too...

> If they knew how to test for who would be helped and who wouldn't be...

I am pretty sure there is work in this area. More precisely targeted treatments can only be a win.

I don't dispute whitaker's findings (well especially since I haven't read his book! Nor will have time too sadly) but what trifle I've picked up indicates he's making sense.

> In fact, the drugs induce upregulation of neurotransmitter receptors within > weeks, which is responsible for chronic dependency, confusion, and > tragically in some people, psychosis upon withdrawl.

It's difficult to address this. All I can say is that I did not find most of these problems, and of psychosis I think I got that while taking the drug, not upon withdrawal. And note this: that psychosis was not a bad thing at all. One side effect I'd happily live with again, even at the cost of memory loss and whatnot. Just a data point.</comment></comment></comment></comment></comment></comment>


FckdEx - <AUTHOR> https://www.profgalloway.com/fckdex <comment><USER2> Interesting article in general, but it has one major flaw:

It incorrectly assumes that all FedEx delivery drivers are FedEx employees - and that is not true for FedEx Ground. A quick look at Glassdoor confirms this: [https://www.glassdoor.com/Reviews/FedEx-Ground-Home- Delivery...](https://www.glassdoor.com/Reviews/FedEx-Ground-Home-Delivery- Driver-Reviews-EI_IE16846.0,12_KO13,33.htm) (Edit: You might have to google search for this to get past the login wall)

FedEx contracts companies out to handle Ground deliveries, and pay/benefits/etc vary depending on the contracting company you work for. Not sure what the total makeup is between FedEx employees vs. contractors, but based on the glassdoor reviews, it seems fairly skewed to contractors.

</comment><comment><USER3> I wish this article had been presented in a less crass manner. The content is interesting but I regretted reading it.

<comment><USER4> I thought it was candid, may be blunt.

<comment><USER3> It was candid and blunt. Those are the good attributes. They are not sufficient overcome the bad.

Here's some examples of quotes from this article that would be flagged if they were posted on HN as comments. They're pointless and are visible as a trend across many of this author's posts. I can't send this to coworkers because they might have grounds for an HR complaint. I can't send this to peers because they'll wonder why I would consider this acceptable to share with others. (I don't.)

> _to charge a nominal fee for Teams and let Slack bleed out, instead of > putting a bullet in its head_

> _staging a mock homecoming queen ceremony so you can pour pig's blood on > your competitor_

> _these weapons have rendered CNBC Amazon's bitch_

<comment><USER2> >Here's some examples of quotes from this article that would be flagged if they were posted on HN as comments.

I see similar contents on HN quite frequently, some of them quite highly upvoted. I'm not sure I agree with the premise that these would result in comments being actioned on, assuming that the comment on the whole is substantive.

As for HR and peers, I suppose it depends very much on where you work and who you work with. Most places I've worked, this wouldn't be a concern. A few places, it would have been.</comment></comment></comment></comment>


A new upstream project to break up Docker into independent components - <AUTHOR> https://github.com/moby/moby/pull/32691 <comment><USER2> Hi all, Docker founder here. It appears that the explanation in the pull request is not very clear. Sorry about that. We didn't expect the PR to be the first thing people read: there is a new website at mobyproject.org. Unfortunately Github is struggling under the load, and I can't update the PR text to clarify.

Here is an updated version with some clarifications:

<<<

Docker is transitioning all of its open source collaborations to the Moby project going forward. During the transition, all open source activity should continue as usual.

IMPORTANT NOTE: if you are a Docker user, this does not change anything. Docker CE continues to exist as a downstream open-source product, with exactly the same interface, packages and release cycle. This change is about the upstream development of the components of Docker, and making that process more open and modular. Moby is not a replacement for Docker: it's a framework to help system engineers build platforms like Docker out of many components. We use Moby to build Docker, but you can use it to build specialized systems other than Docker.

You can learn more at [http://mobyproject.org](http://mobyproject.org)

We are proposing the following list of changes:

\- splitting up the engine into more open components \- removing the docker UI, SDK etc to keep them in the Docker org \- clarifying that the project is not limited to the engine, but to the assembly of all the individual components of the Docker platform \- open-source new tools & components which we currently use to assemble the Docker product, but could benefit the community \- defining an open, community-centric governance inspired by the Fedora project (a very successful example of balancing the needs of the community with the constraints of the primary corporate sponsor)

>>>

EDIT: I'm happy to answer any follow-up questions here, if it helps clarify.

<comment><USER3> Do you know that keeping your users in a constant state of confusion is not the way to convince them that you're building a stable and secure product?

Also, isn't it kind of ironic that you built your company on OSS and then invited a well known destroyer of OSS onto your main stage?

Plus, I want my DockerCon money back. What exactly did you announce besides multi-stage builds at the general sessions that is actually benefiting Docker users? I don't care about your plumbing and constant rebranding, other than finding it very discouraging, I want to know what you're actually doing with your product this year. I guess nothing.

<comment><USER4> > Also, isn't it kind of ironic that you built your company on OSS and then > invited a well known destroyer of OSS onto your main stage?

I think I missed this; who are you referring to? I scrolled through the list and didn't recognize anyone that I would consider a "destroyer of OSS" so I'm not sure if I missed something, if you're just exaggerating or a little bit of both.

<comment><USER3> I'm not going to name names, if it's not obvious go watch the last general session keynote.

Edit: See my response below

<comment><USER5> Well, guess I'll do the detective work. Here's a link to the Docker blog that has the two keynotes:

[https://blog.docker.com/2016/06/dockercon-general-session- vi...](https://blog.docker.com/2016/06/dockercon-general-session-video/)

Guest speakers for the last (second) general keynote were:

 _-Guest speaker #1: Docker and Microsoft demo by Mark Russinovich, CTO Microsoft Azure

-Guest speaker #2: Docker at ADP by Keith Fulton, CTO, ADP_

And just somehow I sense that the parent poster isn't objecting to the CTO of ADP. /s

(What makes the objection doubly silly is that Mark Russinovich isn't the usual corporate drone one might expect. He's the guy who did the Sysinternals tools and several editions of the "Windows Internals" reference on the architecture of the Windows OS.)

<comment><USER6> > (What makes the objection doubly silly is that Mark Russinovich isn't the > usual corporate drone one might expect. He's the guy who did the > Sysinternals tools and several editions of the "Windows Internals" reference > on the architecture of the Windows OS.)

From Sysinternals to the Azure CTO... what a weird transition. That guy has had an interesting career.

<comment><USER7> And most entertainingly those Sysinternals were open source originally and were immediately close sourced after he was hired during fierce negotiations by Microshaft and many angry at him for thumbing them publicly, especially for the NT SKU registry change debacle.

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

(Interestingly citation needed; people still circulate the code on BitTorrent of very old copies.)

Ironically a MSer told me he was famous for his infamous condition he be a Senior Engineer with an unorthodox, exceptional contractual or understood conditions: no painful managing other MS people. This only changed when made the CTO of Azure.

No idea if that's rumor's true. He's a personal hero and I'm yet to read his novel about cyber war (yes, you heard me).

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Excerpts from mobyproject.org give a much better explanation:

Moby is an open framework created by Docker to assemble specialized container systems without reinventing the wheel. It provides a "lego set" of dozens of standard components and a framework for assembling them into custom platforms.

Audience

Moby is recommended for anyone who wants to assemble a container-based system, this includes:

Hackers who want to customize or patch their Docker build

System engineers or integrators building a container system

Infrastructure providers looking to adapt existing container systems to their environment

Container enthusiasts who want to experiment with the latest container tech

Open-source developers looking to test their project in a variety of different systems

Anyone curious about Docker internals and how it's built

Moby is NOT recommended for:

Application developers looking for an easy way to run their applications in containers. We recommend Docker CE instead.

Enterprise IT and development teams looking for a ready-to-use, commercially supported container platform. We recommend Docker EE instead.

Anyone curious about containers and looking for an easy way to learn. We recommend the docker.com website instead.

<comment><USER9> Moby is the fedora like oss project and docker is the RHEL like commercial product. Purely a clever rebranding job. Timing is perfect - now that enterprise is adopting the technology, when you tell your boss you adopted moby he/she will say- but the CTO wants to be seen as being innovative for adopting this new technology and ita called docker not moby!

<comment><USER10> > but the CTO wants to be seen as being innovative for adopting this new > technology and ita called docker not moby!

I see this kind of cynicism / snark all the time on HN (especially when it comes to Docker) but is it really warranted? Surely it's the rare exception? I've never met senior people who couldn't understand the naming difference between the open source version of a thing and the enterprise-branded version. Or a CEO or President. They're not morons.

This seems like cheap shots for upvotes. Or am I wrong?

<comment><USER11> I don't think your wrong. Someone being that entitled and ignorant must be the rare exception in 2017. Maybe I'm in a bubble too.

The conversation usually goes like this with my folk:

I get it, Moby is the OSS version and can be easily stood up and you don't see the need for extra cost. I'm glad you're trying to reduce expenses, but I don't mind paying for 24x7 Enterprise Support and it gives me piece of mind and priority escalation support.

Basically, I don't mind paying extra for a get out of jail free card if a whole swarm is offline.... I can tell the CEO we have the vendor partner engaged with a critical ticket and she can have piece of mind too. So, let's quote out the Enterprise version of Docker and evaluate the TCO of both solutions.

<comment><USER12> By calling Moby the "OSS version" you are implying that Docker EE isn't open source. Honest question... is it true that Docker EE contains proprietary code, or did you mean to say "community version"?

<comment><USER11> I probably should have written that as Community Version. I'm very uninformed when it comes to all of this and the Docker, Inc. ecosystem. Sorry about that :)

</comment></comment></comment></comment></comment></comment><comment><USER13> @shykes - so im one of the lonely few that love Docker Swarmkit (not Swarm - cos, that would be too confusing right !). I have spent a lot of time in the Kubernetes ecosystem (including several SIG) and value the batteries-included setup that Docker Swarm brings.

More recently, I was part of a discussion where Kubernetes has decided to roll its own logging infrastructure, while leaving important parts like log rotation still undecided.... driving me even closer to the Docker ecosystem.

However, it seems that Swarmkit is a big casualty of the whole CE/EE (and now Moby) split. Docker EE ([https://www.docker.com/enterprise- edition](https://www.docker.com/enterprise-edition)) still does not mention Swarmkit anywhere. In fact, there is NO top-level page on Docker's own site that actually mentions Swarmkit [1] and even Docker "Swarm-mode" is part of some second level documentation and help pages.

It makes me really worried about how you are seeing Swarm-mode/Swarmkit as part of the long term future of Docker Inc. You guys really dont talk about it - not even on twitter.

I'm assuming this is your handle as well ([https://twitter.com/dockerswarm](https://twitter.com/dockerswarm)), which has not seen a tweet since Jan 2017. However, you guys do tweet a lot about "Docker Datacenter".

What's going on ?

[1] [https://www.google.co.in/webhp?sourceid=chrome- instant&ion=1...](https://www.google.co.in/webhp?sourceid=chrome- instant&ion=1&espv=2&ie=UTF-8#q=site:docker.com+swarmkit)

<comment><USER14> > More recently, I was part of a discussion where Kubernetes has decided to > roll its own logging infrastructure, while leaving important parts like log > rotation still undecided.... driving me even closer to the Docker ecosystem.

Can you please refer to this particular discussion and link to it here, I would like to make sure that this indeed is what happened.

<comment><USER15> I don;t think that is really what happened. :) As part of the runtime abstraction, kubernetes must necessarily decide how to handle stdout/stderr logs. Not having a decision for something at a given point in time is not exactly a bad thing.

<comment><USER14> Thanks, this seemed to be quite unusual decision to be made by the Kubernetes dev community, that's why I've asked.

<comment><USER16> Hi, I'm from sig-node. We just don't have enough time/people to cover all log management in 1.6, this is just a temp workaronud so we can ship CRI in time. Log mgmt, together with some other missing parts will be definitely picked up after CRI fully released.

<comment><USER17> I recommend that you learn from the world around you. This is a long since addressed problem. This is the way that the daemontools world has been addressing logging since the middle 1990s, and there is a lot of design and implementation experience to draw upon and learn from.

The ideas of decoupling logs from lifetimes of the the things being logged, desynchronized log-watcher services that ship logs to central off-machine log stores, logging chains, shims for things that talk to syslog over AF_LOCAL or UDP sockets, shims for things that talk to the systemd journal using its idiosyncratic logging protocol, compartmentalized logging services that are protected by the operating system from compromises to the logged services, and persistent log pipes that do not lose log data; have all been designed and implemented.

* [http://jdebp.eu./FGA/daemontools-family.html#Logging](http://jdebp.eu./FGA/daemontools-family.html#Logging)

* [http://jdebp.eu./FGA/do-not-use-logrotate.html](http://jdebp.eu./FGA/do-not-use-logrotate.html)

* [http://jdebp.eu./Softwares/nosh/guide/logging.html](http://jdebp.eu./Softwares/nosh/guide/logging.html)

* [http://skarnet.org/software/s6/s6-log.html#diesyslogdiedie](http://skarnet.org/software/s6/s6-log.html#diesyslogdiedie)

* [http://skarnet.org/software/s6/s6-log.html#loggingchain](http://skarnet.org/software/s6/s6-log.html#loggingchain)

* [http://tinydns.org/#ContributedLogging](http://tinydns.org/#ContributedLogging)

</comment></comment></comment></comment></comment></comment><comment><USER18> More information can be found there: [https://github.com/moby/moby/pull/32691](https://github.com/moby/moby/pull/32691)

> Docker is transitioning all of its open source collaborations to the Moby > project going forward.

Should I understand that the core team wants to keep the brand "Docker" but use it in a commercial way, while Moby will be the underlying open source code?

Is it Docker/Moby = RHEL/Fedora ? or Docker/Moby = Mongodb.com/Mongodb.org?

<comment><USER19> Also from that thread:

Moby = open source development

Docker CE = free product release based on Moby

Docker EE = commercial product release based on Docker CE.

Nothing is dead; and everything that was open-source remains open-source. In fact we are open-sourcing new things.

<comment><USER20> So essentially the difference between Chromium and Chrome?

<comment><USER21> No, that would not be accurate.

The difference between them is like

Redhat Enterprise Linux (Costs Money, Enterprise Supported)

vs

CentOS (Community managed, community supported, Libre Free)

<comment><USER22> CentOS comes from RHEL, while Docker comes from Moby. So the correct parallel is Fedora-RHEL or Wildfly-JBoss.

</comment></comment></comment></comment></comment><comment> pi-rat From comment by @stykes on the pull request:

      Moby = open source development
      Docker CE = free product release based on Moby
      Docker EE = commercial product release based on Docker CE.

      Nothing is dead; and everything that was open-source remains open-source. In fact we are open-sourcing new things.

<comment><USER23> The pre-emptive defensiveness of that comment says a lot...

<comment><USER24> Maybe. The defensiveness could likely be that in many rebrands things tend to get lost in the scuffle (e.g. documentation not fully up to date; difficult to find references to some subproject's new name; checkbox for feature still listed on the enterprise version's landing page; assumption that it was made closed-source). The devs just want to get ahead of that as much as possible.

<comment> grey-area There is absolutely no need for this rebrand, because they're not actually getting rid of the old brand, they're trying to reuse it for something different, which is insane. Hence the defensiveness. They know this will cause problems and complaints. They can't get ahead of the complaints without actually fixing them, by reversing the decision.

</comment></comment></comment></comment><comment><USER25> Why am I having the feeling that Docker Inc is being pissed about everyone making money off docker except Docker Inc. themselves ?

This is not nice.

<comment><USER26> Oh, because it's true. Their employees were fairly outspoken about it at Dockercon. I had one just dramatically and rudely turn and walk away from me mid-sentence when I mentioned I was using Kubernetes.

<comment><USER27> That's just silly. Kubernetes is an open source project too, and I don't think Google is making a ton of money from it.

<comment><USER28> Smaller vendors are making money from turnkey k8s. There are at least two I won't mention.

Docker is out on a limb with the dynamic mesh, nobody else is using the p2p gossip protocol that I know of and there are problems, and Docker paid-for support is just dropping tickets related to networking issues making this work. The service outages caused by mesh gossip problems are simply measureable by NewRelic free ping synthetic monitors. Docker is getting paid-- they are falling down on support.

<comment><USER29> Consul is all p2p gossip, and it seems to be pretty popular.

</comment></comment></comment></comment></comment><comment><USER30> Indeed, it seems that github.com/docker/docker now redirects to this. From a technological perspective it's irrelevant, but from a brand management perspective it's baffling. Did they perceive the Docker brand as tainted in some way?

<comment><USER31> The Docker brand is "tainted" in the eyes of their commercial competitors who don't want to use shared tools/libraries.

By creating an independent project commercial actors in the Enterprise space can share resources, components, and standards without having to explain why they`re better than Docker even though they`re built on top of Docker.

This is a great move towards industry and container infrastructure orchestration standardization. Common APIs will go a long way to widespread container adoption.

<comment><USER32> It's not the brand that is tainted. People simply cannot trust their projects on someone else's commercial objectives. There is no indication this is changing.

<comment><USER33> Yeah, good luck with finding a technology stack that doesn't rely on any products developed by companies...

</comment></comment></comment></comment><comment><USER34> This is the one of the worst kind of business decision one can make. But I am not theirCTO and CEO. While not the same as Vagrant being replaced (and then revived because the alternate project was a burden), feels the same shitty decision IMO. Plently of people run successful OSS under the same name. Disappointing.

<comment><USER31> I believe you might be reading the situation backwards...

Dockers underlying components are quite usable for many solutions in other projects and platforms. Now, instead of having "Docker TM" components in their stack, OSS projects can connect the tools without seeming to support a specific commercial provider.

Presently there is a lot of confusion and OSS projects are hesitant to use Docker components because of the perception of a closed eco-system. Now the project has clearer commercial branding and a more appealing package set for OSS consumers.

Remember: many of the most important actors we need to collaborate in this space are direct commercial competitors to Docker Inc.

</comment></comment><comment><USER35> I do not understand the amount of negative feedback on this. It seems logical to me to move the underlying open source components to a separate org from the proprietary stuff. Why the hate?

<comment><USER4> Honestly I think it makes sense as well but the way it was announced it was so incredibly confusing that I find myself agreeing with some of the negative and positive comments here depending on what my state of understanding was at the time.

</comment></comment><comment><USER36> What is it with tech companies and fucking terrible name/branding analogies?

Docker. Ok, works with containers I get... wait. Your logo is a WHALE with a bunch of shipping containers on it. You know that whales DISAPPEAR underwater for hours at a time, and shipping containers are NOT MEANT TO DO THAT?

Ok ok maybe it was an honest mistake hey whats this new thing moby.. wait. Whales. Moby. Moby dick? Your project is named after a mythical white whale that sank boats, the very thing that _actually_ carry CONTAINERS.

Having said all that, based on this [1] summary of Docker's usefulness in production from February, maybe both names are absolutely on-point for the reality of this abysmal 'product'.

1\. [https://thehftguy.com/2017/02/23/docker-in-production-an- upd...](https://thehftguy.com/2017/02/23/docker-in-production-an-update/)

<comment><USER37> A+ post.

Funny rambling backed up by a crazy well detailed article and you get downvoted by the HN hive mind. Docker is the ...ahem... whale in the room that you shouldn't criticize ever!

<comment><USER38> Author of the article here!

Just updated the titles to include moby.

Maybe I should change the links as well, then it can get reposted on HN and reach the first page along the announcement :D

<comment><USER39> Love your articles. Thanks for taking the time and effort to write it up and put it online.

</comment></comment></comment></comment><comment><USER40> Why change the name? All the books and posts reference the name Docker.

<comment><USER41> It looks like they want to rename the OSS version, to differentiate it from their commercial version. They're using the analogy of Fedora->RHEL.

Moby = open source development Docker CE = free product release based on Moby Docker EE = commercial product release based on Docker CE.

<comment><USER42> Why doesn't the open-source predecessor have precedence?

<comment><USER43> Because people are more likely to pay for the more recognized name.

</comment></comment></comment></comment><comment><USER44> Personally, I think this a great move for the community, but the reasoning and implications could have been made a little clearer.

The intention is to have a clearer split between the Open Source community project - which is and will always be the heart of Docker (or now Moby) and the "product" pieces. The Docker product itself is not changing at all from an external perspective - you will still call "docker run" as before. However, Docker will be an "assembly" of pieces from the moby project plus some under the docker namespace, probably including "docker/docker-cli". Going forward, this will allow the docker-cli to make more product-centric moves like further Hub integration that would be too controversial for the community moby project. It also allows other organisations to take the moby code and reassemble it in different ways without offending the Docker "product". Furthermore, the intention is that in the long run, various Moby pieces will move to community foundations such as the CNCF and OCI.

</comment><comment><USER45> If I read this correctly they split up the Docker repository into several components. The moby repo pulls these together and spits out a build (or many builds?). So for instance one might choose an alternative container runtime to containerd? Then there's an officially supported set of components from which they build Docker CE. But why is Docker now called moby? Doesn't make sense to me.

</comment><comment><USER46> Please rename to Moby Dock instead.

<comment><USER47> Docker Failwhale Edition

</comment></comment><comment><USER48> This certainly won't cause any confusion going forward.

<comment><USER31> If you`ve hit the wall in between multiple container infrastructure orchestration platforms I think the potential this provides is pretty big, and will have a lot to say for Enterprise adoption.

Separating out the shared commodity container stack points towards plug-and- play cross-vendor container stacks based on standardized APIs. Puppet, Chef, Ansible, Azure, AWS, VmWare, Kubernetes, etc etc: todays market is a divergent mess. Being able to mix-and-match configuration tools, clustering tools, and management interfaces will get us to best-of-breed solutions. It should enable plug-and-play components that today, amidst a dizzying array of incompatibility, generally force you onto wholesale stacks.

Props to Docker for investing in the shared eco-system and risking the brand confusion to push the industry towards the next step.

This doesn`t impact users of Docker or containerized app devs, people won`t be setting up a Moby stackexchange site any time soon. This is big news for the devs of container platforms though :)

</comment></comment><comment><USER49> Bad title. That's not what's happening. Moby is the name of the open source project.

</comment><comment><USER50> They should have just re-branded to qwikster.

</comment><comment><USER51> So devops conferences will no longer sound like "Docker docker Docker? Docker. Docker docker docker docker? Ahh, Docker docker Docker docker docker." Now they'll sound like "Moby moby moby...?"

This seems absurd from a branding point of view.

I personally find this a little bit vindicating. I'm 39, which is like 120 in programmer years. I feel like one of the advantages of being an "old" (in quotes!) programmer is that I'm pretty good at spotting a fad. Unfortunately whenever I point one out I get mocked and down voted to oblivion, so I've learned to just sit on the sidelines and watch the fads go past and just work to avoid them in my own projects.

Programming is very faddish, and I've seen fads come and go. Here's a few of the ones I've seen in my tenure:

\- "Design patterns" heavy "enterprise" programming, such as commonly seen in the older work in the Java and .NET ecosystem.

\- XML for everything.

\- Agile. Oh god, agile.

\- Test driven development.

\- Dynamic languages (as productivity magic pixie dust).

\- Service oriented architecture (SOA).

... I could go on.

Not everything in these fads is bad. Fads often contain good ideas and some fads contain non-fad elements that stick around. But they're fads insofar as they are over-hyped as magic cure-alls.

The key characteristic of a fad is this:

It's heavily hyped as a cure to some set of very hard problems in programming or system administration, but all it _really_ does is move the problem somewhere else or hack around it in some trivial gimmicky way. There is no real innovation. Meanwhile the fad often introduces new problems that nobody thinks about until the shine wears off.

My simple heuristic for recognizing a fad is to ask "where's the innovation?" A real innovation is a conceptual leap forward. It has a certain "meaty" feel to it and seems worthy of at least one solid CS paper. It often _reduces_ complexity, since when deployed you can now dispense with all the mountains of hacks you used to work around the problem prior to the innovation.

Here's some current things that I very strongly think are fads:

\- Microservices, which is just a reboot of SOA. The idea is not inherently bad and often results in more scalable systems, but the faddish part is the idea that replacing local API calls with RPC API calls or event queues is going to make some major class of programming problems go away. No, and you've also just introduced a new set of problems around network unreliability.

\- "Serverless" cloud, a.k.a. total lock-in to a proprietary mainframe. Everyone doing this is going to regret it in 5-10 years except Amazon's shareholders. It's a roach motel. Compute will get another order of magnitude cheaper and prices for everything else will drop accordingly, but these prices will not since you drank the kool-aid haha.

\- Containers.

... yes, containers.

Like most fads, containers are a response to a real set of problems. These are mainly:

\- System/VM configuration drift and variability.

\- Dependency and DLL hell.

\- The fact that Linux/Unix has devolved into a single-tenant operating system where it's hard to deploy more than one thing on one "server." (This debacle is deserving of a whole very long blog post.)

Containers are a fad because they don't address any of those problems with real innovation.

System configuration drift, dependencies, and DLL hell are are addressed by the gimmicky hack of basically tar'ing up whole Linux images and _treating them like gigantic statically linked binaries_.

If you're going to do that, why do you need Docker/moby/whatever? Just use a static Linux distribution like [http://sta.li](http://sta.li) and run every service in its own home or chroot. Keep your service trees in git and manage systems with Chef, Puppet, or f'ing shell scripts.

I fail to see why orchestration (a.k.a. provisioning) systems like Kubernetes could not work in such an environment without the container cruft.

Containers don't solve multi-tenancy much in practice. Their security profile is not good enough for true multi-tenancy, and if you try to run too many on one server you're going to run into stability problems that derive from all the bugs that exist in all that extra complexity they add.

Real solutions to these problems would... you know... really solve them. A real solution would make it possible to deploy stuff easily and forget about DLL and dependency hell. A real solution would restore true multi-tenancy to Unix, allowing _users_ (not root) to install and run services on commodity identically-configured Unix systems. A real solution would reduce complexity.

Edit:

I do wonder a little if the idea of throwing out dynamic linking, which both containers and some newer compilers like Go do, is not a bad idea. Maybe it's obsolete. Maybe the tiny memory savings of dynamic linking are no longer justified by the complexity overhead of dependency management.

<comment><USER52> Because it's cheaper to "snapshot" and roll back, than to pay somebody capable to fix the thing.

I'm 36, and have seen most of what your described and more.

<comment><USER51> Yes I get that, but you can do that with "git".

</comment></comment></comment><comment><USER53> previously: discussion of the announcement [https://news.ycombinator.com/item?id=14139691](https://news.ycombinator.com/item?id=14139691)

</comment><comment><USER54> Not to be rude or anything but the people in charge of such changes need to take a class in change management.

</comment><comment><USER55> Wow, so much documentation, blogs, keywords, adsesnse and stackoverflow to update! Better hurry!

</comment><comment><USER56> Can this piece of the puzzle really support a venture funded company? I get RedHat, that's a complete operating system. And Mongo, the database is a huge chunk of a system. But Docker seems definitionally a tiny sliver of the overall ball of wax.

<comment><USER57> I think that's the problem they are trying to solve. They want people to be buying their higher level stuff, container management, orchestration, etc. But all the attention is on the lower-level container runtime.

And, their competition at the higher level is starting to abstract away from their runtime. Like this: [https://github.com/kubernetes- incubator/cri-o](https://github.com/kubernetes-incubator/cri-o)

</comment></comment><comment><USER58> Is there any wiki page of moby project on the WikiPedia? This is not related: [https://en.wikipedia.org/wiki/Moby_Project](https://en.wikipedia.org/wiki/Moby_Project)

</comment><comment><USER59> Moby dock?

</comment><comment><USER60> So Docker is now called Moby or Moby is the OSS version of what i believe it will be the "enterprise" version of Docker. Like RedHat is to Fedora, Docker is to Moby right?

<comment><USER61> Think how RedHat is the name of a company and an operating system product (RHEL) assembled from the pieces in Fedora.

Docker is the name of a company and a container management product (Enterprise and Community Editions) assembled from the pieces in Moby.

</comment></comment><comment><USER62> What about all the SEO, Stack overflow questions, and the differentiation between the two(?) platforms?

<comment><USER38> The SEO is not a problem.

1) It's not conflicting with anything major (Unless it does, short 4 letters names are way too common).

2) It will transfer along the URL redirections

3) Docker has enough credit and following to gather SEO on any new domain and product name that comes out

The new pages will be top links on google very quickly. No worries about that, machines are fine!

The trouble is with humans, they can't keep up. All the existing content -documentation, community, articles- will stay under the Docker name, forever splitting the knowledge and bringing confusion onto mankind.

</comment></comment><comment><USER63> Seems to be done hastily - why?

</comment><comment><USER32> It's time for a foundation if they are serious about this.

</comment><comment><USER64> Bargey or Tanky may have been a better name.

</comment><comment><USER65> Are we getting ishmaeld now?

<comment><USER51> They could have ishmaeld to monitor mobyd and ahabd to kill mobyd if it misbehaves.

</comment></comment><comment><USER66> Searched "runc" on this page - 0 found :(

</comment><comment><USER67> This isn't April 1st, is it?

<comment><USER68> No, but it's 4:20.

</comment></comment><comment><USER69> What a horrible title.

Docker isn't being renamed to Moby, but rather all of the open source components are being spun out into a new umbrella OSS org called Moby.

No need to s/docker/moby anywhere.

This is going to end up being a case study in how not to make announcements, because the news is otherwise big/interesting.

<comment> grey-area This url is redirecting so that has changed (a rather important url):

[https://github.com/docker/docker](https://github.com/docker/docker)

This all seems so unnecessary. Why didn't they just keep docker docker and have docker-xxx for whatever other brands they want to introduce? Reminds me of CoreOS rebranding as Container Linux.

<comment><USER70> > Why didn't they just keep docker docker

They'd lose 40k+ GitHub stars, I guess.

</comment></comment></comment><comment><USER71> This is a bait and switch of whale proportions.

Docker used to be the open source part. Now that's being moved out of the way so when you search for Docker you get the paid offerings. The goal is to confuse the people who haven't been following this into thinking Docker is a thing you pay Docker (the company) for.

It's brilliant.

<comment><USER36> > The goal is to confuse the people who haven't been following this into > thinking Docker is a thing you pay Docker (the company) for

Following the first thing they google without actually understanding what's involved, all the way to handing over money sounds about what I expect from someone who thinks Docker is a viable platform to use for anything worth handing over money for.

<comment><USER71> That's not quite how it works.

\- Decision maker googles and finds there's this Docker company that will solve their problems. Heard good buzz about Docker in the news, how open it is, and how many companies use it.

\- Decision maker to engineer: "Hey can we use Docker software to solve problem X"

\- Engineer: "Sure, the software is actually called Moby now though"

\- Decision maker: "Meh, I don't care what it's called, I just want problem X solved. Docker solves it?"

\- Engineer: "Yeah I guess"

\- Decision maker: "Ok here's your budget. Pay Docker to solve problem X."

\- Engineer: "Alright"

<comment><USER36> Is that how VC companies "work" ? "Decision makers" make unilateral decisions about technology and "engineers" just say "yeah I guess" when asked about using new tech?

What fucking problem does Docker solve that a "decision maker" can understand it enough to get a result telling them to use Docker, yet s/he can't understand the concept of "open core" software.

Docker's status seems entirely driven by me-too cool kids cargo-culting the bejeezus out of it because they heard it can run their nodejs react app better.

If you work for a company where your described situation could happen, fucking leave.

<comment><USER72> A lot of devs seem completely fine with being pushovers and yes-men to the MBAs.

<comment><USER73> I'm between jobs at the moment at least partly becaue I pushed back.

</comment></comment></comment></comment></comment></comment><comment><USER74> Sharpen the Spears?

</comment><comment><USER75> Shoulda called it d suite.</comment>


$1600 for 295 sq foot apartment in SOMA - <AUTHOR> http://money.cnn.com/video/pf/2013/06/20/pf-uh-san-francisco-micro-apartment.cnnmoney/index.html

<comment><USER2> This is a joke. $1600 is ridiculous for this and that guys marketing speak makes me want to punch him in the face: "less stuff, more experience!"

That place is totally over priced.</comment>


Ask HN: PHP 7 for new projects – your experience and recommendations - <AUTHOR> If you are using PHP 7.x for your side-project or main product, what has been your experience?<p>- has speed of performance ever been an issue?<p>- how easy have your found it to deploy (and keep up-to-date) PHP apps on the server<p>Overall, do you recommend PHP 7.x for new web projects? Your thoughts appreciated. Thank you. <comment><USER2> I would highly recommend PHP for quick web development. We've been using it for all our sites and it's such a breeze to develop using it. We've never had any performance issues either (in my experience they are always more on the db end)

I'll highly recommend that you spend some time learning composer first. That is a must for any serious php development.

Then there are optional things you can learn like a framework like laravel, symfony, etc. My personal opinion is to stay away from it since I have found that a router is mostly all you need to get started quickly. Often times the headache to configure and debug the framework far exceeds the utility of it. So my own personal preference is to just use composer and a router and native PHP. Keeps things simple, easy to debug and super easy to deploy. But YMMV.

<comment><USER3> Are you advising that a beginer should implement their own auth solution ? That they will get csrf or xss handling right ?

<comment><USER4> Is interfacesketch actually a beginner? If he/she is a true beginner, that would change the entire question.

<comment><USER3> I don't know any senior web dev that need the advices you gave, nor ask question about PHP. Everybody with years of web xp has did something in php at least once or know what' s up with framework.

<comment><USER4> Two things:

1\. That wasn't me who gave the advice.

2\. There's a big difference between putting up a Wordpress install on PHP 5.6 and greenfielding a modern project on 7.x.

</comment></comment></comment></comment></comment><comment><USER5> I'm currently using it for creating specific components for two customer projects. With Java, JavaScript, TypeScript and Ruby (for scripts) being my usual go-to languages, I'm not a huge fan of PHP but I'd say PHP 7 fares quite well.

It's reasonably fast. Though not part of the core language, PHPUnit is really good, as is the PHP support in IntelliJ IDEA (or PhpStorm, JetBrains' dedicated PHP offering).

If PHP is your main language or if for some reason PHP is required by your environment (e.g. if the target platform for your software are run-of-the-mill virtual servers) then PHP 7 absolutely is a good choice for new projects.

</comment><comment><USER6> I still haven't found a language that lets me get a very basic website up and running faster than PHP.

I don't care too much for the syntax but if you just want to put up a simple page with server-side logic in as quick a time as possible then its as good as most.

<comment><USER7> Have you tried Node.js with Express and Handlebars (express and hbs packages)? It's dead easy and fast to develop.

</comment></comment><comment><USER8> PHP < 7.1 goes EOL by the end of the year. [http://php.net/supported- versions.php](http://php.net/supported-versions.php)

So it's not a choice it's a requirement

</comment><comment><USER9> I have a few decent-sized systems in different languages (PHP, Elixir, Go).

Six of one, half-dozen of the other if you ask me.

Almost any of the big ones will do, so stop sharpening your pencils, pick one, and get to work.

</comment><comment><USER10> Speed of PHP 7 is much improved, it's way faster than 5, and fast enough for any app (Facebook runs on a flavor of PHP)

I use the Laravel Framework on PHP 7, Laravel makes PHP nice to work with. Laravel is as enjoyable as Rails, sure you miss Ruby but Laravel keeps development fun. If you are doing a project in PHP use Laravel.

I use forge.laravel.com to spin up servers and do deployments. It saves a ton of time and is definitely worth it. You could use it for any PHP project not just Laravel. There is also envoyer for zero downtime deployments. You setup Forge to pull code from from your Github/Bitbucket.

Forge is really amazing you can register a new domain, create a new Laravel project, and have it live on the web in 10 minutes. You can also add Lets Encrypt SSL certs right from the forge dashboard. Same for setting up an existing project from scratch it's fast to create a new droplet for an existing project.

If you are using Laravel I would recommend updating your apps as new versions of Laravel are released. Each update is pretty painless but if you wait to update doing them all at one time to get to the latest version can take some time.

There are lots of great time saving Laravel packages out there most require you to keep Laravel close to the latest release so it's worth staying up to date for the packages. Plus each release of Laravel always has nice additions to the framework.

<comment><USER11> Do you use frontend frameworks like React or Vue with laravel/PHP?

I'm still debating what my 2nd backend language for webdevelopment should be _(besides NodeJS)_. Rails is highly opinionated, activeORM is amazing, has rails API mode, but it lacks native async support, and has a weird way of doing things. A lot of magic behind the scenes.

I only learned enough to know how powerful it is, and it's paradigm. I think everyone should learn it. Abstracting away rails to sinatra I've been told is painful, and I've never heard of anyone building websites with pure ruby

PHP seems appealing to me b/c it couples well with Vue, PUG (html templating). I have heard doing things other than the rails way is a nightmare, but I don't know how it is with laravel.

PHP also b/c of wordpress. I still find it superior to any alternatives (Jekyll, hugo, gatsby, etc) because of the rich plugin ecosystem, proven ground, and ability to own your comments (and not have middleware like disqus)

Rails doesn't really work with windows OS either, and I primarily use a windows machine too.

The other downside of PHP is that it's frowned upon due to developers dislike for legacy PHP codebases.

How well does PHP work as a REST API? Is Laravel highly opinionated or are there many ways of doing things inside the framework? Does PHP have native async support? I could probably look these up but I'm curious to know what your opinions are.

<comment><USER10> I created one Laravel app with React. I use vue now. Although I'm not completely sold on using Vue(or React) for the front end.

For most Apps I still build them as a traditional web app with just enough javascript/jQuery on the front end as needed.

Granted Vue is really nice, I'm sure I'll move over to using it more.

Laravel feels similar to the Rails way.

The developer of Vue works closely with the Laravel community so there is great compatibility there.

Checkout the Laracon talks Evan speaks at Laravel Conferences.

Laracasts.com is similar to Railscast.com and a great place to learn Laravel. There are some free classes to get you started.

WordPress, y I still maintain some WordPress sites, I don't enjoy it but it's the easiest way to setup a blog/content site. I have some Laravel apps that are setup to connect to the WordPress database, it works well it's easy to setup objects in Laravel to interact with Posts, Comments, Reviews, etc. This is mainly for dashboards, batch editing of comments for VAs, etc.

As far as windows, I switched to OSX when I was learning Rails. I was always having problems with Rails tutorials and would spend 10s of hours on windows workarounds.

Using windows for Laravel is a little easier. Like Rails most of the tutorials, developers use OSX. I would recommend using a mac for development. It's just easier more productive.

Even the entry point macbook air is more than capable for Laravel or Rails development.

If you need one you could probably pick up a last gen macbook air on sale (new ones just came out and are $1199) I've seen them as low as $649 but have been on sale for $799 pretty often.

Laravel works well as a rest API it is setup for api routes out of the box. There are lots of tutorials for using Laravel as the backend and interacting with vue through an api.

Native Async support included: [https://laracasts.com/series/learn-laravel- mix/episodes/9](https://laracasts.com/series/learn-laravel-mix/episodes/9)

<comment><USER11> I owned a 2015 macbook pro, but I am a long time windows user, and I have a decked out gaming desktop rig.

I'll have to play around with laravel / php / vue more to see what I like. NodeJS is great and all, but it's not opinionated with it's frameworks. Too many ways of doing things. I want to build shitty prototypes quickly with a slow moving but well established framework

I like rails because it has a singular mindset. I'll have to give laravel a try.

<comment><USER10> Gaming rig? PUBG?

<comment><USER11> Was playing alot of battle royales, but lately I've been playing destiny2 and soul calibur

</comment></comment></comment></comment></comment></comment><comment><USER12> I use PHP still, using Laravel. So far I enjoy it. Definitely a pleasure to use. My web apps are used by at most a hundred people throughout the month, so performance won't be an issue.

Deployment with Laravel is a breeze. I don't use any of their deployment utilities though like Forge.

I came back to PHP. Used it back in what feels like the Stone Age. Then went through Rails when it was the new hotness. Switched to mobile and desktop development. Was behind when I needed a web project done, and knew I could fall back to my PHP skills faster than Ruby. Tried out Laravel and have been pretty happy since.

</comment><comment><USER13> I wouldn't recommend PHP, but there is nothing wrong with it, especially not if you're good at it. Django is more productive, and react, graphql + Apollo and prisma is better in production, but really, if you're good at PHP then PHP is fine.

I wouldn't worry about it not being the fastest tech, the fact is that if it's more productive, then it's often more cost-efficient. Iron is so cheap, that if you need to spend 1-2 weeks extra on development, then you'll be able to pay for your servers for several hundreds of years until a faster tech becomes more cost-effective than something that deploys faster.

</comment><comment><USER14> PHP7 is really fast and performance won't be an issue. It's usually another bottleneck, like the database that kills your performance.

Laravel is highly recommended these days. For even more performance you should check out PhalconPHP ([https://phalconphp.com/en/](https://phalconphp.com/en/)). But still - I'd go with the Laravel ecosystem.

</comment><comment><USER15> php 7 is about 2x as faster as php 5. There's no reason you shouldn't be using php 7.2+

</comment><comment><USER16> 1) performance: it depends on your case. 2) deploying: easy as uploading something via FTP.

I suggest you to use a good IDE (Atom or PHPStorm) and maybe learn a good framework like Symfony, or it would become unmanteinable quickly.

</comment><comment><USER17> I'd recommend considering alternative options to PHP, in other projects I have found it hard to maintain over a longer period and things got messy very fast, even when using frameworks.

Also, in my opinion, it's not a very nice language at all.

<comment><USER18> Do you care to provide any actual arguments?

Don't get me wrong, your post just doesn't sound too helpful</comment></comment>


Steve Jobs Will Save Print Media - <AUTHOR> http://www.wired.com/epicenter/2009/11/inevitable-apple-tablet/ <comment><USER2> I'm not willing to bet the house against Steve Jobs but unfortunately, just like this article and just like today's world, no one has announced a plan or much less hinted at an idea of how to save the print media world. However, I think there is an important distinction here - one between the actual art of print dying (the physical paper) and the other of monetizing the digital aspect of it. The latter is so challenging because the online distribution model is so vastly inexpensive to produce that charging for it goes against everything free out there - which is the majority of the market.

Now, if a tool such as the tablet is such a cool way to read the paper in the morning - then maybe, just maybe, apple can work with publishers on some fee based solution. I think that this article leads us back to the underlying point that technology can and has saved some industries from dying and now, how can tech save print media from running out of ink.

<comment><USER3> The reason that no one has hinted at "an idea of how to save print media" is that there is _no_ cure for print media as we have had it in the recent past. Their business model has been in decline for several decades, and they're not interested in changing. If you graph subscription/readership, you'll notice that somewhere between 2015 and 2020 the last newspaper in America will close. The industry is dead. It is just a matter of time before the corpse finally stops twitching.

</comment></comment><comment><USER4> What's killing publishers is not a content monetizing problem, it's a basic business-model problem: publishers have been making too much money on print-ad sales and like everything else the internet has made advertising cheaper.

Publishers don't just need to perfect a micro-payment solution for content, they need to change the way they create that content to make their entire business cheaper to operate.

<comment><USER5> Unless you're going to pay journalists less or hire fewer of them, journalism isn't going to get any cheaper. It's a revenue problem, not an expenses one.

I want the best journalism possible, and I'm willing to pay for it not just so I can read it, but so others can be informed and our democracy will actually have a chance of working. Producing journalism as cheaply as possible won't result in the kind of democracy I want to live in. The sacrifices that have been made have already led in that direction.

<comment><USER3> > _pay journalists less or hire fewer of them_

That has been the practice of media companies for more than two decades. Mergers and aquisitions have reduced the number of print media owners to a tiny handful. The problem is more that those businesses are used to 20% profit margins, and with over-inflated prices paid during the acquisitions, there is far less incentive to pay market rates for journalists, or even to keep them employed.

While _you_ might be willing to pay for the best journalism, the people hiring the journalists sure aren't. Furthermore, the line between editorial content and actual reporting has become so blurry that the smart thing to do is presume that the entire newspaper is editorial.

<comment><USER5> _"While you might be willing to pay for the best journalism, the people hiring the journalists sure aren't."_

I agree. That's why I think the best option is for people like me to hire our own journalists by funding non-profit journalism. Then again, I'm biased.

<http://www.texastribune.org>

</comment></comment></comment></comment><comment><USER6> He'll save print by making it digital?</comment>


What Is Functional Programming – In Python - <AUTHOR> https://www.coriers.com/what-is-functional-programming-using-python/ <comment><USER2> > "lambda calculus", which has existed for even longer than functional > programming

The lambda calculus _is_ functional programming, regardless of whether it was intended to be run on a computer or not.

> This is also known as "currying", a term named after FP pioneer Haskell > Curry.

So Curry — a mathematician — is an FP pioneer, but the lambda calculus is not functional programming. I find this a strange stance to take haha.

> These functions can turn many-line loops into incredibly concise one-liners. > However, they are often harder for the average programmer to grapple with, > especially when compared to the almost-English flow of imperative Python.

I'm undecided whether these concepts are _actually_ more difficult to understand, or if they're more difficult for people who are used to imperative programming specifically because they're used to imperative programming. I'm interested to hear other people's perspectives on this.

> Personally, I can never remember the argument order [of these higher-order > functions]

A fault of Python, not the author, I think.

> However, I wouldn't recommend writing a lot of functional-first Python, > especially in a shared or long-lived codebase.

I don't think the author really motivates this thesis, but strangely that's because the rest of the article doesn't seem to be about this thesis (in my opinion).

Writing functionally is, as the author says earlier in the piece, more of a way of life than anything inherent to the language. So long as your language supports higher-order functions, you can write functional code.

The rest of the article's suggestions — opting for pure functions, limiting use of classes, etc — all fit in with a functional-first paradigm, I think, despite the author's claim that they "wouldn't recommend writing a lot of functional-first Python". You don't need to use map/reduce to be a functional programmer. You just need to be working with functions and their composition instead of data and its mutation, and you're mostly all set.</comment>


KCK Mayor and Googler Kevin Lo on KCUR now about Google Fiber project - <AUTHOR> http://www.kcur.org/uptodate.html#Thursday

<comment><AUTHOR> Steve Kraske just finished interviewing Kansas City, KS Mayor Joe Reardon, Googler Kevin Lo, KCK School Superintendent Dr. Cynthia Lane about the Google Fiber project in KCK.

Key points:

\- Kevin Lo sees jobs created in the next few years to be massive, more than Google could ever hire.

\- Mayor Reardon and Kevin Lo both agreed KCK represented a great opportunity in that many still lack access to technology and that KCK schools make tech a central part of school.

\- Stories about Mayor Reardon's son, and KCK students, being excited about gaming speeds improving. \- Dr. Lane talks about possibility of still having school activities even on snow days.

\- Great question about separating line between what Google will do and what local businesses can do. \- Kevin Lo points out that service will be symmetric -- 1gbps down and 1gbps down.

\- Question from host Steve Kraske about what happens in 15 years -- will fiber optic be old-school by then. Kevin reiterate that Google believes it to be future-proof.

\- Kevin Lo answered question about video and voice services. Google focused on providing fast Internet connections, others will provide other services.

</comment><comment><AUTHOR> Audio recording of the show is now available at <[http://archive.kcur.org/kcurViewDirect.asp?PlayListID=8168&#...</a>.</comment>