Show HN: How to start a business in France - <AUTHOR> Hacker News loves talking about the state of startups in France [1], and the particularities of our social security system [2].
There is no official answer in English on the Web to the question "how to start a company in France", so we've built a website to guide you through it with as little headache as possible.
https://mycompanyinfrance.fr
It's open-source software [3] built inside the French public startup incubator, beta.gouv.fr.
For those interested : does it convey most of the information you need ? What's missing ? It's the first iteration, and we're planning many new features.
[1]: Startup nation ? https://news.ycombinator.com/item?id=18066248
[2]: The French healtcare and pay as you go pension systems are also regularly discussed e.g. https://news.ycombinator.com/item?id=12998163
[3]: Source: https://github.com/betagouv/syso/ <comment><USER6> France is a fantastic country to start a company: very little things to pay until you actually make a profit, company creation process is easy, consequences for failure are very low to inexistant if you're a startup. And the state is there to help you get all kind of loans by offering guarantees to the banks for you.

<comment> saiya-jin Firing people is ridiculously hard in France. I would say quite an important point in case startup experiences anything else but ideal logarithmic growth, actually even in that case (realizing somebody wasn't a great hire after trial period)

<comment><USER7> You can fire at will for the first 4 month, renewable once, so practically 8 month, for IT people.

It's plenty of time to determine whether someone is fit for a job or not.

<comment><USER8> Short sighted / Incomplete. The odds are you'll be a service co, hence, "high" salaries. There will be up and downs in your sales, and you will find yourself in a cash crunch at some point - especially when you are "small" with just few projects at a time - and you will have to fire. If you do that by the book, you wont be allowed to hire for 2 years. It just makes it incredibly hard to manage, hence, the reluctance to hire quickly, and ... the thrive of consulting services (often more than 50% of the dev team are consultants ... ;-) ). It's a mess, for everyone.

</comment></comment></comment></comment><comment><USER9> Would be great to understand more about accounting requirements, recurring filings, costs of preparing and filing these and the business tax system in general. Also, are there any other demanding/taxis laws for a company with let's say 4 employees. What about sick leave, what about parental leave? What about if the first hire is underperforming, can you easily get rid of that person etc (important in startups with a handful of employees)?

At least in my case, I would want some information regarding that so I could decide if incorporating in France is a good idea, compared to let's say Estonia or the US.

</comment><comment><USER10> I'm slightly surprised to see that not only is this in English but there isn't even an obvious option to switch it to French. That's pretty un-French in the first place.

It's interesting to read the SARL process and compare it with the UK one: [https://www.gov.uk/limited-company-formation](https://www.gov.uk/limited- company-formation)

In the UK, not only is a company bank account not a prerequisite, it's the other way round - you form the company first. There's no requirement to notify a newspaper. There's no minimum capital requirement. The minimum filing requirements are pretty light.

The more I think about social security requirements, the more I think they should just be paid out of general taxation and not entangled with a particular relationship of "employment".

<comment><USER11> > The more I think about social security requirements, the more I think they > should just be paid out of general taxation and not entangled with a > particular relationship of "employment".

In France they are too, with the CSG and CRDS.

<comment><USER12> Interestingly (?), courts disagree about the legal nature of the CSG/CRDS (see [0] for some information):

\- According to the Cour de Cassation, it is both a tax and a social contribution \- According to the Conseil Constitutionnel, it is a tax \- According to the Conseil d'Etat and the EUCJ, it is a social contribution

[0] [https://fr.wikipedia.org/wiki/Contribution_sociale_g%C3%A9n%...](https://fr.wikipedia.org/wiki/Contribution_sociale_g%C3%A9n%C3%A9ralis%C3%A9e#Nature_de_la_contribution)

Slightly off topic but for foreigners who are interested, the welfare state (called Social Security, the word thus a much broader sense than in the US context) in France has been created as a separate entity from the Government.

It is managed by workers' representatives and employers' representatives. Since, in the end, it is the Governement (the Parliament, to be exact) that make laws, including those related to the Social Security, it has as much power over this sytem as it wants.

Nonetheless, this leads France to have technically two different budgets - <USER2> Government one and the Social Security one - with their own bills and two systems of taxation - social contributions, which go to the Social Security budget; and taxes, which go to the Government budget.

OVertime, social contributions - which are computed on labor income - <USER3> been cut, especially for low wage earners. The shortfall in financing has been partly compensated by transferring tax revenues to the Social Security.

This leads to weird public accounting and public debate: for instance, there is much talk about the Social Security deficit or even specific branches of the Social Security (since they are all financed by their social contribution), missing the fact that it reflects completely arbitrary ways to earmarked specific taxes to different part of the Government.

Another example of weirdness in the public debate because of this is the enormous importance of the "income tax" in the public debate, and especially that few households pay it and most of the money comes from a minority of household ... but the "income tax" actually brings _less_ money than the CSG, which is a tax on income that is different thatn "the income tax" (impôt sur le revenu). Because of the names and the arbitrary accounting practices, the vast majority of income taxation is completely out of the public debate radar.

</comment></comment></comment><comment><USER13> This is amazing. I wish such site was available in french when I created my company, you should consider it.

<comment><AUTHOR> Thanks ! That's our next step. Looking for a way to translate it in a collaborative Web interface.

</comment></comment><comment><USER14> Looking at the cost of hiring, it's crazy to see that the employee only gets ~50% (or even less as the salary grows) than what the employer pays.

This makes it very expensive for an employer to pay their employees well, and explains very well why salaries are so low in France.

Something else to note is also employment laws, which are way more strict in France and makes it either extremely expansive or just impossible to fire someone, the cost of hiring seems to be way too high for startups, which are business why high risks already.

<comment><USER15> That's because in France you get indirect salary as well whereas in other countries you have to pay some of those things from the indirect salary from your own pocket. To compare to a US salary, I would personally add 30 to 40% to those raw figures to reflect external costs.

> Something else to note is also employment laws, which are way more strict in > France and makes it either extremely expansive or just impossible to fire > someone, the cost of hiring seems to be way too high for startups, which are > business why high risks already.

No it's not, first there's the trial period for permanent employees where you can fire at will and then once it's over, you can still do it but you need to motivate your decision & respect the process.

<comment> saiya-jin There is no concept of indirect salary I am aware of. Do you mean that medical insurance is paid straight out of your salary to the state? This is a huge benefit to US, but only US - all european countries apart from Switzerland have this, and many other palces around the world too.

Or you mean social insurance? Same story, you pay it from the money your employer pays you, its just that you don't do it by yourself - company ha to do it for you by law.

<comment><USER15> They also created a calculator if you speak French: [https://embauche.beta.gouv.fr/](https://embauche.beta.gouv.fr/). So the employer also pays the retirement, health insurance, unemployment benefits, work accidents and family benefits.

<comment> saiya-jin It's a big fat lie that employer pays anything - employee pays it all, from money employer is willing to pay him/her for work done. No matter how we wrap the facts, this won't change. It doesn't matter that its taken away before it reaches your account.

I understand the motivation - people would be properly pissed off if they realized state is taking 50-70% of their income prior to letting them get the rest. And then they are taxed more with VAT, housing, fuel etc. Of course there are services given back, in some cases very substantial and helpful (and in some cases very wasteful and useless), but never forget the fact that you pay for it with most of your income, like it or not.

</comment></comment></comment></comment></comment><comment><USER16> Very cool ! Seeing the french gov having a post on hn is amazing !

</comment><comment><USER17> Before considering creating a company in France, check the position of this country in the 'Employment flexibility index 2018' [1]. France has the worst ranking...

Before doing this kind of marketing, do the essential updates first and companies will blossom all over the country.

[1]: [https://en.llri.lt/wp-content/uploads/2017/12/Employment- Fle...](https://en.llri.lt/wp-content/uploads/2017/12/Employment-Flexibility- Index-2018_-LFMI.pdf)

<comment><USER18> Maybe the author doesn't have the power to do said updates :). Does a low flexibility index indicate that companies should not be opened in France, or even considered? Your point is totally valid, however I don't see how it invalidates what OP worked on

<comment><USER17> Reality always comes back to snag you out of delusion. And reality is that France is not attractive. Without core modifications this kind of initiative will be close to useless.

(I'm one of many french engineers who left France to have a decent career)

<comment><USER18> Same here. I left because France is not attractive indeed. And I also agree core changes are needed to make France attractive for entrepreneurs.

At the same time, the points that OP makes are still valid :). For someone that wants to open a company, social aids and healthcare access can matter. Other countries are more open than France is, but it doesn't make France a black hole where nobody can make a good career. The Paris tech scene is most alive.

<comment><USER17> You're right that this initiative is one step in the right direction. I don't want my comments perceived as too negative. I'm one of the people singing "Let's make France great again!"

<comment><USER18> Amen to that !

</comment></comment></comment></comment></comment></comment><comment><USER19> Huh. This is really interesting. I'm currently living in Paris and have been talking to my (French) girlfriend about starting a business. Does anyone know of any other good resources?

</comment><comment><USER20> Congrats for the successful Show HN maelito.

If you're located near Paris, we are starting a new meetup about programming and startups. The first drink will be held the 6 november near Bastille (where the French Revolution started):

[http://meetup.com/dailyprog/events/tmsrjqyxpbjb](http://meetup.com/dailyprog/events/tmsrjqyxpbjb)

I hope some people from Beta Gouv will come. I do my best to promote that new community (especially towards VCs).

Feedbacks and insights are welcome :-)

</comment><comment><USER21> This is useful and very smooth. Taking it for a test-run and as this is Show HN I'm not being picky, just some feedback.

On 'How much does it cost to hire?' [https://mycompanyinfrance.fr/social- security](https://mycompanyinfrance.fr/social-security)

* I love that you can just choose one on the 4 input boxes and the others calculate. Lots of flexibility to let the user focus on what input they have and answer they want

* There's not an indication whether figures input are on a monthly basis, annual, or other. This affects the tax calculation: Entering 300, 3000, 30000 gets non-linear scaled results - <USER4>

* When re-clicking a field, previously entered digits need to be manually deleted rather than the field resetting - minor just my preference

* The breakdown of where contributions go lower down the page is great

* I'd input an existing French company that came to mind. Finding the 'This is not my company' link took a few minutes - <USER5>

There is a fastidious amount of detail. You seem to have been very thorough e.g. bicycle allowance.

Does France also have tax, social insurance or benefit differences between cities/regions? Is it material? Is it worth the time/cost to manage?

On the reverse side, does France provide incentives regionally or based on city for starting companies?

For the above couple of questions, my context for asking:

I live in China and there's a lot of interest/very simple questions about tax that individuals and companies have. A handful of consultancies put online calculators for things like employment cost online and cover major cities (Beijing, Shanghai, Shenzhen, perhaps Hangzhou and similar) where social insurance contributions may vary.

They do this for free as a lead for their consultancy practices. They don't put calculators online for things like city- industry- specific incentives because this is a moving playing field with hundreds of cities moving incentive goalposts each month, it isn't practical to be accurate.

Are you looking for synergies with not only demystifying social security, but for example 'find an accountant' and 'find an office'. The potential for rabbit holes could be large, but also a very nice one-stop hosted CaaS (Company as a Service).

</comment><comment><USER22> One nice feature to consider adding is linking to the official French regulations for each item you explain in English. This would be helpful for someone like me who can read French but doesn't know where to look. To me this would add a level of trust to your comments/Advice.

</comment><comment><USER23> I went through this process myself recently and found it to be pretty challenging to understand the differences between the company types - particularly since my french is still pretty weak. This is a great resource though, wish I knew about it sooner!

</comment><comment><USER24> "any idiot can start a business, but it takes a genius to exit one without harm" \--unknown

</comment><comment><USER25> what are the advantages of opening an llc in france compared to the US/UK/HK?

what about taxation?

how easy can I take money out of the company?

how easy is it to close a business?

couldn't find anything on the website. is there a gov.uk equivalent i could check?

<comment><AUTHOR> Taxation is one of our next features. How can the director pay itself (salary, dividends) is also on the list.

</comment></comment><comment><USER26> In Europe you can't fire employees.

It makes it nearly impossible to run a startup. It is the very antithesis of running a startup.

Unless you get lucky and can survive by hiring contractors, just forget about starting a startup in Europe.

Source: 2 startups in Europe.

<comment><USER27> First of all, why do you need to fire employees to run a startup ? I don't think this is a major need in the development of a startup in fact firing someone is dangerous since you lose experience and knowledge.

France as many countries in Europe have laws that protect employees against abuse from companies but you can still fire someone if there is a reason it is just regulated.

</comment></comment><comment><USER28> I am French and I applaud at any initiative to help the part of the French economy not under the government control (circa 45%)!

1\. But even if my browser is set to English, I see French on [https://embauche.beta.gouv.fr/](https://embauche.beta.gouv.fr/) and most of the issues on the Github repository are written in French! What signal do you want to send?

2\. As one can find on "[https://embauche.beta.gouv.fr/"](https://embauche.beta.gouv.fr/") the employee gets only half of what the employer pays.

Contrary to what is stated on the same site, one employee does not get much benefit of what the employer pays for her retirements and healthcare, because:

* if she is hired now, there is a good probability that she will have only a little retirement pension in 40 years, even if the law does not change. (probably close to the minimum salary, at least I hope so). So all this considerable amount of money will be wasted in the state and the "sécurité sociale" deep pockets.

* It is the same for the health fund: What makes the French health system seems free for workers, is that they have a mandatory mutual [0] which pays for most of the costs. The "Social security" pays around of 10% of most usual costs, the mutual fund pays the rest...

Most French companies are trying hard to use other schemes for paying better their employees, for example because they have some company investment fund, but "shut...".

[0] This website is provided by the URSSAF, the French social security contributions collector"

<comment><USER13> Why spreading FUD?

Social security paid for 76% of all medical costs in 2014 (last numbers I could find).

92% of hospital bills 64% of doctors visits 62% of drugs, glasses and such. Most prescribed drugs by your doctor being reimbursed 100% you don't even have to pay at the pharmacy.

[http://www.vie-publique.fr/decouverte- institutions/protectio...](http://www.vie-publique.fr/decouverte- institutions/protection-sociale/risque-sante/depenses-sante/quelle-est-part- securite-sociale-financement-consommation-soins-biens-medicaux.html)

You also have a very simplistic way of understanding how our retirement pension system works and the role it has in the society.

<comment><USER28> > Most prescribed drugs by your doctor being reimbursed 100% you don't even > have to pay at the pharmacy.

Not paying at the pharmacy does not mean that you do not pay at all. You pay three times: Your employer pays for you a huge amount, you pay (look at your payroll), your mutual fund pays.

Most people pay much more indirectly during their life than they receive services through the SS.

<comment><USER13> You just described how insurance works.</comment></comment></comment></comment>


The IRS will ask taxpayers if they own cryptocurrencies in new 1040 tax form - <AUTHOR> https://www.theblockcrypto.com/linked/42960/the-irs-will-ask-taxpayers-if-they-own-cryptocurrencies-in-new-1040-tax-form <comment><USER2> Boating accident, all the crypo's fell into the water.

</comment><comment><USER3> Is bitcoin a virtual or a digital currency?</comment>


Ask HN: What are important CLI / bash commands for a full stack dev to know? - <AUTHOR>

I created a prioritized list of CLI commands for full stack developers that reflects important basics or will improve productivity - and am looking for contributions and feedback: https://github.com/nemild/cli_for_full_stack
Current documentation (like a man page) is typically exhaustive, doesn't sort by importance/usage, neglects common compound flag combinations, and is not located in a single doc. For example, for grep I want to know the top X ways to use it and some background about when they should be used - not everything. Further, there are a lot of HN posts about developers' favorite piped commands  (I call them command cocktails - where multiple commands are used on the same line with outputs flowing into inputs) that are spread over HN comment threads - and are primarily communicated today by word of mouth to new devs. I've culled the top HN posts and comments on the CLI over the years - plus a few websites to put together this list.
Pull requests highly encouraged. <comment><USER2> What's your goal here? Are you trying to ensure that that people know how to run commands, that people use the same forms, or what?

Compare your question with:

"What are the most important English/Language keys for a typist to know?"

The most important command depend on context. If people know "the basics" they'll be fine with the rest.

<comment><AUTHOR> I made it as a reference for newer engineers to feel that they had the basics to be productive. When I started: 1\. I found myself consulting 20 different resources, not 1-2 2\. Was often unsure what commands were important 3\. Had a hard time finding the most used examples (it often is passed down by word of mouth)

Clearly, it depends on context/audience (e.g., if you're a data scientist and work with CSVs a lot vs. a frontend eng) - but I wanted a good baseline (say for a strong startup eng) without getting too esoteric.

Not sure I've achieved that, but appreciate your further feedback or pull requests.

</comment></comment><comment><USER3> Welp, there was a few programs I've never heard about, but the "Keyboard Shortcuts" section was the most shocking for me. No one ever told me!</comment>


Down with Homework, Say U.S. School Districts - <AUTHOR> https://www.wsj.com/articles/no-homework-its-the-new-thing-in-u-s-schools-11544610600 <comment><USER2> I'd be concerned for these students about the transition to post-secondary education, where homework is still largely required for success.</comment>


Going back to BASIC - <AUTHOR> http://sdtimes.com/sd-times-blog-going-back-basic/ <comment><USER2> BASIC rules. I still remember most of it, and could likely code in it today if I had to.</comment>


A list of everything in the multiverse - <AUTHOR> http://orteil.dashnet.org/nested

<comment><USER2> Cached: [http://webcache.googleusercontent.com/search?q=cache%3Aortei...](http://webcache.googleusercontent.com/search?q=cache%3Aorteil.dashnet.org%2Fnested)

<comment><USER3> This must be for an mmporg, then? I drilled down to a continent on a planet, and into a realm and then a castle, and then into a woman's memories, and even the body and mind of a bacterium on her left leg. (The bacterium's only thought was "I'm one cell of a guy.")

<comment><AUTHOR> It's not for anything, it's just for fun, according to the source code.

</comment></comment></comment><comment><USER4> This is simple rule based generation. Every type of node has certain pseudo random distribution of children. So you pass seed object (by default universe, but comment in source specifies it can be anything), and then programmatic pseudo-random on the fly generation magic happens.

</comment><comment><USER5> What's a Qwubble?

<comment><USER6> And what's a stackoverse ?

[edit] is that even a theory ?

</comment></comment><comment><USER7> 503'd.</comment>


Twenty reasons why it's kicking off everywhere. - <AUTHOR> http://www.bbc.co.uk/blogs/newsnight/paulmason/2011/02/twenty_reasons_why_its_kicking.html

<comment><USER2> Maybe the thing we see here is not "contagion" but "critical-mass".</comment>


Creating a type checker magic function in IPython - <AUTHOR> https://switowski.com/python/ipython/2019/02/08/creating-magic-functions-part2.html <comment><AUTHOR> Hey,

I've been writing a short series of articles about magic functions in IPython. If you are curious how to:

* Run JavaScript or Ruby code without leaving IPython

* Create a type checker that will use mypy to check blocks of code in IPython

* Or what is the difference between "line magic", "cell magic" and "line and cell" magic functions?

then check out the second part of the series: [https://switowski.com/python/ipython/2019/02/08/creating- mag...](https://switowski.com/python/ipython/2019/02/08/creating-magic- functions-part2.html)</comment>


The software industry is going through the "disposable plastic" crisis - <AUTHOR> https://lwn.net/Articles/829123/ <comment><USER2> People blame developers but it's all driven by a product mentality that favors rapid iterations and technical debt to run business experiments on customers. Slow-and-steady, carefully written software isn't tolerated within many product orgs these days.

<comment><USER3> I am really hating working in the current state of the industry right now. I am used to writing robust, clear, well-tested, and _easy to maintain_ systems.

The job right now seems just stitching AWS services together, and spending the rest of your time debugging and putting out fires.

<comment><USER4> The lie we tell ourselves is that the quality of code matters to non- engineers. It seems it doesn't.

The most uncomfortable truth of our field is that there is _no_ floor for how bad code can be, yet still make people billions of dollars.

Because that's the outcome everyone else is seeking - making money. They don't care how good the code is. They care about whether it's making money or not.

<comment><USER5> Haha the non-engineers at my place don't care at all about code quality.

The non-engineers also decided to write their own internal tool, with no review and zero attention to quality. It's been outputting wrong results that will cost them a few million at least.

<comment><USER6> Reminds me of the job where we'd have huge slowdowns in our massive SQL Cluster because some non-engineers in "R&D" "had" to run unoptimized, barely legible Access queries against it.

We eventually had to create a replica of Production specifically for such nonsense.

Well then we moved a lot more business logic that they "helped develop" that ran on a distributed platform closer to "real time" for the application, because it was very dynamic in nature, and couldn't be denormalized back into the DB and remain performant. So I had to build a new system for some of their ad hoc queries and teach them how to use it.

What eventually chuffed me was realizing the "R&D" person I was "training" on the system always wore a different three piece suit every day and at least in fashion signals was probably making a magnitude higher salary than me for slower, wronger answers than any system I worked on, but probably was great at throwing it (very slowly) into very fancy graphs in Excel and useless salesmanship.

There were a lot of reasons I already wasn't long for that job at that point, but that was a lasting lesson that quality and performance won't matter to certain styles of upper management.

</comment></comment></comment></comment></comment><comment><USER7> Something like four years ago I wrote a command-line tool in Rust to interact with a service I wrote (not in Rust). Then I left that company for a new job.

At a recent happy hour, I learned that despite nobody there having much of a clue about Rust, they were able to clone the repo, build it, and run it based on a short wiki page I left behind. I thought that was really cool, and a great validation of the care the Rust project takes around dependency management and backwards compatibility.

<comment><USER8> One of the more attractive things about Rust for me is that I can easily write portable code. I distribute Windows binaries for a certain Rust project and they've kept working despite the fact I haven't tested on Windows in years.

I'm not sure I would even know how to _build_ any of my C/C++ projects on Windows.

<comment><USER9> > they've kept working despite the fact I haven't tested on Windows in years.

How do you know? :)

Cross-compilation, avoiding the need to _build_ on many different systems, is great - but I'd still want to _test_ on all those systems.

<comment><USER10> As a Windows user, I see the other side of this, and it is usually true. It is easy to run in CI, maybe that's part of it.

I'm not sure exactly how it's the case, but I've been thinking about it a lot lately; I had a convo on HN last week about this...

</comment></comment></comment></comment><comment><USER11> I am reminded of the profession "programmer–archaeologist" in Vinge's _A Deepness in the Sky_. In roughly 2010 I reminded my grand-boss that a great deal of the important business process we had consisted of largely uncommented C and various mismashes of shell scripts.

It's true, there's something about all of the frameworks and the fads and such which causes so many projects to need, well, continual attendance to the dependencies. One proposed platform at a previous job bothered me for reasons I could not explain, so I mapped out the major dependent technologies, pointed out that we had nobody who had even a passing familiar with with them, and also pointed out how quickly some of them were moving.

There's something to be said for keeping your tower of dependencies short. It's a tradeoff, to be sure.

<comment><USER7> I absolutely love the vision of software technology in the _Fire_ / _Deepness_ books. The "zones of thought" concept dovetails nicely and lets him expand on those ideas, too. Highly recommended reading (for that and a bunch more reasons).

<comment><USER12> I have put off reading this book for so long. Now I have the reason to pick it up!

</comment></comment></comment><comment><USER13> I've found that the further back in time you go, the harder it is to run programs without encountering odd bugs, until you hit a certain inflection point where the systems are so old that they're relatively simple to emulate, and for popular systems we often have high-quality emulators that are capable of running the software reasonably well. For example, try running Diablo 2 (released in 2000!) on modern Windows, or modern macOS: it's not straightforward or bug-free, in my experience. It's reasonably good on Wine, ironically — because the Wine developers have built a really good emulation layer.

I don't think it's (application) developer fads; how would that even make sense? Either the OS broke userland, or it didn't; if it didn't, then the same binary should run just as well today as it did then. If it _did_ break userland, that's not the fault of application or framework developers.

<comment><USER14> I agree to a point, but there are harsh realities to this.

To name just a few off the top of my head, where there is no _choice_ in whether the userland changes or not:

\- Cipher suites and crypto protocols changing often end up "cutting off" older applications because they used an embedded SSL library that can't do TLS 1.2. This is required because vulnerabilities are discovered in older protocols and they _must_ be turned off.

\- Changes in the CPU instruction sets. For example, it is not possible to run 16-bit Windows binaries in a 64-bit host OS, but there are no 32-bit supported versions of Windows. Even if the majority of the code is 32-bit, a tiny 16-bit component can be a showstopper. I had to support a large (20K concurrent user!) environment that ran a 16-bit DOS application. On Windows 2008 32-bit. In the year 2015. Really.

\- I've seen apps that just can't handle high performance CPUs or multiple hardware cores, simply because they were written in an 100MHz single-core era. I've seen all sorts of timing issues, deadlocks, etc. For example, one particular release of World of Warcraft simply couldn't patch the game on 4-core CPUs, because one task would race ahead, time out, and then deadlock the downloader utility. That persisted for about a year, because Blizzard thought it was "okay" to support only 99% of their userbase that had 2-core processors that were common at the time.

\- If you app has _any_ external dependencies of any kind, its days are numbered. License servers. Update checkers. Content providers. Cloud services of any kind. Whatever. It's going to be turned off eventually, and the app will stop dead.

<comment><USER15> > there are no 32-bit supported versions of Windows

Windows 10 has a supported 32 bit version

EDIT: It support 16 bit apps too: [https://www.groovypost.com/howto/enable-16-bit- application-s...](https://www.groovypost.com/howto/enable-16-bit-application- support-windows-10/)

<comment><USER14> But there's no server version with 32-bit support, but this application required server components not in the desktop edition.

</comment></comment></comment></comment><comment><USER16> Problems linked to this:

\- Developers wanting the last shinny programming language instead of mastering one.

\- Developers wanting the last shinny framework instead of sticking to one and learning it inside out.

\- Developers wanting to start projects from scratch instead of learning to refactor. The new code is full of tech debt half a year later and some developers already want to move on to some new code because if you don't know how to refactor and evolve architecture your new shinny product lasts clean a few months.

\- Developers that care more in the hiring process that you know the latest version of the framework/platform/library but do not understand algorithms, data structures and other basic stuff. They think that functional programming is something new that starter 2 years ago, because it is the first time they heard about it.

In my experience business pushing for new features is only half the problem, approaching development as fashion instead of engineering is the other half.

<comment><USER17> Very much agree (friendly tip it's 'shiny' with just one 'n' btw)

</comment></comment><comment><USER18> The rich irony is that the problem is probably due to our reluctance to throw- away old code and rewrite better software with improved domain understanding. But that requires thoughtful and disciplined stewardship. Instead we recklessly patch leaky abstractions on top of each other because we're too lazy to work from scratch and are focused on "shipping" instead (cue: Titanic).

We are so afraid of reinventing the wheel and actually having to understand something that we will happily refactor out a car wheel and use it for a bicycle (hey, "code reuse"!) and play the charade of "best practices".

Software is one context where we don't have to worry about "disposing off" waste; we ought to make much better use of that.

<comment><USER19> Actually I feel it is the opposite of that. Existing code can be battle tested and reliable, with lots of unforeseen bugs encountered and fixed.

But those bugfixes made the old code difficult to work with, and rather than take the time to understand it, new code is developed instead with a whole new set of bugs (many having been solved previously). Working with old code is unexciting and unsexy anyway, and it is unlikely to advance your career. And so the cycle continues.

<comment><USER18> The contrast between the two perspectives depends on the relative emphasis between human understanding of the domain knowledge and accumulated domain knowledge in pre-existing code.

Biased by the domains I have worked in, I feel that we undervalue the human ability to figure things out and create good solutions, and overvalue code that is available for "free" even though it addresses a problem only tangentially related to what one is doing. My comment pertains mostly to such situations. In situations where the opposite is true (the domain in mostly static, and the old code is a good fit, and we don't trust human intelligence to figure things out and solve problems), "stable" code is certainly valuable.

<comment><USER20> I agree with both sides to a degree. The tendency to use monster truck wheels on a shopping cart or vice-versa (because reinventing the wheel is considered evil) makes software a mess, but so does throwing out years of debugging subtle/rare conditions.

Code reuse however also tends to add tons of bloat and potentially bugs caused by things that aren't even relevant to the current usage. Not to mention all the added complexity of having to add another layer over to translate the current terms into the terms the re-used code understands and then override what it does and translate the output.

There are some cases where it would be preferable to preserve the embedded domain knowledge, but in many cases the cost of 'reinventing the wheel' would be less than adapting an unfit wheel.

</comment></comment></comment></comment><comment><USER21> "You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

When Joe Armstrong said this he was talking about object-oriented programming, but it applies to dependency hell as well.

</comment><comment><USER22> Pretty much any electron app you download is probably tied to a backend and will fail if their servers go offline. It is kinda sad. Electron apps are usable as long as the company is really iterating forever.

Is the real problem that we're overemphasizing UI and React and UI frameworks so much that we're now just really focused on building really pretty apps that have little or no long term usefulness? At this point it feels like full Companies are just Apps and those companies make something that fills exactly one need, like renting a broom from your neighbor. And it's really pretty and they had the best lawyers in the world thinking about all the potential legal nightmares of neighbors renting brooms that it really is a great app, should you ever need to rent your neighbor's broom. Or you can walk over to your neighbor and borrow it.

<comment><USER21> Wait, what??

Electron apps contain a local web server. (That's part of the reason they're such resource hogs.) In principle at least they work offline. Github's desktop app, for example, works fine on a disconnected machine. You obviously cannot push or pull, but you can do local git operations with the GUI.

<comment><USER23> Electron apps contain _an entire headless browser_. How anyone ever thought this was a good idea blows my mind.

<comment><USER21> I actually think it would be a great idea iff they would use a webview, which every OS provides nowadays. Apparently I'm not the first person who's thought of this.

[https://blog.stevensanderson.com/2019/11/01/exploring- lighte...](https://blog.stevensanderson.com/2019/11/01/exploring-lighter- alternatives-to-electron-for-hosting-a-blazor-desktop-app/)

<comment><USER24> That strategy of "web applications on the desktop" was actually pioneered over 20 years ago by Microsoft:

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

Even in the Windows world, they were never all that popular.

<comment><USER21> HTAs were not cross-platform; Electron is. Furthermore HTML5 and JS are much more capable now than they were prior to Windows Vista.

That's why Electron is popular and HTA wasn't. But Electron is still the worst possible example of the resource inefficiency of static linking.

</comment></comment></comment></comment></comment></comment><comment><USER25> How closely can we can link the rise of SaaS (and corresponding disposable frameworks) to an effort to find a stable revenue model in a world which had problematic levels of software piracy? I remember when I was a teenager, you might be looked down upon if you obtained your copy of Windows XP legally.

There are a lot of posts like this that bemoan the current state of [insert social ill] but don't care to explore what structural forces contributed to this state.

<comment><USER26> Actually a very salient point.

Still, I don't like the reality because it obscures the bad parts of where we are.

I've seen a _slew_ of software licencing models in my travels. I hate where we have wound up.

Some of my more-appreciated ones:

\- Not-Crappy-Hardware-Lock: \- When I was in the RF/HFC Drafting industry, a very entrenched program was utilized for most signal level calculations. This company used a solution that involved a Parallel or USB Device that took a Vendor-provided Dallas one-wire device. You paid X$ for the software, you had updates up to X date with that key. They did have a way to 'upgrade' but I don't remember what that involved as we never did it. The system seemed fair, I'm guessing it was fairly PITA to hack (remember, in this industry you have access to a decent number of people with good signal analysis equipment) but also had a fair cost standpoint. \- It was nice that "Who can use it" was just tossing a key around.

\- Usage + Audit: \- Same industry. Market forces led us to also have a product from a vendor that also competed with the biggest CAD vendor out there. This company essentially had a multi-stage setup; The systems running the software would check in with our locally-installed license server running on a box, license server would periodically check in with vendor's home-base server (uploading our usage data and downloading some response, I'd assume). If there were any issues with our usage the vendor would call us and inquire as to what was up. \- If your machine was not going to be able to check in to the license server (i.e. Field use, this was also before mobile hotspots were cheap, and not too many corps had proper VPN setups) you could 'check-out' a license and generate a time-expiring key \- They were WAY WAY more than fair. Our usage was balance out based on some algo on their end. IDK quite how it worked, but for example; if you had 3 licenses, didn't use any Monday or Tuesday, 2 on wednesday, but then had 4 people simultaneously using on Thursday/Friday, _they didn 't care_. \- When somebody who may have been me left the app up for a month _and_ had a checked out license for a laptop, while we were in crunch mode and others were using the application, we eventually _did_ get a phone call. But even during the conversation they discussed the amount of logged time and it didn't result in any penalties or fees. \- We got updates as long as we paid a fairly low maintenance fee. If we stopped paying updates, we only could use up to a certain version. \- Seriously, maintainers of the DGN format, you guys were amazing about licensing and just great to deal with.

\- Per-Seat licenses: \- Arguably the most fair \- You know what you're getting \- Can do either with a central reg or reporting server \- Possibly more balanced than above towards vendor, definitely lower maintenance level.

\- Jetbrains style licensing: \- Similar to Usage + Audit, but only the usage part \- Works well. I dig it. \- But seriously, what is up with the awkward 2-factor setup?

\- SAAS: \- How would you like to be charged today? \- Vendor Lock-in \- Change Friction \- Don't own the hardware \- Offloading of liability

Unfortunately, SAAS wins out because it's the best way to make money, especially when one considers that _last_ bullet point. But also, when you consider 'base' charges versus 'overage'; as an industry we might be diving head-first into the same malarkey that we have complained about in places like this, or forums, or even usenet groups; the forced minimum pricing/bundling of services.

What's ironic here (for me,anyway) is that Cloud computing used to be different; you used to just be able to buy a hosted server. Somehow we jumped from that straight to the current model instead of more consumer-friendly concept of burstable VMs.

<comment><USER27> SAAS is also the easiest to maintain, because at any one time there's (usually) only one version of the software running on one OS & hardware version. And the vendor is running it, so access to logs and core dumps is effortless. It's a big problem getting logs, etc. from customers running on- prem software.

</comment></comment></comment><comment><USER28> I'm very confused. What does it matter, for running old software, whether a framework was a fad or not? And what does a "brittle" dependency even mean in the context of preserving software?

If you're trying to preserve software, you've got two options.

One, you can preserve the binary and run it with emulation. For webapps, this means preserving a deployable image. Your faddish/brittle dependencies are 100% irrelevant, because your image includes them already, right?

Or two, you can preserve the source code. Which for _any_ project is going to involve a mess of complicated tooling that dates to when the project used to be compiled. But if you're intending to preserve something for the long term, you should preserve the dependencies too -- e.g. node modules or whatever. Or else you're gonna have to track down the packages used on a certain historical date, just like you might have to track down some random specific version of a Borland compiler that ran on a certain version of an OS.

I don't really see what's all that different.

<comment><USER29> My favourite iOS game from when I was a kid is no longer actively developed and as a result it was removed from the app store because it doesn't work properly on new devices.

Its perfectly understandable why this happens but its a shame there is no way at all to play this game other than finding an old ipad that still has it installed where as old windows games still work fine.

<comment><USER30> Unrelated...

"My favourite iOS game from when I was a kid"

I'm 40 and maybe this is the first time I feel really old on HN. Cheers!

<comment><USER31> I'm 32 and even I felt old reading that. :D

</comment></comment></comment></comment><comment><USER32> Some people question when I've decided to only use a handful of dependencies in a project - usually "You could do it so much faster if you used X, so why not?"

The problem is that every dependency is a possible source of failure. For most languages, you can do a whole lot if the standard library is well-written - Python 3.6+ is particularly good for this, PHP if you don't mind API strageness, whereas Go without modules is less convenient, and outliers like node.js are basically unusable.

Also, frequently you don't need the popular "everyone uses it" libraries. For python, requests isn't needed anymore, as built-in urllib is quite good now and lacks a lot of "smart" functionality that causes strange breakage. pytest has more rough edges than built-in unittest. The only things that I use regularly that legitimately add functionality are pyyaml and tox (only when testing!).

<comment><USER33> Funny that you should call node.js an outlier when it's all the rage these days. Node does, however, go to show that short-term convenience trumps reliability and long-term stability by a wide margin.

</comment></comment><comment><USER34> I wonder if the comment was intended to be mainly about the newer mobile OSes. I don't think I'd have too much trouble finding a way to run 10-year-old Windows or Linux desktop apps, and it would be easier than running Mac apps from the 1990s, but I didn't even get the opportunity to save copies of the iOS binaries I used 10 years ago. Even if I did, I doubt I'd be able to do anything with them.

<comment><USER35> they're talking about web apps and mostly javascript.

<comment><USER36> Doesn't make much sense then. Your browser will run those.

<comment><USER29> I have seen web apps that simply can't be deployed anymore because their ruby version includes a rubygems version so old it can't use TLS 1.2. Its probably a good thing and will force upgrades eventually but old web apps can't always be used.

<comment><USER37> mod_perl 1. Oy.

Never say you can't rewrite a project. I've done it too many times.

</comment></comment></comment></comment></comment><comment><USER38> Funny I upgraded to ubuntu 20 from 18 last night. Ruby sass wouldn't work anymore. Why? Well just read what the maintainer said...

"When Natalie and Hampton first created Sass in 2006, Ruby was the language at the cutting edge of web development, the basis of their already-successful Haml templating language, and the language they used most in their day-to-day work."

The page continues...

"Since then, Node.js has become ubiquitous for frontend tooling while Ruby has faded into the background."

[https://sass-lang.com/ruby-sass](https://sass-lang.com/ruby-sass)

So I installed the nodejs version. And in a few years I'll move over to the next fad....

<comment><USER39> consider not using ubuntu

<comment><USER40> What would you suggest as a replacement?

<comment><USER39> arch linux, artix linux

<comment><USER38> and why more importantly

</comment></comment></comment></comment></comment><comment><USER41> I worked on my previous project for 22 years yes 22 not a typo. It changed a lot over the years but there was still code that was recognizable from the early days. At my new job I work on projects that are designed for minimally viable products. Basically throwaway.

</comment><comment><USER42> As commercial software developers, our job is to write profitable code.

Not bug-free, elegant, perfect code. Not buggy, unusable, dependency-riddled unmaintainable code either.

It's an art getting that balance right. Not everyone does.

<comment><USER43> Profitable, yes, but considering what time scale? Profitable for six months? Profitable for two years? Five years? Ten to twenty?

<comment><USER44> Ideally from day 1, the sooner you have the option for profitability, whether or not the company decides to take profit or reinvest, the better your chances of not wasting a ton of money. Even if the actual tech takes a year or two to develop, if you have a paying customer from day 1, the better your chances should be.

<comment><USER42> Depends on the business.

For a bootstrapping startup, yeah, day 1. It has to be. Otherwise you don't eat.

For an Enterprise business with 6 or 7 figure revenues, a lot longer. Possibly decades. If it gets political, never ;)

</comment></comment></comment></comment><comment><USER45> I also feel old fashioned imperative programming is much easier to debug than modern event-driven frameworks.

Technically unit tests should prove a system is modular and testable but I just keep seeing huge dumpster fires.

I'm not sure if I'm just old or it really is a problem.

</comment><comment><USER46> When I started out of college as a SWE at HBO in 2009, there was a ton of code written in like 1999-2002 still in use. It was cool to see well-written and documented code live on in real perpetuity. Also, most of the engineers who wrote that code were still there! I think things have both changed a lot in the last ten years (power of iteration), and also things in a stable, profitable company are just a lot different than in a startup.

</comment><comment> Const-me I mostly use Windows. Most software written after 2005 just works.

Not everything, e.g. I have a flatbed scanner in attic which requires me to fire a WinXP virtual machine (I use it couple times a year), because there's no drivers for Win10. Many low-level OS-related utilities are broken as well.

However, majority of software works. For lulz, I once to tried to run a binary of pinball from Windows NT4, worked fine on modern Win10.

</comment><comment><USER47> I don't know... Can I run Netscape Navigator on Ubuntu 20.04? How about Gtk 1.2 programs or old Qt3 programs? Can I run Opera 12.x?

<comment><USER48> It's easily doable by running a virtual machine. If you have an OS compatible, it will run out of the box. Now try to do that with one app that depends on one of the cutting edge development stacks of say, 2011... Good luck telling me how you can run it as easily as I can tell you about the last version of Netscape for instance - just run a Win98 VM and voila, you're set.

</comment></comment><comment><USER49> cleaning up unicorn poop has been an excellent business. Nice to see it will continue for awhile.

<comment><USER50> My buddy has built an entire career hopping to late stage start up after late stage startup and refactoring rails into java

<comment><USER51> >> and refactoring rails into java

Oooh planning ahead for round 2.

</comment></comment></comment><comment><USER52> I think some technologies, specially the ones related to web, cause this fatigue more than others.

It's probably because web devs build and switch stacks at a higher velocity. I'm in my mid-twenties and have seen 4 monumental changes in frontend development alone.

</comment><comment><USER53> For an interesting vision of how software could potentially be constructed to give users more agency/ownership and longevity without ditching the benefits of SaaS, see Kleppmann et al's "Local-First Software: You Own Your Data, in Spite of The Cloud" [1]. From a technical standpoint, anyway, what they don't really get into is how subscriptions are just too damn attractive as a business model. If anyone has interesting approaches on that front, I'd love to learn more!

\- [https://www.inkandswitch.com/local- first.html](https://www.inkandswitch.com/local-first.html)

<comment><AUTHOR> Submitted and discussed at length a few weeks ago:

[https://news.ycombinator.com/item?id=24027663](https://news.ycombinator.com/item?id=24027663)

</comment></comment><comment><USER54> One comment states:

>Given full blueprints, you can reasonably rebuild any machine from 19-th century from scratch, no matter how complicated. Even if you start from raw materials.

Wich is totaly untrue, not the blueprint was important but the handcraft knowledge, and that is often forgotten. Whe even had to relearn many details how appolo landed on the moon because of lost knowledge, and that thing was pretty good documented.

Just one of many examples:

[https://www.sciencealert.com/why-2-000-year-old-roman- concre...](https://www.sciencealert.com/why-2-000-year-old-roman-concrete-is- so-much-better-than-what-we-produce-today)

</comment><comment><USER55> It's because software design is guided by individualized, balkanized, competitive, hierarchical human incentive, rather than public incentive. The extraneous branching and churning of what amounts to the formal, ever-evolving definition of all human interaction and knowledge: one might define modern computing as this. To accomplish this branches must be deleted over time and unified in order to properly abstract and make infinitely useful the definition. Branches are useful in uncertainty, in areas where discoveries are still being made. Branches become impediments in settled areas and Babel-tower formation begins, increasing brittleness. It's the human-knowledge equivalent of Keynesian hole-filling, but the price one pays for this is software duplication, increasing computational complexity, and increasingly less interoperable systems for like things. Sometimes lightning strikes and we have to build all the rooms again, but that happens at the bottom of the tower up. I think the role of the State should be to unify these conditions over time, so as not to create extraneous noise, confusion, human-churn and suffering, and material resource waste.

</comment><comment><USER56> People are using lots of external dependencies (which expire over time) for a reason. They allow a single software developer to build a social network of very high quality, or hardware that would have taken a whole department to build 20 years ago. The pace is so fast that the system vendors can't catch up providing all this functionality in their native frameworks, which IMO is the primary problem here.

</comment><comment><USER57> [https://github.com/nixos/nixpkgs/](https://github.com/nixos/nixpkgs/) Everything, I care about, fully reproducible.

I don't mean to "hawk my wares" in what feels like many threads, but seriously, this is a solved problem, despite the continued mess-making of people that don't use it.

</comment><comment><USER58> 2013-2019 had a lot of "re-discovering the wheel" \- especially wrt programming languages and frameworks(read: JS)

</comment><comment><USER59> I blame the consumers. They're being lazy and shortsighted. Computer programs where half of it runs on some remote server and the graphical frontend is a home page running in a WWW browser is plain stupid for all reasons except "easy to update" and "easy to control".

I absolutely refuse to use "web applications" for anything productive. I run my computer programs on my computer, and if they don't work without an Internet connection, I'm not using them either.

My Nintendo Wii has never been online, it's only been used with physical media, so I know it will continue to work as long as the hardware does, and when that no longer works, the software on those DVDs still work. The same goes for my Playstation 1,2 and 3, and my xbox and xbox 360.

<comment><USER60> How the blame can be on the consumer? They don't even have a clue what a front end is. Just look at Adobe customers to see if they are happy with the cloud for their apps.

<comment><USER59> I blame the consumer because we all vote with our money. Sure, technical proficiency in mainstream users has probably fallen somewhat since the 80s, but people should care about the huge difference between buying a product for their computer, or merely renting access to a product. They should understand that they're giving up the choice to stay with a version that works for them and their computer, one that won't force them to upgrade hardware or other software to keep going.

</comment></comment></comment><comment><USER61> Just wait until all these SPA's stop working without constant maintenance.

Data: Always readable, assuming it sticks to some discernible format.

Data generated by code: Inherits both disadvantages; the changing of data formats AND the ephemeral nature of old code.

</comment><comment><USER62> I expect there somewhere someday there will be a company that focuses on just buying failing SaaS software to have their code as an asset quickstart to a real market solution .

kind of like buying a bankrupt generator company as the basis of starting a car company. You need a liquid fuel engine design anyways...

(Edit dont get pedantic about the analogy's shortcomings)

</comment><comment><USER63> Perhaps the issue is that it is far cheaper and easier to start from scratch and create a small app these days.

As we innovate exponentially faster and have better tools and languages, it is far easier to tear the building down and start over.

Also, I don't know of a single app I use regularly that is older than a few years.

<comment><USER64> > I don't know of a single app I use regularly that is older than a few years.

What did you use to visit this website? Check your email? Open a spreadsheet last? If your a software developer, what do you edit code in? Your operating system?

Hard to believe you're using apps less than a few years old for any of those much less all of them - or even those that are by name older but have been through a Big Rewrite in the past few years.

<comment><USER65> Firefox - July 2020

Mutt - July 2020

Gnumeric - August 2020

Vim - December 2019

OS - Ubuntu, April 2020

They might not have had big rewrites, but they are still under active development (I actually run slightly older versions, but nothing older than 5 years)

The code I use which isn't under active development is stuff I wrote years ago, but showing its age -- one uses flash to deliver video for example. Last update was a specific view for a blackberry, which gives an indication on the age. That view didn't support video as we didn't have 3G in the fleet.

</comment></comment></comment><comment><USER66> I don't see why this is a problem, I actually think it's a feature. Do you really want to be using 20 year old software? I don't. Furthermore, not being able to run old code has never impacted me in a meaningful way and I'm part of the small minority of people who write software for a living. I recon if you go ask pretty much anyone out on the street about this "problem", they wouldn't even care.

I think it is fair to say that unchanging software systems can be harmful. The unemployment benefits system in the United States is a good example. They built those systems in the 70s and never touched them again. Now that the requirements have changed due to Covid induced economic collapse and the systems are overloaded, there isn't a single person who has a damn idea how to fix it. If there were people iterating on and improving the system this entire time, things would be much easier to fix, or maybe there wouldn't have been a problem at all.

Data is forever, not code. Code should be fickle. Changing code is progress

<comment><USER67> Changing code _may_ be progress. Replacing working code with code that works less well is definitely not progress, though.

The problem is that working old code often has far more corner cases and bug fixes in it than you think. It's easy to "replace" it with something that is buzzword-compliant and that uses the new shiny, but that doesn't cover all the cases and doesn't have all the needed bug fixes. That's _not_ a step forward.

<comment><USER66> > It's easy to "replace" it with something that is buzzword-compliant and that > uses the new shiny, but that doesn't cover all the cases and doesn't have > all the needed bug fixes. That's not a step forward.

This is a false equivalency imo. If you build a replacement system that is buggy and sucks, you did a bad job, it has nothing to do with the tools that you are using. This seems like more of a criticism of management to me

<comment><USER68> > If you build a replacement system that is buggy and sucks, you did a bad job

Or you just didn't know about all the edge cases, niche ways of using it, and the regulation on page 475 of some arcane law code that requires that something be so.

<comment><USER66> > Or you just didn't know about all the edge cases, niche ways of using it

Sure but this goes both ways. Developers cannot know all future requirements when writing the software. SaaS models largely alleviated this problem because people are continuously working behind the scenes adding new features and fixing bugs

</comment></comment></comment></comment></comment><comment><USER69> A bit oversimplified in my opinion. Sure, SaaS only works as long as it is online, but with reproducible builds and versioned dependencies most software can still be built for a very long time. So i think for OSS the argument is not really valid.

</comment><comment><USER70> I really, really doubt I can run most 1980s software on a modern machine without effort.

<comment><USER71> Folks I work with support some clipper apps written in the late 80s.

It's getting harder now with 64bit windows not supporting 16bit apps — they are living on a "legacy" Linux VMs tenant in Azure now, and probably will continue until around 2030. Possibly longer, as they are on emulated DOS now!

<comment><USER72> DOSBox has been something of a godsend for getting a lot of 1980s software working again. Not so great if you also need to interface with proprietary ISA cards, but lots of software can be brought back to life.

<comment><USER73> Not that this is relevant to DOS software, which needs whole-system heavyweight emulation right from the start these days, but...

It would be interesting to have a solution which allowed you to progressively wrap software to allow it to run in just as much isolation as it needs, from the ultra-lightweight scripts that just futz with LD_PRELOAD (when most of the environment is still there) to actual Docker images (when the OS is still there) to images to run in a hypervisor (when the _hardware_ is still there) to full-on heavyweight system emulation like SIMH, for when even the hardware has gone.

It's all very Tao:

When the userspace libraries have gone, there is LD_PRELOAD

When the filesystem hierarchy is gone, there is Docker

When the OS is gone, there is Xen

When the hardware is gone, there's SIMH. Hi, SIMH!

[https://www.youtube.com/watch?v=Vkfpi2H8tOE](https://www.youtube.com/watch?v=Vkfpi2H8tOE) Laurie Anderson — O Superman

</comment></comment></comment></comment><comment><USER74> This graph of software dependencies from various sources is fragile but exactly the sort of issue IPFS was designed to solve.

If something like node.js stored all sources in IPFS then the data would remain as long as someone builds the software.

</comment><comment><USER75> As long as you vendored your dependencies it all actually still should run fine. Bitrot is not a new phenomenon. But it is incredibly frustrating.

<comment><USER29> Most languages do this pretty well. ruby and rust package managers store all past versions of packages so its trivial to get the same setup again. Its C where the problems come from. Finding the right packages to build something is quite a task since every distro calls them different things and has different versions and only keeps 1 version at a time.

<comment><USER76> To be fair you could track down the git repositories or tarballs and compile and install the right versions. If the author used autotools as is standard, the version number should be listed.

It's not ideal of course. I wish it were standard to build all dependencies from source and statically link a big binary like Go does.

</comment></comment></comment><comment><USER77> Why 2005?

<comment><USER78> That's about the start of the Ruby on Rails hype.

<comment><USER29> If you are trying to run a rails app from 2005 your biggest issue is the trillion security holes in your app and not getting it running which is usually not too hard.

<comment><USER79> That is absolutely true, and probably equally true for any other web application that was wasn't maintained for 10-15 years. But this is article is talking about the ability to run older applications, not about safety concerns about doing so. I just wanted to point out that, while Rails is far from perfect, from a software-archeological perspective there's not really much ground to pick on it. The ruby gem ecosystem (again not perfect) is at least pretty stable in the sense that 10+ year old libraries are readily accessible (as they should be!).

</comment></comment></comment></comment><comment><USER45> Surely this is a lot to do with browsers and js frameworks always changing. Everything non-browser related is probably fine.

<comment><USER20> A lot of desktop software has in recent years moved to assume always-on high- bandwidth internet connection and/or moved to a subscription model.

</comment></comment><comment><USER80> What was it like setting up CI in the 80s or 90s "without too much hassle?"

<comment><USER20> You typed the compile/build command and it compiled/built. Then you had an executable you could test and/or deploy. Or you got errors, which you resolved until it did compile.

<comment><USER80> In other words, you had one physical machine per platform, and at least one developer manually running each build on each platform. Or perhaps one developer per each if you've got an even bigger budget.

I'm just imagining a quasi-Luddite hacker collective that eschews automation and does their own builds directly on the physical hardware to keep themselves "in touch with the hardware." That actually sounds pretty fun and social. Plus I wonder what the effect would be on catching regressions/issues before release compared to modern CI.

</comment></comment></comment><comment><USER81> "The developer guide to handling agile" handbook could help if it existed.

</comment><comment><USER82> It's more like fossil remains from the Mesozoic than litter.

</comment><comment><USER83> To further the analogy, blockchain is the reusable metal straw that costs 100x the energy to produce, lasts forever, but mostly gets shown off a couple of times before being thrown away anyway.

</comment><comment><USER84> For that to be true, there would have to be no actual domestic crisis, with poor countries with lax oversight responsible for 99% of the damage, but with politicians passing laws making our lives worse at home because it makes uninformed people feel good.

I'm stocking up on plastic straws and bags while I can.</comment>


Jerry, the independent inventor whom had 600+ patents, torpedoed big corps - <AUTHOR> https://en.wikipedia.org/wiki/Jerome_H._Lemelson <comment><AUTHOR> Guess who's the highest paid lawyer in America? One of Jerry's former lawyers, the "Babe Ruth of patent trolls" whom also happens to be one of the major supporters of the Aspen Institute.

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

</comment><comment><USER2> Reading that wikipedia article, it seems like this guy created submarine patents too. :/</comment>


Apple II games in your browser - <AUTHOR> http://www.virtualapple.org/

<comment><USER2> Nifty, but I am sorely disappointed that it isn't written in Javascript like the NES emulator was.

<comment><USER3> This is much more hardcore, though. It simulates disc changes and the like.</comment></comment>


Strong earthquake rocks Nepal, damages Kathmandu - <AUTHOR> http://www.bbc.com/news/world-asia-32461019

<comment><AUTHOR> It's also mountaineering season there. Himalayan Experience just issued this[1]:

 _" A massive earthquake has struck Nepal and a big avalanche came over Lhotse basecamp.

Every people including our sherpas are safe on our side. Injured people from other camps start coming to ours for rescue which we are currently organizing.

I am in Kathmandu at the moment and because of massive destructions, communications are difficult.I will send more news as soon as possible.

Russel"_

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

</comment><comment><USER2> That's so sad... I was in Nepal two years ago and stayed with some locals. I hope they are ok.</comment>


Ask HN: My startup has multiple VCs pitching us. How do we choose? - <AUTHOR>

My first instinct is to pick two and have them split the round, but they all want to lead. <comment><USER2> Congratulations. Here are my suggestions:

1\. Don't assume they won't flex if you inform them you're willing to work with them only on your terms.

2\. Before you start optimizing for terms, however, get as much information as you can about your prospective partners and decide who you most want to work with.

3\. Choose based on who you want to work with, and try to use the competitive situation to get you the best possible terms.

When we were reviewing term sheets, we did a lot of diligence, in particular talking to other entrepreneurs who were in -- or had been in -- the portfolios of the funds. Of course you want to understand the basics of how working with that person or firm was, but you also want to get some color on how things played out for the deals that went sideways or failed.

Startups often have bumps along the road, and opportunities present themselves for VC's to take advantage or take the high road. How the partner(s) in question have handled themselves when faced with these options, and how the fund dynamic played into that, will tell you a lot about how things are likely to go for you under similar circumstances.

Good luck!

<comment><AUTHOR> So you recommend going with just one firm? We've heard that asking two to co- lead might be advantageous.

<comment><USER2> I wasn't explicitly taking a position on that issue, but rather suggesting that the "who" is more important than the how.

"Co-leads" can mean different things, and in any nomenclature having two funds in roughly equal positions in an early-stage round can be great... and can also have unintended and significant consequences.

If you're not aware of these nuances, please add a seasoned advisor to your team asap.

</comment></comment></comment><comment><USER3> Terms. Ceterus parabus, terms (valuation / dollars, etc) will dictate who wants to be in the deal the most. If you are fortunate enough to be in that situation, get the most out of it. I will caution you, do it carefully. You don't want to start off that type of relationship with your investors feeling screwed...they have long memories.

</comment><comment><USER4> Optimize for the long-term relationship, not the short-term transaction.

</comment><comment><USER5> Consider fit, long-term value and their brand above valuation.</comment>


MySQL founder protests against Oracle takeover - <AUTHOR> http://www.guardian.co.uk/technology/2009/dec/14/monty-widenius-oracle-protest

<comment><AUTHOR> He makes a pretty compelling point about why Oracle would want to dump MySQL:

"MySQL is used in many of the world's largest companies and they use it for an increasing number of purposes. This not only scares but actually hurts Oracle every day."</comment>


Show HN: eCommerce functionality into any social network - <AUTHOR> https://www.shopwindow.co <comment><AUTHOR> Hi!

I have been working on a new concept for selling online.

Targeting from people selling by direct messages on social media to eCommerce owners for whom a traditional online store is an overkill.

The idea is basically to lower the entry barrier to selling online ad maximum for anyone by:

       - Avoiding the big fat square 0 (build online store) by getting something simpler (landing shop).

       - Getting sooner to square 1: promotion, which is what actually drives sales.

       - Selling by tagging your publications with your shoppable product URLs.

       - Reminding users to post periodically to help building and nurturing an audience.

I would love hearing your feedback about it!

Thanks in advance for your time!

Stay safe!</comment>


The Raven Paradox (logic) - <AUTHOR> http://en.wikipedia.org/wiki/Raven_paradox

<comment><USER2> I'd go with Dave Cole. From the Wikipedia article: _"when one finds a black raven, it is a much more important discovery than finding a non-black object simply because there are fewer black ravens than everything else"_

Finding a black raven yields evidence that all ravens are black.

Finding a green apple also yields evidence that all ravens are black, but _very_ weak, much weaker than finding a black raven. It offers the same weak (and in this case misleading) evidence that all ravens are pink.

<comment><USER3> Non-paradox, since each non-black object that is not a raven will infinitesimally increase your belief in the proposition, until you find a counterexample or exhaust the set of all non-black objects.

The reaseon that finding a black raven is more important is because the set of ravens is much smaller than the set of non-black objects, so it increases your certainty more.

The green apple does indeed offer the same infinitesimal evidence that all ravens are pink, but by going through the set of non-pink objects in the universe and eventually finding a raven, the proposition will be disproven.

So part of the "paradox" here is a conflation of "evidence" and "proof". The other part of the paradox lies in the fact that the evidence gained by seeing one green apple is SO tiny that it won't even register on the human brain's "is this evidence?" heuristic.

<comment><USER2> _"The green apple does indeed offer the same infinitesimal evidence that all ravens are pink, but by going through the set of non-pink objects in the universe and eventually finding a raven, the proposition will be disproven."_

I had residual doubts about these pink ravens, but that's a great way to put it. Now I really feel "on top" of the paradox.

</comment></comment></comment><comment><USER4> The Raven paradox is a good example of why we need Bayesian inference. The paradox is not a real paradox -- it doesn't imply true and false at the same time -- but it makes a strong case for a system that integrates degree of confidence through and through, as opposed to merely assigning _true_ and _false_.

</comment><comment><USER5> What came to my mind when I first read the paradox was that the class of ravens is closed whereas the class of non ravens is open. We have a definition of raven that's independent of its colour, otherwise we wouldn't be able to tell whether a particular thing is a raven, and thus, whether its colour is evidence for anything related to ravens at all. However, we don't have a definition for all non raven things, so the number of non-ravens is not merely large, as the article suggests, it is in fact infinite as counting needs definition to tell one thing from another. Drawing conclusions by induction from one of an infinite number of instances seems meaningless to me.

But there is another interesting question that arises from the Bayes explanation at the bottom of the article. If we had all things in the universe available and sufficiently defined to tell what is one thing and what is another, and we found that there are indeed no non-black ravens, that would still leave open the question of whether there could possibly be non-black ravens in the future. They could be born right in this moment, so there would be a race condition between making the statement and the statement being falsified by the event of a non-black raven being born. And I think that's one of the problematic things about purely extensional logic advocated by philosophers like Quine.

<comment><USER6> _"If we had all things in the universe available and sufficiently defined to tell what is one thing and what is another, and we found that there are indeed no non-black ravens, that would still leave open the question of whether there could possibly be non-black ravens in the future."_

That's not a bug in Bayesian inference, that's a feature! It would be a mistake to ever assign a probability of 0.0 or 1.0 to any statement. It means you have infinite confidence in the statement, which is impossible unless you have a screwy prior distribution.

You also don't have to evaluate _all_ of the data if you're giving a probability. You can just report your degree of confidence in the proposition based on the data you've evaluated so far, and this degree of confidence is called a probability.

<comment><USER5> I know the whole point of Bayesian statistics is that you actually need much less data to get a good prediction. But the edge case I was talking about is still interesting I think, if not as a criticism of Bayes.

</comment></comment></comment><comment><USER7> I don't get why this logic violates intuition. The proposed solution in the article is fairly obvious and intuitive. Just because two logical statements are equivalent doesn't mean evidence for one gives evidence for the other:

"The origin of the paradox lies in the fact that the statements "all Ravens are black" and "all non-black things are non-ravens" are indeed logically equivalent, while the act of finding a black raven is not at all equivalent to finding a non-black non-raven. Confusion is common when these two notions are thought to be identical."

<comment><USER4> If two logical statements are equivalent, then yes indeed, evidence that implies one of them (in classical logic) implies the other one. The solution is indeed _intuitive_ but is not formalizable in classical logic.

Classical logic does not, in general, jibe with the intuition: consider the case of the negative antecedent:

<http://www.earlham.edu/~peters/courses/log/mat-imp.htm>

For example, the statement, "If unicorns have one horn, then I am the Queen of England." is logically true.

<comment><USER7> hmm, I see the point. But isn't that just the limitations of classical logic? Just seems like a question of semantics rather than a clash between logic and intuition, but maybe I don't get it

<comment><USER4> It is a clash between _classical logic_ and intuition, which is the point -- it indicates a difficulty with applying classical logic, and encourages us to take up other avenues.

</comment></comment></comment></comment><comment><USER8> The statement that "my pet raven is black" is not even weak evidence that "all ravens are black." Rather, it's strong evidence that "there exist black ravens." That's the flaw I see.</comment>


The Mac Malware of 2019 - <AUTHOR> https://objective-see.com/blog/blog_0x53.html <comment><USER2> Off topic, but I felt compelled to express my love for the work of this company Objective See.

I've been using their application called Lulu every day, and I cannot imagine working on a Mac without it. So thankful that it exists, and that it's open source!

[https://objective-see.com/products/lulu.html](https://objective- see.com/products/lulu.html)

"LuLu is the free, open-source macOS firewall that aims to block unknown outgoing connections, unless explicitly approved by the user."

<comment><USER3> How does this compare to Little Snitch?

<comment><USER4> Not feature-rich as Little Snitch. However, it's free and open source. I primarily use Little Snitch for my iMac and MBP. But use LuLu as well on other machines.

Can highly recommend all the other apps Patrick Wardle (Objective-See) has developed.

</comment></comment></comment><comment><USER5> it's $45 less, for a start.</comment>


Tell HN: TechTestNow, an app to help you hire the best coders - <AUTHOR>

We are launching the beta test phrase of our startup, TechTestNow. TechTestNow allows you to run online coding tests to select the best programmers to interview. You can setup a test and give the link or invite them by email. Then the candidates are asked to take a test
http://beta.techtestnow.com/
At the moment, we support 2 languages Java and Ruby. We are adding more questions and languages gradually. And as soon as we have more data, we are going to analyze and fine tune the ranking algorithms.
Here are two example tests,
Java : http://beta.techtestnow.com/en/user/testLogin/secret/TTN4c2479e455a032.22415626
Ruby : http://beta.techtestnow.com/en/user/testLogin/secret/TTN4c247a1e3fc618.66097557
To view the system as the recruiter, login as "sandaru1/hnhackers". (please don't delete/deactive above tests)
Any feedback would be appreciated. <comment><USER2> I do like the idea of compiler driven tests over Q&A, but you still fall in the same trap of only getting answers for a very contrived case. There are more dynamics to a good developer than just a few hypothetical situations.

For example someone could be great at Hibernate but not really have some a lot of work with pure JPA. Just because they are not familiar with the JPA does not mean that they have not mastered ORM concepts and would be able to do JPA development as good as the rest of us in a week or so.

Which brings me to my next point. I would throw time completely out. With the situation I just framed a senior level developer is going to do what all of us do. Fire up the browser look at the JPA api and implement it. This is what makes a good developer. Someone who can gather code together and create a solution.

On almost any given project there are going to be new API's that developers will have to familiarize themselves with. The ones that can are far more valuable developers, because they disseminate that information back to the rest of the team.

Your test does not account for that and by making it time based you are disadvantaging the very ones that posses that valuable skill. If the answer is right, it's right.

As well you should consider offering the service to recruiter and hiring line managers, not as a competitive test, but rather as a filtering tool. Competitions are regarded in academia, but in the corporate world people just want to know if you can do the job.

<comment><USER3> What you say is quite true and resonates with my personal experiences.

I myself do not possess an encyclopedic knowledge, nor will you see my fingers flying over the keyboard.

On the other hand, what I have noticed is that my understanding of the basics of coding, i.e. how to mix and match loops, arrays, conditionals, etc has vastly improved over time.

I frequently forget advanced or language specific topics - and I don't really care, since I can easily re-read about them online and refresh myself.

I have worked as an examiner for computer science university students and also as an interviewer for new hires for companies. What I have noticed is that the best candidates are similar - they have a rock solid grasp of the fundamentals of the language, and just twist and turn that knowledge to acquire the results they need.

You yourself have mentioned this - a good developer with an understanding of ORM can easily adapt to whichever framework he is required to use.

This mastery of the basics is what we are trying to assess with TechTestNow. You might notice that none of the questions require in-depth knowledge of the APIs (although that knowledge might help you solve some of them faster, there is always a solution that uses only basic constructs).

The main reason the tests are timed is because, all said and done, a good programmer does need to have a certain coding speed !

Also, in real life, a lot of time is spent not on figuring out how to solve a problem, but rather on figuring out what the problem is in the first place - what do we really need to do ? (and can it be done at all ?). Although the problems given in TechTestNow might seem contrived, they do have the advantage of being unambiguous, so that the programmer can just concentrate on writing a solution.

</comment></comment><comment><USER4> Your method of grading the tests fails. I couldn't determine if you were counting number of times compiled against the person, or just looking for something VERY specific in the final result, but both methods failed to properly categorize technically right solutions, even if they didn't meet what was entered as "correct". Even worse, there's no interface to determine what solution you were even looking for, requiring the test requester to either trust your (unique) judgements on correctness of answers or review the playback of every entry, removing the major benefits of the site. The fact that every person gets random questions also doesn't help compare capabilities of different testers. And the final thing missing, the ability to see the requirements + final code submitted without going through the playback.

Note: This isn't a "wah, I did it all right and it said I was wrong!", I specifically used correct, valid answers that were unlikely to match the model you were looking for (empty for loop body for decrementing a variable to a certain value, etc.).

<comment><USER3> I went through your solutions and I must disagree. Your solutions did not generate the correct output for the questions.

For example, I'll take the following question :

'Given the string variable 's' and the integer 'n', return a new string consisting of n repetitions of s.

For example, if s = "abc" and n = 3, you should return "abcabcabc".'

The code you have written is as follows :

String duplicate(String s, int n) {

      String result = s;
      // First assignment already done

      while (n > 0) {
         result += s;
         n--;
      }

      return result;

}

If we analyze the following code (assuming that s = "abc" and n = 3), initially, the variable 'result' is assigned the value "abc".

The loop then runs 3 times - when n = 3, when n = 2 and when n = 1. Which effectively means that "abc" is concatenated 3 more times giving the string "abcabcabcabc", which is incorrect.

I do agree that the solution is _almost_ right. Note that you are allowed to compile your code and run it against our testdata (and even your own test cases) in order to establish it's correctness - which means that you did have the opportunity to find out that there was a bug in your code and fix it.

But in computing, how often is it acceptable to get things 'almost' right ? Would you be happy if Google returned search results which were almost right ?

I know that if a human conducted the interview, he would have helped guide you through the test - in fact, we are almost done adding the capability for recruiters to monitor test sessions in real time and converse with candidates.

I can also provide a case by case analysis of your other solutions if you wish.

<comment><USER4> question 2 of 6 for duck: Write code to trap these exceptions and return 1 if a FineException is thrown and return 0 if a CoarseException is thrown.

      int exceptionTrap(int a) {
        try {
          exceptionThrower(a);
        } catch (FineException fe) {
          return 1;
        } catch (CoarseException ce) {
          return 0;
        }
        return -1;
      }

You're saying the above is invalid? Tests out perfectly fine on my system...are you trying to say there shouldn't be the last return because you say "You may assume that an exception is always thrown"? If a function returns a type of int, all codepaths then need to return a type of int, programming 101.

Others indeed do have some errors as I quickly typed them up (off by 1, forgetting that java array length isn't the same as C++ std::vector.size). Number 3 could definitely use a better example, such as a = 12 (so the result would be {12, 11, 10}.

I admit, I checked number 2 closely, saw a horribly invalid failure reported and only glanced over the rest. Independent of the other failures, you cannot have incorrectly graded questions, and the rest of the points still stand, the requester has nothing to compare against, leaving the judgement up to your pass/fail (which is clearly not 100%) and the random assignment of questions to different test takers results in no real comparison ability between skills.

<comment><USER3> You're right about question 2, my apologies. There indeed was a bug in the test data for that question (which we have fixed now). However, the rest of the questions given in the test work properly.

The reason different test takers get (somewhat) different question sets is because our algorithm alters the difficulty of the questions based on the test taker's performance. I.e. if you did the first few questions well, you'd start getting progressively tougher questions. On the other hand, if you do badly, you'll be given successively easier questions.

</comment></comment></comment></comment><comment><AUTHOR> Clickable Links

<http://beta.techtestnow.com/>

Java : [http://beta.techtestnow.com/en/user/testLogin/secret/TTN4c24...](http://beta.techtestnow.com/en/user/testLogin/secret/TTN4c2479e455a032.22415626)

Ruby : [http://beta.techtestnow.com/en/user/testLogin/secret/TTN4c24...](http://beta.techtestnow.com/en/user/testLogin/secret/TTN4c247a1e3fc618.66097557)

</comment><comment><USER5> Wow the recorded sessions feature is really cool. Props to you guys, I hope you do well.

</comment><comment><USER6> Where are the questions? The UI is not very intuitive. Good luck anyway!

<comment><USER3> I think that the confusion is because you attempted to take the test using the login credentials for the recruiter.

Recruiters cannot take tests - only candidates can. Note that you can easily create a new account at the 'take test' page (please use one of your email addresses).

<comment><USER6> Recruiters should be able to see the questions and answers.

</comment></comment></comment><comment><USER7> What is the difference between this and <http://codility.com/>?

<comment><AUTHOR> TTN has quite a few more features. The key ones would be :

1\. Viewing a playback of how the candidate coded the question.

Even a bad candidate might be able to 'prettify' his final code (or even craftily cut and paste code while solving the problem).

However, it is almost impossible to do so in a playback of the entire coding process.

It is like the difference in complexity between creating a fake photo vs creating a fake video !

2\. Adaptive testing

Depending on the performance of the candidate, the questions presented will increase or decrease in difficulty - allowing the system to accurately assess the candidate's skill level (that is the advantage of using several small questions, as opposed to a few large questions).

3\. The ability to embed the testing widget both on your website or even on a job posting on a job site - that way candidates never even have to leave your website.

<comment><USER7> Number 1 is actually a downside, to me. I don't really care whether a coder starts with ugly code (don't we all?) but I care what it looks like when he hits "submit". Also, do the rules specifically disallow writing the code in my IDE and then copy/pasting it in? I think that would be a silly rule. What about a good developer who writes a test first, and of course, codes against that test.

However, number 2 and 3 are nice.

<comment><USER3> Both of the points you make are quite valid.

As you said, it is the final code which is more important. But don't you think that it is also important to view the process by which the programmer arrived at the final code ?

An experienced coder will quickly reach a solution. Although he might make several mistakes on the way, he can usually quickly detect and correct them.

Someone less experienced would take longer, make more mistakes and probably take several attempts to correct those mistakes before getting it right.

Even though the final code might be more or less the same, the playback would help you discern who has better coding skills.

Of course, this would mainly be of use when attempting to choose between two closely matched coders.

Regarding copying and pasting - at the moment the rules don't explicitly ban this. The problem with allowing it is that the likelihood that the coder might attempt to cheat (and get away with it) is vastly increased (and cutting and pasting makes the playback feature worthless !).

That is why we went to the trouble of enabling syntax highlighting, compilation and testing within the widget, so that it would be as close to an IDE as possible.

BTW - regarding testing - aside from the 2 default test cases, it is also possible to enter your own testdata in the widget.

</comment></comment></comment></comment><comment><USER8> The coding window assumed I have an american keyboard, which made it sort of hard to program.

<comment><USER3> Thanks for your input. Can you give me more details ? What were the problems you encountered ?

<comment><USER8> Special symbols, like []() etc. are located on different buttons on an american keyboard compared to e.g. a swedish one. So when I push shift+8 I usually get "(", but here I get "*".

</comment></comment></comment><comment><USER9> grate work guys</comment>


Smokers expose you to 'thirdhand smoke' just by being in the same room - <AUTHOR> https://www.fastcompany.com/90471870/smokers-expose-you-to-thirdhand-smoke-just-by-being-in-the-same-room <comment><AUTHOR> Fortunately with all of the pandemic scare mongering, anybody triggered from 3rd-hand-smoke is probably having conniption fits from having to walk through all of that potentially infected exhaled breath when they're out and about.</comment>


Social Security Administration: Cost to exceed income for first time since 1982 - <AUTHOR> https://www.ssa.gov/oact/trsum/ <comment><USER2> "Social Security's total cost _is projected_ to exceed its total income (including interest) in 2018 for the first time since 1982" (emphasis mine). Current title ("cost exceeds income for first time since 1982") is clickbait and wrong.</comment>


Can astronomy explain the biblical Star of Bethlehem? - <AUTHOR> http://phys.org/news/2014-12-astronomy-biblical-star-bethlehem.html

<comment><USER2> Note Arthur Clarke's story, _The Star_ : [http://www.uni.edu/morgans/astro/course/TheStar.pdf](http://www.uni.edu/morgans/astro/course/TheStar.pdf)

</comment><comment><USER3> The idea of tying the account of Matthew to an actual astronomical event is a perennial. I remember as a kid the local planetarium running a Christmas show of what the skies would look like for the closest remarkable events.

[http://en.wikipedia.org/wiki/Star_of_Bethlehem#Astronomical_...](http://en.wikipedia.org/wiki/Star_of_Bethlehem#Astronomical_object) has more on the idea.</comment>


CAPTCHA's Can Be Useful, Don'tcha Know - <AUTHOR> http://gigaom.com/2008/08/15/captchas-can-be-useful-dontcha-know/ <comment><USER2> One great point about this system is that they also offer an audio CAPTCHA by default. This makes it one of the easiest ways to get an accessible (as much as is possible) CAPTCHA.</comment>