Ask HN: Is Accidental Complexity Growing Faster Than Essential Complexity? - <AUTHOR> I've recently been involved with a few line-of-business projects recently that have been fairly successful. They all use well-honed agile principles, and they met the requirements that their Product Owners had of them, and by all measures were successful.
However, simultaneously, I'm seeing a great deal of technical complexity being introduced to systems: microservices and SPAs (with all the attendant web stack complexity) being the most common. A lot of it seems to be driven by a need for developers to keep their CVs shiny, or because smart developers want cool things to play with, or because of "Google envy". There seems to be very little engineering justification for these approaches in most cases, and technically simpler approaches would work better.
I've been thinking about Fred Brooke's Mythical Man Month, in which he described 2 forms of complexity: Accidental Complexity as being technical in nature, while Essential complexity relating to the problem domain, and being more intractable.
Although Essential complexity remains stubborn in business systems, I believe we are slowly getting to the point where it is being tamed through more responsive (agile) dev practices, leading to happier customers who get software that does what they expect. On the other hand, I feel that accidental complexity is exploding, and for the first time in my career, it is growing at a faster rate than essential complexity, and masking a lot of the gains we are getting from improved processes. Is this a fair observation, or am I just jaded? <comment><USER2> I work for a large company in the automotive space. I can say that most of the accidental complexity I see is related to shoe horning solutions into technologies that we happen to have licenses for as opposed to what is the simplest and most robust solution.

The kind of over-engineering for the CV polishing almost always comes from our college hires. It's not really their fault, as I understand the attraction to the shiniest object when your a newb. When their monstrosities are allowed to make it into production, however, is when you have a dev manager that doesn't really understand software engineering.

For my part, I used to scream from the mountain tops that we were over- engineering everything, but now I just let them fuck shit up cause I'm tired of trying to save people from themselves.

</comment><comment><USER3> Many companies have too many engineers (and some not enough). This is mainly due to #engineers = f1(revenue || vc money) while it should be #engineers = f2(problem). Mostly because our industry has no clue about f2 and so falls back to f1.

But this also works with business thinking, e.g. CEO thinking

techbudget = 0.1 * revenue

With the law of the used budget (all people always use up their budget of fear to not get the budget next year when they might need it), CTOs use the whole budget

#engineers = techbudget/salary

so f1 is often

#engineers = f1(revenue) = (revenue * 0.X - hosting - laptops - licenses)/ salary

and with salary >> hosting, salary >> laptops, licenses -> 0 due to open source usage,

f1(revenue) = revenue * 0.X / engineer salary

(the 0.X is determined by VC experience/push, negotiation between CEO and CTO, how much of a tech company the CEO sees his company or from his previous experience, most probably on a wholly different tech business model).

with no need to understand the tech challenge at hand.

For startups and high margin tech business, there is often a large tech budget, so many engineers are hired (also other forces like capability building, war of talents etc. - some startup CEO tell me their VC said they need to hire 100 engineers until the end of the year - this is without knowing anything about the tech problem at hand).

Coming to your point:

If there are too many engineers for the essential complexity they create accidental complexity.

<comment><USER4> A near optimal one is f2(x) = 5

:)

<comment><USER3> Most efficient is f2(x)=2 or f1(x)=1 I think, not sure yet :-)

<comment><USER5> I'd say 2 because code reviews are one of the rare "methodologies" that improve quality in my experience.

</comment></comment></comment></comment><comment><USER6> You'll enjoy these two videos from Alan Kay and Uncle Bob Martin, respectively:

"Is it really 'Complex'? Or did we just make it 'Complicated'?" \- [https://www.youtube.com/watch?v=ubaX1Smg6pY](https://www.youtube.com/watch?v=ubaX1Smg6pY)

"The Future of Programming" \- [https://www.youtube.com/watch?v=ecIWPzGEbFc&list=PLcr1-V2ySv...](https://www.youtube.com/watch?v=ecIWPzGEbFc&list=PLcr1-V2ySv4Tf_xSLj2MbQZr78fUVQAua)

</comment><comment><USER7> I honestly don't think it's any worse than it has been before. Back in my youth it was "components". If you can encapsulate functionality, then you should be able to compose it like tinker toys. So let's build these "reusable" components which act like black boxes. We'll nail up the API to the wall, and use some kind of versioning scheme to ensure that it's always backwards compatible. We can even build frameworks that standardise the communication between these black boxes and provide language agnostic object representations. Hell, we can even build database interfaces around that concept and pass business domain objects back and forth directly. And we can hide the complexity of the object-relation mapping in another framework.

Yeah, that will simplify _everything_ :-). It only looks shiny because the people doing it weren't around in the 90's to get sick of it the first time around. Ah... who am I kidding? 4GLs have been around since the 70's... :-P

<comment><USER8> Yes, but "components" as a concept _actually works_. Why do you think we keep seeing attempt after attempt to bring the concept into the browser UI ?

Software development with components as building blocks maps well to our mental model of how you build things and is extremely productive. Despite the amount of grief that drag and drop GUI builders receive for being too simple, not being explicit MVC, etc., you won't find a better way to allow new developers to learn how to use a tool and be immediately productive with smaller projects. The Delphi and Visual Studio IDEs had it 100% right in this regard. That's why you see so many LOB applications from the late 90's, early 2000's still kicking around that used Delphi's VCL/Visual Studio's WinForms. They got out of the way and allowed people with in-depth business knowledge to create _actual solutions_. In the long run, isn't that the most important measure ?

I will agree with you on ORMs, though. There's never been more of a case of "putting a square peg in a round hole". Sometimes, the best you can do with disparate systems is to just talk the language of the system that you're interfacing with and stop trying to make it be something that it isn't. Put another way: if your "avoidance" code ends up being 50% more complicated than your "direct" code, and prevents the developer from understanding _how_ the whole interaction occurs, then you've committed a grievous error in architecture. There are ways to make such interfacing easier without making it be completely different. For example, with SQL one of the most difficult things to deal with is result set binding/retrieval, and this was solved rather early on with classes/components that eliminated the complexity of doing so with APIs like ODBC. We should have stopped there.

<comment><USER7> Yeah, I'm not really arguing that it doesn't work. There are definitely use cases for it. The main thing is that the simplicity is a facade. Generally it's achieved by limiting scope. But as the scope creeps upwards, the complexity of the machinery starts to overtake the complexity of the problem. The biggest issue is that there is a considerable amount of technical lock-in. The solution is so specific that it becomes impossible to change your mind later in the project. Techniques like refactoring are impossible because you've already baked in the subsystem decomposition early, early in the process. The whole thing becomes a brittle mess. But for certain problems (or putting up a quick MVP that you might throw away later), it can be very useful. And as you said, it can be an excellent way to build projects of limited scope with people who are heavy on domain knowledge, but light on programming expertise.

<comment><USER8> There isn't anything intrinsic to the Visual Studio/WinForms or Delphi/VCL environments that prevents you from refactoring an application into a more structured manner as it grows. They simply don't shoehorn you into an enterprise development model for applications that don't require it (or don't require it initially). Thousands upon thousands of large business applications have been written in both, so obviously they were perfectly manageable for that purpose (2-tier, N-tier, web back-end). The point is to create reliable software that satisfies your business needs. One company that I'm familiar with built a beautiful application server/front-end UI in Delphi that uses SQL Server as the database server and serves 160+ concurrent users every day. The front-end UI was a ~16MB .exe, and the application server was a ~8MB .exe, both with no dependencies other than using Windows Vista or higher as the target OS. It was a very impressive application (I wish I had wrote it), and served the ~$45mil company very well.

</comment></comment></comment></comment><comment><USER9> It sounds to me like you are in a software company with a lot of inexperience.

I have seen people spin up massive map-reduce clusters to perform something AWK could do in half the time. And I have seen spend enormous amounts of time training neural nets for something a simple SVM could do. In both cases (and most similar cases I have seen) a lot of needless time and energy was expended.

But why? This is my hypothesis anyways...

There seems to be two primary pools of people who feed into the software engineering. Those from engineering disciplines and those from research disciplines. Engineering schools can be fairly cut throat; limiting the number of candidates who can move on at various stages, or designing courses to reduce the number of enrolled students. Those from research disciplines are required to create novel ideas which are worth publishing just to graduate their programs. And those that actually _like_ academia believe (and rightfully so) that creating new ideas is the way towards notoriety and success.

That means a lot of the craftsmen who would prefer making tiny refinements on well understood paradigms are simply weeded out from the discipline before they can even enter it.

I have known very smart people who quit engineering in college because they could simply not stand being in a room of people where everybody wanted to be the "smartest in the room".

Of course... the incessant CV polishing in Silicon Valley probably doesn't help either.

</comment><comment> d--b Well, a theory is that Agile is responsible for both. While its short devlopment cycles help deal with essential complexity (you understand better the customer's problem because you have more interaction with them), it also implies incremental coding which often increases the accidental complexity.

As an example:

After a short development cycle, you created a database schema where each Client class has a single address, and because it was done quickly, the address fields are in the same Client table.

In a second development cycle, your customer tells you that their clients may have one or more address and one of them is the primary. The quickest path to delivery is to keep the address in the Client table as the primary address, and add a secondary address table.

While short development cycles help in not screwing up large requirements, it also impairs our ability to see the larger picture, and cause us to take decisions that we need to undo afterwards.

<comment><USER10> that sounds more like a symptom of forgetting to include refactoring in your agile loop, than an inherent issue with small iterations.

<comment> d--b Yes, in this tiny example, it could be avoided by adding a simple refactor in your second iteration.

In general though, the customer may ask you some iteration that he doesn't realize imply a complete rewrite of the code. Like:

"now I want the same thing, but I want it available 24/7 with no downtime".

Or "Now we have a great text editor, we want to add live collaboration".

"You know what would be great: that we could see what changed between 2 versions of the spreadsheet".

<comment><USER10> true, and it's hard to work around unreasonable customer requirements. In the ideal circumstance you would have that conversation and explain that having 100% uptime guaranteed is basically impossible and aiming for e.g. 6-sigma uptime requires high ongoing costs - but I'm sure we've all experienced that "I can have it both ways" attitude.

</comment></comment></comment></comment><comment><USER11> I have noticed several developers deliberately introduce accidental complexity for the sake of job security. Just to make it really really hard for a new person to do any thing with it , they create a hostage situation where you have to do a full gut of his or her work and redo it. This is more evident in a situation where the teams are geographically distributed and the main team (typically in USA) feels insecure that their jobs are going to India or some other country where software maintenance is cheaper. The problem of accidental complexity is very serious for large enterprise software companies who have aging products typically on a Microsoft stack so those engineers who have spent a decade coding and maintaining it tend to be happy with a crooked way(hacks and workarounds - Undocumented of course) of doing things which gives them an unfair advantage. To conclude; accidental complexity is a political tool introduced by developers deliberately of reasons best known only to them

</comment><comment><USER12> It is easy to look at this from a functional and practical standpoint, take any program in your stack, and look at what it does vs what you need it to do.

There is a parallel to this where people were trying to where people write c++ programs in visual studio realize they often can do so without needing the microsoft visual studio runtime and its routines and their program drops from 68k to 2k and a dash of code to bring back what is missing in most cases, if it is even needed. [https://hero.handmade.network/forums/code- discussion/t/94](https://hero.handmade.network/forums/code-discussion/t/94)

I love looking at things and thinking about this, people in this field often find themselves over-implementing(or using software that is a source of over- implementation), setting up a tremendous amount of foundation to get a little thing done, getting carried away, and finding out it got too involved and over-engineered when there is a tight and simple solution that matches exactly what is needed.

Of course there are situations where microservices are still needed: [https://semaphoreci.com/blog/2017/03/21/cracking-monolith- fo...](https://semaphoreci.com/blog/2017/03/21/cracking-monolith-forces-that- call-for-microservices.html) Everything should be thought out and joining the latest craze isn't necessary. If you really need it, you will find yourself looking for or implementing the solution, regardless of what it is currently called, microservices have been around in one form or another before the hype, and used as needed when needed, instead of getting being used to wax a resume.

Your accidental vs essential comparison has real world monetary consequences. There are many examples that while it might take 2-3 months to stop and think and analyze what is going on instead of adding to the pile, you can save 100k-300k a month for even smaller scale deployments.

</comment><comment><USER13> I agree 100%. I'm beginning to feel a lot of 'developers' live in a circle jerk where they share about how awesome they are and other developers tell them how awesome they are, unless it makes the other 'geniuses', what many above-average intelligent people in my generation are told from a young age, feel too inferior.

Hubris is a real observable phenomenon in the history of economic bubbles, paradigm shifts in scientific/technologic progress, and in recent events in media, politics, and business.

We need to start questioning business-as-usual as much as possible. Everything can be simpler, less egocentric, and more beneficial to all parties.

</comment><comment><USER14> I've been working professionally in software for 20 years. Anecdotally, I'd say that line-of-business software has never been more reliable, more extensible or had better user interfaces than it does now.

</comment><comment><USER15> The _consequences_ of accidental complexity are now much greater because everything's more intertwined, and the systems as a whole, larger. This puts us in "Ghengis John" (John Boyd) territory, close to the point where we don't have enough attention to fix all the problems that arise, including from the fixes themselves. Probably you youngsters are actually better about not introducing complexity needlessly, since the consequences of doing so are ever more obvious.

</comment><comment><USER16> I'm just getting to the point in my career where I've seen this happen a couple times. I believe it's cyclical. OO came and complicated everything and that died down. WYSIWYGs came and complicated everything, those have died down. Huge frameworks came and complicated everything, and largely died down. SPAs and Microservices came and will soon die down. I think every few years of new blood introduces a critical mass of complexity.

<comment><USER17> Edit: I just checked the meaning of 'died down' and it means 'to reduce in strength' not 'to become literally dead'. So, my comment isn't really a correct response to the parent but I keep it here.

Do you really think all those concepts died? IMO, they aren't dead, they have been assimilated. We learned from OO and it's now a tool you can use almost everywhere when you need it. But we also learned to not try to model everything in an OO paradigm.

You can say the same thing for your other examples. You have a phase where the concept/techno is being seen as the silver bullet that will save us all. That brings a lot of adoption. People do mistakes. We (hopefully) learn from them. The hype fades away, concepts are consolidated and assimilated in stable and mainstream tools.

But that takes time. And I'm not sure how things could work differently. Don't we need the hyper-hype phase to experiment and learn about the concept/tech?

</comment></comment><comment><USER18> "... perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away ...", Antoine de Saint Exupéry

This is true for requirements but also for used technology.

</comment><comment><USER19> There have been various improvements in programming that reduce accidental complexity but they don't apply in every area. For example, Ruby on Rails makes it easier to create an MVP, but scaling an application to millions or billions of users will still require working on many layers of "accidental" complexity (since scaling isn't an inherent part of solving the problem). Running applications in the browser also adds "accidental" complexity since certain details of the product now need to be defined in both the browser and the server. Testing can also get more complicated as there are more layers and services interacting with each other. It seems as hardware and software improve, the demands on them increase as well. So we can't just relax and enjoy a world of Essential complexity.

Meanwhile as machine learning gets more advanced, it's able to tackle certain "essential complexity" problems that were supposed to always require hand- coding by a human programmer. So there are trends working in many different directions.

</comment><comment><USER20> I really can't address the issue of overuse of microservices in a line of business app type project, but I want to push back about little about "SPAs" being "accidental complexity" here. I imagine by "SPA" you're referring to the use of a JS framework like AngularJS, Backbone, EmberJS, React(and some type of models), etc.

While I agree that sometimes there is no need for these in a simple CRUD app, I'd also caution that depending on your basic needs (frontend validation, autosave, keyboard shortcuts, etc) and frequently, on more complex client requests (like for fast JS-driven form navigation that requires some sort of frontend routing, or to save to some industry-specific file format, and such), you can easily end up with a big spaghetti ball of JQuery if you're not careful.

I've seen these balls of tangled JS all too often in line of business apps, and they're a nightmare to maintain or modify. The point of using a framework is to provide some sort of organization for frontend JS, and to provide common features.

If your team has the maturity to organize their frontend JS into neat MVC/MVP apps without the use of a JS framework, great. But in my experience, few "full-stack" developers are comfortable enough and/or care enough about frontend JS to do this. Thus the use of frameworks.

If you need a very minimal framework, BackboneJS is both tiny and simple to use. Even Backbone can save simple apps like this a lot of grief.

The alternative to something like this is to stick to a full-stack framework like Ruby or Django and stay strictly in that environment/best practices. But even there you're bringing a lot of complexity into the picture, or sometimes you still end up needing some sort of organizing principle or framework for the frontend JS.

</comment><comment><USER21> > A lot of it seems to be driven by a need for developers to keep their CVs > shiny

This is immaturity, not a real need. The people who make the most money in tech aren't the ones with the most buzzwords on their resumes.

<comment><USER22> I wonder about that. Right now, I can pick up pretty much whatever tech is thrown at me. But any job demands that I have experience in this field or that field which is pretty frustrating tbh. "You don't have experience in this entire react stack? Bye!" oki... I'll look for backend dev? Oh right. Must be fullstack and must know all the JS frameworks.

Maybe devops/sysadmin/whatchamacallit? "Must know this particular NoSQL DB, and be able to administer Kubernetes clusters"

Fine I can kind of do that, but I have my doubts because I've never used said DB. And it goes on.

It's a deeper argument than what I just made, but my extreme other side point was just to highlight that the job market looks scary when you browse sites and realise you've only worked with pure js and jquery and no one wants that anymore. And then you see that they want people who've worked on real world apps using all this new tech.

There is eithe a real need or at least the illusion of a real need and I wouldn't discount that entirely. Somewhere in the middle, the answer probably lies.

<comment><USER23> People who post job ads where you can browse them usually don't understand the job they are hiring for, hence the checklists and keyword screens. So you need to find a way to get in touch with those on the inside who do know, and can make decisions. Hacker news ads are one way, maybe look at stack overflow, certainly look through your network for internal referrals, perhaps some meet ups.

Also I think one should not use the keyword stuffed resume when going through backchannels. Personally I discount them, and focus on resumes with a record of getting things done in a related field.

</comment></comment></comment><comment><USER24> It's always been a problem. Premature optimization may be the root of all evil, yeah, yeah, but that quote is sort of a waste of breath as premature optimization is not that big of a problem. Over engineering is the great disease of the software profession.

I suppose premature optimization is one source for it, but more common is premature generalization and excessive levels of abstraction. Other major sources include backward compatibility needs, the creation of virtual layers to escape calcified bad design, and of course the need to show off and look smart.

<comment><USER25> I'd say overengineering and premature optimization are nearly synonyms.

<comment><USER26> They're both bad, of course, but beyond that I'd say they're nearly antonyms. Premature optimization trades structure for performance, overengineering trades performance for structure.

You could argue for equivalence under a broader definition of optimization and engineering, but in the context of software engineering the more specific definitions used above seem to be fairly well established.

<comment><USER25> _Premature optimization trades structure for performance, overengineering trades performance for structure._

This makes them the converse of each other, but not antonyms. At any rate, I'm not sure I agree those terms are exclusive to this relation. There can be fast overengineering and slow PO.

</comment></comment></comment></comment><comment><USER3> Yes. This is one one of the most prevalent problems in engineering I see when consulting for startups.

</comment><comment><USER27> Are microservices more complex or less complex?

there's more operational complexity, because now you're running two things instead of one. But there's also less complexity in other areas, because parts of your code are firewalled off from each other, so you have a smaller problem space when making changes/fixing bugs.

I think that there's a tendency to view things that are harder to set up initially as more complex, when the long-term complexity might be lower. It mainly depends on what you think is important.

I think a lot of the difference in viewing complexity is due to difference in foundational knowledge. People doing Haskell see monads for DSLs as nice and easy abstraction, but people outside see it as a crutch, needed because of a lack of native effects in the language.

Some people see Javascript toolchains as needlessly complex, others see people using Javascript instead of <some compile to JS language with better abstractions> as needlessly complex.

Differentiating between what kind of complexity is brought is important. Because a team of people bad at operations shouldn't be rolling out a new service every week. But a team good at operations but bad at separation of concerns might gain a lot from being "forced" to chunk things out.

<comment><USER28> > _Are microservices more complex or less complex?_

I've long argued that microservices are a great way to reduce complexity; however, I had one project that I was involved in where microservices definitely _added_ complexity. You get it right that,

> _less complexity in other areas, because parts of your code are firewalled > off from each other, so you have a smaller problem space when making changes > /fixing bugs._

This is exactly right, and is exactly how microservices _should_ make things less complex: by limiting the surface area that needs to be inspected when issues arise.

Where microservice I was thinking of fell short (IMO), is that it received JSON structures on the wire, and essentially, those Mappings and Lists made it all the way down to the lowest layers of the code. Deep in the heart of the service, Mappings and Lists are constructed, bubbled all the way back out towards the HTTP handlers (being mutated all the way) and then finally serialized and put on the wire as JSON.

Obviously (or, at least, I hope) this is not good. At any point, all I know is that I have a Mapping or a List; I have no real idea what the semantic business _type_ of the thing is. (Unless it has a good variable name.) No validation (aside from it being JSON) is done, so if a structure is not well formed, that error isn't detected until such a time as it matters to the code (b/c something expects a String, and it isn't, for example), and everything grinds to a halt.

Couple a few of these together, and a badly formed JSON substructure can wind its way through _multiple_ services. This can make debugging hard as you can't attach to a single process and follow execution from inception to failure, and the problem now spans potentially multiple machines.

So, this makes me wonder if this is where all the vitrol for microservices comes from (I've never really heard a good argument against it) or if it's just a strawman. The above, of course, is a failure not of microservices, but of mostly input validation and an unwillingness to strongly type your parameters. (Mappings of Lists of Mappings of etc. count as "stringly typed" in my book.)

</comment></comment><comment><USER29> In regards to the SPAs, what exactly is the alternative?

In my mind you have two possibilities:

1\. The most ideal is to "pick the right solution for the problem." Meaning, you will analyze the problem and do the right thing, e.g. content mainly? server side rendering. web application? SPA.

2\. Do what you know, consistently. In many cases, this means using an SPA basically all of the time, whether or not it's necessary. This also might mean server side rendering all of the time, adding javascript only when absolutely necessary.

In regards to SPAs, I feel there must be a solution. Ember tries to do this with fastboot, allowing you to essentially have the flexibility of an SPA with the SEO and other advantages of serve side rendering, but I'll ignore that for now.

Is there a paradigm/language that allows you to write _the same_ templates for both the server side and SPA view? I guess this would mean the view is the same, and the model and controller would be your choice.

I think it's natural to just do what you know, which is why you're probably seeing what you are.

<comment><USER30> > Is there a paradigm/language that allows you to write the same templates for > both the server side and SPA view?

That's the main motivation behind my web framework Sandro. It is just an experiment, but I do just that!

See [https://bitbucket.org/aurelito/sandro](https://bitbucket.org/aurelito/sandro) and [https://bitbucket.org/aurelito/sandro- lib](https://bitbucket.org/aurelito/sandro-lib)

It uses rhino and domino to render server side using the DOM API. I am busy with work that pays my bills, but I would love if I were able to work full- time in it ;).

<comment><USER31> Server side rendering can be done with any JS framework, though often one must compromise performance by using a more heavyweight implementation like jsdom, or some custom implementation if the framework provides it.

Also I have done something similar using domino: [https://simulacra.js.org/#server-side- rendering](https://simulacra.js.org/#server-side-rendering)

</comment></comment></comment><comment><USER32> I believe it's a little bit of "column A" and a little bit of "column B".

On one hand it can feel maddening that a generation (or two) of young IT professionals have seemingly gone full-circle and tried all kinds of techniques only to end up leaning on tried-and-true technologies of the past (think: NoSQL vs ACID compliant relational DB's, Ruby/Python vs Elixir/Erlang, Flash/Flex - XML based design vs React/Javascript/HTML5/Canvas, Dynamic vs Strict typing, etc).

There has been a lot of re-inventing.

However, I think this had to happen. Many great ideas of the past were amazing ideas but they simply were before their time, not quite implemented well enough, we're too heavy/complex for the hardware at the time, and so-on.

Software has been moving too fast for the collective mind to keep up.

Maybe, in an ideal world, we would have methodically built up on the best of software from the 60's without wasting time and effort experimenting with new ideas. Honestly, that might have been awesome for productivity and the advancement of humanity as a whole. That's not how we seem to function as people, though. I can't help but think of "space travel" here (it sure didn't carry on exponentially from the moon landing ~50 years ago).

In my mind I believe this always happens with technology of any kind. It may be why we're discovering that ancient civilizations probably had much more interesting technology than we initially imagined. They simply has certain cycles where they "really hit a sweet spot" and other periods where it all became contrived.

On that note, if anyone has any suggestions for books about this subject please let me know. I know it's not an original thought and I'd bet there's been some interesting research.

</comment><comment><USER33> The software field is still very young, and there's lots of things we haven't explored yet. A great example of this exploration is the ongoing evolution of javascript from simple scripts to SPAs and a universal compile target. It seems like a lot of effort is being wasted (because it is), but it's similar to startups in the economy. Most efforts fail, but enough succeed that we end up in a better position overall.

The field may hit a point where there's an obvious standard way to build things, (e.g. most houses in the US are wood-framed with drywall because it's cheap an durable enough for most use cases), but this won't happen for a long time. We've had thousands of years to figure out how to build houses and roads, but software really only started in the second half of the last century.

<comment><AUTHOR> I'm all for learning and experimenting, but is it ethical to do it at the expense of paying customers (including employers) on business critical systems, without their explicit and informed consent?

</comment></comment><comment><USER20> Can you please cite some examples of this accidental complexity? I'm very curious to hear, if for nothing else than to avoid it if I agree that it's indeed accidental.

I do agree that because of the "GitHub resume" phenomenon, lots of devs are engaging in the type of engineering you describe.

<comment><USER34> OP mentions line of business apps. I may be presumptuous but that to me says (broadly) data entry forms and reporting.

Anything beyond HTML forms, a SQL database, and maybe a bit of Javascript and CSS is likely to be more complexity than you need for something like this.

<comment><USER3> Most companies I see, treat their problems as rocket engineering when in reality their startup is just a simple database frontend.

</comment></comment></comment><comment><USER35> > tamed through more responsive (agile) dev practices

Sure, for a given project, you can make it more or less complex by taking different approaches. But there's some lower bound on essential complexity and when the product itself requires a lot of features that interact in complex ways, your essential complexity is going to be high. And once the complexity gets too high, every new feature you add starts making future features even harder & slower to add. (A few caveats: 1. You can of course argue that it doesn't really "need" all those features, and everyone would be better off by sacrificing a little on the user experience to make it a lot less complex, less buggy, cheaper to build/maintain, etc. 2. By the time you run into these issues, the program is large enough that some accidental complexity has snuck in, and it can be hard to estimate how much of your problem is from that vs how much is from the essential complexity.)

Anyway, If a project never gets to that size where the essential complexity becomes unmanageable, then great. I'd agree it's probably a mistake to introduce extra complexity with microservices or anything else, and certainly some people make this mistake (or miscalculate whether their project will stay small and simple).

But if it does get to that point, some of these solutions you mention like microservices can be an independent, constant complexity cost. Ideally each microservice itself is a small app with manageable complexity. On the other hand, a naive, monolithic app will continue to have its essential complexity grow super-linearly with variables like time, lines of code, number of developers, etc. The bet is that by introducing the new thing, you can bring the overall complexity of the entire system down.

So my short answer would be "no" \- in many large projects, essential complexity is growing faster than accidental complexity. This has led to a proliferation of tools to help bring it under control, and yes, if you look at these tools in isolation they are pretty complex.

(And there are hundreds of billions of dollars worth of companies using these tools, if it is all just a waste of time then there's a massive business opportunity waiting for someone to undercut them)

</comment><comment><USER36> Yes.

Sort of.

One of the reasons for this is actually the success of both OOP and COTS/FOTS to provide us with workable reuse (just as Brooks predicted, by the way). Just about every GUI program reuses huge libraries of graphics and UI code, usually provided by the OS vendor. Every Rails app reuses significant functionality. We scoff at the huge dependency lists of programs, yet in some sense this is a sign of success: we no longer _have_ to rewrite all of this functionality from scratch like we used to.

However, we now have to glue all of this stuff together. With glue code. Lots and lots of glue code. Which is by definition accidental complexity. And which appears to be growing non-linearly.

So as is usually the case, our success in the last iteration (OOP/COTS) gets is to a new stage, and at this stage we face new problems that are a result of our previous success. In this case, I'd venture that the problem is that we don't really have a good approach to gluing these pieces together. Yes, we can do it, but we don't know how to do it well.

I think John Hughes in _Why Functional Programming Matters_ [1][2] hit the nail on the head when he said that we need new kinds of glue, and where FP has been successful I think it is largely because it provides one new type of glue: function composition. (He says two, but whether pervasive lazy evaluation is actually a good kind of glue is at best controversial).

 _Architectural Mismatch: Why Reuse is [still] so hard_ [3](1995)[4](2009) shows the general problem while _Programs = Data + Algorithms + Architecture: Consequences for Interactive Software Engineering_ shows that the problem is particularly pernicious in GUI programs, which are notoriously tricky.

For me, the solution is to make it possible to (a) use different types of glue within a program, (b) define your own kinds of 1st class glue and (c) adapt existing glue to your needs. I've built a language to enable this[6] and have been applying the ideas both in research and practice. So far it appears to be working.

[1] [http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html](http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html)

[2] [https://www.infoq.com/interviews/john-hughes- fp/](https://www.infoq.com/interviews/john-hughes-fp/)

[3] [http://www.cs.cmu.edu/afs/cs.cmu.edu/project/able/www/paper_...](http://www.cs.cmu.edu/afs/cs.cmu.edu/project/able/www/paper_abstracts/archmismatch- icse17.html)

[4] [http://repository.upenn.edu/cgi/viewcontent.cgi?article=1074...](http://repository.upenn.edu/cgi/viewcontent.cgi?article=1074&context=library_papers)

[5] [https://www.semanticscholar.org/paper/Programs-Data- Algorith...](https://www.semanticscholar.org/paper/Programs-Data-Algorithms- Architecture-Consequences-Chatty/ffa0b7c7182fd7f0577d774a4778a950abfec1cb)

[6] [http://objective.st](http://objective.st)

</comment><comment><USER22> Context intro to my answer: I'm come from a service economy. Much of what I've seen is from companies that go out there, get clients from various types of businesses - construction to finance - and create custom solutions for them that are then maintained by the same service companies. I've also seen a few product companies and I have worked with one for a year.

\---

After reflecting on this question, I feel like a good way to think about it might be this:

Companies are hitting extreme points right now. On the one hand you have companies that have stuck to their way of working for years. It worked, and in the process of getting customers and making the money come in, they never really thought to upgrade the company processes. After all, back in the day, tech moved at a much slower pace and that's what they are used to. There's been little to no incremental improvement in the technology or even the practices that have been used throughout the companies life. These types of companies still use FoxPro for ERP's, much much older Java enterprise tech stacks (and practices) for their server side stuff. I don't say that that's bad mind you. The ERP company has been around for over 25 years.

On the other hand you have the fresh companies started by people who really don't want to enter the juggernauts of the market. The establishment. Guided by the excitment that reaches us from Facebook listicles, and Techcrunch, they want to ride their own paths and build a fresh future. They want to go in and show businesses that the establishment is giving them "boring" and that they can do it better. I've met with lots of these people as well. Generally they'll start explaining their business by start from their tech stack. "We are a SME ERP business using react and a full JS based stack". That is not an exaggeration. That is near verbatim.

In between these companies you have the graduates who need to pick a side to go work in. And those that are entering the establishment, want to make their mark. Their impact. They walk into a company that is using SVN for their source code management, and they groan. They see Java being used and they say "why not NodeJS?". And what I've seen that happens, is that they run into the people of the establishment who have no interest in upgrading. Instead of having mentors who work with them towards incremental improvements where each improvement is justified by developer productivity and improvements to the customer they hear "what we have is good enough. Forget it". Or the more common "too much work. Don't bother". As a personal note, the latter really bugs me. Of course it's too much work. You've set it up to be too much work. But, what happens then is that some people will become the establishment, while the others will bide their time waiting for a greenfield project to come and for them to be given a PM role (mind you I see PM roles being handed out to people with almost no technical knowledge, little ability to evaluate tech or specs, after being in a company for 1.5 years). And when they get it, "LET'S DO NODE JS!!!!".

Oh and what of those graduates who left college to join the "entrepreneurs"?. They too have gone through university being taught web app development using "ASP MVC" and "Microsoft SQL" and they long to be let out into the world to play with the tech that they hear their peers are working with around the world. Admittedly, the Open source world of react and angular and what not is super exciting in terms of pace of announcements these days. And then they join their peers and everyone gets to feel excited that they are working with new things because they believe new must mean better.

\---

Ultimately the answer is yes. Accidental complexity is growing faster than essential complexity. Business practices change much slower than tech in today's world. I also feel like understanding the reasons behind it is worth pondering on.

For me, I feel that a lack of mentorship has a lot to do with things. There are far too few Uncle Bob's - veterans of the software industry who've kept pace with the change and understand things with a deep historical context - who lead architectural decisions and project management at a company. It doesn't even have to be Uncle Bob level veterans. But my observation of companies from where I am shows me very clearly that after 3-5 years of being in the industry, the deeper level constant learning vanishes. Which means that the older employees and the relatively new employees have stopped growing and the mentorship they provide is based on a tiny amount of work that they've done at some point in their life.

So to recap, we have people who've come out into the industry, fascinated by the flashy stuff (which is fine! That kind of youthful enthusiasm is also needed in the eco system). These people quickly make their way up to the management level within a couple of years, and then get to push the flashy stuff, and it doesn't go beyond there. Understanding the balance between tech decisions and what's required to solve the problem efficiently for the customer doesn't happen. And then these people guide the next generation which multiplies the effect.

From my POV and from where I live, this is the service industry today. Accidental complexity is a growing beast heading towards an exponential curve.

</comment><comment><USER37> I get your drift, mostly, but I'd say accidental complexity comes from forces more powerful than technical geekery: money.

I work at a fairly well known startup that has raised many tens of millions from VCs. Having raised this money we are now fully expected to hit quarterly numbers. In this pursuit we often end up adding random shit to the product or doing extra non-core shit to get a deal done. Product roadmap be damned.

Unless you have a principled and powerful (dictatorial, even) leader who can say "no, we should stick to our vision rather than introduce new tech debt" and enforce it through product and engineering, the accidental complexity will continue to pile on as selfish quota-carriers eat up all resources available to them.</comment>


Stock Photos That Don't Suck - <AUTHOR> https://medium.com/design-ux/62ae4bcbe01b <comment><USER2> Wikimedia Commons has a large set of curated, high-quality, free photographs: [https://commons.wikimedia.org/wiki/Commons:Featured_pictures](https://commons.wikimedia.org/wiki/Commons:Featured_pictures), [https://commons.wikimedia.org/wiki/Commons:Quality_images](https://commons.wikimedia.org/wiki/Commons:Quality_images).

There are also many, many gems among the 20+ million other free images at [https://commons.wikimedia.org](https://commons.wikimedia.org).

The site has an extensive category system that complements keyword-based search, e.g. [https://commons.wikimedia.org/wiki/Category:Fruit](https://commons.wikimedia.org/wiki/Category:Fruit).

<comment><USER3> note that a large portion of the wikimedia commons is licenced under some terms requiring at least attribution. Make sure you're checking the licence before you use images from the commons.

(not saying you shouldn't use wikimedia commons, it's a great resource. just don't use it blindly)

</comment></comment><comment><USER4> I have few issues with this post:

1 - The quality of images are not that good. Some are okay, but overall not that good.

2 - Many microstock sites have large volume of decent looking images and you can always find something decent.

3 - You end-up spending more time on these sites trying to find a decent image than you save money.

4 - Photography (quality) is arts and craft. Because of the higher supply the price have come down but they still need to make money.

5 - Model release? Just looking at one of the sites [1] one of the images had a photo of a skater [2]. I'm not sure if the skater had given a model release or not. But at least with more reputable stock sites you know there is always a model release required.

[1] [http://unsplash.com/](http://unsplash.com/)

[2] [https://s3.amazonaws.com/ooomf-com- files/7erBZvZMQ2mmuFQ10vc...](https://s3.amazonaws.com/ooomf-com- files/7erBZvZMQ2mmuFQ10vcA_IMGP4512.jpg)

edit: formatting

<comment><USER5> I thought in general the technical execution was quite good, but they tend to be over processed like 90% of all photography on the web.

> 3 - You end-up spending more time on these sites trying to find a decent > image than you save money.

This is the real kicker. I found the same with stock icons and vectors. You might get lucky with the free stuff but if you have any needs that aren't completely generic you are better off going to a paid side, spend $20, and save yourself a ton of time.

</comment></comment><comment><USER6> Looking at some of the links on this site to supposed "stock photos that don't suck".. they are just awful in quality. Many are underexposed, poorly composed & out of focus. Also some of those sites ask for an email address so they can spam me with few pics they select every week. I just want to find a pic today that I want not something sent to me what someone else wants. Just awful.

Having been an istockphoto photographer/contributor since 2005, I can tell you that to be an istockphoto or getty photographer/contributor the bar is high. You need to pass a photography test and every photo uploaded is scrutinized by pros so it doesn't suck. So that it's exposure, framing, quality etc is top notch. Therefore guaranteeing quality at a price.

If you want free photos, you have a better chance of finding ok photos on flickr. When you find one you like contact the photographer and ask if you can use their photo giving them credit on your site. Just be careful with faces in a photo. Sites like istockphoto force all photographers to sign a Model Release form which means no surprises for the people appearing in a photo.

</comment><comment><USER7> Unfortunately, free stock photos do suck.

I've known about unsplash and most of the other resources for a while. This weekend I needed to find some images for a landing page I was creating.

The photos you find on websites like death to the stock photo are better quality than most pictures any of us will take. They also have that hipster feel that a lot of start-ups go for with their visual communication. The problem, as semerda has already mentioned is that you have to wait periods at a time to get a small collection of photos. Unless you are extremely lucky, none of those photos will match what you require.

The other problem is that ostensibly, photographs with people and face convert far better than images of landscapes or abstract imagery, which is what most of these websites provide. If they do happen to have people then the uncertainty of release is in question (again, already mentioned in this thread).

Searching for good photographs is really hard. Especially if you don't want to lax your visual requirements. I ended up spending 4 hours searching for a good image to use on Fotolia, a professional paid-for service. If I stuck to free services, I'd still be searching.

What DOES suck about stock photography is understanding the licensing with paid-for sites. A lot of it seems riddled with ambiguity and legalese. For instance, the photos I paid for yesterday - I downloaded them but wasn't asked to provide a domain. Should I be expecting a copyright infringement notice when their bots scan my website? I'll then have to prove I bought the license to use that image. A bit of an inconvenience and sometimes a scary affair.

Another thing that sucks is the ubiquity of white people in stock images. Being in South Africa, and trying to serve the South African market as my primary market, I wanted to find great photos of black people. I'll tell you, it's not easy. Also, comparing about 100 photos, I can anecdotally say that images of black people usually cost less credits than those of white people.

What I do think they are great for is imagery to use for blog posts. I often use them [1] for blog posts that I write. Just shell out some money for paid photography if you're serious about using photos properly.

[1] [http://blog.mybema.com/2014/04/10/improving-Mybema-test- suit...](http://blog.mybema.com/2014/04/10/improving-Mybema-test-suite-time- by-53-percent/)

<comment><USER5> They also tend to be tagged poorly while on the paid sites the owners are highly incented to properly tag the pictures to increase search hits.

</comment></comment><comment><USER8> Resembles an older post by Dustin Senos with almost the same list and the title.

[https://medium.com/design-ux/62ae4bcbe01b](https://medium.com/design- ux/62ae4bcbe01b)

<comment><USER9> Uh oh. It really does look like [1] is ripping off [2]. They've reordered the list a bit and added a couple.

If all other things were equal, [1] might be slightly more substantive. But not if they ripped off another post. HN has a strong bias in favor of original sources (and simple fairness!) so I think we'd better change the url. If anyone wants to make a case for the opposite, we can always change it back.

[1] [http://designrope.com/design/find-stock-photos-dont- suck/](http://designrope.com/design/find-stock-photos-dont-suck/)

[2] [https://medium.com/design-ux/62ae4bcbe01b](https://medium.com/design- ux/62ae4bcbe01b)

Edit: there is other, much more obvious blogspam at [1], so I think this is the right call. Thanks dirtyaura.

</comment></comment><comment><USER10> I watch TV and I believe that the ethnic mix of people on TV (in the UK) is fairly representative of the mix you would find on the train going in and out of London.

I look at marketing material prepared with stock images and fashion catalogues. What do I see? Lots of white faces. Maybe there is a picture in there somewhere of some black girl playing with young Tarquin (who is obviously white). The word 'tokenism' springs to mind.

I don't believe most people care less about what colour people are, however, if you use a lot of stock photography, step back, look at the body of your work and wonder why all the faces are white. It happens. Sometimes all the images that are supplied are of white people, yet you may not notice this until, for some random reason, you get a person of colour showing up. Then the '98% white' trend is revealed.

The thing is that not everyone wants to be white. People might want to be young, thin, beautiful, with a full head of well groomed hair - that is aspirational. So you can keep the old, fat and ugly people out of the marketing material - that is fine. But to consciously or otherwise end up with only white faces is where TV was more than a generation ago. We should have moved on, perhaps even more so than TV as the internets is global rather than parochial.

<comment><USER11> I don't see why young faces everywhere is all right. Racism is horrible, _and so is ageism_.

Nobody is physically young forever and you can't help that - being young is definitely _not_ aspirational (and neither is a head full of hair, by the way). You can't work hard and "earn" your youth, or "earn" your hair. Physical fitness is another thing though, and a person doesn't have to look young in order to look healthy and attractive.

<comment><USER12> I don't understand the outcry at "ageism" in advertising. The point of advertising is to address your _target audience_ , not _everyone_.

The vast majority of products simply do not cater to every demographic. Racism might at least be reasonably considered inappropriate unless you're marketing a product that specifically targets some races and not others, but ageism? It's highly likely that whatever it is you're advertising does have a well- defined audience in terms of age.

This is just another rung on the political correctness ladder. Expecting everyone to include every possible demographic in every conceivable advertising campaign is idiotic.

Making it about "what people want to be" (from GP) misses the point as well. If you're not aiming your advertising at your target demographics, you are failing either yourself or your client. That's not discrimination; it's business. Discrimination is "you're not pretty, you don't get a discount or aren't allowed to use this service."

<comment><USER13> If it's just about target audience, then I wonder why all these companies seem to target detergents / toothpaste / toilet paper exclusively to 25 year olds...

<comment><USER14> In addition to the habit-forming age (if cigarette users are aged 16-60, rational advertising would target 16, not 60), a point is that you don't show your target audience as they _are_ , but you show your target audience as they _wish to be_.

If you target average 65 year old women, then you show gray-haired above- average-health 55-year women.

If you target average 45 year old men, then you show slim (but not too slim) fit (but not too fit) 38 year old men - that might plausibly be average 45 year old men, but are very much skewed towards the idealized goal.

If you target very overweight people, then you show people that are visibly overweight, but particularly good looking for that weight.

That's what works best, that's how homo sapiens are most receptive to be influenced.

</comment></comment></comment></comment></comment><comment><USER15> I wouldn't say that a photo like [0] sucks any less than something like [1] at all. In fact the images listed on [http://littlevisuals.co/](http://littlevisuals.co/) are just plain bad imho.

The only difference I see is that the images listed in this article come with 'filters' already applied. I think for most use cases this is actually a negative; I would never consider using an image like that for something serious - it comes off as really cheesy, even more-so than the shutterstock photos. At least with those I am in control of the post-processing.

[0] [http://designrope.com/wp-content/uploads/2014/04/stock- photo...](http://designrope.com/wp-content/uploads/2014/04/stock-photo- hero-1000x600.jpg)

[1] [http://image.shutterstock.com/display_pic_with_logo/637321/1...](http://image.shutterstock.com/display_pic_with_logo/637321/104276468/stock- photo-winter-landscape-in-the-matterhorn-104276468.jpg)

<comment><USER16> I would like to point out that you are assuming the person using these photos is able to post-process in such a way as to make them more presentable for their purpose. For many people this is not the case - they don't actually know how to make the images better. I would argue that for them, these kinds of sites are a great benefit and make their lives much easier (and cheaper).

Secondly, using one photo from each is hardly representative of the whole. Many of the simple stock photos that are found can be rather cheesy.

</comment></comment><comment><USER17> I built a search engine for flickr CC images. Most of them require attribution (the license is up to the photographer).

Flickr's search is not perfect (it is based on "interestingness" over relevance), but after a page or two typically the results are passable.

It provides some nice default attribution HTML. Basically I was just scratching my own itch. YMMV.

[http://imager.io/](http://imager.io/)

<comment><USER18> This is really neat thanks for sharing.

</comment></comment><comment><USER19> I've always wondered what the copyright law was surrounding these sites.

These sites get submissions from artists who are granting them a license to distribute and offer these images royalty free. Great.

But what if an artist uploads an image to which they don't actually own the copyright. I presume that these sites are protected under copyright laws because they're not liable for content distributed on their networks but what happens to the person who used the image? I understand that they wouldn't be protected and still be liable.

<comment><USER20> Well, the site would have to react to any DMCA takedown notices immediately, but wouldn't be liable for any infringement (so-called "safe harbor" rule).

But you ask a very good question with regards to the spread from there. I suppose, as long as you complied with an cease-and-desist orders, you'd be demonstrating a good-faith ... aaah, I'm just throwing words at a screen now. I'm not a lawyer. The law is often arbitrary and confusing from my perspective.

 _Caveat emptor_ seems to always be on order.

<comment><USER21> > _but wouldn 't be liable for any infringement_ //

You're apparently assuming the sites are all hosted in USA, not an entirely terrible assumption. [Though there is a similar Electronic Commerce Directive in Europe and probably other similar laws in other jurisdictions]

As I understand it DMCA Safe Harbour is for sites where they transmit media without interaction, users upload but the site is there to simply serve the media. If the site were selling the media (direct financial benefit) or offering a commercial license for it then Safe Harbour doesn't seem valid? Applying a license would possibly be considered transformative? Similarly if the site is selecting the images to meet their requirements - using a [partially] manual method then it seems DMCA Safe Harbour wouldn't cover it.

Similarly IANAL.

\---

[http://www.law.cornell.edu/uscode/text/17/512](http://www.law.cornell.edu/uscode/text/17/512)

</comment></comment></comment><comment><USER22> A surprisingly good list. I expected the usual CC galleries on Flickr or elsewhere, or Getty Images' new (and free) embedding option.

As mentioned by someone else, I don't get the "photos sent to you weekly/monthly" sites. Why? I can't picture (har har) someone needing a photo for some design, but thinking "Welp, nothing good on the web... I'll wait to see what comes along next week." Unless it's just aimed at photography enthusiasts who enjoy seeing beautiful photos, with no intent to use them for something.

I'll also add that if you're looking to add photos to your content, consider being different and using a funny cartoon drawing instead, like Jason Cohen, 42Floors, and others have been doing. Here's a stock cartoon site I created just for that purpose: [https://www.gagcartoons.com](https://www.gagcartoons.com)

<comment><USER23> Totally agree about the weekly emails. Unless I was using stock photography all the time (in which case I'm less likely to need the free ones) this would be no use. I was searching urgently for a good free stock photo a while ago and these sites just made me screw my face up.

To make matters worse, there doesn't even appear to be any way to get the back-catalogue of most of these sites. Death to Stock gives you a collection of photos when you sign up, but it's just 10 sample images.

Very confusing.

<comment><USER24> Probably the avenue for monetization would be access to the back catalogues. Which in turn eliminates the free part of free stock photography.

While this may seem ludicrous (eliminating the appeal of your _free_ stock photos over paid ones) this is common practice after a series of emails looking to elaborate on this point with a few of the services.

<comment><USER23> The whole thing seems a bit flimsy to me though: (1) Don't provide free stock photos at the time that people want them. (2) Later doe provide stock photos at the time that people want them, but no longer for free. (3) Profit!

</comment></comment></comment></comment><comment><USER25> The thing is, I don't want to receive stock photos daily/monthly. I want to be able to search through stock photos to find RELEVANT ones to my needs. When I need them.

I mostly use flickr and check creative commons and all the right radioboxes in the search. But yeah most of the time they suck.

</comment><comment><USER26> Ha, I had just put up my launch page [0] yesterday using the blue mountain image. It was kind of weird to see it on top.

This article seems directly copied from this medium post [1] I found a while back, except for the addition of paid stock photo sites.

[0] [http://www.wanderdash.com/](http://www.wanderdash.com/) [1] [https://medium.com/great-reading-for-startup- founders/62ae4b...](https://medium.com/great-reading-for-startup- founders/62ae4bcbe01b)

<comment><USER9> Yes. [https://news.ycombinator.com/item?id=7615179](https://news.ycombinator.com/item?id=7615179)

</comment></comment><comment><USER20> I think the key thing is to not underestimate what you can use for imagery. It's just not necessary to have people standing around a conference room table with a Cisco phone in the middle that they're all leaning towards (except Carl in the back, dammit Carl) when talking about business services.

From all of the things I've ever read or written, nobody cared what the pictures were, unless the pictures were explicitly diagrams or illustrations. Otherwise, it was almost white noise.

I say "almost" because, apparently, they still want for a picture, any picture, in the slot. I don't get it, what is the point of having a picture if the reader never shows a discernable reaction to the content of the picture. But you need to have a picture there. It could be a picture of a pie. It could be a picture of your city's skyline. It could even be a cat (actually, it probably should be a cat, you will probably get more hits). But A) it needs to be there, and B) it doesn't matter what it is.

For that reason, I have a strict "no purchase stock photography" rule. I have in the past, and it just wasn't worth the money. I can throw together what I need in so little time that it's not worth the money. And I'm not a graphic designer, this is just how unimportant the content of the image is.

</comment><comment><USER27> A newly discovered favorite of mine is [http://stocksy.com](http://stocksy.com) \- As far as I know it's invite only and/or has a pretty strict approval process for photographers that want to sell on their site. From what I've seen, the quality is often higher than your typical iStock. It's probably a little more expensive than iStock, but nowhere near the cost of Getty where you can spend several hundred to thousands of dollars per photo. The biggest downsides I've noticed so far is that their search/refinement filters are not the best, and they don't have the quantity that other larger stock photo sites do.

Here's an example:

[http://www.istockphoto.com/search/text/business/filetypes/ph...](http://www.istockphoto.com/search/text/business/filetypes/photos,illustrations,video/source/basic#127b0cd9)

vs.

[http://www.stocksy.com/search?src=head&text=business](http://www.stocksy.com/search?src=head&text=business)

</comment><comment><USER28> "Ethnic people around whiteboard, discussing important business things" \-- artist unknown

</comment><comment><USER29> sxc.hu which recently changed to [http://www.freeimages.com/](http://www.freeimages.com/) has a decentish collection. been using it for years when quality isn't _too_ important.

but i tend to use photodune.com for anything a bit more serious, the images vary from $1 to $5, and they have many to choose from. But if they don't have anything good enough then its over to istockphoto.

of course there is also the getty embed thing they announced a while ago ([http://www.gettyimages.com/Creative/Frontdoor/embed](http://www.gettyimages.com/Creative/Frontdoor/embed)) which might be handy if you just want small blog content.

</comment><comment><USER30> Alternatively, if you want to search for a more specific image, this is pretty convenient: [http://nuggety.com/u/nuggety/top-image-search- engines](http://nuggety.com/u/nuggety/top-image-search-engines)

</comment><comment> bjelkeman-again One of the things which we decided when started up was to not use any stock photography. I think we have mostly managed. Instead we focused on taking a lot of pictures. It feels to us, and we hear a lot from others, that it gives a genuine voice to our comms work. Which is really important for us. The photography is spread over a number of Flickr accounts, but we know where it is.

My colleague Mark has a bunch of it: [https://www.flickr.com/photos/charmermrk/collections/7215760...](https://www.flickr.com/photos/charmermrk/collections/72157606663649266/)

</comment><comment><USER31> The photos from deathtothestockphoto look decent, but I see no central place to search through them. You can only get them by email. Their Instagram feed only has 46 photos. The rest of these look like the usual generic photos.

However, it is refreshing finally find some sites that actually offer free photos. Most sites that pop up in a Google search have a few free ones, then billions of affiliate links to Shutterstock. Nothing against Shutterstock, but it does get frustrating to search for free images and constantly end up on a page requesting payment.

</comment><comment><USER32> Not free, but high quality and much cheaper than shutterstock etc: [http://yaymicro.com/view.action](http://yaymicro.com/view.action)

<comment><USER33> Thanks for recommending yaymicro. Glad you like it. I work for the company behind yaymicro.com. They just launched a new subscription service. Yayimages.com is "spotify for stock photos". The idea is that you can stream unlimited images (the same 4 million+ images as yaymicro) for $10/mo. Just wanted to share with you guys and hopefully get some HN feedback.

<comment><USER34> "They" Are you working for Yaymicro or not?

<comment><USER33> Yes, I am working for them part-time. Let me know what you think about the service if you try it. Would love some feedback.

<comment><USER34> Say hi to Oddbjørn :)

</comment></comment></comment></comment></comment><comment><USER35> Not free, but I've found that [http://photodune.net](http://photodune.net) has good stock photos that aren't too expensive ($1-$5 per image and usually the $1 or $2 image is large enough for a website). They are much cheaper than istockphoto, and they are priced in dollars, not credits, and they allow you to buy a single photo without subscribing to a monthly plan, buying lots of credits in bulk, etc.

</comment><comment><USER36> Cool. Several were new to me. Here's another good one: [http://www.morguefile.com/](http://www.morguefile.com/)

</comment><comment><USER37> Here is the original article that I assume this Medium post was based on. Seeing as they essentially share the same title. [http://designrope.com/design/find-stock-photos-dont- suck/](http://designrope.com/design/find-stock-photos-dont-suck/)

</comment><comment><USER38> Not free, but Dollar Photo Club (www.dollarphotoclub.com) seems to be one of the more cost-effective offers I've come across in recent months. Certainly cost-effective for anyone requiring a steady stream of stock photos for blogging or some other purpose.

</comment><comment><USER39> I created [http://picmint.io](http://picmint.io) just as a place to keep photos I have taken that may come in handy for projects and as a way to tinker with IFTT. Free for anyone to use if you see something you like.

</comment><comment><USER40> I'm surprised 500px wasn't on this list.

<comment><USER41> specifically [https://prime.500px.com](https://prime.500px.com)

</comment></comment><comment><USER42> Anyone know of a clip-art (non-photo illustration) version of this list?

<comment><USER36> Try openclipart.org.

</comment></comment><comment><USER43> Placeit.net

</comment><comment><USER44> This post has been getting a lot of mileage on both HN and layervault. Perhaps disproportionately.

<comment><USER45> I was surprised, when I finally clicked through after the link stayed on the front page for several hours, to find what looked like a link sharing site. Basically just an ad and nothing more? Why would people unvote an ad?

dang mentioned the voting ring detector recently, I wonder if there might be some of that going on here?

</comment></comment><comment><USER46> Stock photos suck by definition. They give an unrealistic and overly edited/positioned view of reality. If you are using stock photos, you are in line with infomercials and false claims.</comment>


Does malloc lazily create the backing pages for an allocation on Linux? (2009) - <AUTHOR> https://stackoverflow.com/questions/911860/does-malloc-lazily-create-the-backing-pages-for-an-allocation-on-linux-and-othe <comment><USER2> it'll call mmap (probably), which will then find 1GB(+ overhead) of contiguous address space

mmap will go and create the page table mappings (entries) for that address space (~262144 of them with 4k pages)

unless someone's been messing with overcommit: the physical memory allocation is normally lazy

this is done by setting the "faulted" bit on the allocated page table entries

when the application first reads/writes from a page not yet allocated: a fault will occur, the kernel will step in, (hopefully) find an unused physical 4kb of memory, update the page table entry to point to it, unmark the faulted bit, then return to the application (which will be blissfully unaware that anything happened)

<comment><USER3> > it'll call mmap (probably), which will then find 1GB(+ overhead) of > contiguous address space

It does. Last time I dug into that I think there was a 128KB threshold. Smaller allocations would use sbrk while larger once would use mmap.

<comment><USER4> The limit is now dynamic on glibc: [https://sourceware.org/glibc/wiki/MallocInternals#Malloc_Alg...](https://sourceware.org/glibc/wiki/MallocInternals#Malloc_Algorithm), [http://man7.org/linux/man- pages/man3/mallopt.3.html](http://man7.org/linux/man- pages/man3/mallopt.3.html)

</comment></comment></comment><comment><USER5> Suppose you WANT malloc to be eager (i.e. make sure all the pages are committed right away, so you don't pay a performance penalty for it later), what do you do?

The obvious answer is just looping through it and setting it to zero would be replaced with a call to `calloc` by an optimizing compiler, and doesn't calloc also do some kind of similar "lazy" trick? So what do you do? Mark the pointer as volatile and loop through it and set all the memory to 0 (or some other value)? Call memset, I guess?

EDIT: apparently malloc + memset compiles to calloc as well [0], so if you want to allocate, zero out memory, and make sure it's committed, using volatile seems like the best bet to me...

[0]: [https://godbolt.org/z/qhaaYc](https://godbolt.org/z/qhaaYc)

<comment><USER6> First of all, you only need to touch a single byte of each page to populate it. Besides, this approach doesn't ensure that the backing pages is allocated, for it's (technically) legal to only allocate one physical zero page after the calloc.

Therefore, you must use OS-dependent primitives to force eager allocation. On linux this can be achieved by two flags for mmap: MAP_POPULATE initializes the page table entries eagerly (but doesn't guarantee a backing store allocation), and MAP_LOCKED for touching all pages (just like the calloc, but at kernel level and more deterministic). Note that MAP_LOCKED doesn't raise error for touching errors due to low memory, so you still need to touch it again at user-level.

<comment><USER5> Why wouldn't the "volatile" approach be valid? I mean, the only way to guarantee that you can write to memory without error (or to make sure it's backed by actual memory pages) is to actually write to it, and the way to guarantee you're doing that in a platform independent way in C is to use volatile, right?

Are you really saying that this is not possible with malloc, you have to drop down to platform-dependent system calls like mmap?

<comment><USER7> Because it's legal for a platform to perform page deduplication as long as from the perspective of the program the correct operating model is followed, many operating systems (including Linux) have a "zero page" that is used for _all_ zeroed memory blocks in the system. Writing a non zero value then would replace it with a different page.

This means that writing zero is unlikely to cause a real allocation to occur. Writing a non zero value may be more likely to cause a page allocation.

That said: it can be entirely legal for a platform to do more page deduplication than just special casing the zero page. Linux has some kernel tooling called KSM (kernel same page merging).

</comment></comment></comment></comment><comment><USER8> malloc() is a C (and C++) Standard Library function that you could write user- level code for yourself (in fact, there's an extended exercise in TCPL to do just that). It doesn't do the low-level handling of pages - that's down to the Linux kernel.

<comment><USER9> But that malloc is implemented in C lib doesn't mean that the question and the answers are wrong. Eventually system specific calls have to occur. The question is very specific, asking what happens in Linux when one makes a malloc call requesting a big allocation:

"does it actually create 1 GiB worth of swap pages? Or does it mprotect the address range and create the pages when you actually touch them like mmap does?"

And how it is implemented can be seen, as an example, here:

[https://sources.debian.org/src/glibc/2.28-10/malloc/malloc.c...](https://sources.debian.org/src/glibc/2.28-10/malloc/malloc.c/)

Note both mprotect and mmap references.

<comment><USER10> The question is only semi-specific and the result depends on a ton of variables, like: which libc do you use; which kernel (maybe a patched linux kernel like on Android, don't know if they change anything regarding memory alloc though) kernel configuration do you use (esp. in regard with overcommit), do you have any other additional tuning, etc.

> does it actually create 1 GiB worth of swap pages

Create? No; probably never.

> does it mprotect the address range and create the pages when you actually > touch them like mmap does?

Both mmap and mprotect are syscalls, and syscalls do not (directly) call other syscalls. So mmap does not do that. And malloc can't because it does not run anymore after it has returned.

On top of all of that, malloc(insanely_big_value) can still fail immediately by returning NULL even if you have overcommit activated. Granted, 1GB is probably never an "insanely_big_value"? Not even sure on 32 bits systems though.

<comment><USER9> Asking "in Linux" obviously didn't mean "on Android" and also not "in Linux after I patch the kernel configuration."

The question was clear, the answer on the site was clear, by the answer here to which I responded was by somebody who I suspect simply hasn't read what was written there.

</comment></comment></comment></comment><comment><USER11> Is this why when I create an encrypted RAM drive that Linux shits itself? I assume that it should not fill itself up yet it does almost instantly and brings the system, down to its knees.

<comment><USER12> No.</comment></comment>


IRC necromancy - <AUTHOR> https://virtuallyfun.com/2017/11/18/irc-necromancy/ <comment><USER2> XDCC original author here. Nice to read this kind of stuff!

<comment><USER3> Thank you! I've downloaded so much stuff via XDCC that wasn't available in torrent form, or even sold anywhere.

</comment></comment><comment><USER4> Oh, memories. We also made a lightweight channel service to take the load off of Q. I think it was a little before newserv came into production. We designed it over generous amounts of whisky in a suburb to Stockholm. It's on github ([https://github.com/quakenet/lightweight](https://github.com/quakenet/lightweight)).

<comment><USER5> For trivia, which suburb?

<comment><USER4> Sorry, I honestly can't remember. I'm pretty sure I was drinking Chivas Regal though.

</comment></comment></comment><comment><USER6> I think the author, Neozeed, is the person back in the day when I asked them to teach me how to "hack", they instead taught me what telnet was and that there was a larger network beyond AOL. It lead me to what I am today. Thanks.

<comment><USER7> Unixgod? Lol long long time ago. ...

But I'm just hosting this post, it's not mine. The rest of the blog ramblings are.

<comment><USER6> It was SOOOO Long ago I don't even remember my handle back then. That was a long time ago. What are you up to now?

<comment><USER7> Changed jobs a few times, changed cities, then continents and then finally settled down. But I'm much older than you!

Started a blog over 10 years ago as a place to record my crazy experiments and to remember obsolete stuff. Not that I think many people care about ancient Unix, Novell or OS/2... I never really have much time to go back to the old chat.taucher.net thing... With the wife / kids / work it's hard to find the time.

<comment><USER6> Can I just email you through your site? Is there contact info there?

<comment><USER7> I have a really unique email..

Neozeed .AT. gmail.com

When Gmail went public I thought we were all doing aliases, meanwhile everyone went with real names for some reason. And some Australian football player with the same name and his rabid fans grabbed all the variations of mine... Oh well.

</comment></comment></comment></comment></comment></comment><comment><USER8> irc is so useful that i cant believe it is dying, and aside from freenode perhaps even dead.

so what killed the IRC? its not like theres any other alternative out there. slack seems to come close but its still very different and for a different purpose.

<comment><USER9> Discord, overwhelmingly.

Every IRC community I used to be a part of even a year ago has made the jump. It's just more convenient for all concerned- the only holdouts are people clinging to their CLIs and people objecting for ideological reasons.

I wish it hadn't come to this, but IRC's just stagnated for too long. The barrier to entry's too high, using it on mobile devices is a chore, the feature set's extremely limited, etc. Had IRCv3 managed to get off the ground and made some strides towards creating a modern user experience maybe two years ago, Discord wouldn't have had such a vulnerable market open for it to stroll in and snatch up.

Discord provides seamless cloud message logging, mobile notifications, intuitive clients, a huge ecosystem of easy-to-use bots, and integration with games that just works without the user having to set anything up. Even non- gaming-related communities have been switching to it for convenience's sake.

<comment><USER10> > The barrier to entry's too high

I don't understand this statement. One finds IRC clients everywhere. One literally has to know just one command at the beginning: /join. And then if you Google "IRC commands" or something like that, you get the rest of them easily (if your client lacks in the _help_ area).

> the feature set's extremely limited

I don't understand this mindset. Why should a program have an extra-large set of features? Is the value of a program measured by the number of features it has?

> Had IRCv3 managed to get off the ground and made some strides towards > creating a modern user experience maybe two years ago, Discord wouldn't have > had such a vulnerable market open for it to stroll in and snatch up

Apples and oranges. Discord did have serious opponents named Teamspeak, Skype, Mumble and other VOIP clients - but certainly not IRC. And if my memory serves, the first thing they did was to make sure to dislodge those programs from the gamers community.

<comment><USER11> I've been a software engineer for several years now and I still have trouble with MiRC and Adium. I tried Irssi and eventually gave up with it. The problem with IRC is that even the "simple" clients never just work. There's always some little infuriating quirks that you have to dive super deep into configs to figure out if it's even possible to resolve without some sort of PR to the repository.

<comment><USER12> These kinds of comments almost make me not want to live on this Earth any more.

<comment><USER10> Most comments really just say:

 _" IRC is like email. An old boring tool that just does its job. I'm not having fun with it, I'm not feeling special when using, so I need a 'modern' alternative."_

<comment><USER13> I don't think what these comments are saying at all. IRC didn't do it's job well, that's why it was replaced.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> I'm also known as MadHacker, and I'm the original author of one of the other Q variants on the list (Q3). It's good to see people still interested in the history of IRC, especially as it seems to be slowly dying, sadly. I've spoken to the author about the various sets of source code for QuakeNet's services, but the versions linked are the best we can find just now. If there's anyone out there with old copies of any of the Q variants, it'd be good to hear from you. \-- MadHacker@quakenet

</comment><comment><USER15> More like "IRC bot archeology".

<comment><USER16> Perhaps, but it's a network services bot, which is very much a part of most IRC networks. Did you know they connect to the network as a server, not as a regular client like most irc bots?

</comment></comment><comment><USER17> I love trips down the memory lane to, what I call "the old internet" (before facebook etc), like this.

I also had to check if "my" bot was involved somehow. I wrote a C-bot called VladBot in the early 90's, stopped working on it somewhere in '97 but it's seen all kinds of reincarnations (good and bad) since then.

</comment><comment><USER18>
      # Appears as ANNA

</comment><comment><USER19> XKCD has cool comic[1] about IRC.

[1] [https://xkcd.com/1782/](https://xkcd.com/1782/)</comment>


How much should I offer for a 5-letter URL? - <AUTHOR>

My start-up came up with a pretty good name, and the URL is currently owned, but vacant. It is set to expire 22-Apr-2010.
Should I: a) wait to see if they drop it, and then try to buy it b) make an offer now c) if b, how much should I expect to pay?
Any thoughts are appreciated <comment><USER2> hey Ritarius,

Most domains that 'expire' are set to auto renew, but if you can wait until 22nd of April you might find that someone else snaps it up before you do. Expired domains are quite frequently back-ordered somewhere.

As for what it's worth, I can understand that you don't want to post the name but it's hard to say what it is worth without knowing the domain. If it is prlxz.com then I figure 200 bucks would do it, if it is light.com then I think it should sell for considerably more.

So without more information that part of the question is unanswerable.

</comment><comment><USER3> you should make an offer.

price varies widely based on what the word is.

try estibot and valuate.com and domain score to get an idea of what it's worth.

email and don't specify a price. just ask what price he'd like for it. first person to name a figure loses.

if it's much less than valuate and estibot then go for it. right now is NOT a good time for domain names because of the recession.

<comment><AUTHOR> as Cooper says 'Let them open the kimono first'...thanks for the tip

</comment></comment><comment><USER4> What is it worth to you?

Have you already been in touch with the owner? I ask because from my experience - they typically already have a price in mind. So, if you get that from them you will have a starting point.

I wouldn't wait for it to drop either. Take some action up front, to at least find out what they would sell it for.

<comment><AUTHOR> well we haven't set our brand in stone so it could change...thanks for the advice

</comment></comment><comment><USER5> Ritarius,

Here's a good post, if a bit old, on best ways to grab domains. It's changed a bit as domain sipping is no longer allowed. But it'll give you a good idea of one guy's attempt.

[http://www.mikeindustries.com/blog/archive/2005/03/how-to- sn...](http://www.mikeindustries.com/blog/archive/2005/03/how-to-snatch-an- expiring-domain)

<comment><AUTHOR> cool, thanks for the link Travis

</comment></comment><comment><AUTHOR> thanks all, I'll let you know how it goes</comment>


Google has most of my email because it has all of yours (2014) - <AUTHOR> https://mako.cc/copyrighteous/google-has-most-of-my-email-because-it-has-all-of-yours <comment><USER2> The takeaway?

Don't use standard e-mail (gmail or otherwise) for anything that needs guaranteed privacy. Once you send an e-mail, it is not within your control what happens to it or who sees it.

That's why, for example, in healthcare -- messages are commonly wrapped in secure message "containers". The e-mail simply has a link that takes you to a third party where the actual message is stored, encrypted, has an expiration date, and you must authenticate to view it.

Convenient? No. But privacy always comes at a cost of some sort.

<comment><USER3> See [https://en.wikipedia.org/wiki/Internet_Mail_2000](https://en.wikipedia.org/wiki/Internet_Mail_2000)

</comment></comment><comment><USER4> My incoming mail goes through SpamAssassin at the IMAP server, which does a decent job. All my mail addresses are public on web sites, so there's a lot of junk filtered out.

My phone also uses the IMAP server, so I don't need any Google services. It's an Android phone, but it's never been logged into Google, wasn't bought from a carrier, and many of the built-in Google apps have been removed. (Hint: when you start up a new Android phone, and it wants you to log into Google, click "Later". Then remove the "Google One Time Startup" app to shut up that message.)

This isn't a security thing; it's to block ads.

<comment><USER5> Or you can also install Cyanogenmod without installing the Google-apps package.

<comment><USER6> This is what I do.

</comment></comment></comment><comment><USER7> Previous discussion: [https://news.ycombinator.com/item?id=7731022](https://news.ycombinator.com/item?id=7731022)

(thanks for the new clickable site-history link; it makes resurfacing the duplicate posts _much_ easier)

Also: (2014)

<comment><USER8> You're welcome! That's one of the reasons we added it. (The other is that it's fun to explore HN's history.)

Since it has been over a year since that thread, though, we won't bury the repost as a dupe.

</comment></comment><comment><USER9> It is unfortunate that encryption systems for email never really found widespread use.

<comment><USER10> It's all about ease of use. https is probably the _only_ user-friendly / good UX crypto solution in common/widespread use (unless you count transparent drive encryption), and it achieves this in part by being centrally controlled via registrars to eliminate the need for the user to understand PKI. This in turn makes it kind of a joke from a crypto-snob POV, though it's good enough for most routine stuff.

Even MacGPG plugins for Mac Mail.app are really hard to install, manage, and use, and require a level of expertise and knowledge of how PGP/GPG works that makes them off limits for non-technical users.

<comment><USER11> I'm trying out TutaNota (not the easiest to remember name :/) and they do encrypted email: [http://www.tomshardware.com/news/tutanota-end-to-end- encrypt...](http://www.tomshardware.com/news/tutanota-end-to-end-encrypted- email-rise,30077.html)

Recipents basically receive a password from you in another channel (email, IM, phone convo, face to face) and can use it to decrypt the email from TutaNota when they receive it. I tried it out myself and the only clunky thing is that they load up their whole web app just to read one message, but it's kind of a clever piece of marketing because the web app works pretty well so the recipient who doesn't use encryption gets exposed to an interface that's just as easy to use as what they're used to.

For everyone using TutaNota, the decryption is transparent which definitely is encouraging.

I've seen some people sending around credit card info or social security info and forcing the intended recipient to use a password when receiving that info is a small price to pay for piece of mind. It's almost criminal to send signatures on documents and social security/credit card info in plain-text!

<comment><USER12> Didn't know about them before, looks interesting. I've managed to find their site - [https://tutanota.com](https://tutanota.com) \- even though I was searching for Tutanova (should have just used copy & paste. The name is indeed not easy to remember...

A few questions remain:

* How do they 'encrypt emails to anybody'?

* Where do they encrypt - locally or on the server?

</comment></comment></comment></comment><comment><USER13> Aka, the "second-hand smoke" effect of gmail (or any similar service). Even if _you_ are fine with giving your data Goggle (or Facebook, etc), it's a problem if your forcing that decision on others.

The solution is probably using email in a manner closer to how it was originally designed: many local MTAs instead of a handful of centralized MTAs.

Here's a product idea, which could make someone a lot if they can find a way to implement it: a home server that is a minimal, secure, _locally contained_ , _turn-key_ home email MTA (with some localhost-only IMAP/webmail interface). You sell the server (and maybe a 1-time service to help people set it up).

This server would have to include a "choose your vendor, enter your credit card, click subscribe" super-easy interface to let people subscribe to vendors (multiple, if desired) that provide lower-MX-priority backup MTA services. (perhaps with an optional "hidden MTA" option, where your home server and lowest MX is only visible to the service, so the home router only connects to know hosts, IFF that is something that the customer wants.

People already understand local-only delivery because it emulates snail-mail. If you can let people receive messages and data unattended and asynchronous, so they can run the server when they want and receive their data directly (nobody else involved except for the backup services _of their choice_ , then you have a product that will sell. It doesn't even need to have to have great uptime (that's what multiple MX records are for) or performance.

<comment><USER14> I love the second-hand smoke analogy. I will use it when having The Talk with my friends :).

<comment><USER13> It's Aral Balkan's analogy, from his talk[1] that I _strongly_ recommend showing during That Talk. His presentation is amazingly approachable for a broad audience. Even my not-interested-in-tech _mother_ has started to understand these issues specifically because of Mr. Balkan's explanation.

[1] [https://projectbullrun.org/surveillance/2015/video-2015.html...](https://projectbullrun.org/surveillance/2015/video-2015.html#balkan)

</comment></comment></comment><comment><USER15> re:publica 2015 - Aral Balkan: Beyond The Camera Panopticon has an excellent further discussion of this problem beyond just Gmail:

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

</comment><comment><USER16> Configuring and maintaining email servers is a mess. Most of the people are just outsouring it. There is a lack of simple to use free tools to provide self hosted email.

<comment><USER17> Have you tried sovereign ( [https://github.com/sovereign/sovereign](https://github.com/sovereign/sovereign) )? For someone who knows a bit about Linux, it's a snap to install and get running.</comment></comment>