Software should be designed to last - <AUTHOR> https://adlrocha.substack.com/p/adlrocha-software-should-be-designed <comment><USER2> I don't think anyone who is serious about software craftsmanship would dispute the basic idea here ("you should be tasteful and minimalist when choosing dependencies").

The problem is that the economics of software development don't really ever require craftsmanship. There are two basic modes of development. 1 - You are a startup, struggling to survive; you have to ship features as fast as possible, with many fewer engineers than you really need to do things right. 2 - You are a huge billion dollar corporation, probably a monopoly, with an enormous moat protecting you from serious competition.

Neither situation prizes craftsmanship. The startup just needs to glue together a hack to raise the next founding round or solve the immediate user problem. The gigacorp has more money than it knows what to do with, so they "solve" every software problem by hiring more engineers. There's actually not many companies who exist in the middle ground, where it might be important to produce high quality software. I believe this is also the reason we don't see more uptake of high concept languages like Haskell and Lisp.

<comment><USER3> I'm writing something designed to last, and here is how I am doing it:

1) I am doing it by myself, without any corporate sponsors or financial pay.

2) I am writing it in such a way that it could have already been working for 25 years.

<comment><USER4> I like that 2nd criteria. Seems like a smart way to avoid components that are much more likely to get software decay.

Have you been programming for 25 years?

<comment><USER5> > Have you been programming for 25 years?

I have longer than that and it is really scary that software to see that software I wrote early 90s is still used. I thought, at the time, it would be rewritten in something cooler every few years. But nope. It does make me pick tech that can or will last; not many dependencies, open source, jvm, .net core or C/C++, so it is possible to revisit it in 20 years and not be completely lost (like I imagine it would be with js frameworks/libs/deps at the moment).

</comment></comment></comment></comment><comment><USER6> What this article really boils down to is the usual coder arrogance: Thinking that most problems are inherently simple[1], thinking they are a better coder than average, and thinking that the answer is always to do more yourself, so that more of the codebase will benefit from your superior skills.

The truth is, there are no easy problems in programming. There are always a thousand corner cases and unexpected complexities. And all those buggy, unmaintained libraries you find in your language's package repository are still probably better than anything you're going to roll yourself. Look into the source code of such libraries and alongside the hacks and outdated code, you'll find hundreds of subtle problems avoided, because the author spent a long time and effort on the problem you've spent ten minutes thinking about.

The answer to quality problems in software engineering is not less libraries, it's more and better libraries. In the same way that the high-quality civil engineering the author admires is not achieved by having one person do everything themselves, but by the successful collaboration of a large number of skilled and specialised subcontractors.

Right now, we're still in the infancy of our industry. This, combined with continued the evolution of hardware capabilities has meant that software engineering has never had the long-term, stable base on which to build repeatable, reliable routes to success. That's fine. If we're in the same position in a couple of centuries, it's a problem, but right now we should be experimenting and failing.

Even today, the situation is not as bleak as if often portrayed in articles like this. There are a huge number of robust and high-quality libraries and frameworks providing extremely complex capabilities in an easily reusable way. If a programmer from the mid-nineties were to be transported to the present, I suspect they'd be amazed by what off-the-shelf libraries enable even a single programmer to do. The undeniable quality problems that do affect much modern software often have more to do with the hugely increased scope of ambition in what we expect software to do for us.

[1] Outside a handful, like encryption, that are acknowledged as hard for the purpose of being the exception that proves the rule.

<comment><USER7> > The answer to quality problems in software engineering is not less > libraries, it's more and better libraries. In the same way that the high- > quality civil engineering the author admires is not achieved by having one > person do everything themselves, but by the successful collaboration of a > large number of skilled and specialised subcontractors.

I think one of the fundamental problems with our industry is that there is no funding mechanism for those subcontractors. The "base" that we build on is either unpaid volunteers, or tailored to a specific companies needs and goodwill.

If free software was not the norm, I think we'd see a lot of investment and enterprise around producing high quality libraries.

<comment><USER8> I recently wrote about this problem here [1]. I think "free" software should still be the norm, but companies who use it should have to pay into a fund that distributes the money to where it can be used most productively to make new and more useful libraries. Otherwise there's no sustainable way for most people to contribute to open-source and be paid for it.

[1]: [https://blog.andrepopovitch.com/complement-collution- paradox...](https://blog.andrepopovitch.com/complement-collution-paradox/)

</comment></comment></comment><comment><USER9> I would like to answer the question "Why is software so frequently disappointing and flawed? "

As a developer, there is nothing I would like better than to turn out the highest quality software, as long as I could be compensated for it.

Does anyone really think that the millions of lines of code that went into Windows is worth the piddling $100+ the consumer pays for it?

Let's start with a basic premise: quality is worth money. I'm sure we agree that a Hyundai (or whatever passes for a cheap car in your neighbourhood) costs less than a Porsche or BMW because the Porsche is better designed and better built. Better design means more experienced and brilliant engineers, more talented designers; better built means more skilled and dedicated assembly-line workers. All these people demand more money. Hence the Porsche company commands a higher price for their Carreras, 911s, whatever.

The same should be true of software. If a company invests great care in designing a better operating system, or a better word processor, that never crash, and always have helpful help and meaningful error messages, how much do you think that would be worth? I'll give you a hint: the military do in fact get top-quality software for their jets and rockets. They get software that almost never fails, and does exactly what it is designed to do.

Do you know how much this software costs? $50 per line of code.

Translating into everyday terms, a bullet-proof operating system would cost you, at a rough guess, $5,000 per copy.

Now I have no doubt some people would be happy to pay $5,000 for a stable OS. However, there are many people who couldn't afford this amount.

So what would happen? In any other field (automobiles, stereos, TVs, restaurant meals, housing) people who can't afford quality just put up with less and shut up.

But in the software field... well, they just make a copy of someone else's software, and enjoy the full benefit of top-of-the-line quality, without paying for it. I wager even you couldn't resist obtaining a $5,000 OS for free.

How long do you think a software company would last if their product cost millions to make, and they only sold a few copies at $5,000? Why they would go broke, of course.

This is the crux of the software dilemma: except in a few specialized cases (commercial or embedded software), the maximum price for software is the monetary equivalent of the nuisance value of duplicating it.

In consumer software, this is in the range of $19-$29.

The digital world turns the economics of quality upside-down: in traditional models where quality is supported by price, the market pays the price if it wants the quality.

In the digital model, a perfect copy of the merchandise costs virtually nothing, and undercuts the legitimate market, putting a cap on the maximum that can be charged for a product.

There is a built-in limit to how much time, effort and expense a company can invest into a mass-produced product. This cap is equivalent to the "nuisance value" defined above. It is not reasonable for the consumer to expect warranties and liabilities that go way beyond what the manufacturer receives from sales of the product.

The music and movie industry are wrestling with the consequences of easy digital duplication. They have taken a different route to protecting their intellectual property.

I challenge anyone to come up with a business model where the software developer that invests great expense in building a quality product, can obtain full compensation from the market segment that values his quality.

Whose fault is it anyway? Simple: it's the consumer who copies and pirates software that forces the price down and therefore the quality to remain low. Any analysis that does not take this into account is simplistic.

It is naïve to think that most developers are not struggling to make ends meet and stay in business (Microsoft notwithstanding).

<comment><USER10> What are your thoughts on where OSS fits into this?

<comment><USER9> [https://progenygenealogy.blogspot.com/2018/01/the-open- sourc...](https://progenygenealogy.blogspot.com/2018/01/the-open-source- mirage.html)

</comment></comment></comment><comment><USER11> I want to build software that lasts, but I don't think you really can at this point.

We haven't even figured out fully how we should represent a string or date or number in software let alone have an enduring language or ABI.

I feel like I am building everything on a foundation of sand at it will need to be rebuilt every 5 years, 10 if you're lucky.

I do think it will change, but it will be awhile and by then it will probably just be a few big players making software anyway, kinda like car companies.

<comment><USER12> I've got the same exe running in client installs since the late 90's. It's had a tweak or two here and there, but largely unchanged. I last recompiled it about 2yrs ago and had a fresh install of it about 6 months ago.

It's not the prettiest thing and could have certain upgrades in light of new security practices (eg use new encryption algos & go thru an in-depth security audit). But to the clients, it's unbeatable and there's nothing remotely close to migrate to.

Unbelievably, it's a vb6 app that I never bothered porting to dotnet. Even more unbelievably, it's a port of its predecessor, written in turbo pascal. As long as I can continue to find the dev environment installer, it's good to go.

So. I think s large part of the problem is that ppl don't redirect their dev environment enough to keep an install disk, (if one was available in the first place).

A second large problem is that modern development relies heavily on 3rd party library use, which means your software is reliant on more than one company for your binary.

So. Find an environment that you can archive/keep, and ignore the not invented here rule to a large extent

<comment><USER13> >>> I've got the same exe running in client installs since the late 90's.

That's on Windows that has stable API and ABI. The 90's is probably the limit because older software are 16 bits and don't work on current 64 bits Windows.

On Linux all software break with each distro release because "core" libraries are unstable. Got executable and libraries compiled on RHEL 6 and most of them fail to load on RHEL 7 because something.so not found.

<comment><USER14> You can bundle the .so files in Linux just like you would bundle .dll files in Windows. Or statically compile if you don't want dynamic libraries. Linux and Windows isn't really any different there aside from Windows has more in the way of novice friendly tools to create redistributables.

It's also worth noting that you're comparing Apples to Oranges in that Visual Basic 6 is a very different language to C++. VB6 has its own warts when it comes to archiving such as it's dependence on OCX and how they require registering for use (they can't just exist in the file system like DLL and SO libraries, OCX required their UUIDs loaded into Windows Registry first).

To further my previous point, if you wanted to use another language on Linux, maybe one that targets the OS ABIs directly (eg Go), then you might find it would live longer without needing recompiling. Contrary to your statement about user space libraries, Linux ABIs don't break often. Or you could use a JIT language like Perl or Python. Granted you are then introducing a dependency (their runtime environment being available on the target machine) but modern Perl 5 is still backwards compatible with earlier versions of Perl 5 released in the 90s (same timescale as the VB6 example you'd given except Perl is still maintained where as VB6 is not).

<comment><USER15> _Linux_ ABIs might not break often.

But GTK, Qt, libwhatever ? More often than one would like.

<comment><USER14> I'd discussed that problem in the first paragraph of my post.

<comment><USER13> For reference, the C++ ABI is changing with every minor version of gcc, making compiled libraries like glibc or Qt incompatible. Major distro releases upgrade gcc so all packages are incompatible.

I agree on compiling statically to avoid DLL hell. However it is fairly difficult in practice because software rarely document how to statically build them and they very often take dependency to some libraries on the system. All it takes is one dynamic dependency to break (libstdc++ is not stable for example).

<comment><USER14> > _For reference, the C++ ABI is changing with every minor version of gcc, > making compiled libraries like glibc or Qt incompatible. Major distro > releases upgrade gcc so all packages are incompatible._

It's actually not as dramatic as that and you can still ship libc as a dependency of your project like I described if you really had to. It's vaguely equivalent in that regard to a Docker container or chroot except you're not sandboxing the applications running directory.

This is something I've personally done many times on both Linux and a some UNIXes too (because I've had a binary but for various different reasons didn't have access to the source or build tools).

I've even run Linux ELFs on FreeBSD using a series of hacks, one of them being the above.

Back before Docker and treating servers like cattle were a thing, us sysadmins would often have some highly creative solutions running on our pet servers.

> _I agree on compiling statically to avoid DLL hell. However it is fairly > difficult in practice because software rarely document how to statically > build them and they very often take dependency to some libraries on the > system. All it takes is one dynamic dependency to break (libstdc++ is not > stable for example)._

There are a couple of commonly used flags but usually reading through the Makefile or configure.sh would give the game away. It has been a while since my build pipelines required me to build the world from source but I don't recall running into any issues I couldn't resolve back when I did need to commonly compile stuff from source.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> The idea that removing external dependencies necessarily simplifies your code and leads to a maintainable system is a fallacy. Use external dependencies appropriately, follow SOLID principles and a clean architecture and you can leverage the benefits of other people's code without losing the intelligibility of your system.

In the example the author gives, the real mistake is allowing the web framework to define a system that you then try to customise to produce your application. The battle is already lost because your business logic is now a dependency of someone else's (rotting) generic web app template. This may be appropriate for you if this is a proof of concept or spike but for something with a longer lifetime, any time you save will be paid back with interest when the host framework diverges from your needs.

A JSON parser is not an equivalent class of dependency _if_ you keep it at the periphery of your system. There's not much point in writing a JSON parser unless you have a particular requirement that cannot be satisfied by a third party library. You should be able to swap it out for a different JSON parser in a few hours.

80:20 seems like a ratio that was just pulled out of the air; I have no data to hand either but for most user applications I would suspect the real ratio is more like 99:1.

Edited to add: I'm still in agreement with a lot of what the author says here, such as: evaluate your dependencies seriously, understand them, and be mindful of their impact on things like binary size.

</comment><comment><USER17> For truly long lasting software, I feel all code that make up a system should be treated equally; i.e. not divided into "own code" and "third party dependencies". Basically extreme form of dependency vendoring.

But it is very expensive way of doing things, and would not work well with modern constantly updating libraries. But I do personally consider software maintenance to be an antipattern. I'd rather have my software be correct and eventually replaceable than constantly changing and "maintainable"

</comment><comment><USER18> In order to have software that lasts, you need environments that last.

The classic 1950s Big Iron software, now run swaddled in layer upon layer of emulation on current mainframes, is software which lasts because people will recreate its environment again and again, and ignore the people who are ill- served by it because they don't fit into that environment neatly. Oh, your name doesn't fit into an all-caps fixed-width EBCDIC form? Go fold, spindle, and/or mutilate yourself, NEXT! (This happens to me. Over and over again.)

On the opposite extreme, unmaintained Internet software rots:

[https://utcc.utoronto.ca/~cks/space/blog/tech/InternetSoftwa...](https://utcc.utoronto.ca/~cks/space/blog/tech/InternetSoftwareDecay)

Or, to be more precise, software is built with assumptions underpinning it, and those assumptions change out from under it more quickly on the Internet than in other contexts. Software can go from being secure and completely above reproach to being a major factor in DDoS amplification or spam runs because the world changed around it. Software that lasts is like ships that last: Replace the hull, the mast, the sails, the cabins... same ship, neh?

</comment><comment><USER19> It's very sad for me to see that software in consumer products isn't that reliable or performant anymore, just because vendors can "push updates", which seems to result in crappier software overall.

<comment><USER20> Why do you think consumer products at a similar price point used to be more reliable or performant in the past? I don't think that's true at all. In the 90's, software was riddled with bugs, you saved files every five minutes because your word processor regularly crashed, you had to restart your computer multiple times a day when the OS hanged, and starting Photoshop easily took a full minute.

Also why do you think the ability to push updates results in crappier software? In the 90's, if your copy of CorelDraw or Windows had a bug, you lived with that bug for years. Today, if it's a common showstopper, it gets fixed quickly.

To my eyes, everything's gotten _far_ better.

<comment><USER21> I don't think he's talking about the 90s. But the late 2000s were definitely better than now. Computers were powerful enough to do most things we do today, and yet both OSes and applications seemed to be much better. Compare the quality and stability of Windows 7 (or even Vista) and their macOS counterparts to their nowadays' versions.

<comment><USER20> I guess I'm not seeing that either.

Compared to the late 2000's, today's computers have SSD's and retina displays and play 4K movies. They're _vastly_ faster, with typography you can't see pixels in.

And OS's and applications are basically the same. My macOS is no less stable than it was a decade ago. The main difference is that my Mac is far more _secure_ , so I trust third-party software much more.

I'm just not seeing how the quality of OS's _or_ applications has gone down. I think what would be more accurate to say is that both OS's and applications have added more _features_ , and that otherwise quality has remained basically the same.

Sure, I still have finicky Bluetooth issues today. But I had finicky Bluetooth issues 10 years ago too. It's certainly no _worse_. But now Bluetooth gives me AirDrop too.

<comment><USER21> > today's computers have SSD's and retina displays and play 4K movies

And yet, something as basic as a Slack client now requires gigabytes of RAM, microblogging such as Twitter loads a monstrosity of a webapp that immediately makes the fans spin up to display 240 characters in the rare case it actually loads without errors which require to refresh the page. Modern entry-level laptops have the processing power of a decent machine from a decade ago, and yet they appear just as slow to do the same computing tasks we did 10 years ago.

My 2017 Macbook lags and stutters when loading a YouTube video page. YouTube used to load fine and not stutter in 2009 on a laptop with a third of the RAM and CPU that I currently have, and yet the task at hand didn't change at all, it still just needs to display a video player and some text.

Windows 10 broke _start menu search_. Come on, this problem was solved a decade ago.

Every large website's login flow now involves dozens of redirects through various domains which can break in all kinds of interesting ways leaving the user stranded on a blank page in the middle of the flow. I know the reason behind them (oAuth, OpenID Connect, etc), but as a user I don't care; this is a major UX downgrade and the industry should've done better.

We've replaced offline-first applications with cloud-first. Nowadays even something that should work fine offline will shit itself in all kinds of unexpected ways if the network connection drops or a request fails.

<comment><USER22> It's not the software. It's all the ads that load up in the background, that tracks you, even when you're browsing incognito.

<comment><USER23> Slack doesn't have ads.

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> The kicker these days is that "standing still" is not enough. Software that "lasts" has to constantly change, because externalities force it to - primarily, security.

Whatever library, language or foundation you built on, you can guarantee whatever version you used is going to stop getting security updates in a couple of years. And then there will be a whole lot of baked in dependencies you didn't know about - URLs (like XML schema URIs that were never meant to be resolved but lots of libraries do), certificates, underlying system libraries etc.

So designing software "to last" now is designing software to be constantly updated in a reliable and systematic way. And the interesting thing about that is from what I can observe, the only way to achieve that currently IS through simplicity - as few dependencies as possible, those that you do have very well understood and robust, etc etc. So it sort of comes back to the author's argument in the end, though maybe through a different route.

<comment><USER25> It's possible to engineer for this. The mental model: imagine you are equipping a time travel mission decades into the future, to integrate with the future internet, and to return home with acquired results.

A TLS client is not possible to future proof like this of course, but you could have a roster of approaches. For example, try getting your hands on the latest curl / wget builds (try each with a few different approaches), or the latest JVM/Python/Powershell & use those TLS APIs.

A fun game would be to try this with tools available 20 years ago, and then redo it to make a sw time capsule from present day to 20 years into the future...

<comment><USER26> A better approach is to have the "TLS" library accept either an already connected socket (and host-name to validate) OR return something that behaves like one after dialing and validating an address. That way when the underlying library is re-linked to something modern it'll still have the same API / ABI but the underlying security implementation will belong with the updated library.

<comment><USER25> That could indeed be an idea, if you can assume the SW can be rebuilt/linked against API compatible libs, and you rely on the API existing far into the future. The automatic CLI tool scouring option would allow you to hedge your bets over several implementations because of looser coupling.

</comment></comment></comment></comment><comment><USER27> As a counter point to the author:

* Half baked in-house implementations of things are often filled with bugs and broken edge cases. Especially when it comes to security and concurrency.

* In a larger code base, you won't understand everything whether it's in-house code or third party code. The in-house code was written by someone who quit 5 years ago and is now a monk in Tibet.

</comment><comment><USER28> Software should be built to accomplish its purpose. It's not a special snowflake, it's a tool to do some specific job. To think otherwise is to setup yourself and your company/team for disaster.

Kernels, compilers, language runtimes, databases? Sure, build them to last. Web pages that will not be used in 2 weeks? Don't waste your time with "build to last".

The problem is that some of us think that our software should be build to last - but in reality it's just some mediocre thing that needs to get in front of the clients as fast as possible and some bugs are "OK" to live with.

<comment><USER29> That would be fair if all those "pages that will not be used in 2 weeks" actually ended up not being used after just 2 weeks. Instead, they will probably continue to be used for 2 months or 2 years.

</comment></comment><comment><USER30> I try to use no dependencies beyond my database connection. The one area I feel unprepared to handle myself. Anything else I try to code a minimally- viable functionality that meets my needs. As a bonus, I have learned what all these things do and how they work while fiddling with implementations, and if I want to customize their functionality in any way, it's generally pretty easy.

I'd almost always take a pasted tutorial over a robust dependency every time, the former is more reliable. Any dependency I do take on is something I have to watch the changes of and project status of like a hawk.

<comment><USER31> That doesnt work in most cases though. You are not going to reimplement jpeg encoding, mpeg, etc.

<comment><USER30> If the language/framework you are using handles it already, you're probably golden: Your language/framework is functionally the one dependency you always have, and features implemented in the platform tend to be fairly stable. Pick a platform that supports the most difficult things core to your application.

I'm most comfortable in .NET or PHP, both which have extremely large long- lived built-in function sets that generally are non-breaking over a span of many years. Meanwhile, I generally don't add anything to them via NuGet/Composer/etc. They both operate almost opposite to the JavaScript world, where everything is built by random third parties. If it's popular enough a need, it tends to be added the basic package.

</comment></comment></comment><comment><USER32> Pure HTML with progressive enhancement has worked fine for 30 years and will continue so for many more. But a good, lasting product is incompatible with the current "take the money and run" business strategy and analytics for management. If it works well for so many people, what can we do?

<comment><USER33> That's all well and good but go and visit some random websites and see how many of them depend on sites like unpkg or jsdelivr or something.

Every time you try to load a resource from a domain you're introducing a _huge_ risk by letting them be the judge, jury and executioner.

Domain gets hacked and injects malicious scripts or collects user data? Domain fails entirely (no-renew) or in 10 years just stops responding?

A lot of web pages today have built in self-destruct features purely based on the JS/resources they're loading.

For 0 benefit, as well, since the amount of BW saved in so marginal.

<comment><USER32> Yes, security is the most sensible reason we use mega frameworks, because FB and Google will patch any issues instantly, for free and forever.

</comment></comment></comment><comment><USER34> Software is not always designed to last. Take video games that use servers, the video game company can take down the servers and the video game no longer works. You'd have to set up your own server to emulate what the video game company's server did.

All those mobile games that require a server, once the server goes down the game no longer works.

In the old days you set up Doom as a server on your PC networked to other PCs for multiplayer. Those can last and be remade for new platforms.

<comment><USER35> LAN hosted games are the golden area. Online game servers are a really interesting example of brittle software.

When the server is shut down, the game breaks and the software _is_ unusable.

This often happens because of the misaligned incentives of the business to not release the server code. This disappoints both the original developers and the consumers.

I'd argue that this is not only a software problem, but mostly an problem of copyright distorting the incentives of publishers.

One could imagine a client hosted game or alternative architecture that removes the central dependency on the company could be the way to build software that is built to last to last longer.

In the online game I'm developing - I make sure that every client can also run as a game server. This way if my servers are shut down players can play without depending on me.

My decision to remove myself as a dependency directly goes against the incentives I have as a publisher. I slightly narrow the possible monetization options for the game.

Mostly I'm trying to explain why developers/publishers decide to make brittle software, even if I don't agree personally.

</comment></comment><comment><USER36> More often than not, the code I have to write needs to be written fast, and I (mostly) won't have time to look at it again once deployed. I've mostly worked at fast growing companies, so that's been the case everywhere.

What I've learned is that making stuff as simple and stable/low maintenance as possible is the only way to be sane. I can't afford to deploy code that then requires me to hold its hand with a team of 3-4 engineers for the upcoming years. It needs to run itself and be forgettable. And it needs to be written fast.

This has become much harder in recent years with the switch to things like Kubernetes. Kubernetes moves so fast and needs constant nurturing, even for casual users. Running old versions of it is painful and dangerous, so you're forced to update. And the ecosystem is still so early in its life that all the paradigms change and flip on their head every year. Odds are that something you deploy in it today, will need to be looked at in 18 months. And the whole thing will need a team dedicated to keeping it healthy.

Anyhow, that's my angle on the author's rant. Things need to last, IMO, mostly because I don't have time to go back to them later.

<comment><USER37> I'm using completely opposite approach. I'm trying to define a strict requirements to a given task and then I code assuming those requirements. If any small detail changes, my code will break. So I'm trying hard to break it as soon as possible (using asserts and similar patterns) with enough information to understand the reason of this breakage.

So my code definitely requires maintenance in a changing world. But more than once those breaks actually identified a bug somewhere else and fixing that bug was essential. If I would try to self-fix wrong data, those kinds of bugs could be missed. Sometimes I need to fix a code to adapt to a changed format or something like this. But that's not a big deal, because change is simple and something like exception stacktrace allows to instantly find a code which is to be fixed.

</comment></comment><comment><USER38> If you want your software to last remember that you also have to have a working and upto date development environment, ie your code may still work fine but if you cannot compile it to the correct target it is useless.

I found this out the hard way when I had to recompile some fpga firmware for a $100K piece of equipment which used a programmer not supported by windows, a chip and code not supported by the current IDE and a binary blob which we did not have the source code for and would not link, luckily we winged it by replacing the FPGA with a hardware compatible replacement... We now preserve the whole development environment on a VM and save it with the source code.

</comment><comment><USER39> If you write your code properly, you will have tests which break on every library incompatibility, and a tiny wrapper around your libraries. (If you do TDD properly, you will have it.) And that's all you need to keep your code up to date. When upgrading a library, you will of course build and test your code with it, and that will show you any problems, which you can fix in the library interface layer before having any chance to go to production.

<comment><USER40> _If you write your code properly, you will have tests which break on every library incompatibility, and a tiny wrapper around your libraries. (If you do TDD properly, you will have it.)_

In general, I'm not sure it's possible for all of these things to be true.

Many libraries are useful because of their side effects. Depending on what those side effects are, it may simply not be possible to integration test your entire system in a way that would satisfy all of the above claims.

The alternatives tend to involve replacing the parts of the code that cause real side effects with some sort of simulation. However, you're then no longer fully testing the real code that will be doing the job in production. If anything about your simulation is inaccurate, your tests may just give you a false sense of confidence.

All of this assumes you can sensibly write unit tests for whatever the library does anyway. This also is far from guaranteed. For example, what if the purpose of the library is to perform some complicated calculation, and you do not know in advance how to construct a reasonably representative set of inputs to use in a test suite or what the corresponding correct outputs would be?

</comment></comment><comment><USER41> I think we can all agree that software should be designed to last :)

My experience tells me that when this fails to happen its usually not explicitly due to too many dependencies. Rather it is because the developers have a poor/partial understanding of the problem domain.

External libraries help this problem a bit because it allows developers to offload tasks onto other more experienced developers. They can (and occasionally will) misuse those solutions, but that is not the dependencies faults. On the contrary skilled developers will produce quality solutions with or without dependencies.

The signal seen (poor software has many dependencies) does not mean that software with dependencies are poor. It means instead that developers who have a poor domain understanding but good business skills are disproportionately successful compared to their peers that have good domain understanding but poor business skills.

Make of that what you will :)

</comment><comment><USER42> Isn't the inevitable conclusion "you should design your interfaces so that they last" (and/or choose existing interfaces which look likely to last) rather than "you should avoid dependencies"?

</comment><comment><USER43> It's all an illusion. Software kinda isn't lasting, some things merely have competence behind them

Look at the GNU coreutils, things you probably think shouldn't have changed in a while: [https://github.com/coreutils/coreutils/tree/master/src](https://github.com/coreutils/coreutils/tree/master/src)

There's actually frequent edits. Legendary disk destroyer was just updated last month. The difference is the competence

</comment><comment><USER44> Building things to last has a really high cost and is usually not worth it. The vast majority of the buildings and infrastructure humans have constructed have been torn down, completely rebuilt or abandoned. What remains are usually extremely expensive monuments to religon, culture or governmental constructions.

Most software is not worth to preserve the same way most buildings are not worth to preserve (except for perhaps the aesthetically pleasing facade).

</comment><comment><USER45> "...bridges and civil engineering projects are designed to last, why can we also design software for it to last?"

Some software has lasted for many decades. This isn't necessarily a good thing. [1]

[1] [https://arstechnica.com/tech-policy/2020/04/ibm-scrambles- to...](https://arstechnica.com/tech-policy/2020/04/ibm-scrambles-to-find-or- train-more-cobol-programmers-to-help-states/)

<comment><USER46> On the other hand, there's lots of software that's been around for decades that still works quite well today. Most GNU software for example, and particularly Emacs.

</comment></comment><comment><USER47> 90 days certs that needs renew based on external service API that can change says No.

Software in a hardware that is designed to do certain job should indeed last. Like Telecom towers should work fine "forever".

But software as in APIs and services that constantly has to evolve and be expanded. Yeah that is a harder sell.

We live in crypto world where each advancement in cputing or ways to solve could render algorithms "bad" means we have to update and adapt.

</comment><comment><USER48> Software that lasts is software that is a joy to use.

Imho the tech, how good you are at programming is all not very relavant when the user doesn't like to use your software.

I have written a small CMS for a company which was replaced twice but every time they ditched it to return to my old simple version.

This is just one example but I think that should be in people's minds when they create software that lasts: people must enjoy using it.

This can even apply to a command line program.

</comment><comment><USER49> If somebody is a solo developer working on a huge project, it would be lovely if the software lasted... but the big fear is that it won't get users. Can't really spare the time to worry about 10 years from now when you are thinking about how you have to get a regular job if you can't get X users in the next 6 months

</comment><comment><USER50> Civil engineers and spacecraft designers build their systems to last because they don't have a choice. You can't deploy fixes to a production bridge ten times a day.

There might be good reasons to build software to last, but "These other engineering fields build their things to last" isn't one of them. I have no doubt that if you _could_ reliably send fixes to bridges and spaceships, people would do it - and that many lives would have been saved.

My personal opinion is you should design the larger ecosystem around your software to last and be robust to the replacement of any individual part. Building on Go's standard library HTTP server would have seemed needlessly cutting-edge about five years ago. Building on Apache and mod_cgi would be considered dated today (even though it would work). The stack you should be using _will_ change. Build your system so that, when change comes, you're not afraid to write new software.

In practice, this means making good designs to avoid hairballs of complexity, having deployment pipelines that let you roll out canary versions (or better yet, send a copy of production traffic against a sandbox environment), keeping track of who's using APIs internally so you can get them to change, having pre-push integration testing per the Not Rocket Science Rule so you can be confident about changes, etc. You should think about your choice of web framework or JSON library up front, sure, but more importantly, if a sufficiently better web framework or JSON library comes along tomorrow, you should be able to switch. As a principle - any time you see something that you think you'd be afraid to change in the future, don't ship it if you haven't shipped it yet and figure out how to build the right abstraction around it if you can.

</comment><comment><USER51> Reusable abstractions is the foundation of what makes programming productive. This person does give respect for libp2p, which is good, but clearly they've never seen a small abstraction that is still immensely valuable.

</comment><comment><USER52> The software (as in the actual code for an implementation), should be ephemeral in my opinion.

The data model, protocols and knowledge base (docs, requirements etc) should be designed to last and be extensible.

</comment><comment><USER53> Constructive criticism if the author is in here, I find multiple bold sentences per paragraph to be taxing on the eyes.

</comment><comment><USER54> > _If all three are in agreement, they carry out the operation. If even a > single command is in disagreement, the controller carries out the command > from the processor which had previously been sending the correct commands._

By this definition, wouldn't all three processes be the last ones to send the correct commands?

<comment><USER55> Actually the way it usually works is a voting system, where if one component disagrees, and two agree, the majority vote is upheld.

</comment></comment><comment><USER56> for some reason when I saw the headline I went over to check up on grc.com that guy's obsessiveness into coding everything in assembly gives me comfort

</comment><comment><USER57> >> Software should be designed to last

Not necessarily true.

If the requirements of the project are to be secure or fast or easy to maintain or built quickly or have beautiful user experience or be maintainable or be designed to be robust & failure resistant, then that is what it should be.

And if the requirements of the project are "the software must be designed to last", then the software should be designed to be designed to last.

But if it's not a requirement, then no, it does not matter if it lasts.

The point being that blanket statements about what software should be are missing important context about the purpose of the software and the constraints under which it was developed and the specified requirements.

<comment><USER58> Couldn't you have just said "Not all software must be designed to last"?

Also, the author said software _should_ be designed to last not that it _must_.

Lastly, you didn't address the core argument of the article which is that you should carefully select and manage dependencies. Reading your comment I wonder if you even read the article..

<comment><USER57> True. somewhat long winded, edited thanks.

</comment></comment></comment><comment><USER55> This is why I like long-established technologies. You can build most anything with typical POSIX utilities and time-worn libraries. And they will be there for you in 25 years. Who knows where Rust and Go and Node will be in a quarter century?

<comment><USER59> You can apply the Lindy power law :)

<comment><USER55> Looked it up finally, I agree. It's why we have steering wheels instead of joysticks (except for the people who have a leg-related disability, they've been driving with joysticks for like 100 years).

</comment></comment></comment><comment><USER60> no, software should be designed to work for as long as necessary, because we're responsible professional and don't want to squander other people money on infinite perfection

the whole bit is nonsensical included the parallels with civil engineering, bridges are built with tolerances, maintenance schedule, and a disposal plan for when maintenance cost become higher than replacing the bridge, because nothing in this world actually lasts.

heck our internet is built around operating systems that didn't exist 25 years ago. imagine investing capital and sink opportunity costs in delivering the perfect vax typing program...

mind, this is not to say that all software should be quick and dirty. but the conscious engineer knows whether it's building infrastructure to last decades or a temporary bypass to support some time limited traffic spike.

the important bit is to ask the stakeholder what's more appropriate.

I also want to see people build their own json parsers at acceptable level of performance, possibly as streaming parsers instead of just gobbling everything in memory. imagine wasting a month on building that and then having to defend your choice every time a bug or a malformed input causes silent data corruption somewhere in the backend. [http://seriot.ch/parsing_json.php](http://seriot.ch/parsing_json.php)</comment>


Show HN: MailDB – Find and verify email addresses - <AUTHOR> https://maildb.io/ <comment><USER2> Where is the pricing? Quotas?

<comment><AUTHOR> Within the member panel (for now).

<comment><USER3> Where is the member panel? I see Features, Contact, Sign Up and Login. and at the bottom: Features, Contact, Sign Up, Login, Terms, Privacy</comment></comment></comment>


Best Business Books for Entrepreneurs - <AUTHOR> https://www.plerdy.com/blog/26-best-business-books/ <comment><USER2> While there are some books which are quite good and I do recommend them, there are also a few of them which are quite dubious to say at least.

Finance gets skipped too many times too often in discussions like these. Forget Robert Kiyosaki and Brian Tracy for finance books, they are reserved for the "self-help" section.

What I definitely recommend is "Financial Intelligence for Entrepreneurs" and "Simple Numbers, Straight Talk, Big Profits" as some of the pillars for startup finances.

<comment><USER3> Finance is still such a broad field without really adding value to your bottom line except for advice on leveraging debt to increase the return on your investment.

The shift to digital that is catapulted by platforms with network effects are the new goggles to use to look at your business model. Marketplaces are online able to service the long tail of consumer demand and a platform matches producers of the long tail with consumers of this value.

Market size cap of the top 5 most valuable firms of the world are platforms. FAA(N)G et al. Have revenue multiples of 8 while traditional businesses like Shell have a multiple of 2 and this difference has nothing to do with finances. Platforms do not create the revenue themselves.</comment></comment>


Public Service Announcement: You Should Not Force Quit Apps on iOS - <AUTHOR> https://daringfireball.net/2017/07/you_should_not_force_quit_apps <comment><USER2> Unless they misbehave

Or you want to

No, it won't (probably) help your battery

But who cares? It's ___my_ __phone

<comment><USER3> John Gruber cares.

Stop holding the phone wrong!</comment></comment>


DosBox 0.75 is out with Pixel Perfect Feature and More - <AUTHOR> https://dosbox-staging.github.io/v0-75-0/ <comment><USER2> super cool! interesting to learn that migrating to SDL 2.0 resulted in 50% less code.</comment>


In Amazon's warehouses injury rates are twice the U.S. national average - <AUTHOR> https://www.cbc.ca/radio/day6/amazon-workplace-injuries-enforcing-privacy-laws-photographing-climate-change-hockey-in-north-korea-more-1.5376837/in-amazon-s-warehouses-injury-rates-are-twice-the-u-s-national-average-1.5376849 <comment><USER2> Move fast and break bones.

In other news, here in the UK Amazon has launched a TV add campaign encouraging people to visit their warehouses. Is the bad press starting to hit their bottom line?</comment>


Nick Szabo is Satoshi Nakamoto, the Inventor of Bitcoin - <AUTHOR> http://blog.sethroberts.net/ <comment><USER2> Just for some background, previous discussion on the referenced article: [https://news.ycombinator.com/item?id=6828169](https://news.ycombinator.com/item?id=6828169)

Gwern's response on Reddit refuting it: [http://www.reddit.com/r/Bitcoin/comments/1ruluz/satoshi_naka...](http://www.reddit.com/r/Bitcoin/comments/1ruluz/satoshi_nakamoto_is_probably_nick_szabo/cdr2vgu)

</comment><comment><AUTHOR> The blogger who suggested this hypothesis a few months ago has a new post, with a stylometric analysis of the writings of some cryptocurrency people:

[http://likeinamirror.wordpress.com/2014/03/11/occams- razor-w...](http://likeinamirror.wordpress.com/2014/03/11/occams-razor-who-is- most-likely-to-be-satoshi-nakamoto/)

(a smaller score mean a closer match. Not sure what scores stand for precisely).

 _Word length distribution_

        Diff Nick Szabo / Bitcoin: 0.160
        Diff Wei Dai / Bitcoin: 0.241
        Diff David Chaum / Bitcoin: 0.257
        Diff Adam Back / Bitcoin: 0.337
        Diff Hal Finney / Bitcoin: 0.510

_Character frequency distribution_

        Diff Nick Szabo / Bitcoin: 0.191
        Diff Wei Dai / Bitcoin: 0.208
        Diff David Chaum / Bitcoin: 0.228
        Diff Hal Finney / Bitcoin: 0.284
        Diff Adam Back / Bitcoin: 0.342

<comment><USER3> Statistical analyses rely on assumptions of sample independence and random selection that are pretty hard to justify with something like this. Are all the articles on the same topic? Are they written for the same audience? Are the works independent or is there copying and/or inspiration being shared?

</comment></comment><comment><USER4> Regardless if he is or if he isn't, his essays are unbelievably good:

[http://szabo.best.vwh.net/](http://szabo.best.vwh.net/)

<comment><USER2> Folks seem to really like [0] his writing. Anything you recommend starting with?

[0]: See sidebar on his blog: [http://unenumerated.blogspot.com/](http://unenumerated.blogspot.com/)

<comment><USER4> I loved this one:

[http://unenumerated.blogspot.com/2006/02/irreducible- complex...](http://unenumerated.blogspot.com/2006/02/irreducible-complexity- of-society.html)

But any random post of his is likely to be intensely interesting, even if you don't agree with some of his conclusions.

</comment></comment></comment><comment><USER5> Yeah, we've thought for a long time he's probably involved. Along with other people (he almost definitely didn't write the code); Satoshi likely isn't just one person.

That being said, what's the point of articles like this? We will never know unless Satoshi chooses to reveal himself/themselves and proves it with a pgp key. Which won't happen. Otherwise, it's just idle speculation.

<comment><USER6> The point is that Newsweek is very likely wrong.

</comment></comment><comment><USER7> Link to full post: [http://blog.sethroberts.net/2014/03/11/nick-szabo-is- satoshi...](http://blog.sethroberts.net/2014/03/11/nick-szabo-is-satoshi- nakamoto-the-inventor-of-bitcoin/)

</comment><comment><USER8> >>>"One was her observation that he put two spaces after a period"

Wait, was that actually one the reasons Dorian was labelled as Satoshi? Because that's true of a huge number of people. Many people who learned on a typewriter (like my parents), or who were taught touch-typing formally by those who were (like my wife) still do this. It's hardly rare enough to be any kind of discriminator.

<comment><USER9> _" It's hardly rare enough to be any kind of discriminator."_

Something that's true of 50% of the population under consideration, and which is uncorrelated with other measures, is still a bit of information.

</comment></comment><comment><USER10> I like that the linked blog has high quality ads: Real book recommendations, and links to individual books. Instead of brand-spam, a potentially useful product. Only way it could be better would be to recommend books directly relevant to the blog post topic.

</comment><comment><USER11> I'm extremely curious in understanding why he wanted to be anonymous when publishing his idea of Bitcoin. Nobody could possibly have anticipated that Bitcoin would become _the_ most used crypto-currency today. Many experts from the cryptography mailing list were quick at discarding his idea from the beginning, so I can't imagine Satoshi wanting to remain anonymous in case Bitcoin would become a billion dollar business and people would start going after him for his money. This is why I believe Satoshi is probably just some brilliant person who's name is actually Satoshi Nakamoto (not Dorian).

<comment><USER12> Maybe it is the other way round. He didn't want to damage his professional reputation which could have happened if important and vocal members of the crypto community had declared that they thought the project ridiculous.

Just like Carlo Pedersoli renamed himself Bud Spencer so as not to damage his good reputation as an olympian athlete with his movies.

</comment></comment><comment><USER13> _Szabo's achievement is good news for me because we have a similarity. He was a law professor. They are not supposed to invent new and useful things._

Not saying he's wrong, but this reeks of confirmation bias.

</comment><comment><USER14> "The clincher, for me, is that he wrote an article about the emergence of money that is compatible with my theory of human evolution."

Apparently author really wants Nick Szabo to be creator of bitcoin because they have similar views.

Previous four reasons given are way better compared to reasoning used in Newsweek article, however it is still nowhere near enough to assert that Nick Szabo is Satoshi.

</comment><comment><USER15> Why has no one spoken with Nick Szabo?

<comment><USER16> They have. He's denied it.

<comment><USER17> Can you give a link to where he's denied it? I haven't seen anything.

<comment><USER16> [http://www.wired.com/magazine/2011/11/mf_bitcoin/all/1](http://www.wired.com/magazine/2011/11/mf_bitcoin/all/1)

Wired, weirdly, didn't quote his denial. They just said he denied it. On his blog, he also suggested that Finney or Dai might be Satoshi.

I'm inclined to believe it's him. He's been writing about this topic passionately for years. Weirdly, though, he was still writing about "Bit Gold" and Hal Finney's attempt at an implementation in December 2008, after Satoshi posted the BitCoin whitepaper which is very, very strikingly exactly an implementation of his concept (with some major improvements, obviously), which he made no mention of.

He also seems so prolific on his blog - writing post after post of greatly historically informed academic research - that I just don't know how he would find the time to implement BitGold.

I also have not seen any of his other programming projects, and so I don't know whether or not he's a good enough C++ engineer to implement it successfully.

But of all the people so far he seems to be the best candidate.

<comment><USER15> Thanks.

<comment><USER16> He discusses fake name use in this post to Cypherpunks List in 1993. He also mentions "Digicash" in the same thread.

[http://borg.uu3.net/ldetweil/medusa/originals/unpleasant](http://borg.uu3.net/ldetweil/medusa/originals/unpleasant)

"In my limited experience creating Internet pseudonyms, I've been quite distracted by the continual need to avoid leaving pointers to my True Name lying around -- excess mail to/from my True Name, shared files, common peculiarities (eg misspellings in written text), traceable logins, etc. The penet.fi site explicitly maintains a list of pointers to the original address. All kinds of security controls -- crypto, access, information, inference -- have to be continually on my mind when using pseudonymous accounts. The hazards are everywhere. With our current tools it's practically impossible to maintain an active pseudonym for a long period of time against a sufficiently determined opponent, and quite a hassle to maintain even a modicum of decent security. Pointers to info and/or tools to enable the establishment and maintenance of a net.nym, beyond the standard cypherpunks PGP/remailer fare with which I'm now familiar, greatly appreciated. Especially nice would be a list of commercial net providers that allow pseudonymous accounts.""

</comment></comment></comment></comment></comment></comment><comment><USER18> There's probably some bayesian probability analysis that shows how likely each candidate is

<comment><USER19> A Bayesian approach would likely show how flawed linguistic analysis is. a false positive rate of say 0.1%, for example, over the 7 or so billion people who aren't satoshi would be huge

</comment></comment><comment><USER20> I think, more likely, it's Jed McCaleb. Also, I think a person who so carefully is trying to conserve his identity and was capable enough to come up with Bitcoin, will possibly hide his linguistic tracks as well.

<comment><USER21> I'm not so sure about hiding those tracks. Surely creating something big is challenge enough that you'd put all of your efforts towards mobilising your early adopters rather than hiding tracks just in case you became successful.

</comment></comment><comment><USER22> man, i don't know if i will ever be comfortable making any kind of judgement based primarily on stylometric analysis like that.

I could consider it supporting evidence in a mountain of otherwise overwhelming evidence, but I never anything to base a decision off of.

Are we going to end up having some kind of anonymizer that uses snippets taken from spam mails to compose emails, like a digital surveillance age mash up of spam lit and using words cut out from magazines for a ransom note?

[http://en.wikipedia.org/wiki/Spam_Lit](http://en.wikipedia.org/wiki/Spam_Lit)

</comment><comment><USER6> Both the title and URL of this HN post need to change.

</comment><comment><USER23> What? The guy outs satoshi(supposedly) and then puts a plug in for his "Shangri-La Diet" as a great advance in health?

</comment><comment><USER24> > I'm sure it's <name>

tl;dr: bullshit article

</comment><comment><USER25> "Those who know don't tell. Those who tell don't know." -Onngh Yanngh

</comment><comment><USER26> No, I am Satoshi

</comment><comment><USER27> I am Satoshi

<comment><USER22> i am spartacus</comment></comment>


2 years of the Hacker News London meetup - <AUTHOR> http://www.coderholic.com/2-years-of-hnlondon/

<comment><USER2> Thanks for all your hard work guys. It's one of the few meetups I try to attend every month, and I've seen some excellent talks over the years, and met some really interesting people. Highlights for me were Joel Spolsky, Eben Upton, and being proved wrong about Shed Simove! Good luck with your move to the valley Ben, and thanks to Dmitri and Steve for keeping it going.

</comment><comment><USER3> I remember when it was just a bunch of geeks hanging out in the back of a pub... now look what it's become! :-)

Major congrats to Ben and Dmitri for all their hard work on the meetup. Great work.

</comment><comment><USER4> I was studying one year in London and went to almost all Hacker News Meetups there. It was fantastic that these kind of events are possible. Well done and thanks to you both!

</comment><comment><USER5> Is it that hard to avoid stealing someone else's stylesheet unmodified? That's exactly the same stylesheet I had on my blog until a few days ago: [https://github.com/mitsuhiko/lucumr/blob/8ca68485ca230f772b0...](https://github.com/mitsuhiko/lucumr/blob/8ca68485ca230f772b04c30e48722b54465592ec/static/style.css)

Makes me grumpy :-/

<comment><USER6> Your site appears to be open source and you haven't mentioned anywhere that it isn't okay for someone to use your code. Your repository doesn't have a license or mention if it's okay for people to re-use elements, but I (and the OP too?) would assume that if it's open source (unless otherwise stated) it's free for anyone to use whatever. He probably should have given credit, but I don't think it would be considered "stealing".

<comment><USER7> By a reasonable reading, the linked repo is BSD licensed (see lucumr/about.rst).

If author didn't intend for some files in the repo to be BSD licensed, he should be more explicit.

<comment><USER5> What? The only thing with BSD it says is this:

> All of the open source stuff I work on is BSD licensed which means you can > do with it whatever you want.

Nothing about the website is open source work. It says that _if_ I make something open source it's BSD licensed. You can spot open source work because it comes with a license file that has an open source license in it. The website does not.

</comment></comment></comment></comment><comment><USER8> As the person who started the Hacker News Seattle Meetups and just celebrated our 1-year birthday... major props to Ben and Dmitri. I've talked with Dmitri a bunch of times and gotten advice on the Seattle meetup, and you guys really do a great job. :)

</comment><comment><AUTHOR> It's been a fantastic 2 years! The next event will be on Aug 23rd. See [http://www.meetup.com/HNLondon/events/77825522/?a=ea1_grp...](http://www.meetup.com/HNLondon/events/77825522/?a=ea1_grp&rv=ea1) for details.</comment>


EU proposes end of anonymity for Bitcoin and prepaid card users - <AUTHOR> https://thestack.com/security/2016/02/02/eu-proposes-end-of-anonymity-for-bitcoin-and-prepaid-card-users/ <comment><USER2> I think that people should be shielded from surveillance, and especially from surveillance by non government entities, in their everyday doings.

Like we can use cash in real life, we should be able to use something similar online.

This is especially true for the goods the may reflect you political opinions - like purchases of news papers or online articles.

</comment><comment><USER3> Please track everybody all the time - said no non-politician citizen ever</comment>


Show HN: Analog audio hardware on the cloud - <AUTHOR> https://watape.com <comment><USER2> More samples is always good. Is there pricing? This seems like it would be insanely hard to scale - I guess for some hardcore tape lovers it would be fine if it gets popular though it would be hard to keep up without charging.

</comment><comment><USER3> This is really cool! Please show some more recording samples before and after.

<comment><AUTHOR> I'll do! thanks for the feedback!</comment></comment>


Show HN: Particle Playground with Glowing Light - <AUTHOR> https://codepen.io/wonglok/pen/djPLZy <comment><USER2> If you're interested in developing this into a useful library, perhaps you should consider starting a Patreon (rather than a kickstarter). Having a monthly drip of money is probably a more sustainable model for an open source project than a lump sum payout with nebulous goals (that it looks like you've already achieved).

<comment><AUTHOR> thanks for your advise! Maybe I should give Patreon a try after the kickstarter :D this kickstarter is a quick-starter. [https://creators.kickstarter.com/quickstarter/](https://creators.kickstarter.com/quickstarter/)

It is mainly for making new backer friends or have a good relationship with my potential customer of my web visual effect dev tools.

thanks a lot for your help on overall direction of business model. have a super nice and happy day~!

</comment></comment><comment><USER3> I'm sorry for being slow on the uptake, but … what is it? I mean, I see four text panes and a glowing light, but why?

<comment><USER4> That's literally it. It's graphical particle effects. Think of simulating sunlight on water, or laser blasts, that kind of thing. Just happens to run in codepen, is all.

<comment><AUTHOR> Yes :D It's fun to play with the way things could be through imagination and code. :)

</comment></comment></comment><comment><USER5> Wow! That's an intense particle. I'm thumbing through the code now. Nice work so far!

<comment><AUTHOR> aww thanks a lot for your kudos!! :D You can try try replace similar code with these code...

vec3 ball1 = ballify(vec3(x, y, z), 1.0);

      nextPos = ballify(ball1 + nextPos, 17.0);

      nextPos.x += cos(nextPos.z - time * 30.0);
      nextPos.y += sin(nextPos.z - time * 30.0);

      nextPos += getDiff(nextPos, mouse * 17.0) * 50.0;

      gl_FragColor = vec4(nextPos, 1.0);</comment></comment>


Show HN: Dockerfiler: declarative management of images built from Dockerfiles - <AUTHOR> https://github.com/jbergknoff/Dockerfiler <comment><AUTHOR> Hi, I'm the author. Thanks for taking a look. This is basically a tool to help manage a "Dockerfile" repo (along the lines of [https://github.com/jessfraz/dockerfiles](https://github.com/jessfraz/dockerfiles)), where you build any tools you want into images that you control. This can be really useful for personal use or within a company.

Why build tools into Docker images? Love it or hate it, there are many senses in which Docker is currently the best medium that we have for distributing and running dev tools. Here's an article making that argument: [https://jonathan.bergknoff.com/journal/run-more-stuff-in- doc...](https://jonathan.bergknoff.com/journal/run-more-stuff-in-docker/).

<comment><USER2> this description is a lot clearer to me than the one from readme :)

<comment><AUTHOR> Thanks for that feedback! I'll update the readme.

</comment></comment></comment><comment><USER3> We've made all this so complicated. Instead of the beautiful simplicity based on UNIX philosophy (arguably), modern devops feels like a mishmash of ideas plopped together, tied with a bunch of yaml tape and god forbid if you ever want to look inside the stack of mess. Containerization is a great idea but flawed in its interface.

I like what Jim Keller (chip architect) says about complexity - that we need to throw away everything and start from scratch to which the interviewer asks, how often? Jim responds that currently chip architectures are re-done every 10 years but it should be more like every 5 years[1].

Just like any evolutionary process, there comes a point of diminishing returns because mistakes made cannot be corrected due to many other things that get piled up on _top_ of it. So, it is difficult to track back. What happens is more shit gets piled up on top just to patch up old mistakes. Like our laryngeal nerve that loops around from the brain, all the way to the cervical area and goes back to the voicebox[2]. It is even more evident in a Giraffe. A good architect wouldn't design anatomy like this. The reason why it is the way it is, is because evolution has no hindsight and marginal cost of _undoing_ the nerve is higher than just slightly increasing the length of the nerve. This is what we do in software. A good architect wouldn't design software like this. Sorry for the diversion, but I just feel so much pain with Docker, Kubernetes, Terraform and a whole load of AWS complexity. Holyshit.

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

[2] [https://en.wikipedia.org/wiki/Recurrent_laryngeal_nerve#/med...](https://en.wikipedia.org/wiki/Recurrent_laryngeal_nerve#/media/File:Recurrent_laryngeal_nerve.svg)

<comment><USER4> Sure it seems complex, but we're solving insanely complex problems that didnt even remotely exist during the halcyon days of "beautiful simplicity" of the ol' Unix philosophy. That philosophy was borne out of tools to process text files. It's closest proxy in the ops world might be microservices, but if you compare the amount of labor it used to take to set up a datacenter in even something so recent at the first dotcom era, its _insane_ what we can accomplish with a cloudformation yaml file or a terraform configuration file in a similar amount of time. The reproducability, the change management, all of it is light years better than it used to be. Every one of these 'yaml messes' all evolved out of drastically shittier shellscripts, duct tape, hope, and weekend pagers blowing up.

It might seem complex, and obtuse, but its turtles all the way down, and everything all the way back to to the original von Neumann architecture could definitely be looked at again and redesigned, but otoh, we're still doing weird shit like dividing our day into 24 hours and 60 minutes and 60 seconds for no other reason than 'its always been that way' and if we had a chance to actually design a sensible time system we could eliminate a lot of the complexity that has piled up on top of that system.

But yeah, no way would I ever want to go back to the way things were before all these layers existed.

<comment><USER5> There were just as many tools that existed during those "halcyon" days that didn't adhere to the UNIX philosophy. They just didn't tend to survive.

The one thing that hasn't changed is commercial (& ego) pressure to make the "one tool to rule them all", which has been pretty much immutable throughout the years, while on the other hand there is the reality of trying to string all of these things together.

Small, self contained tools with good APIs have persisted and will stand the test of time while the monoliths always die eventually (maybe with the exception of excel, which has really managed to cling on).

I don't think kubernetes or docker really have a bright future because they both have an ambition to be "the one tool to rule them all" and they simply can't.

</comment></comment></comment><comment><USER6> I am growing my anxiety as more layers to the Docker onion grow faster than I can stay current. In the past 2 years my company adopted kubernetes to manage our already confusing Docker infrastructure design, and then they added Rancher to it because no one was making sense of kubernetes.

Meanwhile we're shipping on five year old containers that everyone is afraid to update and no one remembers how to build them. We're building a skyscraper on a floating pier and trying to reach the moon before the tide changes.

I know this is the way, but I am having a hard time because it just doesn't make sense. This doesn't feel like process. It feels like compounding of reactions. Is it just me? My company? Or is this a general feeling?

<comment><USER7> Maybe I am stupid, but is there a problem in Docker build design? By default you should get both a Docker image and an artifacts.zip of binaries that it downloaded so you can pin them? The cache isn't just for speed. It allows for reproducible builds.

<comment><USER7> Also, Docker should have a reproducible flag that creates binary reproducible images. Timestamps and local system info would have to be nerfed to some default or fed in statically with a config file.

<comment><USER8> You can already make reproducible images of e.g. NixOS. I don't know if there's a good way to tackle the problem at the docker level without sacrificing container OS agnosticism.

<comment><USER9> My OS is a docker image, booted bare metal.

[https://godarch.com/](https://godarch.com/)

</comment></comment></comment></comment></comment><comment><USER10> See also Nix, which can declaratively generate Dockerfiles (example on home page) :-)

[https://nixos.org](https://nixos.org)

<comment><USER11> > declaratively generate Dockerfiles

This is inaccurate, assuming you are referring to the 'dockerTools.buildLayeredImage' function in the nixpkgs repository.

That builds docker _images_ declaratively, not dockerfiles.

</comment></comment><comment><USER12> So this is for me to easily manage all my linters, formatters and such in one image from a group of upstream, published images, right?

<comment><USER13> Looks like it. When developer tooling causes conflicts to install globally and tricky to configure with the project (say phpunit) then this can all be taken care of by building it within a docker container. However if the linting also dependent on a specific version of a programming language to test its code now you are no longer testing the production environment.

</comment></comment><comment><USER14> From the article:

> Docker is an excellent means of distributing those sorts of tools.

No, package managers are excellent means of distributing and managing installed tools. Docker is an excellent way to package the tools, but it's distribution and management are terrible. There isn't even a command to simply show which containers are considered "outdated" without having to repull all your images, which can take 10+ minutes on 30 images.

</comment><comment><USER13> I guess we are fixing our lack of compatibility story by encasing our tools in fixed environments. Then write new tooling when this is no longer usable.

That seems like a short term view of things.

</comment><comment><USER15> Pretty sure the name is ungoogleable.

</comment><comment><USER14> That is what I use Skaffold for

</comment><comment><USER16> I think I may be a bit slow -- I don't get it =/

<comment><USER8> You write declarative manifests that include source repos/tags and destination repos/tags and build arguments, and this thing figures out what commands are needed to get your container registry in the desired state. It outputs those commands. You'd then pass then to an environment that has access rights to make the necessary changes.

<comment><USER16> Ohhhh.

So the example in the repo being, you have some set of tools which you may want to run in CI/CD, or maybe every developer to have the same version of (linters, deployment tools, test runners, etc) and this will figure out the optimal way of pulling them so they're available?

Thanks, makes sense now I think.

<comment><USER8> Yep! Not only pulling them, but also building them and pushing them if needed.</comment></comment></comment></comment>


Ask HN: A new moderated email service for younger children - <AUTHOR>

I've just built this: https://www.pennyred.net/ and wondered if other parents on HN would find it useful and have feedback... <comment><USER2> It would be cool if this worked for facebook.</comment>


IGListKit – Data-Driven UICollectionView Framework from Instagram - <AUTHOR> https://engineering.instagram.com/open-sourcing-iglistkit-3d66f1e4e9aa#.iqblt2ay7 <comment><AUTHOR> Hey! I worked on this. If you have any questions let me know. Pumped that we could share this, eliminates a ton of common collection view problems.</comment>


Who marries who - <AUTHOR> https://www.bloomberg.com/graphics/2016-who-marries-whom/ <comment><USER2> This is fascinating, thanks for sharing.

It's especially interesting that female software developers seem to marry other devs, whether they're gay or straight, but gay male software devs tend to marry fitness workers.

<comment><USER3> It's interesting, but it doesn't surprise me one bit. It's exactly like what the article posits: that women marry equal or up, and men don't care that much. Obviously, it doesn't matter if the men are gay or straight; in both cases, they're quite likely to marry someone with a much lower-paying career.

Also, the premise that women only want to marry up (or equal) really explains why I see so many women on the dating sites in the DC area with high-powered careers (their positions are frequently shown right on their photo in Tinder), who seem to be perpetually single and whose profiles I see over and over. They're obviously not interested in me because 1) I'm a software engineer: software engineering is not seen as a prestigious career at all in this country, despite the pay, and 2) I don't have an advanced degree; many women are degree snobs and won't date someone who didn't go to an Ivy League or doesn't have a Masters or PhD, even though I likely make as much or maybe more money.

<comment><USER4> I think it makes quite a bit of sense if you're at all interested in having children and staying home with them for any amount of years to worry about the income of your partner. That description tends to apply more to females than males. Pick your poison.

Personally, I know I've prioritized dating men who are willing to stay home themselves since I don't like the idea of being a stay-at-home mom.

Anyway, just seems rational.

<comment><USER3> >I think it makes quite a bit of sense if you're at all interested in having children and staying home with them for any amount of years to worry about the income of your partner.

Sure it does, but these days very few women stay home for that long (out of women with well-paying careers). Also, more importantly, there's nothing stopping women with high-paying careers from marrying lesser-earning men and letting them stay at home with the kids, but as these statistics clearly show, women are simply not doing that: they're demanding partners who make at least as much as they do. (And they seem to be failing at finding such partners, and are then just staying single, and frequently (in my observation) going to a sperm clinic and getting artificially inseminated and intentionally becoming single mothers and hiring nannies to raise their kids.)

>Personally, I know I've prioritized dating men who are willing to stay home themselves since I don't like the idea of being a stay-at-home mom.

That's great, but you seem to be a rare exception. Very few women seem to be thinking that rationally, as shown by these statistics.

<comment><USER5> > That's great, but you seem to be a rare exception. Very few women seem to be > thinking that rationally, as shown by these statistics.

There's no causation shown this data. It takes two parties to be in a relationship and you have no reason to assume that it's primarily the woman making that choice.

If you want another anecdote, I've been dumped after disclosing I made more than my partner.

<comment><USER3> There's really no way to know without doing an extensive survey/study, but from what I've seen personally in the dating market, I think it's more a case of high-status-career women being overly picky than them running into too many men who refuse to date them because they earn too much. I'm sorry, but if you're 35+, you just can't expect Mr. (or Mrs.) Perfect; those people are already taken, and were off the market sometime in their 20s, probably even in college. The statistics here clearly show women rarely earning more than their husbands, and given how liberal people in large cities (where these high- earning women live) are, I refuse to believe, until I see better evidence, that this is just because of male chauvinism. I have personally seen _far_ too many profiles from these women who specifically say they won't (or are hesitant to) date men without an Ivy-League and/or non-graduate degree, for instance. If you're going to be that snobbish and picky, then no wonder you're still single (esp. these days when women outnumber men in universities, 60% vs. 40%). Believe what you want, but your singular anecdote about one experience with one single man vs. my anecdata about many dozens of women posting their requirements right in their public dating profiles makes me believe I'm right. Moreover, your singular anecdote is easily countered with my own: I have no trouble dating a woman who makes more, yet I've never had any luck dating such a woman, even in a city that's infamous for having a surplus of single women. (FWIW, I'm now dating someone with a good job, but she makes less than me. Honestly, I'd prefer if she made more but I don't make it a requirement in any way, that's just how it worked out.) Of course, you can claim there's something deficient about me, or that I'm aiming too high, but similar can be said of you or the guy who dumped you; a single data point just isn't that useful. But seeing common trends on dozens or hundreds of dating profiles, IMO, is much more so.

As for women primarily making the choice, that's true. Go look at OKC's data: women get FAR more unsolicited messages than men, that's a simple fact. The person who has more options has more power.

</comment></comment></comment></comment></comment></comment><comment><USER6> previous conversation: [https://news.ycombinator.com/item?id=11081575](https://news.ycombinator.com/item?id=11081575)

</comment><comment><USER7> who marries whom?</comment>


Why and how to search two years back in your Elastic search logs [pdf] - <AUTHOR> https://cloudvyzor.com/How%20to%20search%20in%20your%20ES%20snapshots%20-%20v1.2.pdf <comment><USER2> I don't get many 'new toy' moments with the unix CLI, and writing those words down makes me want to change that situation.

A number of years ago we had your typical low-disk-space-server problem and someone had bought us time by shortening the log rotation interval and compressing the logs. This is how I (re-)discovered zless and zgrep.

Streaming compression dovetails nicely with a number of kinds of tools, but seems to work particularly well on anything with pipe semantics. I'm certain that phenomenon informed the rather long tenure of the tgz file format.

</comment><comment><USER2> I was trying to refresh my memory of the BWT algorithm for compression the other day and stumbled on a guy doing a tutorial on how they use it for gene analysis/searches. One of his assertions was that suffix trees and BWT aren't that far apart, and it has me wondering.

Compressing text and searching text are both about identifying patterns. How much R&D have we done on trying to do both at the same time? Is searching for text in a compressed file in log(n) to sqrt(n) time a solved problem?

<comment><USER3> There's literature on this topic, it is called succinct data structures. Wikipedia got you covered as usual: [https://en.wikipedia.org/wiki/Succinct_data_structure](https://en.wikipedia.org/wiki/Succinct_data_structure)

</comment></comment><comment><USER4> This seems to use this: [https://cloudvyzor.com/downloads.html](https://cloudvyzor.com/downloads.html) Is it only on Windows?

</comment><comment><USER5> Is this an ad?

</comment><comment><USER6> S3 Select

</comment><comment><USER7> One issue with the title: the presentation says CSV and not JSON.

<comment><USER8> We changed the title to that of the article, as the site guidelines ask.

(Submitted title was "Convert: Elastic Search snapshots to zipped JSONs. 60TB to 3TB searchable [pdf]")</comment></comment>


Ask HN:Product Focus Help - <AUTHOR>

Hi HN,
For the past couple of weeks, I've been working on a couple products in the event/ticketing market. I need to buckle down and focus on one specific area, and I'm having trouble deciding which. Let me know what you think, or if you think of any other opportunities to explore.
1) Build a Search Engine for Facebook Events. Localize/Categorize the events. There isn't an official API to get ALL events, but there are a couple workarounds that could probably be used. Build a facebook app/website as a frontend for the events.
2) Build a Native Facebook application for creating events that you can sell tickets to. Essentially a "super" events app. Ticketing is built into the app.
3) Build a web app that integrates into Facebook Events. ie. You create an event on my website, I ask you if you'd like a facebook event, then I create it for you.
4) A Subset of (2), build an application solely for Facebook Pages that allows you to create events and sell tickets within the application.
I don't have a huge amount of time or resources, so I'm trying to figure out what the best MVP would be. I'd like to keep the product as simple as possible (obviously).
Please let me know if you have any suggestions, critiques, or ideas. <comment><USER2> I think number 2 could be huge, especially with Facebook rolling out it new credits/payment platform. Political campaigns and non-profits would love it for fundraisers. I ran a Congressional campaign and something like this would have been great.

I also now a bunch of people in the music/event promotion business locally that would be the perfect fit for this kind of app.

Some of the issues I think of at first glance for this kind of app regard around the physical ticket.

The process of selling the ticket digitally is simple enough but, getting actual physical tickets that work at the door is another task; especially if you take into consideration fraud prevention and some sort of pos mechanism(QR Codes by phone??) to verify the ticket in the case of larger events.

I'm surprised no one in the online tickets space is making a move to integrate the Facebook platform into their current ticketing offerings. Or are they?

I've got experience with events through politics, music, and some work on a web app for handling event registration for car shows on a car enthusiast social network. Feel free to touch base with me at schaecher.michael at gm if you want to bounce anything off me or whatever

</comment><comment><USER3> If it is only for use on Facebook, I would go for option 4, then expand to option 2 (if it's quicker).

If you plan to expand beyond Facebook, I would be tempted to start with option 1 and expand to 3.</comment>


Facebook announces anonymous login - <AUTHOR> http://venturebeat.com/2014/04/30/facebook-logins-are-going-anonymous/

<comment><USER2> The most important thing FB can do is win universal login. And the #1 thing it can do to promote that is restore some faith in its privacy commitment. This is a very smart move. Of course let's see how they implement it. If the process is too complex, it won't work for users

<comment><USER3> Facebook have got the 'Microsoft problem'. Microsoft is 'hated' by many people, especially in the tech community, because of their historical actions, even if many of their actions today are positive.

Facebook suffers the same fate. Anyone who has left Facebook over privacy concerns is unlikely to trust Facebook again.

Once bitten twice shy. Leopard doesn't change it's spots, etc

<comment><USER2> Quite true. There's still a shot for someone else to "win" universal login. But it's nearly impossible without tremendous scale.</comment></comment></comment>


Reasonable Anger In Europe Over Ridiculous Copyright Extension - <AUTHOR> http://www.techdirt.com/articles/20110913/03591515929/reasonable-anger-europe-over-ridiculous-copyright-extension.shtml

<comment><USER2> Hey copyright hoarders. We had a deal. The society granted you a limited time monopoly in exchange for the works going into the public domain after this time. You broke this deal by hands of corrupt politicians. I do not feel obliged to keep my end of this deal anymore.

<comment><USER3> Too bad they can still sue the shit out of you if you lose the bittorrent lottery and your IP is selected for public exemplary punishment.

<comment><USER4> Which isn't likely to be a concern anymore, since most people here would be smart enough to either use a private tracker (which isn't selected) or to use some filehost like rapidshare.

</comment></comment></comment><comment><AUTHOR> Obviously the labels are doing it for themselves, but even their argument that they're doing it for the (very old) artists isn't a good one. The purpose of the copyright was to ultimately create a richer culture, and to do that they needed artists to create works of art, but once they do that, the period of time for which they own the copyright should be optimized for "minimization" not maximization, so the society at large can benefit from them.

Copyiright was designed to ultimately help the society. Helping the artists protect their works is just a step towards that goal, not the goal itself. But sadly the labels are trying to make protecting the works the ultimate and _only_ goal of copyright, because they get to benefit even more than the artists themselves from that.

</comment><comment><USER5> I think that the advertisement incident in the UK a few yeats back was telling. A full page advert with a list of artists that supposedly supported the copyright extension. People noticed that some of the artists on the list weren't even alive, and some artists came out that they were never asked if they supported it or not.

</comment><comment><USER6> I just want to point one thing: As China is becoming the super-power (engine of the world), their view how copyright should be handled will become prevalent.

In other words, the majority of money to be made will be in Chindia and not in Europe and US. We need to prepare for that.

<comment><USER7> The USA will find the weapon of IP law etc. it has been building all over the world turned against it.

One would expect China and India to follow USA commercial practice and use the established structures of IP. But USA-IP is not intended to be good economics in the real sense, it is supposed to benefit the USA. When the USA is a net importer, it will be the loser. It will start to disavow international IP.

But IP is fairly dumb in an information economy so it must die out in the not too distant future anyway.

<comment><USER8> Historically speaking, it is far more likely than in 10-20 years, China will "see the light" and institute much stronger IP laws, once they have more stuff to protect, because your proposal is unstable; if the US starts disrespecting Chinese copyright, the historical outcome is a treaty, not mutual disrespect. If mutual disrespect were the stable outcome, we'd already see that.

<comment><USER7> Well, yes, disavowal is too strong: the USA will just try to reduce (international) IP. The main point is the turnaround.

</comment></comment></comment></comment><comment><USER9> Wait, so composers and lyricists get life+70 years? How long has _that_ been going on?

[http://www.telegraph.co.uk/technology/news/8759524/Will- copy...](http://www.telegraph.co.uk/technology/news/8759524/Will-copyright- extensions-ever-end.html)

</comment><comment> buff-a FTA: _They've sold out the public, who they're supposed to represent._

People keep saying this like its an opinion. This is the central fact of modern day politicians and government bureaucrats. Lets stop fucking talking about it. Lets get a voter measure on the ballot to criminalize it.

</comment><comment><USER10> I don't believe that a living creator should have to suffer their creations going into the public domain. Once dead, however, their works should transition to the public domain.

<comment><USER11> > Once dead, however, their works should transition to the public domain.

So we can make their work free once they're dead? That doesn't seem fair. What's wrong with something going into the public domain? It's not terrible.

<comment><USER12> Plus the chances of an "accident" occurring to the creator of very popular content increase.

</comment></comment></comment><comment><USER13> Any time period is going to be essentially arbitrary... but it seems to me that 20 years like patents, or maybe 30 years is plenty of time for the creator to derive value in the marketplace from their work.

These were never meant to be eternal, for good reason, and constantly extending them to me seems very corrupt... that this is favoring one group's interests over another.

<comment><USER14> This can (and has been) modeled using future value analysis (from economics). Since future payments are discounted (based on interest and inflation), extending copyright means that the value _now_ of creating a new work increases but by smaller and smaller amounts. Somewhere in the 15-30 year range is about "right" according to most studies -- the additional value of even an infinite extension is minimal at this point.

Then there's the economic value of a work: very few copyrighted works have an economic life of one year, let alone a century. This is particularly true since copyright protections were extended to _all_ works rather than just those which were registered with a copyright office (this post is copyrighted, however my economic interest in it is nil, still, it will extend for the next 120 years).

The real argument for extensions is _copyright term in works of enduring value whose copyright is about to expire_. This is the "Mickey Mouse Copyright Law" in the US. Walt Disney's first Mickey Mouse cartoon, "Steamboat Willie" (itself borrowing very heavily from earlier works) was published in 1928, and there's been a strong trend in extension to prevent works from at least this date from ever entering the public domain.

This results in the exceptionally strong protections of copyright being extended to a huge volume of valueless (and often ownerless in the sense that no true owner can be identified or contacted) to protect a very small number of works of enduring economic value, though by no means does this promote the directive in the US Constitution "To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries" (other nations have their own justifications).

<comment><USER8> While I'd love to see copyright terms just tuned down across the board, I could deal with a system whereby the next extensions required explicit renewals. For practicality's sake I might even be willing to put up with allowing owners to file one form for their entire catalog rather than enumerating everything, because if nothing else at least this would clear the zombie owner backlog.

<comment><USER15> I agree with this and I think you could even scale the fee for renewal up over time to discourage just automatic renewal of stuff that has almost no commercial value anymore. Seriously I could care less if disney wants to keep paying for steamboat willie to stay copyrighted as long as the fee keeps going up making them think about the value of doing so.

</comment></comment></comment></comment><comment><USER16> I genuinely give as much of a shit as I did before they extended it and I'm sure that is the case for the rest of the population.

This is more about PR and marketing than it is about law.</comment>