171–180 of 243 posts
Earlier quoted context omitted.
> Push the proprietary version hard enough and I'll reconsider whether I even want to use the Open Source version Qt is pushing hard for commercial licensing (which I heard prevents you from using the open-source version), putting L/GPL FUD on their websites, and trying to track users of their installers more.
And nowadays, most people use Electron instead of Qt.
Earlier quoted context omitted.
I think the point was a financially successful company not contributing to an open source project even after making a bunch of money just seems un-ethical? Maybe I'm old-school but I still think we should be supporting each other in this type of situation especially if one of us strikes it big? Sure - move away from Nginx but maybe throw some $ their way for the service they provided even if you don't legally have to…
For what’s it worth, many companies have a hard time justifying “unnecessary” expenses to their boards or shareholders. Depending on company structure, their hands may be somewhat tied. Not all companies, of course; and to be clear, I think such a company structure is a problem itself and agree with you.
Earlier quoted context omitted.
The sibling comments point towards the difference in configuration if you take the "out of the box" product. But there is also a vast difference in how code is organized, in case you ever have to touch it. From my point of view Nginx feels "old". It's a C codebase without a great amount of abstractions and interfaces, and instead having a bunch of #ifdefs here and there. Unit-tests and comments are not to be found. B…
> uses Bazel for builds Is this unanimously good? I've heard both praise and horror, never used it myself.
Earlier quoted context omitted.
They don't compete though. Google offers 17+GB free with email, office suite, unlimited photos, drive and Voice with a free number for unlimited calling and texting. Dropbox has much stricter bandwidth limits as well. For $9.99 you get all that plus 2TB storage with Google One. Dropbox has a minimum for of 3 users for their business plan, but with 1 user on G Suite for $12/mo I get unlimited storage and all the Goodi…
I'm learning to believe that there are various sub-sects of the HN crowd. The people who would rather pay $3/month to host a slow-ass VPS, and those where $10/month delta, as long as their work-flow is optimized is a "win". In fact, I think that drives a lot of these "what is better" debates in threads here. Some people go "Google Drive is better, because I get 2TB/month for a flat-fee that bundles the other services…
When you cost your business hundreds of $k/yr, who cares about $5-100? Thats less than the cost of the free coffee and snacks!
Earlier quoted context omitted.
> Push the proprietary version hard enough and I'll reconsider whether I even want to use the Open Source version Qt is pushing hard for commercial licensing (which I heard prevents you from using the open-source version), putting L/GPL FUD on their websites, and trying to track users of their installers more.
The model of "copyleft if your project is open, pay us if your project isn't open" is one where I have no problems or concerns, and will happily use the open version and recommend that people building something proprietary purchase a paid license. Nor will I typically worry about the motives or future of the project unless I have some other reason to. And the KDE Free Qt Foundation means I never have to worry about Q…
EDIT: I've just realized that I want a revenue-limited trial, rather than a time-limited one. I basically want the Prosperity license, but with the ability to say "you have to pay me if your company makes more than $100k in annual revenue". Is there a license like that?
I've emailed the License Zero people, hopefully they'll do something for that.
It's interesting almost no web server provides an easy way to deal with multi-tenant multi-domain architectures in a good way that includes automatic SSL. Caddy is the closest, but still not near enough. There is this small segment of the market that we operate in that requires thousands of TLS connected domains to be hosted behind a dynamic backend. It's services like Tumblr, Wordpress.com, or any other hosting serv…
https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL...
> A traditional problem with SSL in combination with name based virtual hosting has been that the SSL connection setup happens before the HTTP request. So at the moment lighttpd needs to send its certificate to the client, it does not know yet which domain the client will be requesting. This means it can only supply the default certificate (and use the corresponding key for encryption) and effectively, SSL can only be enabled for that default domain. There are a number of solutions to this problem, with varying levels of support by clients.
Then, the best approach seems to be the following:
> Server Name Indication (SNI) is a TLS extension to the TLS handshake that allows the client to send the name of the host it wants to contact. The server can then use this information to select the correct certificate.
Earlier quoted context omitted.
The subject of monetizing opensource software is a tricky one. Some companies pursue the Open-Core principle, others monetize through the consulting services or cloud infrastructures. As for investing into opensource, Dropbox is trying to do that when possible, for example we (along with Automattic) did sponsor HTTP/2 development in Nginx.
Personally I think that monetisation of open-source goes against the consumer of the OSS in practically all cases. - Open-Core::: Features are not added to core, as they want people to upgrade. - Consulting::: Ease of use is ignored, as if it's too easy people won't need consultants. - Sponsoring Goals::: Software is almost held at ransom, until goals are reached. The best way to help open-source software is to donat…
Also note that we’ll cover the open source version of the Nginx, not its commercial version with additional features. It always kills me when very successful companies don't buy software from other companies. I remember being at a lunch with a prospective client that really loved our technology. About 1/2 way through, he said he really would love to purchase our software, but the CEO doesn't allow them to use anythin…
So much of what happens in sufficiently large organizations has nothing to do with profit maximization. Think confederacy of dunces, not a conspiracy of greedy evil geniuses.
Also note that we’ll cover the open source version of the Nginx, not its commercial version with additional features. It always kills me when very successful companies don't buy software from other companies. I remember being at a lunch with a prospective client that really loved our technology. About 1/2 way through, he said he really would love to purchase our software, but the CEO doesn't allow them to use anythin…
I’m increasingly concerned about being screwed by non-OSS vendors. Imagine a use case like Slack. Say you have an employee that goes to visit a family member in Venezuela & connects to the company Slack. Slack has been given a mandate to terminate accounts for people in Venezuela by the Trump administration, and now your key employee is cut off from communication, or perhaps your Slack account gets flagged.
Also if your going to china take a disposable phone and a laptop that is clean ands can be wiped on return.
Earlier quoted context omitted.
I had to chuckle as well when I read that article and the part about gRPC. Seems like the pendulum is swinging into the other direction again - back to where we've already been ten or twenty years ago. New name of course, but same concepts. One really starts to feel old at such occasions.
It certainly does look like that. I do think though that we've learned a number of central lessons in the process: - treat messaging as a first class concept, not something to hide & abstract away. - do not attempt to implement polymorphism in a messaging protocol. Do not bind your messaging protocol to a programming language's type system (they serve different purposes). - bake fundamental monitoring & maintainabili…