Left-pad as a service - <AUTHOR> http://left-pad.io/ <comment><USER2> This is really exciting!!! I was a bit disappointed that the right-pad will be out only in 2017. I am looking forward to that release because there is a high demand for it now.

What kind of load balancing is being used on the back-end? I called leftpad(str, ch, len) with the length I needed and noticed that is not very scalable because it is blocking.

A better approach I would recommend to those using it is to call the API in a for loop. In my tests, it had performance very close to those I see in C or assembly.

I was a bit turned off that the free version can only handle strings up to 1024 in length. I know you need to make some money, but it is big turn off for a lot of my projects.

Edit: I finally signed up for it but still noticed that I am only allowed to use 1024. I called your customer support line and they said I was calling the API from multiple IP addresses and for that I need an enterprise license. Please help me with this issue, it is very crucial at this point as my project is in a complete stop because of this.

<comment><USER3> Best practice for performance for large left-pad jobs is to call the service recursively using mapreduce. Remember that left-pad(str,pad,n) is equal to left-pad(left-pad(str,pad,n/2),left-pad("",pad,n/2),n). This should run in logarithmic time and is highly parallelizable.

If you don't like the "" magic string in there you could replace it with a call to left-pad(null, null,0).

<comment><USER4> oh god it's too real

<comment><USER5> Poe's law for programming culture extremists

</comment></comment></comment></comment><comment><USER6> As a very sarcastic person, I highly approve of this. This absolutely reflects my opinion of all this mess.

Thank you for making this site so that I don't have to write an opinion piece like everybody else seems to have to. Instead, if asked about the issue, I can just point them at this site.

Yes. This isn't constructive, but this mess had so many layers that I really can't point to a single thing and offer a simple fix as a solution.

As such I'm totally up for just having a laugh, especially when it really isn't being nasty against specific people but just laughing about the whole situation.

Thank you to whoever made this

<comment><USER7> I don't expect to come across irreverent comedy on Hacker News, so I think the site is great! Creator: [https://twitter.com/gabrielgironda](https://twitter.com/gabrielgironda)

</comment></comment><comment><USER8> I don't understand why this community has to have a weekly cycle of bashing different programming communities. Every week there's a new drama thread bashing Java devs, Go devs, Javascript devs etc. The thing that I come to this community for every week is to read about new developments in our industry, if you don't come here for that then what are you coming here for?

And wasn't it just a few months ago people were praising the innovation of Urbit for having a 'global functional namespace'? But because it's popular to hate on javascript devs for applying -- sorry, I forgot this was javascript bashing week -- for reinventing concepts from other areas in computer science and software engineering the HN community has to start hating on another programming community's work.

That said this is a pretty funny satirical page, apologies to the author for venting at the HN community.

<comment><USER9> its called self-regulation.

Each community has its own quirks and extremes as seen by everyone else. Without the bashing, they would become even more extreme. At least after this a lot of devs will think twice about making "micro-modules".

<comment><USER8> If that were true java would have started dying a few years ago, javascript frameworks wouldn't pop up every week, and most people would use shell scripts instead of build tools. This is exactly the kind of flame war stuff the guidelines seem to have tried to stop.

<comment><USER9> I think that self-regulation is a real effect... tho tempered by momentum (i.e. Java's OOP/abstractionism momentum is huge).

Saying the effect exists says nothing about the effectiveness of that effect.

<comment><USER8> I was referring to:

>Without the bashing, they would become even more extreme. At least after this a lot of devs will think twice about making "micro-modules".

I don't think this "self-regulation" (I called this bashing, the guidelines call this flaming) is going to make people think twice about making micro modules. If they are useful they will be used, I think this community is better than to just bash these communities and call it 'self regulation.'

</comment></comment></comment></comment></comment><comment><USER10> I went ahead and made an SDK [https://www.npmjs.com/package/left-pad-io-js- sdk](https://www.npmjs.com/package/left-pad-io-js-sdk)

<comment><USER11> The try in browser fails with an unexpected token syntax error. Do you accept PRs?

<comment><USER12> I submitted a pull req to fix them...and added some tests. Sarcastic programming is fun!

</comment></comment></comment><comment><USER13> As a Java developer, I am a bit jealous. When people joke about us we usually only get a link to the Spring documentation of AbstractSingletonProxyFactoryBean (or maybe the enterprise hello world), but no one ever wrote that as a service. Maybe someone can do that? [https://abstractsingletonproxyfactorybean.io](https://abstractsingletonproxyfactorybean.io) seems to be available!

<comment><USER14> Jesus Christ, is that a real thing!?

[http://docs.spring.io/autorepo/docs/spring/2.5.x/api/org/spr...](http://docs.spring.io/autorepo/docs/spring/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html)

<comment><USER15> > Convenient proxy factory bean superclass for proxy factory beans that create > only singletons.

that actually makes sense to somebody?

<comment><USER16> Not sure what about that is hard to understand, it's a convenient proxy factory bean superclass for proxy factory beans that create only singletons. Says it right there on the page.

<comment><USER17> Exactly, just like a monad is just a monoid in the category of endofunctors!

</comment></comment></comment></comment></comment><comment><USER18> I'm late to the left-pad discussion. I thought it was considered a bad practice to depend on an external repo as part of your build process. At my company we use Artefactory to host our maven libs. Even if one were removed maven central our builds would continue to work fine (in theory).

<comment><USER19> I'm always surprised at how common this is. You check out some repository, and it ends up having to fetch more stuff from all over creation. Whether it's just git submodules or some more sophisticated dependency manager, it seems like an obviously bad idea.

It's OK if they're pulling from other repositories you own, but requiring external repositories as part of the checkout process seems like an obvious point of failure. There's all sorts of possibilities for malicious activities, and just plain downtime will affect you too. Storage is cheap, so it seems like there ought to be no reason _not_ to pull in external dependencies and save them locally. Dependency managers should support and encourage this rather than defaulting to just referencing some random stuff off in space.

<comment><USER20> The reason is maintenance. Once you set up yet-another-repo-mirror (after your apt, rpm, nuget, pypi etc mirrors), someone needs to keep it up, back it up, secure it, refresh the packages, etc etc.

It's "cloud culture": rely on some else's maintenance effort and just work on your own problems. Like all things, it has drawbacks.

<comment><USER19> I don't buy it. You need a place to keep your own repository, and once you have that, keeping copies of other repositories is pretty much free. Keeping up, backing up, and securing N repositories is no more work than doing that for one repository. You can still outsource this, even. There's nothing wrong with using GitHub or Bitbucket or whatever for your repositories, just make sure that you're using _your_ repositories, not relying on other people's.

The only thing that potentially gets harder is refreshing the packages, and I'd argue that's actually a _good_ thing because that's really just saying that packages don't randomly change out from under you. In any case, your package manager should make it easy to refresh them when you want to, just say "go update that dependency to the latest available from the official source" and let it do its thing. If package managers don't offer this, they need to start.

<comment><USER20> You need a place _and a person who knows all this stuff_ (or likely more than one). That's expensive and hard, as knowledge of _all_ these setvices has to be correctly handed over across people and over time. That's _on top_ of org- specific processes that are likely more important and more byzantine, which means they have priority. So the day your awesome_pkg_server breaks, nobody remembers how and why it was set up, and the whole thing is scrapped. Back to square 1. This assuming you actually have one or two people with enough free time in the first place...

Whereas standard "fetch package" scripts are trivial, and each individual stack is known well enough by developers working on it every day that there is zero administration and little need for extensive knowledge transfer... At least until left-pad disappears from under your feet; but that's rare enough that the trade-off is worth it overall (or people cannot even imagine it ever happening).

I'm not saying this is how it should be, I'm just describing why a lot of people do what they do.

Maybe the solution is an overall simplification and harmonization of all these services, so that the responsible option and the lazy option won't differ so much. You could have something like a prebuilt "repo server" image that can be downloaded and configured quickly, and which will then auto-cache all requested packages across different services. Cache invalidation would still be tricky but could be triggered selectively from an admin panel. Maybe all this should be packed into CI servers by default...

</comment></comment></comment></comment></comment><comment><USER21> Hahaha - isn't it hysterical how everyone using npm for small reusable code pieces! Aren't they morons! How stupid of people to trust their package manager to be consistent and correct and return packages they were expecting.

How stupid of people to reuse small often used functions that only do one thing well.

How does everyone taking the piss intend to protect themselves from this in their OS package manager, or PPM or composer or pip?

It's not javascript devs fault that the standard library is so piss poor you need these short code snippets and I've definitely included small 5-10 line packages via npm or other package managers rather than roll my own because it's likely they have bug fixes I haven't considered. I can also use npm to share these snippets between the many projects I'm building.

* No I wasn't affected by this because I review the packages that I want to include, however the level of smugness here is absolutely ridiculous.

<comment><USER22> > How stupid of people to reuse small often used functions that only do one > thing well.

This is a straw man argument. The reason so many people are criticizing left- pad _et al_ is about the cost of adding a dependency.

> trust their package manager

That's exactly the problem: you're assuming that a package manager can be trusted. The network isn't reliable, packages can changed innocently or maliciously, and mistakes happen.

The "stupid" part is pretending these have zero risk, and the part that makes some people angry is when they also have to depend on this zero-risk assumption transitively through another library.

> It's not javascript devs fault that the standard library is so piss poor

Nobody is claiming it was. However, Javascript devs _are_ responsible when they add critical dependencies on external components. They are also responsible when they publish libraries that extend those critical dependencies to the people that use their library without a _very_ good reason.

<comment><USER23> > This is a straw man argument. The reason so many people are criticizing > left-pad et al is about the cost of adding a dependency.

The cost of a dependency for a good package manager is zero, and the cost of not having that dependency is non-zero. So the problem is with NPM, not with adding a dependency.

<comment><USER24> "Zero" isn't a cost of anything -- there's no free lunch.

NPM, like any package manager, pretty much blindly accepts user input. I, as a module maintainer, could happily change every single function in my modules to

        function whatever() {
            return "WHHEEEEEEE!!!";
        }

and check it in. Doing that will result in no fewer problems than just deleting the module entirely, and it's not NPM or any other similar package manager's responsibility to vet changes. Obviously _curated_ package managers like those used by most Linux distributions do carry some responsibility, but even then, there's not ZERO risk.

<comment><USER23> Except a _good_ package manager will let you specify exactly which version you wish to depend upon, so any changes you make upstream will have no effect on people who protect themselves against automatic version updates.

Seriously, the properties of good package management should be obvious by now. Any design that can break dependents _and there 's nothing they can do to protect themselves_ is broken.

<comment><USER25> And wait till you hear what a sufficiently smart compiler can do!

[http://c2.com/cgi/wiki?SufficientlySmartCompiler](http://c2.com/cgi/wiki?SufficientlySmartCompiler)

<comment><USER26> But there already exist package managers that let you pin to a specific version like he's saying they should e.g. Maven, so I don't think your link quite applies here.

<comment><USER25> Npm allows that too -- you just specify an explicit version number, e.g. "1.5.3" instead of "*" or "^1.5.3" etc.

My comment was against this belief that "smarter" tools in general are some sort of panacea.

For example pining to a specific version won't help you match if the package is removed altogether (as in this case), and ever worse if it's replaced afterwards by another (newly registered) with an incompatible same version out. It won't try to overwrite your specific install of course (since the version already matches what you have), but you'll feel the pain when you try to duplicate/deploy etc a new install with the same package listing -- suddenly the package either won't be there (or will be modified in the worst case scenario).

So, then we opt for ever more features of a "sufficiently smart package manager", e.g. signatures, permanence of anything published etc...

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> Nice, it is even bug compatible

[http://api.left-pad.io/?str=foo&len=7&ch=12](http://api.left- pad.io/?str=foo&len=7&ch=12)

return {"str":"12121212foo"} and not {"str":"1212foo"}

<comment><USER28> Probably because they use the package itself?

</comment></comment><comment><USER29> Reminds me of Fizzbuzz enterprise edition: [https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)

<comment><USER30> fizzbuzz npm edition:

        var zero = require("number-zero");
        var hundred = require("number-one-hundred");
        var isDivisibleBy5 = require("is-divisible-by-5");
        var isDivisibleBy3 = require("is-divisible-by-3");
        var isDivisibleBy5and3 = require("is-divisible-by-5-and-3");
        var numberToString = require("number-that-is-between-one-and-hundred-to-string");
        var fizzbuzz = require("string-fizz-buzz");
        var fizz = require("string-fizz");
        var buzz = require("string-buzz");
        var incrementByOne = require("increment-by-one");
        var forLoop = require("for-loop");
        var ifCondition = require("if-condition");
        var elseIfCondition = require("else-if-condition");
        var elseCondition = require("else-condition");
        var lessThan = require("less-than");
        var print = require("print-string");

        forLoop(zero, lessThan(hundred), incrementByOne, function(i) {
            condition(isDivisibleBy5and3, print(fizzbuzz),
                elseIfCondition(isDivisibleBy3, print(fizz),
                    elseIfCondition(isDivisibleBy5, print(buzz),
                        elseCondition(print(numberToString(i))))));
        });

<comment><USER31> This must be what heaven feels like!

</comment></comment></comment><comment><USER32> It's 2016! Left-padding without any deep learning algorithm is so lame.

</comment><comment><USER33> HELP!! The CEO heard about this new service and now my manager told me we need to upgrade all our packages to this new service ASAP! But there's nothing on stack overflow I can use to change our system! I need to get this pilot done STAT so we can plan the migration and send it out for bid!

HELP!!

</comment><comment><USER34> Tomorrow: left-pad.io announces $120 million investment at $1.2 billion valuation

Month from now: left-pad announces purchase of $170 million office building in SV to house their 1200 employees

<comment><USER35> Eighteen months from now: left-pad announces massive reduction in workforce. 1150 laid off.

</comment></comment><comment><USER36> Doesn't work with unicode characters:

# ~ [8:47:18] $ curl '[https://api.left- pad.io/?str=點看&len=5&ch=0'](https://api.left-pad.io/?str=點看&len=5&ch=0') {"str":"←ᄏ゙￧ワヒ"}%

<comment><USER37> What do you mean? It returned a string just fine.

</comment></comment><comment><USER38> >`left-pad.io` is 100% REST-compliant as defined by some guy on Hacker News with maximal opinions and minimal evidence.

Wonderful

</comment><comment><USER39> I'm desperately looking for some feedback from big users.

\- Does it scale well?

\- Is it pragmatic for long term use scenario?

\- Is it Thread safe?

\- Does it learn from previous call made to the API?

\- Does it have a modern access layer?

\- Does it enforce 2nd factor authentication?

\- Is it compatible with Docker containers?

\- What about multi-region scenarios?

\- Any benchmark available showing usage with AWS + cloudflare + Docker + a raspberry pi as LDAP server?

<comment><USER40> There are rumors twitter is talking to those guys about 140 len version, they are likely to be acquired. We need to wait to see. Tomorrow we should know.

</comment></comment><comment><USER41> I'm very disappointed in the creators' choice of font for their landing page. Practically unreadable, my eyes burned.

<comment><USER42> and the scrolling behavior. my goodness.

</comment></comment><comment><USER43> What about splitting left and pad in two microservices?

<comment><USER9> 3 maybe.... iteration-as-a-service also??

<comment><USER44> 2 micro-services should suffice for all computation:

        $ curl 'https://api.S.io/?x=x&y=y&z=z'
        {"S":"x z (y z)"}

        $ curl 'https://api.K.io/?x=x&y=y'
        {"K":"x"}

<comment><USER9> ...now theres an idea for a new language.... slightly verbose tho....

<comment><USER45> [http://www.madore.org/~david/programs/unlambda/](http://www.madore.org/~david/programs/unlambda/)

</comment></comment></comment></comment></comment><comment><USER46> While very useful SaaS, I always use the tweet package manager from [http://require-from-twitter.github.io/](http://require-from- twitter.github.io/)

</comment><comment><USER47> As a friend said on IRC, it's kind of sad that the website is not made with bootstrap.

</comment><comment><USER48> Can someone explain to me why I might need this? I checked the site and the documentation is horrible. The site isn't professionally done and there are no videos.

Can I rely on this service going to be around in 5 years? It just seems like this company might be, you know, a feature rather than a company.

</comment><comment><USER49> I am waiting for "integer addition as a service" (vide [http://jacek.migdal.pl/2015/10/25/integer- addition.html](http://jacek.migdal.pl/2015/10/25/integer-addition.html)).

<comment><USER50> I'm working on it now. All plans will be free except if you want to use negative numbers. AWS will charge me more for 1 + (-1) as opposed to a 1 + 1 operation.

</comment></comment><comment><USER51> A programmer is someone who writes code, not someone who installs packages. Do you really need someone else to pad strings for you? Come on.

</comment><comment><USER52> My gut feeling tells me serious software engineers who look down on javascript programmers are feeling justified now. Brogrammers are exposed, hence the lot of knee jerk. Indeed, it is pretty funny, but dependency management still remains a hard problem.

</comment><comment><USER53> Very nice! Any plans for integration with [http://shoutcloud.io/](http://shoutcloud.io/) ? I would love to have my strings both left padded AND capitalized, but the APIs are incompatible. :(

</comment><comment><USER54> I don't think this is enterprise ready. And I am not sure that they are able to scale their service. Left padding is serious business.

</comment><comment><USER9> Presumably this is using a docker instance on AWS or the like? </sarcasm>

BTW: Well done... nothing like rubbing it in. :o)

<comment><USER55> I suspect API Gateway + Lambda.

</comment></comment><comment><USER56> I need a SOAP binding for this, because reasons.

<comment><USER57> Funny way to spell CORBA.

</comment></comment><comment><USER58> Needs more Enterprise. Where are the factory factory builders?

<comment><USER59> If it doesn't have a CORBA _and_ EJB interface, it's not enterprise.

</comment></comment><comment><USER60> Where do I sign up for alpha- or beta-testing for right-pad.io?

<comment><USER61> I think they're announcing an MVP soon.

<comment><USER62> They are raising $10M Series A lead by Sequoia

</comment></comment></comment><comment><USER63> Cool, but it would be more useful if they had a npm module for accessing the service.

<comment><USER64> [https://www.npmjs.com/package/left-pad- io](https://www.npmjs.com/package/left-pad-io)

</comment></comment><comment><USER65> BUG! (I think) using '#' as a 'ch' value pads the string with spaces:

$ curl '[https://api.left-pad.io/?str=wat&len=10&ch=#'](https://api.left- pad.io/?str=wat&len=10&ch=#')

{"str":" wat"}

Please provide github link to fork/submit pr :)

<comment><USER66> Pretty sure you have to urlencode hashes, don't you? What happens if you do ch=%23?

<comment><USER65> good point :) API needs to add a POST support with explicit description of rationale being the need to url encode characters when using a GET.

Also needs HATEOAS.

</comment></comment></comment><comment><USER67> I get an error

      {"message": "Could not parse request body into json: Unexpected character (\'o\' (code 111)): was expecting comma to separate OBJECT entries\n at [Source: [B@6859f1ef; line: 2, column: 22]"}

when using double quotes. It seems some JSON parsing fails. Not sure if this can be exploited, so I wanted to let you know.

Demo link: [https://api.left-pad.io/?str=%22;](https://api.left- pad.io/?str=%22;)

<comment> adam-ff I get an error changing the example request from 68 to 67 characters:

[https://api.left- pad.io/?str=paddin%27%20oswalt&len=67&ch=@](https://api.left- pad.io/?str=paddin%27%20oswalt&len=67&ch=@) {"message": "Could not parse request body into json: Unrecognized character escape \'\'\' (code 39)\n at [Source: [B@38ac0021; line: 2, column: 21]"}

</comment></comment><comment><USER68> I'm looking for a Left-pad specialized linux distro. Anyone ?

</comment><comment><USER69> This is great, but I'll need an API wrapper package.

<comment><USER70> [https://www.npmjs.com/package/left-pad-service- api](https://www.npmjs.com/package/left-pad-service-api)

</comment></comment><comment><USER71> this is fantastic! What is your stack? Are you NoSQL or relational? Redis? What is your test coverage? I am sure you hiring only trendy developers. I see huge potential in your service, do you accept private investments? I would like to get in now, before Google or YC snatches you! again, keep up good work and - can't wait for right-pad next year!

</comment><comment><USER72> But the question is, is it enterprise-ready? :-)

</comment><comment><USER73> Do you have any client libraries available for different languages?

I don't want to create a direct dependency between my code and your API. I'd rather create a dependency between my code and your client library's code, as I'm _sure_ you will always keep that up to date with any API changes.

</comment><comment><USER74> That would be fun if a company named Left Pad asked to get this domain like Kik did at the beginning of all this.

</comment><comment><USER75> The real discussion is not about package managers, micromodules, or whatever.

It's about "real programmers can write left_pad by themselves" and everybody else just sucks. True scotsmen etc.

Now I don't know why asm people arent feeling threatened and aren't attacking the C left_pad gurus yet...

</comment><comment><USER76> Are you hiring?

</comment><comment><USER77> SECURITY NIGHTMARE!!!!!!!!!

Without any sort of nonce, this service is trivially susceptible to a replay attack

</comment><comment><USER78> This ain't got nothing on Fuck Off as a Service: [https://www.foaas.com/](https://www.foaas.com/)

</comment><comment><USER79> Boy, that escalated quickly.

</comment><comment><USER80> They didn't even think to version their API. This is total crap.

</comment><comment><USER81> If left-pad.io goes down, will it take the rest of the WWW infrastructure with it? I'm missing a Q&A for important and apparently relevant questions like these.

</comment><comment><USER82> Have we, or have we not, officially entered the silly season?

</comment><comment><USER83> I wonder whether the author uses leftpad on this site

</comment><comment><USER84> 100 times on the board [http://bit.ly/1RzOIK2](http://bit.ly/1RzOIK2)

</comment><comment><USER85> This is awesome. Props to you all.

</comment><comment><USER86> for the graphic designers out there who need left-pad, blue-steel-pad is now available.

</comment><comment><USER87> Will there be a premium plan?

</comment><comment><USER88> Wow, so funny. DAE lol javascript?

Ugh, how does this garbage even get upvoted so highly.

</comment><comment><USER89> Is it rate limited?

<comment><USER44> Maybe each request should be accompanied by a proof-of-work, proving that the requester invested at least 10s of computation...

</comment></comment><comment><USER90> this is hilarious and timely

</comment><comment><USER91> I'm ready to get downvoted to hell with this comment but here we go..:

I feel like only non-javascript devs are bashing against small modules and NPM. All great javascript devs I know LOVE that mentality.

Let me offer some reasons why I (as a current Javascript dev having professionally coded in C/C++/Java/Python/PHP/Scheme) think this is great:

\- Unlike most other languages, javascript doesn't come with a battery standard library. So you're often left on your own to reinvent the wheel. I mean, common, in Python you do "'hello'.ljust(10)" but AFAIK there isn't such thing in javascript. Javascript is more like the wild west where you need to reinvent everything. So having well tested libraries that does one thing extremely well is really beneficial.

\- Javascript, unlike most other languages, has some pretty insane gotchas. I.e. "'0' == 0" is true in javascript. Most devs have been burned so bad in so many ways in Javascript that it's comforting to use a battle-tested library, even for a small feature, rather than reinventing it.

\- And anyway, where should we put that function? Most big projects I've worked on have some kind of "helper file" that has 1500 lines, and then at some point different projects start depending on it so noone likes to touch it, etc. So, yeah, creating a new module takes a bit more time, but remember that it's not about the writing time but more about the maintenance time. I'd much rather have lots of small modules with clear dependencies than a big "let's put everything in there" file.

\- I feel arguing about whether something should be in a separate module is similar to arguing without something should be in a separate function. For me, it's like hearing "Hey, learn how to code, you don't need function, just write it when you need it." And hey, I've worked in projects professionally where they had no function and it was TERRIBLE. I was trying to refactor some code while adding function, and people would copy my function inside their 1500 lines file. Let me tell you I left that company really fast.

\- It's fair to say that UNIX passed the test of time and that the idea of having lots of small programs is extremely beneficial. It forces common interface and great documentation. Similar to how writing test force you to create better design, modularizing your code forces you to think about the bigger picture.

\- As far as I'm concerned, I really don't care whether a module is very small or very big, as long as what it does is well defined and tested. For instance, how would you test if a variable is a function? I don't know about you but my first thought wasn't:

       function isFunction(functionToCheck) {
         var getType = {};
         return functionToCheck && getType.toString.call(functionToCheck) === '[object Function]';
       }

Who cares if it's a 4 lines module. I don't want to deal with that javascript bullshit. Yes, I could copy past that in my big helper file, but I'd much rather used one that the javascript community use and test.

\- Finally, it seems like Node/javascript hasn't started that way. Not so far ago with had Yahoo monolithic javascript libraries and jquery. Even the first versions of most popular node library (such as express) were first written as a monolithic framework. But it's been refactored into dozen of small modules with clear functions. And now, other libraries can just import what they need rather than the whole project.

OK, so I told you about the good thing. What about the bad thing?

\- Adding dependencies to a project is REALLY HARD TO MAINTAIN. I've had so many bad experience using node because of that. I.e. I work on a project, it's tested and work fine. 2 months later I clone and start the project and everything breaks. Oh, X and Y libraries decided to fuck everything, that other library now depend on a new version of Node, but I can't upgrade node because that other library depend on a previous version of Node. It's complex. I won't go on in explaining my solution to this problem, but enough to say that it's a problem and installing random amateur libraries in a professional project can lead to disaster.

\- It takes longer to code. I've touched that earlier. It's a tradeoff about write now vs maintain later. Take a look at segmentio github repo: [https://github.com/segmentio](https://github.com/segmentio). I'd personally love to have that as onboarding experience rather than some massive project with everything copy/pasted a few time. But yes, it took them more time to create those separate modules.

<comment><USER92> >2 months later I clone and start the project and everything breaks. Oh, X and Y libraries decided to fuck everything

Are you not using semver? A common mistake I've seen is to depend on the "*" or "latest" version of a package, which obviously will break when the package releases a major update.

Also, applications should use shrinkwraps to pin their dependency versions to versions they've been tested with.</comment></comment>


Ask HN: What programming languages are needed to develop Covid tracking website? - <AUTHOR> For example: https://ncov2019.live/data <comment><USER2> Any programming language can do the data collection and data processing. For the website itself HTML (the page), CSS (styling), Javascript (interaction). [https://developer.mozilla.org/en- US/docs/Learn](https://developer.mozilla.org/en-US/docs/Learn)

</comment><comment><USER3> Pick one depending on what your goal is - [https://www.kaggle.com/learn/overview](https://www.kaggle.com/learn/overview)</comment>


Google found it was underpaying more men than women for similar jobs - rising-sky https://www.cnbc.com/2019/03/04/google-found-its-underpaying-some-men-as-it-studies-wage-equity.html <comment><AUTHOR> [https://news.ycombinator.com/item?id=19303039](https://news.ycombinator.com/item?id=19303039)</comment>


Kickstarter Projects That Might Actually Change Your Life - <AUTHOR> http://collex.io/c/kickstarter-projects-that-might-actually-change-the-way-you-live-1405346089/

<comment><USER2> Air Purifier - is your air actually so dirty? If it is, there are great purifiers already on the market.

EyeSpeak - no idea if this will work, but sounds cool.

Rainforest Connection - no idea if this will, but sounds cool.

JAESA - I call BS. If the only thing that stood between us and the kind of AI this is talking about was a $30,000, don't you think IBM, or NASA, or Microsoft, or one of a few dozen other large companies would have already done it? Hell, $30k is pocket change to invest into something like this for an individual with a large savings account. The profits earned would be huge.

Pyramid Garden - go to Home Depot and build your own.

GlobalStar - no idea if this is good or bad.

Daymak Beast - the problem with these is always that the battery doesn't have enough juice and the solar panels are only strong enough to power a pocket calculator. It's possible that this thing is a fun toy, but it is not real transportation. Get a bicycle if you want to be green.

Go Kin Packs - IMO a hand wind generator would be much more convenient than tiring your on your hike over many miles.

idenergie/river turbine - is it not a solved problem to extract energy from running water? Wouldn't a water wheel be easier/cheaper?

Rapidly rechargeable battery - it's a capacitor/supercapacitor. They do indeed charge very fast, but hold only about 1/10th of the energy of an equivalent Li-Ion battery. I believe you can already buy pre-packaged supercapacitors with charging circuitry elsewhere.

<comment><USER3> > Daymak Beast - the problem with these is always that the battery doesn't > have enough juice and the solar panels are only strong enough to power a > pocket calculator.

In the specifications they say their solar panel is "15 W/hr". They even calculate that again in their update. I think that's enough to say they don't know what they are talking about.

<comment><USER2> Nice. A Watt is a Joule/second, or rate of transfer of energy. So W/hr is unit-equivalent to Joule/(second * second) or acceleration of transfer of energy.

What they probably mean is Watt * hour which is a unit of energy (Joule / second * second or just Joule). 15 Watt*hours is enough to power a 15 Watt bulb for one hour. Or move a hamster on a trike across a living room for about the same amount of time.

</comment></comment></comment><comment><USER4> Not all of those projects are legit. For instance, J.A.E.S.A. is obviously a fake product. It promises Jarvis, holographic interface and AI, without any explanation of how it works. Even one of the several technological advances it promises would have been revolutionary yet no mention of their existence can be seen outside of the Kickstarter product.

<comment><USER5> At 3:36 in the video, when the 'interface' shuts down, it closes into Visual Studio. So not only is J.A.E.S.A. a next-generation AI, it runs natively on Windows.

The whole video screams 'scam'

</comment></comment><comment><USER6> Many of these are either snake oil or well intentioned but doomed dilettante projects.</comment>


Show HN: A GitOps development environment in the comfort of your own localhost - <AUTHOR> https://www.kubestack.com/framework/documentation/tutorial-build-local-lab <comment><USER2> If you used fluxcd you could remove the need for terraform and keeping the state. Validation can be done with kubeval. The issue would be connecting fluxcd with the local bare repo, but it could be exposed with a reverse tunnel.

<comment><AUTHOR> My framework does GitOps for infrastructure automation. It includes the managed K8s and supporting cloud resources. Not just workloads on the clusters.

Only the development environment is local.

</comment></comment><comment><USER3> Can anyone explain this to me? Is it a sophisticated version of git-hooks?

<comment><AUTHOR> I needed a way to mock the trigger that would usually be sent from e.g. Github to your CI/CD system. This is what I use the Git hooks for.

The way it works is: To get the post-update hook to trigger, you have to push because post-update is triggered by git-receive-pack after a push. So this is why you create a local remote and push to it. This also mirrors the workflow when using the Kubestack framework for real infrastructure.

The goal for the local development environment was to mirror the real workflow. So that people can also use it to try the framework without having to create real cloud infrastructure.

So the hook also needs to trigger a pipeline. Because the best practice is to have the pipeline live with the code, the post-update script will checkout the pushed commit-hash to a third repository and will call the mock-pipeline shell script that's part of the checkout.

You will then see the terraform plan/apply output as part of the remote output coming from the Git push.

</comment></comment><comment><USER4> We need a framework for that!

<comment><AUTHOR> Thank you, and naturally I agree. That's why I am building a GitOps framework. If there is value in building an application on top of a high-level framework like Spring Boot, Ruby on Rails or Django - and there is - then teams should not build the infrastructure and automation from scratch either.</comment></comment>


Ask HN: What Are Downsides of Rust Language? - <AUTHOR> Especially on reddit / HN, as well as blogosphere, rust is touted as one language to rule lot of things. Unlike, say Go, which draws lot of criticism, there are much less accounts on disadvantages of rust.<p>Not considering toolchain / language maturity & stability, what are disadvantages of rust? <comment><USER2> I would say

\- The ABI is not stable yet

\- The compiler is not the fastest

\- Doesn't work on all architectures (compared to C in the embedded space)

While those are potential downsides, they don't have to be. It all depends on what you're using it for and the language you're coming from. I would ignore the "learning curve" comments as they're (in my opinion) irrelevant. You learn it once and then reap the benefit for the rest of your career so a couple of months of investment doesn't sound that bad.

</comment><comment><USER3> The biggest issue which is inherent to the language is the learning curve. I feel there is limit beyond which language cannot be made easy to learn. I still claim it is worth learning Rust, however my point should still stand.

From personal experience: Our company had tailor made use-case to use Rust (switching from Python), more than Go. Experiments were performed and Rust outperformed Go in all aspects (time, CPU, memory). Everyone acknowledged but CTO (who knows C/C++ very well, he is a filesystem developer) decided to select Go. CTO was bullish on Rust to start with but developed cold-feet later. He told me that the only reason was that it is easy to train people in Go than in Rust. This one single thing trumped everything in my case. When I look back, I see his point & I respect that.

While issues like portability, eco-system, ABI stability, etc are important, these are not inherent problems with the language itself. They will get better over the time.

<comment><USER4> I made a similar decision quite a while back, though in the past year I reverted that decision and am back to using Rust.

My revert was mainly due to my realization that yes, Rust does take quite a bit to spin new devs up, it _can_ be far easier than people give it credit for.

Specifically I found that I was able to write Rust code that looked, felt and prototyped just as fast as Go code. The complexities of Rust come when you push beyond Go's feature set, namely lifetimes and the myriad of Generics features. Yet, if you don't use those, if you pretend Rust is Go, the language is far far more approachable to new devs.

You may ask "what's the point then? Why not just use Go?" as I did. The answer imo, lies in if you ever expect to want or need features beyond Go. If you're using Go but need something more you're sort of stuck. You'll force your way through fitting Go's square peg into a round hole, or be forced to rewrite in something else. However if you're already using Rust you can simply use more advanced features in the specific areas you need.

</comment></comment><comment><USER5> [https://old.reddit.com/r/rust/comments/c0xwjd/all_i_hear_abo...](https://old.reddit.com/r/rust/comments/c0xwjd/all_i_hear_about_is_how_great_rust_is_what_isnt/)

> Not considering toolchain / language maturity & stability, what are > disadvantages of rust?

You can't really "not consider" these things - they're big factors in any decision you might want to make. If you think the Rust toolchain and language ecosystem are half-baked and not yet ready for prime time, that's quite important!

<comment><AUTHOR> Well, I am trying to evaluate rust the language, because if the language is good, as a student, time investment can be worth it...

<comment><USER4> So this is a bit off topic, but on the note of time investment, I'd definitely say learning Rust is valuable for your mental model. Common patterns in languages _(take Go for example)_ allow you to do unsafe things very, very easily. Often simply involving pointers.

When you start writing programs in Rust you can often back yourself into a corner. These corners are often unsafe, but _allowed_ patterns in other languages.

Sure, you can solve this by forcefully Mutexing everything, or you can often learn a "better" design which doesn't involve trying to prevent race conditions. These batter patterns are not exclusive to Rust and can be brought to many languages. It's just that most languages won't help you discover them.

So what I'm saying is that learning Rust can make you a better X developer, even if you don't stick with Rust. Especially if you really learn it, and get a feel for what patterns to avoid, etc. If you _just_ learn the syntax Rust isn't likely to help you, imo.

</comment></comment></comment><comment><USER6> I think there is a part of criticism on Go which are not relevant. The language has been designed to be "simple" and it do the job. The latest posts on Go were only for the Karma, re-post, no new elements, no fair statements.

To answer to your question, I will say it will take you time to understand and to be productive with Rust.

But, please stop, Go and Rust can't be compared, they don't have the same goal in mind.

<comment><USER4> > But, please stop, Go and Rust can't be compared, they don't have the same > goal in mind.

Nonsense. For _certain things_ they can't be compared, but many things they can be. If I can compare Python and Rust, why can't I compare Go and Rust?

For example, I chose Rust at work recently for a project that was previously written in Go. How do you think I made that decision if I can't compare them?

Fundamentally yes, they're different languages. But seeing as Rust is quite usable in many areas it's perfectly valid to compare them. I see this "they can't be compared" so frequently that it's comical to me. Not trying to be insulting here, it's just perplexing.

I think it must stem from back in the day when Go was "incorrectly" labeled as a Systems Language. People ended up thinking that Rust and Go were competing for the same space. That there was bound to be a winner and a loser. They can happily co-exist, they're not at war, but they can and will frequently be compared. They have a _ton_ of overlap.

</comment></comment><comment><USER7> Rust is criticized on in too, but you can't read the criticism because it's downmodded to the background color. ;)

For me, Rust fundamentally doesn't offer anything that 1) I want and 2) Python doesn't already have. The language I want is a better version of Python, not a better version of C++.

<comment><USER8> There are a few new languages competing for the title of "better Python," i.e., a language with Python-inspired syntax, optional typing, and native compilation. Julia is trying to be a "better Python" for mathematical and scientific computing, and Nim is aiming to be a better general purpose Python. Nim predates Julia by a few years, but there's a lot of excitement around Julia these days.

<comment><USER7> I've tried both and I don't think they are better than Python. For one, they don't do integer arithmetic correctly by default:

        julia> 2^64
        -9223372036854775808

To me, that is simply not ok. The point of HLLs is that details like sizes of hardware registers shouldn't matter.

<comment> one-more-minute Python uses arbitrary-precision integers by default, unless you use Numpy, in which case you end up with the same issue. It also uses machine floats by default, which can give similar errors (so one could say "Python doesn't do real arithmetic correctly by default", though of course neither does anyone else).

So it's not that your point isn't valid, but it can't be extrapolated to general safety or high-level-ness; this is a really specific feature to rest your decision on. Arguably Julia has an advantage here because you can easily check correctness of an algorithm using arbitrary precision types and then use machine types in production, which is pretty handy.

<comment><USER7> Integer overflow is one type of bugs that can lead to catastrophic failures. Think billing systems that suddenly starts paying customers rather than charging them or rockets firing in the opposite direction. Therefore I think you can say that Python is safer because it prevents one class of bugs that these languages doesn't.

Another reason for saying so is because it's an example of performance meeting safety. Julia, Nim and Rust choose performance, ostensibly to score well on benchmarks which I think is irresponsible. Python choose safety which I prefer. In the future, these languages will again choose performance ("zero- cost abstractions") to preserve their benchmark rankings over essential safety and programmer ergonomics. Another area in which these languages make compromises for performance is in the legibility of stack traces.

It is true that Python doesn't do fractional arithmetic correctly which I think is a flaw. Newer languages should use rational arithmetic by default. 6/5 - 1 should evaluate to 1/5 not 0.19999999999999996.</comment></comment></comment></comment></comment>


Netflix and Net Neutrality - <AUTHOR> http://www.marco.org/2014/02/27/netflix-and-net-neutrality <comment><USER3> I really have to disagree with marco on this one. Infrastructure investment isn't free, and in order to align incentives toward more investment and not less, we need to start implementing metered usage. This would lower the cost of internet access for 95% of people by limited the subsidy to the top 5% of bandwidth consumers.

<comment><USER4> The issue I have with metered usage is that in the data world, last-mile is relatively expensive to rent, and even more so to build, which artificially limits carrier choice. You're already seeing some of the effects of this - <USER2> an example, Verizon's FiOS rollout, they've stopped the rollout in many locations because they can't pay for the physical infrastructure, so many customers are locked in to their current carrier (even when they want FiOS). It's not like wireless where you can simply switch carriers so data pricing stays reasonably honest.

With that being said, you have less incentive for data caps/metered pricing following the mobile model where pricing is kept reasonable by carrier choice/number portability. As backbone increases, there's no reason for Comcast/TW Cable/RCN/etc. to increase the data tiers/lower cost per Mbps, so I believe you'd see costs creep upwards as data consumption grows.</comment></comment>


How to Read a Book - <AUTHOR> http://blog.anguscroll.com/how-to-read-a-book/

<comment><USER2> Susan Sontag wrote a famous essay in 1966 about this: "Against Interpretation" [1], arguing exactly the same thing as OP's link does:

>Sontag is strongly averse to what she considers to be contemporary interpretation, that is, an overabundance of importance placed upon the content or meaning of an artwork rather than being keenly alert to the sensuous aspects of a given work and developing a descriptive vocabulary for how it appears and how it does whatever it does.

and

>Sontag asserts that the modern style is quite harmful; to art and to audiences alike, enforcing hermeneutics- fallacious, complicated "readings" that seem to engulf an artwork, to the extent that analysis of content begins to degrade, to destroy. Reverting back to a more primitive and sensual, almost magical experience of art is what Sontag desires

Edit: You can read the whole thing here: [http://www.coldbacon.com/writing/sontag- againstinterpretatio...](http://www.coldbacon.com/writing/sontag- againstinterpretation.html)

[1] <http://en.wikipedia.org/wiki/Against_Interpretation>

</comment><comment><USER3> > There was an actual book called How to Read a Book published in the 1940s. > It focused almost entirely on non-fiction and encouraged the reader to > analyze everything ad nauseam. In case you hadn't guessed, this essay is > exclusively about fiction (never let mere accuracy get in the way of a good > title) and advocates entirely the opposite approach.

No it advocates the entirely SAME approach.

I think if the OP had actually read "How to Read a Book", the OP might have found that there are some excellent techniques presented, and the authors make a very clear definition between reading for enjoyment and reading for education.

It is one thing to read a single novel for pleasure, quite another to survey all available literature on a subject and to figure out what has not yet been written.

Perhaps if the OP had actually read the book ...</comment>


Perl, the first postmodern computer language - mark-t http://www.wall.org/~larry/pm.html

<comment><AUTHOR> Incidentially, I'm reading John Gardner's "Grendel" right now, which my English teacher calls postmodern. Mostly it consists of Grendel ranting about how humanity enrages him and that's why he kills dozens of people. Similar to Perl, when you think about it...

</comment><comment><USER2> Great article! it is not really about perl and it is a great read around here where there seems to be the idea that lisp (or ruby or python) is the only way.

</comment><comment><USER3> Spring 1999.</comment>


Qualcomm Rejects Split After Strategic Review - <AUTHOR> http://www.bloomberg.com/news/articles/2015-12-15/qualcomm-board-rejects-split-after-completing-strategic-review-ii7dl19y <comment><USER2> "Talk of a split was rekindled earlier this year by activist investor Jana Partners LLC, which bought up stock in the company. Jana signed off on the strategic review, which was initiated in July and included a 15 percent employee reduction and a shakeup of the board."

Once these activist investors gain a toehold, nothing but bad things happen to employees of the company.

I suspect the layoff which occurred in November won't be the last. The investors will want to move the design and engineering arm of the company overseas, and keep the licensing arm in the states. This will mean no more design engineering at Qualcomm headquarters in San Diego. Maybe this is what's required to remain competitive against the Chinese company Mediatek, but the trend I'm seeing in US companies is to keep the HQ in the states with the CEO, Legal, MBA's, and marketing types, and outsource the R&D and design and manufacturing overseas. This type of company is what I call a "Toga Company".</comment>


Targeting Incest and Promoting Individualism - <AUTHOR> https://news.harvard.edu/gazette/story/2019/11/roman-catholic-church-ban-in-the-middle-ages-loosened-family-ties/ <comment><AUTHOR> Few other other articles on the paper:

* [https://www.npr.org/sections/goatsandsoda/2019/11/07/7772764...](https://www.npr.org/sections/goatsandsoda/2019/11/07/777276474/western-individualism-may-have-roots-in-the-medieval-churchs-obsession-with-ince)

* [https://www.sciencemag.org/news/2019/11/how-early-christian-...](https://www.sciencemag.org/news/2019/11/how-early-christian-church-gave-birth-today-s-weird-europeans)

* [https://nationalpost.com/news/world/medieval-catholicism-exp...](https://nationalpost.com/news/world/medieval-catholicism-explains-the-differences-between-cultures-to-this-day-researchers-say)</comment>


Privacy Risks on Public USB Chargers - <AUTHOR> https://spreadprivacy.com/privacy-risks-usb-charging/ <comment><USER2> I know that at least the Google Pixel devices only charge when plugged in. The user has to manually turn on USB data every time they plug in. USB debugging is also disabled by default.

<comment><AUTHOR> You're right. My Android smartphone as well asks for my interactions in order to allow data transfer, but who knows. I wouldn't take the risk. What I'd recommend, is to have a "USB condom" (charge-only), in order to ensure physically (besides logically, like you mentioned), that there will be no chance of juicing my data.

<comment> frosted-flakes Doesn't cutting the data lines prevent fast charging?

<comment> T3OU-736 USB-C and the fast charging (well, power delivery negotiations) make USB condoms... tricky.

</comment></comment></comment></comment><comment><USER3> LineageOS has a "Trust HAL" [0] for restricting USB gadgets while a device is locked.

Android (AOSP) also has a "Default USB Configuration" setting deep in the Developer Options [1] to set a device to MTP, PTP, RNDIS, charging etc...

A device would have to be really misconfigured by either the user or the OEM to allow plugging in a USB cable to extract system from the userdata partition _without_ user input or awareness; or someone is just burning 0days on the general public.

0\. [https://review.lineageos.org/q/topic:%22trust- usb%22+(status...](https://review.lineageos.org/q/topic:%22trust- usb%22+\(status:open%20OR%20status:merged\))

1\. [https://developer.android.com/studio/debug/dev- options](https://developer.android.com/studio/debug/dev-options)

<comment><USER4> >A device would have to be really misconfigured by [...] the OEM

You're giving Android OEMs, on the whole, way too much credit.</comment></comment>


There should be consequences for Ontario grads leaving Canada for Silicon Valley - <AUTHOR> http://www.theglobeandmail.com/news/national/there-should-be-consequences-for-ontario-grads-leaving-canada-ceos/article30597475/?cmpid=rss1&click=sf_globefb <comment><AUTHOR> It's really sad to me that this is the response we are seeing from CCI.

Instead of urging companies to compete with the firms in California and offer a comparable salary, the first reaction is to punish talent for leaving? Totally insane.

You want top Canadian talent? Pay for it.

</comment><comment><USER2> Living in the USA isn't enough punishment already?

I'm only kind of joking.</comment>


YouTube Adds New "Click to Download" Feature - <AUTHOR> http://www.technobuzz.net/youtube-click-to-download-feature/ These Days Youtube is Busy in to implenting new Features in Youtube Videos, Recently they announced the Youtube for TV feature and Also  Mutes Videos With Unauthorized Copyrighted Music. Now they are working on a new feature Download Youtube Videos. YouTube has started offering the option for you to download video content off the site. A new "Click To Download" button has been added directly below videos such as Obama's weekly YouTube address that are "consistent with principles of open government." <comment><USER2> doesn't appear for me. I'm going to assume this is some custom plugin the author hadn't noticed?

I wonder how much money yourtube.com makes in ads.</comment>


Show HN: StumbleUpon for books - <AUTHOR> http://stumblary.com

<comment><USER2> Fetching books from HN threads is IMO a really good idea, but using the submission title seems to produce completely inaccurate teasers for me. I'd recommend fetching the title from Amazon too, and also somehow weighting the books by comment upvotes.

<comment><AUTHOR> Thanks for your feedback and suggestions! Book titles would make more sense definitely. But post titles lead to surprising and funny results sometimes.

</comment></comment><comment><USER3> Very cool idea. I recently spent quite a while paging through HNSearch.com looking for book recommendations.

My recommendation would be to make sure the "Next" button never moves. Some really long titles cause it to get pushed down a bit and that gets annoying when you're clicking on "Next" at a fast rate.

I also agree there needs to be a little more information on the page because of the sometimes-indirect post titles. I find myself hovering the Amazon link to see the name of the book.

<comment><USER4> If I recall, there was a guy who also scraped hn but included movies and other things. It wasn't limited to clicks, he had all the information in lists.

<comment><AUTHOR> Maybe it was me again with [http://www.hnstore.co/](http://www.hnstore.co/)

<comment><USER4> Thank you for that! Somehow I went to a tangent on your site the last time I saw it and came across r/Cyberpunk. I believe you should include subreddit mentions too.

<comment><AUTHOR> Cool idea! I will look into it!

</comment></comment></comment></comment></comment><comment><USER5> I don't like how the titles aren't necessarily about the book or what you're going to get.

<comment><AUTHOR> Sorry about that! I thought getting something unexpected would be more fun. But majority here want to see real book titles so I will look into it.

</comment></comment><comment><USER6> Finding interesting books to read is a huge problem for me. I have tried Goodreads, but its recommendations are poor. I usually just use random lists to find things to read.

I really like the general idea of something like this, but a way to restrict by category or train it in some way would make it a lot more useful for me.

</comment><comment><USER7> Very cool. Naturally, scraping out of HN is gonna provide a few wonky teasers, but a great idea nonetheless. Just submitted my book per the site's instructions for kicks [http://www.amazon.com/dp/111866146X](http://www.amazon.com/dp/111866146X)

<comment><AUTHOR> Thanks for the kind words!

</comment></comment><comment><USER8> Fun name. Took me a moment to realize it's a word combination.. but cool. :)

<comment><AUTHOR> Glad you liked it! Name was one of my concerns.

</comment></comment><comment><USER9> You need to add an Amazon Associate tag to all these links!

<comment><AUTHOR> But is it worth it if visits are not in millions?

<comment><USER10> thursdayb, you're shadowbanned (which is a shame, because that was a good comment). Might email pg and see what's up. Your comment history looks benign to me.

<comment><AUTHOR> That was a good comment indeed! Thanks thursdayb, cheald!

</comment></comment></comment></comment><comment><USER11> If you could get images for the titles and possibly a short summary, it would be a lot better.

</comment><comment><USER12> Good idea. But the site needs some polish. Moreover, you should add a thumbnail of the book in question.

</comment><comment><USER13> A back button would be nice as well.

<comment><USER14> I think the same. If I miss one I have to start over.</comment></comment>


Lock-free Multi-producer Multi-consumer Queue on Ring Buffer - <AUTHOR> http://natsys-lab.blogspot.ru/2013/05/lock-free-multi-producer-multi-consumer.html Work queue has always been one of the most hot points in server software.
  Here is how to scale it effectively to multi-core environment. <comment><USER2> How is this different from disruptor queues ([http://lmax- exchange.github.io/disruptor/](http://lmax-exchange.github.io/disruptor/))?

(Here is a plug for our C version: [https://github.com/redjack/varon-t](https://github.com/redjack/varon-t)).

<comment><AUTHOR> The algorithms are simply different and solve different problems: disruptor is a messaging queue (if a producer P0 emits M0 into the queue then all consumers C0..CN receive M0) while our queue is a classical work queue (if P0 and P1 emit message M0 and M1, then only one consumer Ci receives M0 and only consumer Cj receives M1 (i could be equal to j)).

Our implementation competes with boost::lockfree::queue and it's much faster since Boost implementation uses more heavy synchronization techniques. The benchmark on GitHub also has Boost implementation, so you can compare both the queues.

Unfortunately, there is no adequate algorithm description for disruptor queue, only some indistinct descriptions mostly suitable for business people rather than engineers. So it was not easy to dig it's source code. However, I learned it and there are some notes about the implementation.

The implementation is bit inaccurate: there are a lot of branches without branch prediction information available at compile time, to avoid cache line bouncing it wastes two cache lines instead of simple align an item on cache line (I mean vrt_padded_int). I didn't pay too much attention to memory barriers usage, but giving that X86-64 provides relatively strict memory ordering, probably some of them also could be eliminated. Disruptor uses very cleaver ideas, but I believe its performance can be improved after good code review.

One more point is that while our queue implementation is C++, it's still self sufficient and can be easily ported to C for using in kernel space. It's doubtful (in my humble opinion) that generic container depends on non-standard libcork and moreover logging library (clogger).

</comment></comment><comment><USER3> Interesting, and the author clearly is an expert on the topic. However, I'm curious about how this fits in to a sensible program architecture. When do you need such a queue? It seems to me quite unlikely that production and consumption operate at the exact same rate and with the same CPU usage rate such that the queue runs in a steady state of neither full nor empty. It seems much more likely that the queue will just be either full or empty all the time, in which case this algorithm will be terrible because it busy-waits instead of having condition variables that can be used to wake the consumers or block the producers. By the way blocking the producers is also known as flow control, which many people believe is a desirable property of software.

If your queue is normally empty, it would be fine for the producing threads to just jump straight into the consuming routine and nevermind the queue. If the queue is normally full, it's fine for them to just take a lock and sleep on a condition.

Normally what you want a p/c queue for is to paper over short term variance in a system where on long time scales the consumer side is faster than the producer side. In that role, an ordinary queue with a mutex will work fine. If the consumer is stalled for long enough to fill the queue, blocking the producer is exactly what you want.

Of course, some languages favor the use of this pattern. I'm thinking of Go channels. Totally lock-free Go channels would be pretty awesome, but busy- waiting in select would not be awesome.

<comment><AUTHOR> This is a good question. Currently we've integrated the queue in two projects in production state: user-space proxy server and VPN capturer (Linux kernel module).

In both the cases we enhanced the queue with conditions like is the queue empty or is it full, so we can drop packets if consumers are overloaded and there is no sense to put a packet to the queue.

Secondly, the queue is designed to work on multi-core environments and this is usually multi-node NUMA systems for modern hardware. So we adjusted both the applications in such manner that administrator can assign different number of cores for all processors for consumers and producers depending on current workload. This makes the system mode balanced, so queue is empty or full rarely.

And finally, for kernel space we also implemented lightweight also lock-less condition wait for the queue ([http://natsys-lab.blogspot.ru/2013/08/lock- free-condition-wa...](http://natsys-lab.blogspot.ru/2013/08/lock-free- condition-wait-for-lock-free.html)). It also gives us lower CPU consumption when there is no workload (so the system eats less power) and even better performance due to reduced cache bouncing.

</comment></comment><comment><USER4> Note that "lock-free" doesn't mean "doesn't use mutexes"; it means "at least one consumer/producer will always make progress". (Any algorithm using locks fails this test, as one stubborn consumer/producer can hold up the entire system.) The article doesn't seem to really touch on this property at all (although at first glance the algorithm _does_ appear to be lock-free).

</comment><comment><USER5> I'm a bit skeptical about the code: it seems that it's using only the atomic fetch-and-add synchronization instruction, and not compare-and-swap. However, I think that whether queues are implementable with only fetch-and-add is an open problem in distributed computing (in technical terms, whether queues are in the Common2 family. See for example Afek et al., "Common2 Extended to Stacks and Unbounded Concurrency".)

<comment><USER6> I've seen many queues implemented similarly to this, and it works fine. Every thread that calls fetch and add receives a different result, therefore, wrapping asside, there can only be one thread with access to each slot. If there is only one consumer and one producer you don't need fetch and add at all (that is how fastflow is implemented.) You must check that your slot is populated by either comparing with the other index (producer if your the consumer), which is stupid because that cache line is highly contended. The better way is set a slot to null after you've consumed it, and if your the producer, you first check if the current slot is null before attempting to increment the index. A race condition exists where the slot can be null before incrementing but not afterward (e.g. only one slot free but several producers saw that and incremented.) In reality all that means is the producer can skip slots and the consumer must keep incrementing if it sees a null slot rather than assume an empty queue (can be tempered by checking x slots and then falling back to checking the producer index.) Consumer and producer indexes must be on seperate cache lines and some effort can be made to keep consumer and producer on sperate cache lines in the actual queue. e.g. each slot can be a whole cache line and pop() and push() can be batched to work with 8 elements at a time. In other words OP is a noob and I could write a queue that whoops his hiney (danger: attempt at humor.)

<comment><USER5> Ok, so it is relatively easy to obtain a safe implementation and from there you can use a heuristic to prevent a thread from looping forever trying to find an available slot. Would that sum up the issue in practice?

<comment><USER6> I'd rephrase that as it's easy to create a safe implementation, but the dangers and biggest payoffs are realized when you don't access both producer and consumer counters in the same thread all the time. cache lines shared between the consumer and producer and written to by at least one of them are the hottest points of contention. With careful design you can get that to zero in the common cases.

</comment></comment></comment></comment><comment><USER7> In what way is this different from the wait-free circular buffer implementation described by Sape Mullender [1] (of Plan 9 fame). I listened in to a presentation he gave last november and one of the take-aways was that it scales poorly with the number of cores.

He implemented this in Plan 9, but the performance gain was not tremendous due to shared memory effects among the cores.

[1] [http://lore.ua.ac.be/Teaching/CapitaMaster/antwerpen- threads](http://lore.ua.ac.be/Teaching/CapitaMaster/antwerpen-threads)

<comment><AUTHOR> Unfortunately, there is no good explanation of the algorithm which you refers, also I didn't find a source code for this.

</comment></comment><comment><USER8> The subject might be interesting but the formatting of the article is horrible. Is it that difficult to remove the line terminators at the end of each line so that you get actual paragraphs?

<comment><USER9> You may prefer this version of the article which is better formatted but split across multiple pages: [http://www.linuxjournal.com/content/lock-free-multi- producer...](http://www.linuxjournal.com/content/lock-free-multi-producer- multi-consumer-queue-ring-buffer)</comment></comment>


Changing the Ungit license from MIT to Faircode - <AUTHOR> https://github.com/FredrikNoren/ungit/issues/974 <comment><USER3> Maybe I am missing something. If you release something under a non-copyleft license, as long as I make proper attribution, what I do with it should not be your concern. If you do not want people making money from your software without paying you, use dual copyleft/proprietary licenses instead.

"Faircode" seems like an attempt to have it both ways: squeezing money out of people without being labeled copyleft (because that's not cool in some circles).

There is nothing "fair" about making a company's revenue a criterion for deciding which license terms the company enjoys.

What if I make more than $1M but am willing to release all of my modifications? Does that make me less of a friend to the community than people who sell non-free versions, but have had less success with their business model?

I am trying to avoid the word "shakedown", but this strikes me as exactly that. From the Medium post announcing the license:

"Some people have asked my about the difference between this and donations. I think that for a project like Ungit small individual donations would never work; we'd have to convince thousands of people to part with small sums of money. We're simply not big enough for that. With LYC the idea is to ask a few big players who benefit commercially from the project to part with bigger sums instead."

Source: [https://medium.com/@fredriknoren/trying-a-new-open-source- mo...](https://medium.com/@fredriknoren/trying-a-new-open-source- model-93a1a5a16a40)

<comment><USER4> > I am trying to avoid the word "shakedown", but this strikes me as exactly > that.

Yes, the $90/month cost is going to hurt all the companies that have revenue greater than $1,000,000/year. This will put them out on the streets, I'm sure.

Let's be real: This does not apply to you, and on the off chance that it does, why are you complaining about paying $90 per month for something you should probably already be donating more to?

If your business depends on a tool/library and your revenue is in excess of $1,000,000, and you haven't yet donated to that project, you're just a leech. I guess we could both hope that your revenue falls below the limit so that you can escape these unfair shakedown licenses and continue not contributing in any way to the things you use.

<comment><USER5> What if the company makes contributions to open-source through other projects - for which no one is paying them? Is it 'fair'? Who is the leech?

Even a $1m/y company (which is not big at all) will be hard pressed to pay 1k/year for a git wrapper. The whole idea of OSS is that everyone benefits from the exchange and costs are distributed. This won't scale at all - <USER2> your current open source dependencies and imagine paying that sum for each of them.

<comment><USER6> If they do have a problem paying $90 or even $1000 for a piece of software they really need, they are free to ask one of their developers to write one in house from scratch and see how much this sunken time would cost them.

The sad reality is that costs are not distributed, most companies just grab whatever open source software they can and only contribute the least they can get away with, most of the times nothing at all.

Many projects survive just because of dedicated individual developers and maintainers spending their limited spare time, who end up being burned out.

In an ideal world open source software that brings significant value for companies should be considered as part of their stack, they should either hire or assign someone for supporting it, or pay the existing maintainers, and ideally this should be somewhat proportional to the value they get out of it.

Unfortunately donations as method of payment rarely work(usually end up being paid by individual employees from their own pocket), so the only option to get money from the company itself is to somehow get it charged.

They usually have no problem with being charged money, as long as the price is reasonable for the value it brings and less than would cost to write the same code in-house or to even have a meeting about acquiring it. It also should be significant, they wouldn't go through the bureaucratic procedures for a 10€ one off payment.

Developers don't expect to become rich out of this, they often would settle for less than their full time job, as long as they can work full time on the project they care about and still make a living. But because so few companies share the costs, they tend to be significant for those who do pay, so the prices will be higher at first but should decrease quickly as more companies share the burden.

</comment></comment></comment></comment><comment><USER7> Reinventing GPL with less care. I can copy the code, re-license as plain-MIT, and now commercial companies can use it for free.

A dual GPL-commercial license is the correct way to handle this. A more useful contribution to the license landscape would be to define a commercial sibling- license to the GPL that described how license payments would be disbursed.

<comment><USER8> _I can copy the code, re-license as plain-MIT_

You can't relicense someone elses code. You dont have the right to do that.

If you fork this code, only your changes would be under MIT. So you would have a mixed-license project, and users would need to comply with both licenses.

If you don't want to use this license, you have to fork it from before the license change... giving up the changes that were made after the new license takes effect.

<comment><USER9> You're right, but both the MIT and the non-commercial portion of this new license explicitly grant the right to sublicense. It's not obvious to me that a free use case can't sublicense its use to a huge organization.

<comment><USER8> sublicense != relicense. You can't remove restrictions. All of the terms of the license would remain. That organization would still need to pay the fee.

</comment></comment></comment></comment><comment><USER10> I do not want to judge the license change: everybody should be able to do whatever they want with the code for which there is ownership. Just two general observations:

1) I think this is going to be a trend in the future, for two main reasons, one is that the cloud poses very challenging limits to individuals or small companies to monetize they OSS projects selling services, the second is that many OSS developers are starting to think that it's a bit unfair that incredibly successful companies sold for billions, mostly based on OSS frameworks, libraries, operating systems, don't support the projects they used to reach to such success. And no... releasing your own OSS project to the public, developed for internal interests, is not going to pay back the authors of the projects used to reach the success.

2) If you like this route, better to start ASAP with such a license, or at least start with some restrictive *GPL license and not BSD. Otherwise you are obviously susceptible to forking once you insert such a clause.

<comment><USER11> Yes I think it depends heavily on the type of open source project and it shouldn't be frowned upon for certain kinds of projects.

I run an open source project which is technical and is designed to integrate into other systems; it's ideal for fast growing companies and large organizations that have money; because of this, inbound leads for consulting, technical support, sponsorship, partnership and contract work trickle in on their own. So in my case, a very permissive MIT license makes sense even financially.

If you have a relatively simple product which is more like an external stand- alone tool (not designed to be integrated into proprietary systems at the API level), then it will be impossible to monetise it through consulting or sponsorship.

Also, other kinds of open source projects which are difficult to monetize are those which implement established and well understood industry standards.

Adhering to standards helps with adoption and greatly increases your project's chance of success but it's not creating any new markets; you're tapping into an existing user base and competing with other implementers in a race-to-the- bottom in terms of performance, efficiency and usability and it's hard to capture any value out of that.

<comment><USER10> Interesting observations, thank you.

</comment></comment></comment><comment><USER12> I truncated some of the text to highlight a possible issue with the change written by the Ungit maintainer:

> Permission is hereby granted (...) to use, copy, modify, merge, publish, > distribute, sublicense, and/or sell copies ("Use") of the Software (...)

And then:

> If you are a commercial entity with a revenue in excess of $1,000,000 (...) > you must acquire a commercial license grant (...) to Use this Software (...)

The problem is that according to the license, you can now pay $90 to "copy", "sell", and most importantly "sublicense" the software. Legally, does this work the way the Ungit maintainer intended?

<comment><USER13> Or, can I as an individual who is an employee of the company, but not the company, "use" it myself and then "sublicense" it to my employer?

</comment></comment><comment><USER14> Licenses like these are a logistical nightmare. If someone deploys software under that license, paying that person for the job is the smallest item on the bill: Now I have to connect my legal department with my techies and with the finance folks. Let's schedule meetings every 3 months to review for which software we have to pay now!

Just the logistical overhead alone justifies a fork for any of the targeted users^wcustomers.

<comment><USER15> "Paying people for their work sucks, what a drag. Undercutting their work so we can continue to profit more is a much better strategy."

<comment><USER16> [http://www.paulgraham.com/disagree.html](http://www.paulgraham.com/disagree.html)

</comment></comment></comment><comment><USER17> For open-source projects driven mainly by one contributor, I think the model employed by Sidekiq[1] is better than this one.

There is a base version with the MIT (or similar) license. Then there is a PRO version which adds some enterprise functionality + premium support.

But still a good thing that Ungit is trying this. There is value in experimentation!

[1] [https://github.com/mperham/sidekiq](https://github.com/mperham/sidekiq)

<comment><USER18> I've always wondered, in such cases where you have an open core and plan to monetize on extra features and plugins; what do you do if the community just goes ahead and adds those extra features? Or someone forks the project and adds the features?

<comment><USER19> That's called business competition. Stay in business by delivering greater value.

It's likely the maintainer is in the best position to start a company about the product to deliver more features faster and at higher quality along with more inherent trust.

<comment><USER20> As someone being in a similar situation, it's a really difficult business model. Unlike many other business models with a natural moat (i.e. by virtue of having all the data, being deeply integrated into organisational processes, etc), commercialising open source is a struggle because simply justifying making money already requires constant improvement.

<comment><USER19> Almost all businesses require constant improvement to be commercially viable. This is the common scenario.

Natural moats are rare and highly sought after and fought for, and is actually much harder to build than a typical business based on product value.

</comment></comment></comment></comment></comment><comment><USER21> This isn't open source: it discriminates against field of endeavours (point 6):

[https://opensource.org/osd-annotated](https://opensource.org/osd-annotated)

Restricting commercial use isn't anything new or a bold new experiment or anything. It's the same lesson we apparently need to relearn from the 1980s.

<comment><USER22> I've been telling people for ages now that the slow erosion of copyleft mindshare in favor of permissive licensing is going to bring about a return of the bad old days of proprietary software licensing. Now, maybe I'm wrong, but this move doesn't bode well.

</comment></comment><comment><USER23> If this becomes a trend I'm afraid it will hurt business use of _all_ open source software, since companies will never know if their dependencies are going to suddenly start charging money. Even though you can use the old versions, getting stuck on outdated libraries is a big problem for a lot of projects, where you try to stay up-to-date. It feels like we are only recently at a point where managers and lawyers will permit building on open source software and not force you to use Microsoft and Oracle. But if every repo could be free today and $90/mo tomorrow, will that change?

<comment><USER24> > _But if every repo could be free today and $90 /mo tomorrow, will that > change?_

Well, it's not "free today and $90/mo tomorrow", it's just that they're not going to maintain the one that's under the free license. You don't suddenly have to pay $90/mo for what was already distributed.

It's a fair attempt to make some money, but this license is odious and bizarre. I don't think there's a trend for this.

</comment></comment><comment><USER25> Of course people can license their stuff in whatever weird way they want and I don't have to like it.

But I don't like it when people lie to me. The title is "Trying a new open source model" \- the content is "Trying not to be open source any more". If you don't want to do open source then you can of course do that. But if you don't want to do open source any more and still say you're doing open source then you're lying.

(And before anyone answers: No, there's no "other open source" or "a different kind of open source". Open Source is a clearly defined term and such restricted licenses aren't.)

<comment><USER26> You're confusing open source software with free software.

I'm on your side in principle but the distinction is important in this case.

<comment><USER25> > You're confusing open source software with free software.

No, I'm not. Please read the open source definition: [https://opensource.org/osd-annotated](https://opensource.org/osd-annotated)

In practical terms there's very little difference between free software and open source. It's mostly a "philosophical" difference - free software advocates put an emphasis on "freedom", while open source advocates see it more as a business model. But the requirements for the licensing are identical.

<comment><USER26> I see what you mean but that doesn't make sense to me.

Open source is by definition of the phrase, as well as in practical cases, a program whos source is available. Nothing more.

There are many prominent open source programs that also exist as a licensed product.

That's why I have always believed free software (FOSS) to be the other definition where the software cannot be licensed or sold for a profit.

</comment></comment></comment></comment><comment><USER27> I don't have anything to add, but just want to say it's refreshing to see such a civil discussion surrounding a license change like this.

</comment><comment><USER28> Speaking on his pricing, $90/month is more expensive by far than IntelliJ Ultimate/PHPStorm/RubyMine by far with a lot less value.

Having worked at an org with $xxMM in revenue, we still wouldn't have paid for it. We would have chosen to find a different tool. It's a Git UI. Come on.

<comment><USER29> Since the license allows sublicensing, it seems like a business only needs to buy one license at $90/month, which is a lot cheaper than IntelliJ

</comment></comment><comment><USER30> This is not an "open source business model", as claimed by the Ungit maintainer, because the new license is not open source under the long standard definition maintained by OSI.

Good commentary from Grant Bakker in the discussion: [https://github.com/FredrikNoren/ungit/issues/974#issuecommen...](https://github.com/FredrikNoren/ungit/issues/974#issuecomment-341250490)

<comment><USER31> Just because something is old, it doesn't make it true.

<comment><USER32> Do you have a proposed counterexample? The OSI definition is pretty much the same in spirit and in practice as, say, the DSFG or FSF definitions.

Non-discriminatory terms is pretty much a fundamental precondition for any open-source license. As any lawyer would tell you--and don't forget, licenses are explicit legal contracts--licenses that include discrimination clauses of various kinds (including "fun" clauses like "don't use this for evil") are basically non-starters. It's especially problematic when the discrimination is based on something as malleable as yearly profit, so that someone's inclusion or exclusion on this basis changes every year.

Licenses are legal contracts, and therefore they have the force of law behind them. Rolling your own license is a stupid idea, particularly if you are not a lawyer and you are not retaining a lawyer to give you advice on the matter. Even aspects of major licenses like 3-clause BSD, MIT, GPL, LGPL, Apache, and others have indeterminate legal repercussions, particularly when patents and copyright of contributions come into play.

</comment></comment></comment><comment><USER33> I just learned about faircode[0] and I've got to say, I like the idea. I like that right on the frontpage, it shows that I have the choice to keep using the current license, and have it work like a Patreon, or use their own Faircode License (which seems what this story is about). It makes them look honest.

I like that they are honest about the cost of using the faircode service, right on the frontpage (5% on top of a 2.9% + 30c transaction fee).

I like that they thought about having tools integrated in the ecosystem to allow businesses to easily now what license the deps they're using are on, and how to easily pay for them.

I haven't looked too deep into it, but if it could handle a dual license model as well, then it'd be beyond awesome. I don't want to force companies (even >$1M companies) to pay if they contribute back any improvements they make.

[0]: [https://faircode.io/](https://faircode.io/)

<comment><USER34> Your wish has been heard; I just added a dual licensing option to the platform :) Enjoy!

<comment><USER33> Wow, that's awesome ! You have no idea how happy this makes me ! Thanks for your hard work, I'll definitely be using this and suggesting it to the people around me :D

EDIT: Just tried to sign up, and I triggered an internal error :<

<comment><USER34> Whoopsie, the error messages are still a bit rough but it looks like the recaptcha wasn't clicked? I've improved the errors on the frontend so should give you a nicer error message if it isn't now! Lmk if that doesn't fix the problem.

</comment></comment></comment></comment><comment><USER35> The fundamental problem here isn't the relicense, the problem it's that it's being incorrectly called an "open source model".

This is not an open source software license, so it's not an "open source model". It's not a Free software license either, as defined by the Free Software Definition. Instead, it's a proprietary license. It's not a new software license model, either; historically this has been called a "gated community license" or "open box license". Here's article from 2000 about gated community license models: [http://archive.oreilly.com/pub/a/oreilly/tim/articles/gated....](http://archive.oreilly.com/pub/a/oreilly/tim/articles/gated.html) They've never caught on, in over 20 years of trying, but perhaps this project's experience will be different.

We've had, for decades, a widely-accepted definition for what the term "open source software" means. If someone actually means "open source software" per that widely-accepted definition, then by all means, that person should use the term. Since this project don't actually mean "open source software", then they should not use the term - please call it something else. The world is confusing enough.

</comment><comment><USER36> Will be interesting to see the resulting fork that keeps the MIT license. Looks like a few have already sprung up.

</comment><comment><USER37> Would this prevent github from using ungit (unless they pay)? Presumably this would also prevent ubuntu from packaging ungit?

</comment><comment><USER38> Has the LYC license been tested in court ? I know GPL has.

I agree with the maintainer that they should be compensated for their time. An open core model works but depending on a project who has the time to set that up? Patreon or Kickstarter has the same issue.

<comment><USER39> I don't think the opencore model works very well. The model that does work well is the Redhat/Fedora model of fast moving, and changing cutting edge of full features, with a premium being charged for the fully tested and integrated product.

</comment></comment><comment><USER40> Bad timing, seems licenseyourcode.com is down and does not currently work.

<comment><USER41> It was renamed to faircode.io

</comment></comment><comment><USER42> It is interesting and important to think about ways to support open source project contributors, especially when the projects are being used in commercial organizations. It would have been better to see this license change idea through an RFC before a change though, and with an attorney's advice. If he does really want this to be an experiment it would have been good for him to have a better background on the types of license models available and an attorney's help with license language changes and implications.

</comment><comment><USER43> I'd add that 1M in revenue is barely enough to support 4-5 reasonably paid develops + some opex like aws and a small office in a big city. The license change would probably touch most of its commercial users.

<comment><USER44> Maybe in the US. Many, if not most of the world can support way more developers with that revenue, and open source projects are used worldwide.

</comment></comment><comment><USER22> Why is GitHub happy to provide free hosting for proprietary software? Ungit is no longer free software in either the libre or gratis sense.

<comment><USER45> I was curious about that myself for a similar situation a while back. Their terms of service do not require a free or open source license:

> If you set your pages and repositories to be viewed publicly, you grant each > User of GitHub a nonexclusive, worldwide license to use, display, and > perform Your Content through the GitHub Service and to reproduce Your > Content solely on GitHub as permitted through GitHub's functionality (for > example, through forking). You may grant further rights if you adopt a > license. If you are uploading Content you did not create or own, you are > responsible for ensuring that the Content you upload is licensed under terms > that grant these permissions to other GitHub Users.

</comment></comment><comment><USER46> I don't think this is a new idea, but anyway it's not a proper "open source" license.

</comment><comment><USER39> While I can understand where he is coming from, his stuff is itself largely built on the free licensed software of others.

In the end, this seems to me like pulling up the ladder after himself, and ultimately quite selfish.

<comment><USER47> How is making a living from your work selfish?

<comment><USER48> It depends, is that work based on the free work of others?

Taking advantage of the community and not contributing back for others to benefit (as you have, for free) seems selfish to me.

Maybe if he proportionately (based on LOC or something) donated any income to his upstream dependencies?

...but I suspect that wouldn't leave much.

<comment><USER49> I saw it as him encouraging the community to join him, on behalf of all starving developers who are giving big businesses a free ride.

</comment></comment></comment></comment><comment><USER50> It is a while that I think about monetizing open source.

Honestly, I do not believe that companies will pay to use open source software when they can just download it.

Developers will prefer to just download instead of waiting for the legal department and the budget approval.

On the other hand, if it was simpler to just download the code/executable and then pay later, without any hassles from the legal department it could be the standard way to use Open Source.

However, there is still the problem of what to sell.

A great idea could be to distribute the executable when it applies, thinking about golang, C/C++, any compiled language. For languages that are interpreter you could distribute the ruby gem, or the python egg or the JS packet.

Now if we combine this mechanism with some rate-limiting and price structure.

Stuff like:

* 10€ for one time download of the current version.

* 50€ for one time download of any version forever, when a new version comes out you can download it too.

* 10€/month for 30 downloads/months of the current version

* 50€/month for 30 downloads/months of any version

* 100€/month for unlimited downloads.

... and so on.

This could already provide several benefits, and be enough for several projects.

However we could also go a little forward.

We could provide an incentive to the buyers to buy the software and that incentives could be to do not distribute the building instruction or the dependencies list as open source.

Of course it will be possible to reverse-engineer the build instructions or the dependencies, however, it will be so time-consuming that any sane actor will prefer to just pay a little fee.

Finally, we could provide, under a restrictive license, the above-mentioned build instruction to whoever wants to contribute to the code base in a non- automatic way. Just send an email, ask for them, explain what you are going to do, promise to do not use them to by-pass the above restriction and you are ready to go.

In this way:

1\. We maintain most of the code open.

2\. There will be incentives to just pay for open source.

3\. There will be a trade-off between new contributors and time/resource the current maintainer will be able to support the project. (I don't believe that somebody willing to dive into the complexity of an open source project to add features will be scared off by contacting the maintainer, explain to him what he wants to add, maybe wait his feedback, and finally get the build instructions. Honestly, I see mostly benefits in this project)

I would love to hear feedback about this idea.

So please share your thoughts and if you are interested in trying something like that feel free to contact me via email :)

</comment><comment><USER51> This is a perfectly moral choice, assuming he has not taken significant contributions from others (or they have allowed this relicense, or granted copyright ownership of their contribution to him). Later in the Issue discussion, they attempt to put a name to the type of license. I propose "Freeware with source". Thoughts?

<comment><USER52> They have already allowed the relicense by releasing their contributions under a permissive license such as MIT.

<comment><USER51> Oh yes, of course. Ignore my parenthetical statement then.

</comment></comment></comment><comment><USER53> This thread and the culture of those replying to it fascinate me. Do you really enjoy spending this much time debating licenses, clauses, and legal matters?

I personally, just have to many more important things to do than worry about and waste time on compliance, laws, enforcement. It just seems like such a rediculous waste of time.

I just 2 clause BSD license my code and move on. Compensate me, don't compensate me, I'm busy writing other code, or designing systems, etc

Do people people posting replies here really spend this much time on licensing issues instead of producing?

It just seems so needless to me.

<comment><USER54> I would love to continue producing the rest of my life, without concern for licenses and business. Unfortunately I am running out of savings and will not be able to spend even 20% of my time producing. So I am in support of finding some way of getting a living wage for the software I lovingly produce for free.</comment></comment>


The New York Times Perl Profiler - <AUTHOR> http://open.blogs.nytimes.com/2008/03/05/the-new-york-times-perl-profiler/

<comment><USER2> Doesn't the screenshot also suggest that they also use Linux. NYTimes now officially 0NzorTeHBaZonz0R</comment>