Fixing the Inequity of Startup Equity - <AUTHOR> https://data.triplebyte.com/fixing-the-inequity-of-startup-equity-469793baad1e <comment><USER2> Hold on, if we get this wrong we may be lowering the value of everyone's options and hurting startups. Are there any added protections here against high turnover in infancy-stage startups?

For 30(?) years since the invention of stock options there has also been a de facto added protection against high turnover in infancy-stage startups, where having to rehire and retrain employees is extremely costly. Pre-IPO you basically had to pick a team and take it to that level of maturity before you could leave. You couldn't hop around seed-level startups without giving up your options, usually.

What's changed now is startups are staying private longer, leading to unfair scenarios. E.g. you're at a >$1B company with >100 employees for 6 years and you still lose your options. Traditionally a company would have gone public by that time, but now it's not, so we need a fix.

But if you overcorrect and now eliminate that added protections for younger startups, you risk creating an incentive to leave companies just for the sake of options portfolio diversification. Why bet on one team when you can bet on three, since even 1/3rd of a unicorn that makes it is worth more than 100% of the one that doesn't. And that individual decision leads to higher turnover which can kill infant startups.

Bottom line this fix should be more carefully targeted at what has _changed_ to exacerbate unfair situations, namely startups that have reached "should be public" levels of maturity, yet are still staying private.

<comment><USER3> The internet has made it more clear that being an early startup employee will be worse in almost all possible cases compared to working at google even when you get to the $1 billion 'unicorn' status.

For example, I was a jr. engineer at a stage A $5 million startup with ~%0.4 of the company in stock options. When it reached its $1 billion valuation 4 years later, my options with dilution were worth x25. But $500k/4 years is $125k/yr, which is pretty close to the stock compensation working at google. But these options were not cash equivalent like google's stock, and I had to drop it all on the floor because of the 90 day window. I lost $500k in compensation because I decided to work at the startup vs. google.

Imagine if your employees had a good amount of savings and could easily afford the $10-20k it costs to pre-exercise their options in your infant stage startup. Then these rules are pretty moot. It takes advantage of people who don't have the money to pre-exercise options, who tend to be younger people.

Also it's unfair, investors can diversify their income sources, while employees cannot.

<comment><USER2> That's rough. $1B sure feels like a point where a company has graduated from infancy/childhood to being able to handle some turnover. Having said that, valuations a year ago were pretty crazy so maybe they really weren't.

I have to say that's a heck of a lot of dilution, too. 200x growth in valuation vs. only 25x in your stake? What's that, over 85% dilution?? Sounds like that juicy unicorn valuation was only achieved by a lot of fundraising rounds under presumably not awesome terms. Not that that makes you feel any better.

I'm thinking there should be some kind of extra incentive for early stage teams to stick together, but with a more explicit maturity point. It used to be IPO/acquisition. Now that IPO is often farther off there should probably be some other metrics. What are they? Valuation? Number of employees? Length of employment? Revenues? Some combination?

<comment><USER3> You give them stock straight out with a 'reverse vesting' buyback schedule and you cover the tax. If that starts becoming 'too expensive' because of taxation / valuation reasons for the company, then you've reached the size where you give 10 year options or RSUs.

US startup stock options push the tax externality to their employees. In somewhere like canada, your tax bill is due at liquidation, not at the purchase of options. It makes a lot more of this problem go away. For most early stage employees that do well in a tax scheme like canada's then paying $20k for stock in a large valuation company isn't nearly as painful as paying $20k + $100k in AMT tax.

I think that would probably be reasonable for most angel investment and stage A teams. It isn't a stretch for the company to pay an extra $10-30k for a stock transaction where %60 of it cycles back to them anyway for a total of $4k-12k of a tax bill.

Also another way to value the stock to give to early employees is to treat them as investors investing the $500k+ or whatever equivalent they are giving up for 4 years and giving them that as their stock where you foot the tax bill. Also giving them the same visibility and protections that those equivalent angel investors would get.

The percentage points you start giving up for that although starts becoming too large for most founder's tastes, and thus we get the current situation we have today. Many engineers tell themselves, why should I join an early stage startup when I can do so much better as a founder with a similar risk profile?

edit:

I realized you want a way to keep the golden handcuffs that are unique with the US tax law and current equity structure to incentivize poor-ish early employees to stick around without creating an incentive to fire them with back loaded options.

You could create a second stock option reward for the early employees with a company performance + time condition vesting condition and pay the tax bills by giving them the stock right away.

Pinterest's long term stock option expiry date is contingent on being with the company 2-3 years, otherwise it goes back to the same 90 expiry window I think.

You could try many structures, and the market will respond to it compared to their other offers. A good way to start is to explicitly state what you actually want, and then engineers could state what their price is for that ask in comparison with what they can get.

<comment><USER2> Pinterest also didn't enact that until they reached a multi-billion $ valuation and hundreds of employees. They did it when they already knew they could handle turnover. Earlier stage companies might need longer.

But then it's hard to set a definite timeframe. What you want is to incentivize sticking together as an effective team to reach a point of maturity, to maximize the chances of getting there and thus the options being worth anything. It's probably more about size and valuation. That's what was nice about effectively tying it to IPOs (when IPOs happened earlier). Going public was a decision that the board made when they company was "ready".

<comment><USER4> Why should I care more about the company and "turnover" than the people whom the current system gives an incentive to fire so they get screwed under current equity regulations?

<comment><USER2> You should care about both, but if the company fails then your options won't be worth anything.

<comment><USER4> But you're saying that I should care more about the company. I'm asking why.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> We're excited to make 10 years the new standard option exercise window for startup employees. Each of us have personally experienced someone close to us dealing with the stress of trying to exercise their options within 90 days and it sucks.

We'd like to see more companies making this change, we'll be keeping the public list of YC companies who have either implemented or pledged to implement an extended window, updated here: [https://triplebyte.com/ycombinator-startups/extended- options](https://triplebyte.com/ycombinator-startups/extended-options)

<comment><USER5> I dont understand these things much but I think encouraging employees to exercise their options as early as possible is better thing to do when the value of those stocks is dirt cheap.

<comment><AUTHOR> Sure that works early on but we wanted to get momentum behind a solution that would work for any size/stage of company.

</comment></comment></comment><comment><USER6> While this would be great, I'd personally like to see the tax code change - being taxed on the "value" of something you can't realize, and my NEVER realize, is crazy.

Most of the time I've been at a startup as a founder/early employee, the strike price was low enough that I'd be willing to take a roll of the dice and just exercise, if I was going to leave. It's usually 10's of thousands of dollars.

By the time I started vesting a fair amount, the _TAX_ on that was non-trivial - 100's of thousands if not more. Something I personally can't really do.

</comment><comment><USER7> Sorry but this doesn't fix it, it just delays the inevitable.

The main problem is that startups are offering options instead of restricted commmon stock. That means the new hire is paying for stock as an _investment_. That's not a benefit at all.

I have talked at length elsewhere on HN [1] about the system we use to give employees actual common shares, at current strike price, and delay any taxes until exercise so they have zero out of pocket expenses until they have to pay taxes (usually only capital gains).

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

</comment><comment><USER8> Does anybody know of a startup where common stock is issued right away (or let's say after a probation period), and then the employee issues options back to the startup, which expire at fixed intervals corresponding to the vesting schedule?

For an early startup, this would mean when there is a liquidity event, almost all of the gain would be capital gains.

In Canada, it would be even better: people can defer taxes on stock and option grants until disposition (sale/bankruptcy). And the stock could be placed in a registered (i.e. tax-sheltered) account.

<comment><USER9> Many early stage startups will use early exercise options with a clawback mechanism.

After the 409a valuation of the startup gets too high, this option becomes much harder for employees, which is why you don't generally see it outside of the earliest stages.

<comment><USER10> > After the 409a valuation of the startup gets too high, this option becomes > much harder for employees

(Disclaimer: I am not a lawyer, not your lawyer, this is not legal/tax advice, etc.)

As I understand it, it's not just the valuation, but also the tax implications. If the options (as _granted_ ) are worth more than a certain threshold (~$100K), you can't early-exercise them without losing ISO tax treatment on the value in excess of the $100K threshold. This threshold is on an annual basis, so not exercising them early means that you quadruple[0] the amount that will be eligible AMT (which is preferable to ordinary income tax).

[0] Assuming the standard vesting schedule, in which 1/4 of the shares are made available each year

</comment></comment></comment><comment><USER11> Great stuff.

I've personally had to deal with these decisions and know many friends who struggled with figuring out how they could possibly pay for exercising their vested shares, in some cases after they were laid off and had no choice in the timing.

If I were getting a job, I'd only consider offers with extended exercise windows. If they combined it with a more back-loaded vesting schedule [1], I wouldn't mind and would evaluate that. But dealing with the 90 day exercise window is black and white: it isn't worth all the potential trouble and risk you can be forced to take on.

1: 20%/20%/30%/30% instead of 25%/25%/25%/25%, or 6 years instead of 4 years

<comment><USER12> Does it really matter that much? If you're a first-50 employee, then maybe your shares will be worth a decent amount of money, but your exercise price will be very low (most likely). If you're not a first-50, your options probably won't be worth all that much anyways--is it really worth discarding working for a company based entirely on your exit strategy?

<comment><USER11> Yes, it does matter.

If the stock has appreciated in value, your exercise price may be low but your AMT bill may be high even if you have no liquidity at all. In my case I paid more in AMT than I did to exercise all my shares, though both individually were large and incredibly risky investments.

I could afford the risk and it did eventually work out for me, but some people can't afford the risk or frankly don't want to deal with the incredible complication of doing it. Just trying to figure out what your AMT bill might be involves doing your entire tax return based on projections, which depending on what time of year you are leaving could introduce quite a bit of inaccuracy and guesswork.

If you have an extended exercise window you just don't have to worry about it. If you want to take the risk of early exercise to get better tax treatment, do it. But if you don't (which I suspect will be the majority of people), all of the complication goes away completely... just sit on your options and exercise-and-sell when/if you get a chance at liquidity.

<comment><USER13> On the other hand, converting your options to NQSO means that you pay income tax on the spread at the time of conversion. This sucks equally badly in the situation you've described: you're stuck with a big tax bill, at your income tax rates, based on fictional income.

The only good option (pardon the pun) here is to allow your employees to early exercise.

</comment></comment></comment></comment><comment><USER12> As much noise as I hear about this, it's not really that simple. In my estimation, lengthening the exercise window just ensures that dilution will happen faster. If you have 5% of a company locked up by people who no longer work there, you have to find a way to reward current employees. Sure, cash is one way, but it might be easier to issue more stock, most likely of a different class. It might sound good on paper, but ultimately I really don't think this (edited: "this" = extending the window) will have any real positive impact for employees leaving the company.

<comment><USER14> > If you have 5% of a company locked up by people who no longer work there, > you have to find a way to reward current employees

We need to get past this line of thinking. Why do companies not say the same thing for the salaries they've paid former employees? "Boy, I wish we could get back the $30,000 we paid Bob between July 2011 and October 2011."

We don't say that because the employee _earned_ that and once they've earned it, it's out of your account and into theirs. Stock, though a different mechanism, needs to be thought of the same way. If someone has worked there long enough to vest that stock, _they should have the option available to own that stock_. Just because they made the company successful enough to not be able to afford to exercise their options in time doesn't mean we should take that possibility away from them.

Whether or not it was intended years ago when it became a norm, the 90 day exercise window, at this point, is a surrogate mechanism for companies to steal compensation from employees after the fact. That's horrible.

<comment><USER15> People think that way because you can't claw back the salary but you can dilute the entries on the cap table.

</comment></comment></comment><comment><USER16> Next up (and the harder problem imo) is for companies to feel like they have enough leverage vs investors (mainly institutional VC) that they can be "nonstandard" in their option contracts (particularly during seed and A rounds). It's no coincidence that the companies that have taken the lead on this front are the startup darlings and/or repeat founders who have considerable leverage against funders (including YC companies, since their cred boost makes being nonstandard much easier than those without the brand).

We've made huge progress in that direction over the last 5 years as ZIRP made money cheap (and since the main leverage investors have against companies is the scarcity of funding, their leverage has decreased dramatically since the 80's). But as the funding mania crescendo of 2015 has passed, ZIRP is being wound down, and as private and public market valuations of small young tech companies plummet, I am not sure if that trend will continue into the future.

If there is one cohort that can band together to change the status quo, right now, that would be the YC companies. I am hopeful that enough momentum can be built over the next small handful of years by these companies so that "what is normal" can change permanently.

<comment><USER17> I understand the Fed moved the overnight rate up to 25 basis points. It isn't going to last. Rates are going to stay low for the foreseeable future for a laundry list of macro economic reasons -- the easiest to cover is the USA cannot afford to raise rates as it will increase the global consolidation of capital in the US causing severe issues for EU and AP regional (bond primarily) markets. The yield of the 10 year Treasury should show that money is still flooding in and it is still hard to find quality returns: [https://ycharts.com/indicators/10_year_treasury_rate](https://ycharts.com/indicators/10_year_treasury_rate)

</comment></comment><comment><USER18> This is great! I hope this becomes the new norm for all new startups. If a start-up doesn't want to follow this then it really shows the values founders believe in and the kind of company they want to build.

Is this kind of plan unpopular with VCs; shark and Gordon Gekko ilk?

</comment><comment><USER19> Slightly off-topic: The title made me wonder if it was going to be about the vast difference in equity grants between founders and employees (oh well).

But back on topic, harj et al. what's your opinion of Restricted Stock for early employees? I believe the issue is just that granting Restricted Stock once the company / share valuation is high enough is a _definite_ tax impact. But it seems like nearly every pre-Series-A company could give the early employees 100% Restricked Stock. Is there some reason I'm missing that this never seems to happen?

Edit: s/RSUs/Restricted Stock/ since that's what I actually mean (the weirdness of RSUs remains funny).

<comment><USER20> If you are starting at a pre-Series-A company you are probably much better off getting options (that you early exercise) instead of RSUs to get cap gains tax treatment.

<comment><USER19> Oops, I should have said _Restricted Stock_ (not RSUs). Founders get restricted stock (with vesting), so why not the first several employees?

<comment><USER20> Ya. That's prolly a good idea in many cases. You just have to be careful that the FMV doesn't climb too high, and employees correctly handle their 83b paperwork or there will be tax problems.

Honestly I suspect this is why it isn't more standard. It's kind of a pain in the ass to get right. Options are just easier.

</comment></comment></comment></comment><comment><USER21> @Harjeet thanks for writing this up and putting the work into.

Imo our industry needs this. Atm there is very little incentive for experienced people to join early stage start-ups as non-founders vs starting their own thing. Tikhon summarized this quite well: [https://medium.com/@tikhon/founders-it-s-not-1990-stop- treat...](https://medium.com/@tikhon/founders-it-s-not-1990-stop-treating- your-employees-like-it-is-523f48fe90cb)

Making options more employee friendly by default in our industry is an important & good first step!

</comment><comment><USER22> OK, that's the option exercise period. The next step is better antidilution terms. Employees should have the same antidilution protection as founders.

</comment><comment><USER23> @harj - How do you feel about granting cash bonuses to employees at pre- determined intervals to cover the tax cost of exercising their options? It seems like that would solve a lot of these issues, but also give the employee the flexibility to keep a small amount of cash if they'd prefer that over the risk of owning stock.

An example: I join a $5,000,000 Series A startup with a 1% equity grant that vests evenly over four years. At the end of each year, I get a $5000 bonus for the purpose of paying taxes on exercised options. It's a bit more than the tax cost for the first year, and likely a bit less in the later years, but after 4 years I've been given $20,000 which should be enough to cover most of the tax burden. If I leave at the end, I still have a 90 day window to exercise them and the money in the bank to do so. I could just keep the cash, exercise them at the end, or exercise them for a cheaper cost each year.

That doesn't seem too unreasonable for post Series-A startups cost wise. An extra 5k a year is nothing compared to the cost of a developer overall.

</comment><comment><USER24> How about this - the company agrees to purchase And give to the employee any options that are vested and un-exercised for two years and agrees to cooperate w a declared set of known secondary buyers. Employees are on their own for the taxes and can always decline.

* It extends the retention effect of equity since it starts kicking in at year 3 and extends smoothly forward.

* It has no cash impact on the company since its buying the shares from itself.

* In the early years the tax impact should be minimal. In later years there should be secondary buyers who can give employees enough cash to cover the tax liability at the cost of offering a discount.

* It discourages the pure lottery players since it requires the employee to either cover the tax burden or engage a secondary firm and deal w the discount they require.

* The downside for the company (aside from increased dilution vs the status quo) is that it establishes a clear market price for common equity which can be disadvantageous.

</comment><comment><USER25> It scares me that this could be used to justify stock options as having a value other than $0, and could be used to drive down real actual cash money salaries. I'm fine with the current situation because I have no plan to act on the options anyways - I don't invest in lottery tickets either.

<comment><USER26> If you believe that the stock options of the startup you're at are worth $0, you should just ask for a market salary with 0 equity. Many companies will give you a sliding scale of cash / equity.

</comment></comment><comment><USER27> As I understand it the major problem is that engineers need a lot of cash to get even more cash if they exit the company and need it in 90 days. Possibly very naive question...couldn't you include a clause along the following line in your funding round(s): "Investor X guarantees that they will offer to cover the necessary cost to exercise all options in return for Y%". So basically if engineer A leaves and could exercise options the investor must offer a "bridge loan" with guaranteed ROI (either cash or just keep the equivalent options).

Good investors shouldn't mind this clause that much (I'd think) as it takes away one major point of worry for engineers and lets them concentrate on their job from day 0.

</comment><comment><USER28> "Many employees don't have the money to exercise their options within such a short window and lose them."

Sounds like an excellent opportunity for a business. Providing short term loans, taking x% or the exercised options. Although I am not familiar with US laws that cover this area.

<comment><USER12> I really doubt whether that would work. The loans aren't necessarily "short term", as the term is pretty much not known, the shares are the lowest on the totem pole when it comes to payout and you have absolutely no control over the company. That's a lot of risk, and if the cost of exercising options is so high as to be difficult, the shares probably don't have the upside that might be required to make it work.

<comment><USER28> My bad, misunderstood the nature of these type of options. I was making the assumption that the options could be exercised and then sold straight away. Eg, employee has option to buy during this window at a strike of 1.1, current value 1.3. I presumed the issue was raising the initial (options x preferred price) cash plus any taxes/fees involved.

<comment><USER12> I believe most companies whose stock is publicly traded provide this for their employees. If you have stock in, say, Google, when your stock vests, you can have it sold and take the difference directly--no loan needed. I've never done such a thing, so it's only hearsay on my part, but that's how I've understood it to be.

<comment><USER29> It's called a cashless exercise. You exercise and sell the stock right away so you don't need to have the money to buy.

However the problem is most startups in this case are not liquid so you cannot sell your shares (with some exceptions). Google and other public companies give you direct shares via RSUs since they can sell part of your shares to cover the taxes.

</comment></comment></comment></comment></comment><comment><USER30> Does having a bunch of vested, 10-year-window options on the books of a startup affect its valuation? Would a potential buyer look at that and think "That's a liability!"?</comment>


Quelling the floating point demon in my line rendering code - <AUTHOR> http://mortoray.com/2015/01/07/quelling-the-floating-point-demon-in-my-line-rendering-code/

<comment><USER2>
      > angle = Collision2D.AngleBetween( lv, bisectNormal )
      > if( /*cusp*/ angle < 0.1f || angle > Math.PIf - 0.1f ) {
      >    //use alternate corner cap
      > }

Just a quick note: you might want to use dot product there:

      if( /*cusp*/ dotProduct(lv, bisectNormal) < 0.1f ) {
          //use alternate corner cap
      }

<comment><AUTHOR> I know in some situations you can use dot product and it's an optimization I will apply. A bit more care must be taken though. The input must be unit vectors and the output can be positive or negative.

I tend to do my first code as logically clean and then apply optimizations later. This will likely be replaced by an `IsCusp` function instead, to make it even clearer, and provide a clean place to do the optimization.

<comment><USER2> Oh, indeed. I'm a bit embarrassed I didn't consider the need for normalization and the potential negative output :P</comment></comment></comment>


BankAPI - <AUTHOR> https://github.com/trustly/bankapi/ <comment><USER2> > 1\. All parties MUST use a key length of 2048 bits for their RSA keys.

What is the point of this? Seems to me there'd be no problem in using 3072 bit RSA keys, which makes more sense given that the lowest security symmetrical encryption algorithm permitted for use is AES128, and the difficulty of breaking AES128 is roughly equivalent to breaking 3072 bit RSA.

<comment><AUTHOR> Did you not read the next sentence? "Implementations MAY accept longer keys.". It should say "of at least 2048 bits", I'll update the docs.

<comment><USER2> I did, but it doesn't make sense in the context of the first one (it doesn't matter that peers may accept longer keys if everyone must use 2048 bit keys). But with your correction it makes sense.

I'm still interested in the reasoning behind accepting 2048 bit RSA keys instead of setting a 3072 bit minimum, which corresponds to AES128 in security[1][2].

[1] [http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_p...](http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf) (Page 64, Table 2)

[2] [http://www.emc.com/emc-plus/rsa-labs/standards- initiatives/k...](http://www.emc.com/emc-plus/rsa-labs/standards- initiatives/key-size.htm)

<comment><AUTHOR> Quite many seems to be using 2048 bits RSA-keys for SSL- certicaties:

openssl s_client -connect www.google.com:443 Server public key is 2048 bit openssl s_client -connect www.twitter.com:443 Server public key is 2048 bit openssl s_client -connect www.hsbc.com:443 Server public key is 2048 bit openssl s_client -connect www.citibank.com:443 Server public key is 2048 bit

I don't know the limitations in all the legacy bank systems around the world, but I know my personal OpenPGP smart-card is limited to 3072 bits, but that card is quite modern. Maybe the limits for legacy systems is even worse.

The System Design supports multiple keys per bank, so if a stronger key length is required, keys can easily be upgraded in the future.

But, I agree the strongest key length possible should be used if possible, which is 4096 bits according to the OpenPGP specs.

We will update the specs accordingly.

If any bank for some reason cannot support 4096 bits, then I think it's fair to require at least 2048 bits, as that key length is used by a lot of high profile websites, including banks, already today. (see above list)

</comment></comment></comment></comment><comment><USER3> What's the motivation for this? Is it coming from inside the industry/is it a suggestion/fun project?

I'm don't understand the purpose - it's all about transmission, not data. Banks could sure do sure do with a standardised API, but is interbank message encryption a problem needing solved? I've haven't heard anything like that.

The author is very sure of it's production-readiness. If this transpires to be true, then I could easily see this spec as a good way to encrypt message-based data of all kinds. But where does this bank angle come from?

<comment><AUTHOR> Author here. That's a good question. Please see: [https://github.com/trustly/bankapi/blob/master/doc/rationale...](https://github.com/trustly/bankapi/blob/master/doc/rationale.md)

<comment><USER4> > The decentralized design of BankAPI protocol ensures noone controls it, > noone owns it, noone can shut it down, just like the Internet. The un- > innovative design of BankAPI protocol ensures noone can critizise it, as > there is nothing new invented, it's just a combination of existing well > proven technologies.

I don't think I'm comfortable with the 1960s singer-songwriter Peter Noone having this much control of your system.

</snark>

This is a grammatical pet peeve of mine[1], principally because I used to use it exclusively and was horrified when a girl I liked at the time corrected me.

1\. [http://grammarist.com/spelling/no-one- noone/](http://grammarist.com/spelling/no-one-noone/)

<comment><USER5> [https://github.com/trustly/bankapi/pull/2](https://github.com/trustly/bankapi/pull/2)

<comment><AUTHOR> Thanks for fixing!

</comment></comment></comment></comment></comment><comment><USER6> I dont know if anyone is interested, but someone once asked me to look into the SWIFT messaging system, i'd never done anything with banking before. I made a little once page app as i learned it which breaks it down to what everything does.

It doesnt do anything except send to a validation API, which currently is down cuz i've not touched it in months, but i figured some people might find this interesting.

[http://labs.tamdenholm.com/swift/](http://labs.tamdenholm.com/swift/)

<comment><USER7> I am interested. After looking up SWIFT I can't really get a grasp on what kind of things you can do with it if you're not a financial institution. Do you have any examples?

<comment><USER6> I'm afraid i didnt get that far, to my knowledge theres no use for it outside the banking system. The example above is of an MT999 which is to send generic messages to and from systems, other codes do other things, have a google, theres a bunch of info on it.

</comment></comment></comment><comment><USER8> I don't think that's how banking works to be honest. Money move from bank to bank via the countries central banks if I'm not mistaken. Then the central bank reconcile everything in batch processes to ensure that banks aren't just making up money (well more than they are legally allowed to).

Denmark has had a few occasions in the last few years where this has failed because one bank failed to deliver their transactions one night.

<comment><USER9> IIRC, thats mostly done using SWIFT [1]

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

<comment><USER10> ... for more background, SWIFT is an essentially global monopoly on international interbank transfers with all messages recorded in full by the US and its allies[1]. Despite claiming they only send messages, in effect money is moved and there are documented cases of it being seized off the wire by the US even in EU<->EU state transactions. It opened its first 'international center of operations' in Virgina (~CIA HQ) as a first order of business after accruing partaking institutions at a speed frankly unbelievable given the technology of the time. It was billed as a telex replacement.[2] After recently dispatching with its carefully developed apolitical facade and banning Iran (after receiving Europe's blessings at the behest of UANI, which is essentially Mossad + CIA old guard[3]), it pissed off India (who depend on them for energy security) and raised eyebrows in Russia and China.

While it's probably critical for the future of humanity for a project like this to succeed, frankly anything that leaves the trust and reputation aspects to manual negotiation as per conventional business is just lipstick on a pig. In this sense, Bitcoin is superior. For some more ambitious ideas forming in this area check out [http://ifex-project.org/](http://ifex-project.org/)

[1] Quote from European Data Protection Supervisor in response to FOIA: "since at least 2001" [http://www.asktheeu.org/en/request/information_on_financial_...](http://www.asktheeu.org/en/request/information_on_financial_informa#comment-46)

[2] [http://www.swift.com/about_swift/shownews?param_dcr=news.dat...](http://www.swift.com/about_swift/shownews?param_dcr=news.data/en/swift_com/archived_news/61159_carl_reuterski_ld.xml)

[3] [https://en.wikipedia.org/wiki/UANI#Leadership](https://en.wikipedia.org/wiki/UANI#Leadership)

<comment><AUTHOR> Author here.

Thanks for a well written description and background of SWIFT, I think it is accurate.

I have a question on this paragraph:

>While it's probably critical for the future of humanity for a project like this to succeed, frankly anything that leaves the trust and reputation aspects to manual negotiation as per conventional business is just lipstick on a pig. In this sense, Bitcoin is superior. For some more ambitious ideas forming in this area check out [http://ifex-project.org/](http://ifex-project.org/)

Does "for a project like this" refer to SWIFT or BankAPI? If SWIFT, then I understand. But if BankAPI, then you have misunderstood, because it does not "leaves the trust and reputation aspects to manual negotiation", since it's decentralized and peer-to-peer (or in this context bank-to-bank), just like a lot of other successful peer-to-peer technologies of which you mentioned one.

<comment><USER10> What I meant by "a project like this" was a concrete, functional alternative to existing status-quo systems, with SWIFT as the implied primary target for forced deprecation.

I think banking is an artificial industry, one that doesn't really have to exist. I believe that money that is state issued, electronically issued, trust that can be quantified, reputation and physical goods are all equally valid assets for forward-looking exchange protocols. I believe that any distinction between participants is farcical and that risk management models, encryption preferences, topology specification and other qualitative decisions regarding deployment _must_ be left out of scope.

To clarify my original comment further, I do think that BankAPI, just at a glance, is probably focusing too much on the conventional world of banking rather than looking at the big picture ... which has nothing to do with banks and everything to do with a potential revolution in the way we organize society, removing anachronistic middle men and vested interests who consistently fail to demonstrate any meaningful reason for being while extracting vast quantities of wealth from society at large and encouraging the continuation of a socio-political and economic trajectory that will see our environment destroyed within a generation.

</comment></comment></comment></comment></comment><comment><USER11> Interesting project

More and more financial institutions are starting to implement messaging using the FIX protocol

[http://www.fixtradingcommunity.org/pg/main/what-is- fix](http://www.fixtradingcommunity.org/pg/main/what-is-fix)

<comment><USER12> Really, my experience is the opposite. FIX is old, like 1992 old and its starting to show its age. Not that age is necessarily a bad thing, I just wanted to point out its age as your comment makes it seem like an up and coming protocol. My experience is that more and more firms are leaving it.

Its' no longer suitable for market data. Its barley suitable for sending order messages around. And with the explosion of order types and growth I'm not sure that's a valid statement anymore.

Its not anywhere near as compressible as binary formats. Many exchanges and dark pools have already replaced it with binary formats.

What fix does have going for it are quickfix/j and a wealth of knowledge, which will keep it relevant for a long time, but

<comment><USER13> FIX can operate as a binary, compact ASCII or XML-like protocol. FIX has support for multicast. FIX has open source Java, .NET and C++ implementations. It's got a thriving development community and a non-profit, industry-driven standards body. FIX isn't going anywhere. No buts.

Possibly you haven't looked at it since 1992...

<comment><USER14> But FIX _is_ going away in US equities as all of the major exchanges have adopted native binary protocols. We still have to deal with it in other asset classes, but I (as a developer) am not really happy about it. FIX/FAST is a massive pain in the ass relative to simple binary protocols.

</comment></comment></comment></comment><comment><USER15> With banks considering the switch to the Cloud, how would this specification address the issue of key management on the Cloud? That's the "key" to Cloud security. Currently, there are solutions available which are obnoxious for those who really want security of their data and not just a tick mark on some data security checklist because key managers CANNOT be hosted on the Cloud. The dominant approach (CipherCloud for example) is to have an encryption gateway in-house which encrypts/decrypts/tokenizes on-the-fly before data leaves for the Cloud. Their approach is to enable support for popular SaaS apps like SalesForce and archive storage like S3 etc which makes sense BUT then again, it's dependent on whether the vendor would add support for more apps or open the API for 3rd party devs to plug in support for other Cloud apps.

<comment><USER16> A networked HSM is certainly one approach to solving this. Often, corporations -- not just banks or financial institutions -- will rent a cage in the same data center as the cloud provider, and will run a dedicated line from their cage to the provider. The networked HSM will store all key material, and whatever sensitive servers/databases/applications are provisioned in the cloud will leverage it for cryptographic operations.

In theory... 1) The keys never leave the physically-hardened HSM, so they're "safe", 2) Transmission between the HSM clients and the HSM is done over an encrypted channel, so that's "safe"

There's always a very high risk of implementing things improperly and negating any security benefits of this type of setup, but that risk exists with on-prem infrastructures, too.

<comment><USER17> You forgot to capitalize "Cloud".

</comment></comment></comment><comment><USER18> As far as I know banks tend to prefer dedicated lines rather than relying on the internet, but I guess that isn't always available.

<comment><USER19> More and more traffic to and from banks goes over the public internet, it is a matter of time before 'dedicated lines' will be limited to the military and that's pretty much where the internet originated so at a guess even they are using the internet except for when it is extremely critical to get traffic from 'a' to 'b' with minimum latency.

<comment><USER20> Seems like dedicated lines would be more secure. More expensive, too, but sometimes security should trump expense.

or

How stupid do you have to be to trust core financial information to public communication methods?

<comment><USER19> > More expensive, too, but sometimes security should trump expense.

All security is a trade-off between 'enough security' and expense. There is no such thing as 'absolute security', if dedicated lines are not measurably more secure than the public internet then choosing to route your traffic via the net rather than via dedicated lines is the right decision.

Banks are in general not 'stupid' when it comes to what they do with their data, they try to do their best within the triangle of security, expenses and technical demands.

If you think using 'public communication methods' for the transport of core financial information is stupid then I guess you are also against banks that are connected to the internet using websites, against banks that use 'swiftnet' (SWIFT is a provider of a secure network used to transfer financial information between banks, which - surprise - has been compromised in the past by the NSA and where payments in transit between two other countries has been seized by the USA because those payments violated a US policy).

In the end, at some point a bank will have to trust the wires and the parties that maintain those wires. From a banks point of view an operator like SWIFT and the public internet vary in degree as to their security but which one to use will always be a business decision and as noted above even SWIFT is not 100% secure and might in some ways be _less_ secure than the public internet.

I also wonder how you propose banks communicate with their customers and with their branch offices.

Here is a nice page on the connectivity options a SWIFT partner gives to its customers all the way from DSL to dedicated lines:

[http://www.orange-business.com/en/swift-connectivity](http://www.orange- business.com/en/swift-connectivity)

And dedicated lines can be tapped too, so in the end the encryption matters more than the physical connection.

</comment></comment></comment></comment><comment><USER21> Are there any banks actually using this? Or is it more like a suggested spec draft?

<comment><USER22> Yes some of the largest Northern European banks.

[https://trustly.com/en/](https://trustly.com/en/)

<comment><USER23> I loooked at their pricing page on [https://trustly.com/en/pricing/](https://trustly.com/en/pricing/) \- not a single price is there. Come on guys...

<comment><USER24> If you publish any kind of price, that affects your negotiation options if you want to do individual pricing/haggling for each customer.

Also, a multitude of factors affect the 'true' price including various risk estimates of your company, and it would be counterproductive to say "factor X, as measured by Y, gives you a price increase/decrease of Z", as that would just result in gaming the measurement and misleading about the nature of your business.

<comment><USER23> All valid facts - then just don't call the page pricing. Call it "enquiry" or "contact" or whatever...

</comment></comment></comment></comment></comment><comment><USER25> Is there any potential synergy between this project and Open Transactions? [http://opentransactions.org/wiki/index.php?title=Main_Page](http://opentransactions.org/wiki/index.php?title=Main_Page)

</comment><comment><USER26> Why this weird API? I dunno, I would expect exactly two functions, one for sending a "file", and one for receiving whatever is new in the inbound queue, with the abstraction taking care of delivering the enqueued files to their destination!? And maybe a callback API so I don't have to poll for new inbound "files". Also, I'd expect the abstraction to provide an ordered, lossless stream, rather than some weird "file sync" which seems to lack all reordering and replay protection?

</comment><comment><USER27> From the docs, I can't figure out how this is "decentralized". All I see are encrypted and compressed.

<comment><AUTHOR> Author here. It's decentralized because the FromBank and the ToBank communicates directly over the Internet using TCP/IP+HTTPS+OpenPGP, which is different from a centralized communication system like SWIFT, where the FromBank would first send the message to ToBank's SWIFT address (so called "BIC"), and wait for ToBank to check their SWIFT "inbox".

Compare: FromBank <-> ToBank (BankAPI, decentralized) vs. FromBank <-> SWIFT <-> ToBank (SWIFT, centralized)

(FromBank = Bank sending the message) (ToBank = Bank receiving the message)

<comment><USER28> What happens when the beneficiary bank can't be contacted? Their servers may be down, they may be getting DDoSed, a production upgrade may have gone wrong and they're inadvertently dropping all messages.

That lumps a whole lot of complexity on FromBank, if the onus is on them to ensure ToBank correctly received the payload.

SWIFT takes care of all of this. You also have to guarantee to be connected to the SWIFT network for at least 7 hours per day to process your inbox, and new banks get silo'd in a test area for two months where they have to prove their systems are functioning properly within the SWIFT env before they're connected for real.

As long as FromBank gets its confirmation when it posts to SWIFT, job done. SWIFT takes care of ensuring it gets to ToBank.

<comment><AUTHOR> We are already using SWIFT for much of our messages from/to banks, but it comes with a high cost and a lot more complexity than BankAPI, as messages are not sent directly from A to B, but from A to SWIFT, and then B must check their SWIFT "inbox" to receive the message from A.

With BankAPI, the response from the request comes directly from the beneficiary bank, meaning you know in real-time the message has been delivered. Compared with SWIFT, you only know _SWIFT_ has received the message in real-time.

If the beneficiary bank can't be contacted for what ever reason, the sending bank (FromBank) simply keeps on trying until the beneficiary bank (ToBank) are back online again. The problem with DDoS is a valid concern, but given the banks Internet banking services are also accessed by the banks users via the Internet, they are already dependent on the Internet.

If you don't need real-time messaging and if cost nor complexity is a concern, then you probably won't find BankAPI interesting.

</comment></comment></comment></comment><comment><USER29> Simpler than this, I really wish my bank had a github-style webhook support for so that integration with other services could be great.

</comment><comment><USER30> a similar project: [http://www.openbankproject.com](http://www.openbankproject.com)

</comment><comment><USER31> If it kills Connect:Direct, hooray!

</comment><comment><USER32> HN really needs to show a 2nd level to some domains in the headline:

BankAPI (trustly.github.com) not BankAPI (github.com)

Always takes me a moment or two to work out if it's a Github specific link or a project on Github

<comment> vertex-four This doesn't link to trustly.github.com though.

<comment><USER33> Worth noting that HN does already have that functionality on a domain-by- domain basis. Not sure which domains exactly, but in 30 seconds found examples for blogspot.com, pinboard.in and github.io (example links below)

      https://news.ycombinator.com/item?id=8256653
      https://news.ycombinator.com/item?id=8249953
      https://news.ycombinator.com/item?id=8252208

</comment></comment></comment><comment><USER34> This is a cool project, but considering how over-regulated banks are these days (at least in Europe) I think it's very unlikely that they would actually use this. Most bank software is still written in Cobol code that they have invested four decades into and are now too afraid to rewrite or even touch. So, specifying the requirements for an interbank message system would probably take them a few years already, and implementing it in a "proper" way -i.e. confirming to all their regulatory requirements- would take ages (also, they will probably already have a system for this in place).

That being said, I think for less regulated sectors of the industry this could be a very interesting project.

<comment><USER35> I used to work for one of the megabanks. The majority of their credit card processing is written in Fortran and runs on 20-30+ yr old mainframes. They don't dare touch it. "If it ain't broke..."

There are certain universities that teach Fortran specifically for companies like this; any student of Fortran has an automatic offer once they graduate.

<comment><USER36> Are you sure it was Fortran and not Cobol? Normally Fortran was used for academic/math (ForTran stands for Formula Translation, Cobol in busines (Cobol stands for COmmon Business-Oriented Language).

<comment><USER37> Fortran found its way into finance because it was the programming language taught to engineers in school. (These were real engineers -- software engineers hadn't been invented yet.) If you hired them to build computer systems you got systems in Fortran unless you specified otherwise.</comment></comment></comment></comment>


HN Feature Request: Relevancy voting. - <AUTHOR>

What does anyone think about having an ability to vote on whether you think a particular submission is relevant to Hacker News? The vote could be totally impotent and serve only as a visual signal to the community which submissions are appreciated and which are not i.e. it would not affect its rank. If nothing else it would provide a sink into which you can pour your frustrations regarding off-target submissions. It shouldn't be too hard to implement or remove should it not work out. <comment><USER2> Isn't this the same as a "down arrow" on submissions?

It would be interesting to have a down arrow on submissions that doesn't actually do anything, just to see how people would use it.</comment>


Show HN: Marple – Visualising millions of datapoints for engineers - <AUTHOR> https://getmarple.io/ <comment><AUTHOR> Hi HN, co-founder here! We designed Marple for engineers to make visual analysis intuitive and powerful. Most of our users are control systems engineers or test engineers (but not the kind that tests software). They often have to draw conclusions from millions of time series data points. As a quick example: logging data from a drone control system for 15 minutes at 1.5 kHz is already more than 1 million samples.

This creates some interesting technical challenges. We implemented a custom visualisation engine that efficiently displays only the data that fits the screen. In the same way, we also support applying functions such as low-pass filters, integrals, derivatives, etc.

Having a visual approach to analysing data is in our opinion still highly underrated. Common engineering tools such as Matlab or python+matplotlib scripts require you to reduce the number of samples yourself. And you end up with a plot that is not interactive: zooming, panning highlighting, adding a different signal are all cumbersome or impossible. Marple treats interactivity as a first class citizen.

We recently launched a beta version and we're currently looking for test users to try it out. If you sometimes need to visualise some data from a .csv file, python script, matlab script, simulation, ... you should give it a spin!

Cheers! Nero

<comment><USER2> Some questions:

\- Is there druid integration? Is this a replacement for druid? \- How does schema inference work? \- Can I do SQL queries? \- How is this better than superset?

<comment><AUTHOR> There is no integration for any db setup at the moment, but this is one of the next things we will tackle for sure! Druid was not on our radar, seems like it is used a lot in automotive/aerospace. Never tested superset, I'll give it a try. But it looks to be more like a dashboarding tool. Our goal is to provide an investigative tool that allows the user to detect problems and in a very interactive way change the visualisation.

<comment><USER2> I downloaded and looked at it. Very cool. Superset has the broad alchemy integration, which is pretty nice.

Integrating into a larger enterprise data dictionary would be nice. Eg, amazon glue

This is really a big data visualization tool. There's a whole gigantic rich market there to capture. You seem to be looking at it from the perspective of csv files, which is a fresh take, I guess.

It's also unfortunately a very competitive space being worked on by folks with insanely deep pockets and hyper smart engineers: [https://www.newgenapps.com/blog/10-big-data-visualization- to...](https://www.newgenapps.com/blog/10-big-data-visualization-tools/)

Still, a lot of what's out there is ungainly bloat ware meant for business logic data. If you target specific engineering/science verticals with clear use cases, it would compete.

<comment><USER3> (other co-founder) Thanks a lot! Great to hear these positive reactions. You make some very valid points. We are indeed trying to focus on a certain use case, which we encountered our self in the past.

</comment></comment></comment></comment></comment><comment><USER4> How much does this actually cost? I don't see pricing anywhere on the site. I assume that info comes with the trial email but TBH I don't want to waste my time with the trial if it's going to be out of my price range.

<comment><USER3> This is a beta version, the goal of the trial is to gather feedback and find interested parties. Pricing and pricing model is not set in stone yet and will depend on what we see is feasible. Feel free to contact us in private to discuss more in detail! :)

</comment></comment><comment><USER5> Well that's just odd because I happen to live in Marple the town [https://en.wikipedia.org/wiki/Marple,_Greater_Manchester](https://en.wikipedia.org/wiki/Marple,_Greater_Manchester)

</comment><comment><USER6> Looks amazing! I've been using KST for years [https://kst- plot.kde.org/](https://kst-plot.kde.org/) for interactive plotting but marple looks to have some features kst does not

<comment><USER3> (other co-founder) Cool! Let us know how you like it compared to KST :) We focused a bit more on UX and interactiveness

</comment></comment><comment><USER7> Ooooooh interesting! Does it integrate with streaming or realtime services / db solutions? What's the max load you've tried out so far? Would you offer on- prem like Metabase?

<comment><AUTHOR> Realtime and db are among the things that we will work on next. We still need to figure at a way to do this efficiently for us so that we don't need to integrate ourselves with every kind of db. The maximum was about 400 million datapoints in one visualisation, and that worked fine! We're also definitely considering a Metabase/Grafana approach where you can deploy it yourself.

</comment></comment><comment><USER8> Hello. Nice product, but some small problems:

\- on MacBook 13", when editing calculated signals the dialog is bigger than the screen and the dialog cannot be closed (and maybe some other parts of the interface are hidden) - maybe add a max width/height on the dialog and a scroll

\- the license does not work on windows (but works on mac build)

\- on mac the feedback button the application splits in 2 identical views, with the mouse cursor movements mirrored (and an error about creating a folder .../bugs)

<comment><AUTHOR> Sorry for the huge delay, I missed your comment. Thanks for the feedback! \- just to confirm: this means your screen is has a height < 800px? \- do you remember what exactly went wrong on windows? \- sounds very weird behaviour, do you have a screenshot?

Thanks!

</comment></comment><comment><USER9> I guess I will take the opportunity to congratulate Marple and say (self promotion), that you have an open source alternative, that is equally able to deal with gigabytes of data and millions of points.

[https://github.com/facontidavide/PlotJuggler](https://github.com/facontidavide/PlotJuggler)

</comment><comment><USER10> It looks likes this is a chromium/proton wrapper around a webapp. Is that correct? The plot lib used seems very similar to plotly.

I'd be very curious to hear about some of the tech stack design choices. I'd be also interested to understand who's your target user.

<comment><USER3> Very close, it uses Electron! Front-end is written in ReactJs. The plot library is react-vis currently, but we're replacing that soon. All the zoom/pan logic we implemented ourselves. Backend is a completely separate process. We've chosen for this architecture as it gives us the flexibility to easily change from desktop product to a web/server product, if we feel like that would be a better fit :) Target users can be very broad and is something we are still figuring out, but at the moment we see that engineers that have to deal with data from tests or simulations are a good fit for Marple.

<comment><USER10> Do you plan to commit back to the community your extra graph UX/UI. They look very neat and I don't think it will jeopardize the success of your startup. The reason why I asked about the usage of Electron (or similar) is because they are well known to be resource hungry. Slack went down that route and found themself in a pickle. Considering you are also doing a lot of data manipulation in memory (I assume) this might be very expensive on a React Stack. Anyway, something to keep in mind, don't worry about it right now.

If you are going after individual contributor, I'd spend quite some time figuring out good integration points (ie.: Notebooks), so you are better integrated in their workflow. I'd avoid going enterprise, because date warehouse and data visualization are well solved problem (both in SaaS and PaaS flavor). Source: I led data organization at mid/big companies.

<comment><AUTHOR> (Mbaert his comment, but his account is throttled) We were worried about the performance of Electron as well. All data intensive work is done in a separate process, once in react/electron no data manipulation is needed anymore. So far it works quite ok, performance upgrades we find in electron usually don't have anything to do with the data.

Thank you for the info, we're still finding our position in the market. Figuring out the perfect use case and integration in a certain workflow will be key indeed! Feel free to contact us in private if you like to discuss more in detail about your experiences, we'd love to hear more :)

</comment></comment></comment></comment><comment><USER11> For some reason, your Website is broken on Safari: The images only show as a gray vertical line, about 5px high. Right-click -> "open image in new tab" works, so I'm guessing it's a CSS issue?

<comment><USER12> Works for me in Safari (Mac Catalina and iOS).

<comment><USER11> Yeah, it worked for me as well after reloading. Then it didn't work again on the next reload. And once I opened developer tools, it always worked.

<comment><USER3> (other co-founder here) Thanks for the heads-up! Might be slightly overloaded at the moment

</comment></comment></comment></comment><comment><USER13> Nice! Having developped a tool similar in features at my current job, I'm about to start on my own a similar projects... Happy to see that this area get some traction.

</comment><comment><USER14> Tried it out, looks nice :) Is there a quick screenshot feature? That would be really helpful for sharing analysis and storing important views.

<comment><USER3> Thanks :D We're working on an export feature to quickly share or paste in a ppt etc.. But for now you'll have to rely on your printscreen or snipping tool skills.

</comment></comment><comment><USER15> This looks great, congrats on the launch! Are you taking advantage of any hardware acceleration (eg GPU or CPU vectorization)?

<comment><AUTHOR> Thanks, cool question. The insane performance gains we have when visualising are mostly because of conceptual decisions we made. One such thing is that we don't try to plot more datapoints than there are pixels on the users screen. But when a user does calculations on data (e.g. a low pass filter), we really have to do all the math. So in that case we are mostly using numpy (python) operations, which are optimised in C already. But I don't know if this includes vectorisation

</comment></comment><comment><USER16> Is this a system that runs on a laptop or is it on cloud?

<comment><AUTHOR> On your own laptop for now. This has the advantage that your data is already there on your local disk - no need for uploading. But with some minor changes we can run it in the cloud too

</comment></comment><comment><USER17> Best guess they use an integral images to do the zooming

<comment><USER3> Good guess! We do some cool subsampling (certainly on big files) to be able to show a lot of datapoints.

<comment><USER17> Maybe the financial industry is interested in it, they have time series too

</comment></comment></comment><comment><USER18> Site is broken (broken images). Fix it before you launch.

<comment><USER19> Please don't be a jerk on HN, especially not in Show HN threads, which have special rules: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html).

<comment><USER20> Jerk might be a strong word, I think he/she might have been trying to help, but it comes across a bit terse.

<comment><USER19> It's true, I felt it was a bit of a strong word even when posting it. But naked imperatives ("Fix it before you launch") come across as aggressive in casual English nowadays.</comment></comment></comment></comment>


Pinebook Pro review–a $200 FOSS-to-the-hilt magnesium-chassis laptop - <AUTHOR> https://arstechnica.com/gadgets/2020/06/pinebook-pro-review-a-200-foss-to-the-hilt-magnesium-chassis-laptop/ <comment><USER2> Interesting he liked the trackpad. Most of the feedback I'd seen mentioned terrible lag with that. I guess they've fixed that issue?</comment>


The history of supercomputers - <AUTHOR> http://www.extremetech.com/extreme/125271-the-history-of-supercomputers <comment><USER2> One page and readable: <http://www.readability.com/articles/yqn3js4v>

</comment><comment><USER3> I remember being fascinated how cool supercomputers looked when I was getting into computers in the mid 90s. The Connection Machine supercomputers come into mind. <http://en.wikipedia.org/wiki/Connection_Machine>

<comment><USER4> I loved how the Crays looked. I have a picture of myself standing in the middle of a Cray 2, it is one of the coolest pictures I have.

</comment></comment><comment><USER5> This is a nice photo gallery, but as a history of supercomputers its pretty shallow.

<comment><USER6> Agreed, it is a good "starter" but not an in-depth examination of the history of super computers.

</comment></comment><comment><USER6> As an enthusiast of old mainframes and the like, I found this read to be very enjoyable. Thank you for sharing!

</comment><comment><USER7> _"Throughout history, Intel has occasionally tried to launch chips based on a non-x86 architecture, usually without success. In 1989 it released the i860 [...]"_

The iAPX 432 was an earlier Intel miss. Much ballyhooed in the trade press for a couple of years. Supposed to run Ada programs efficiently, or something.

(Just noticed that lowercase 'i' there - in the 1980s, it meant an Intel chip, most famously the i8086.)

Also, the CDC 6600 probably deserves whatever press it gets. Though I think IBM sold a lot more 360s.</comment>


Study: Youth have more mental health issues than previous generations. - <AUTHOR> http://www.startribune.com/local/81127647.html?elr=KArksLckD8EQDUoaEyqyP4O:DW3ckUiD3aPc:_Yyc:aUUsZ

<comment><USER2> The study's rather useless. How well does the study account for better or changed diagnosis methods? Or whether students simply find it more culturally acceptable to report mental problems? The reporter barely gives recognition to the fact that there /might/ be inaccuracies with the data.</comment>


Ask HN: anyone want to work on a side project with me? - <AUTHOR>

want to start something that's more like a feature with potential to build a legit business on top of it. i can do the marketing/business end. you can do that technical end.some examples: - very niche dating feature off of a concept that already works but for this niche group it does not. and i know why. already know the different strategies that's available to break chicken an egg (online and offline) - similar to hacker news/forum but for a different targeted group. there's a unique way to acquire this group of users (and i'm connect to a lot of them).
anything else that has a consumer facing side that's quick to launch and has an interesting feature (must have virality component e.g. selling sex, communication, or inherently a group activity).
if it takes starts to take off i have access to a decent amount of business/fundraising/even celebrity type connections that can help us out along the way. not set on anything. just want to see if anyone is interested. <comment><USER2> I am Intrested in that , I am an Indian teen with a lot of free time and technical knowledge .</comment>


Show HN: JobTrial – Try a potential fit, before a fulltime offer - <AUTHOR> http://jobtrial.co <comment><USER2> Congratulations on creating & shipping your 1st product!

My first reactions, in order of appearance - hope they will be helpful in crafting the UX:

1\. After reading HN title: Why would anyone need a special site for Trial Period?

2\. After first glance at the site: Aaah, it's only for 3 days. Why so short? Does the site help the companies make a good decision after these 3 days or is just a sourcing channel?

3\. After noticing that the jobs aren't dev only: Great! So many job sites are focused on devs exclusively :)

4\. After clicking "Start trial" link: Why do you want me to sign-in? I didn't notice this requirement earlier. Why Twitter? Why don't you provide some form instead?

5\. After attempting to sign in with Twitter: Why do you need so many permissions? Update my profile? Post Tweets for me? Can I trust you?

6\. After abandoning the sign-in and going back to home page: Aaaah there's "Pleas sign-in message at the top". It seems I was banner blind 2 minutes ago. So where is the FAQ, contact info, TOS and other stuff required to form at least basic level of trust?

So, as in case of many services it was a little emotional roller-coaster between hope, disillusionment and doubt coming form insufficient information. Fortunately all of these seem to be quite easy to fix :)

EDIT: A couple more of questions running through my head during the 1st experience with your site:

1\. How will the trial look like? How much time should I reserve? (it would be great if such info would be part of Job Posting)

2\. Does "Start trial" mean that I'll be instantly connected to someone? Should I expect an interview? Are the positins remote or on-site? etc.

3\. Am I right to expect that the trial will be unpaid one?

<comment><AUTHOR> Thank you so much for taking time and writing this. I haven't really concentrated much on the UX front :(, intentionally.

2) The thought process behind 3 days was job-seeker could take a 3 day off from his current workplace and try the new work. 1 or 2 days would be short, and anything more than 3 days is not feasible from the job-seekers side.

4 & 5) Trial would be provided or requested using your social/public profile i.e twitter and a personal link (could be linkedin or resume or website). So asking for twitter and personal link. Email would be needed in the case of a match between potential employer and employee, I'm sending an introduction on email to both.

6) Yeah I'll need to work on that and clarify stuff.

Edit:

1) Trial could be decided between you and the employer over email, could be remote, or physically move to the office.

2) Once any job-seeker says start trial to a posting, it will be shown to the employer. Using the public profile and the personal link provided employers shortlist candidates. When they too show an interest, email introduction is done.

3) This could as well be discussed over the email after the introduction is made. But I might have to clarify this.

</comment></comment><comment><AUTHOR> Hi HN,

I design digital products, and I've always believed Designers should know code. I've never written code before. Today I'm excited to have built this all by my own. Over the last 20 days I've learnt several new concepts and pushed several lines of code.

I did not want to spend much time on the design so chose a very minimal design after getting inspired by seeing Text-only sites.

I'm interested in knowing your thoughts about the product and of course, any bugs you come across.

</comment><comment><USER3> Although there's no serious enforcement, having those three days be uncompensated has certain legal requirements under labor laws in the US and some other jurisdictions. In particular, it may be necessary to define the terminology during that trial period in a very specific way (e.g. a "trainee"... IANAL).

<comment><AUTHOR> That's quite interest to know. However I was going to limit myself till the introductions are made when there's a match. And leave them to discuss the terms. Like travel/stay/pay etc. Now that you've mentioned this I'll need to do some reading up. Thanks :)

<comment><USER3> For the US, you probably want to look into the US Supreme Court case Walling v. Portland Terminal. Generally speaking (again, IANAL), it sounds like the exemptions have to do with ensuring it's an educational experience that benefits the trainee more than the employer.

</comment></comment></comment><comment><USER4> It's unclear what the profiles are all about. Is it for me as an individual or my company? Posting something cannot be deleted without sending an email. It's not ready for use imo....

</comment><comment><USER5> My only concern before using this as a job seeker would be getting used for free work and then not hired. Maybe oder the potion to get paid over those 3 days?

</comment><comment><USER6> is it a developer posting that I am available for a trial or company posting a job that they have a job offer?

If it's both ways, as a job seeker I would have to go through each item and understand if it's a job offer I could try.

The idea is good. But why twitter? why not a simple email? or probably linkedin is understandable.

<comment><AUTHOR> Hi,

Its 'Companies list positions and people apply to work with them for 3 days.'

My thought process was that companies will shortlist applicants based on social/public profile and a personal link (could be linkedin or website).

</comment></comment><comment><USER7> Very cool idea. I think this could become a great way for companies/startups to find really great talent.

</comment><comment><USER8> Are the salary ranges for those 3 days? Or for a year? Either way they seem too much or too little.

<comment><AUTHOR> :).. They are Salaries per annum. Seems so little because of the dollar conversion.

<comment><USER9> I was curious. According to Quora these are the class ranges in India:

Affluent/Rich - Rs. 500,000 p.m and above. Usually businessmen & celebrities.

Upper class - Rs. 200,000 per month to Rs. 500,000 p.m.

Upper middle class- Rs. 50,000 p.m. to Rs. 200,000 p.m.

Middle-Middle class - Rs. 20,000 p.m to Rs. 50,000 p.m.

Lower-middle class - Rs. 10,000 p.m to Rs. 20,000 p.m.

Lower class - Rs. 6,000 per month to Rs. 10,000 per month

Poor - Less than Rs. 6,000 p.m.

By glance $10,000 per year seems like a good average. Which is 661,500 INR per year or about 55,000 per month.

<comment><AUTHOR> E-commerce giants in India pay Rs. 1,500,000 - 2,500,000 for a good UX designer. And developers salaries fall in this range too for node/angular/scala.

<comment><USER10> Is that per year or month?

<comment><USER11> The range of Rs. 1,500,000 - 2,500,000 per 'month' is limited to CXOs of Indian companies. It's way too high for designers or developers, primarily due to the cost of living.</comment></comment></comment></comment></comment></comment>


Death by Database - <AUTHOR> https://ovid.github.io/articles/death-by-database.html <comment><USER2> I am surprised that their suggested solution was for a many-to-many relationship. Seems like you would want to stay one-to-many but remove the unique validations. If you're sharing address records then it seems there could be many possible frustrating cases. For example:

What if someone goes to create an address, typos it, matches another customer's address, and then fixes it updating the other customer's address in the process? The other customer might accidentally send their luxury item to a stranger if they aren't paying attention during checkout.

The use case with married couples is compelling, but similar to the previous scenario, what if they got divorced? The one that moves updates their address, which updates their ex's address as well. Same as the other scenario, you might end up with a customer sending their item the wrong place.

These might be edge cases but in general I think it's dangerous to change things like an address without an explicit action from the user.

<comment><USER3> I am not surprised because the problem wasn't correctly defined:

> At the database level, they had a "one-to-many" relationship between > customers and addresses.

Which the author goes on to say causes:

> That was their first problem. A customer's partner might come into Bob's and > order something and if the address was entered correctly it would be flagged > as "in use" and we had to use a different address or deliberately enter a > typo.

But that's not true. The problem being described is not caused or implied by a one-to-many relationship between customers and addresses. The actual problem is that the address table has unique constraints defined in such a way that duplicate addresses are not allowed.

So given that the problem was incorrectly defined as one-to-many being the root cause, it makes sense that the proposed solution is many-to-many.

Just to be clear, many-to-many in this use case makes a lot of sense and depending on what the schema looks like it may be the best solution. I am just saying that the problem described was not because of "one-to-many".

For example I work on a multi-tenant web app and we store emails (which have a similar problem with mailing/billing addresses) with a one-to-many relationship to accounts. We don't have a problem with an e-mail being used in several accounts... _because our constraints allow it_.

<comment><USER4> > But that's not true. The problem being described is not caused or implied by > a one-to-many relationship between customers and addresses. The actual > problem is that the address table has unique constraints defined in such a > way that duplicate addresses are not allowed.

Furthermore the unique constraint most likely didn't even serve its purpose: How can you really make sure that an address is unique? There are countless ways to write one and the same address - in its simplest form it might be variations of Street / Str. or Avenue / Ave. Any information combining multiple lengthy strings will be prone to resulting in several slightly different variations.

</comment></comment></comment><comment><USER5> Addresses is one of those categories for which people should regularly read the "falsehoods programmers believe about X" list. Here's one: [https://www.mjt.me.uk/posts/falsehoods-programmers- believe-a...](https://www.mjt.me.uk/posts/falsehoods-programmers-believe- about-addresses/)

<comment><USER6> Hmm, we have name (enter as many as you like, Li Pong Tai if you wish), address, country (select, excludes Kosovo and Western Sahara and other territories pretending to be countries), phone and email fields. Email is verified with a code. Forcing a certain format very rigidly is bad practice. Like first name, last name or state, city. What if the customer is Korean or lives on a ranch in the countryside or is a ranger and uses their work address? Or worse, lives in the Medina in Morocco.

<comment><USER7> In the US there is also a trend for certain companies to use an address "fixer" or "reformater" API to automatically wither check and or fix an entered address. So bad. When I moved into a newly built apartment building a few years ago there were more than a few sites that just would not accept that the actual address was real and valid. ick.

</comment></comment></comment><comment><USER8> This isn't about database design, per se, it's about data model design in general.

Starting a software project by thinking hard about the data model is always good advice, but even knowing this it is almost always impossible to design things perfectly up front.

You need to hit problems square on in practice, and reshape your model to deal with them. If you think otherwise, if you really think you can think through in advance all the possible unexpected permutations of how your model might not work in practice, like with this address thing, you are just kidding yourself. It never happens that way.

So, maybe the best advice is not only to start by thinking about the data model but to have a mindset of continually thinking about and changing your data model, and to build your software using languages, tools and technologies that better accomodate this.

<comment><USER4> I agree and I'm surprised potential data models aren't as often discussed and debated as the choice of technology and stacks.

At least to me considering and planning a lasting data model, despite knowing that it'll change, is a far more significant focus than choosing a framework - a choice which is often dictated by your experience and familiarity with those options anyway. And yet we rarely see discussions about best practices when it comes to data models. Maybe the requirements and solutions are often too specific.

<comment><USER9> > I agree and I'm surprised potential data models aren't as often discussed > and debated as the choice of technology and stacks.

This. People can discuss stacks and tools for hours, whereas the optimal data model seems to be a boring topic, even though very often it turns out far more important in the long run.

</comment></comment></comment><comment><USER10> What they're really asking for is multi-user accounts, which is a whole can of worms... also the address uniqueness requirement seems like it'll leak your customers' information.

Also don't understand why the system for spamming marketing emails needs to share the same address table (and associated headaches) as actual customers. Presumably you will want to spam people who aren't in the system yet...

<comment><USER11> Exactly. These should simply be different databases. You could then enrich the spamming one using the client one, but no need to do the reverse...

</comment></comment><comment><USER12> That Linus Torvald quote comes to mind: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

<comment><USER13> This is why I believe the future of source code management will be via relational databases instead of in hierarchical file systems. Large projects are too involved for trees. The same with GUI specifications: They are too complex to manage with OOP/OOM. Plus, a GUI spec in a database is (mostly) language-neutral so that you are not tied to a GUI library written in a specific programming language. You learn one engine, and then use it for PHP, C#, Java, Python, etc.

<comment><USER14> Data structures have nothing to do with SQL though. That quote is pretty much anti-relational databases.

<comment><USER13> Please elaborate. Non-trivial data structured will either need a database, or end up resembling one anyhow when you add features they'll eventually need as they mature (concurrency, data integrity, querying, adding indexes without changing functionality/design, backups, etc.)

Note that didn't imply that Linux should designed around a DB. However, with virtualization, the idea of an "OS" may change or vanish. The view is toward "applications", with the associations between applications, users, file systems, and machinery more flexible. In that approach, a DB-centric view may make more sense. A (traditional) "OS" is a machine-centric view.

<comment><USER14> Data-structures are machine-centric, not abstract relational algebra. You can understand why it's important to think about data structures for the machine. Which is a completely opposite view from relational databases, where you are supposed to not think of how data relates to the machine at all.

<comment><USER13> In practice the boundary between both is fuzzy. Processing DB data can and is often done in a row-by-row or cell-by-cell basis. Not all computations are convenient to reduce to relational algebra, at least for most practitioners. We can't all be Sheldons.

</comment></comment></comment></comment></comment></comment><comment><USER15> The author advocates starting with database design before software. Some other people advocate the opposite: the database is just a detail.

I think the point is to spend time in designing a good domain model regardless of how it's stored (database).

<comment><USER16> I also always start with the "database" design or the storage model or whatever you want to call it. If you do database design with proper foreign key relationships, etc, the entire rest of the design including the UI and most of the business rules can all flow directly from that.

You can also do that with a good domain model but the rigors of actually having to physically construct it in a database ensures less mistakes.

Now, if you're using a loosy-goosy JSON blog storage solution than there is no advantage to starting at that level.

<comment><USER17> "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious."

<comment><USER18> [https://en.wikiquote.org/wiki/Fred_Brooks](https://en.wikiquote.org/wiki/Fred_Brooks) in case anyone wanted the source.

</comment></comment></comment></comment><comment><USER13> I've often found the "proper" database design is too confusing to users and/or managers. Users will have to understand the complex relationships to enter, inspect, and trouble-shoot data properly. Often they don't. Simplicity often trumps logic and the D.R.Y. Principle even if the limits (simplicity) create extra work in some situations.

Further, you don't know what marketers will dream up in the future and cannot realistically anticipate enough of their harebrained ideas. Try to keep marketing separate from production when possible, but sometimes marketers and/or the bosses want something technically goofy and you have to fudge stuff to get it.

Warn them about possible long-term consequences, but if they _insist_ on Frankenstein, you just have to do it. Get your warnings in writing so that you have a record about their decision when bleep hits the fan later. Further if you avoid complaining a lot in general, then important complaints carry more weight. Otherwise, they'll mistake your important warnings for mundane ones.

<comment><USER19> The db is not only about tables, there's a reason why views exist, the users/managers should only query views, these are easy to change whenever the underlying private schema changes.

<comment><USER13> Views are an imperfect abstraction (as usually implemented). Plus, pre-many- to-many-ing all relationships will make for a notably slower system even if views hide many-to-many-ness. (As I mentioned elsewhere, one often can't know which relationships will grow to many-to-many over time.)

</comment></comment></comment><comment><USER20> Projects and even companies I have witnessed dying are more often than not done in by underinvesting in databases.

When you start a project with a React UI and just throw whatever you need into the schema in order to make things come up on the page...you're headed for disaster.

Or on the flip side...you know how databases work but you don't know how to say NO to features that are expensive.

This seems to be getting worse over time. Databases are becoming a lost art.

<comment><USER21> There is a lot of hard-won knowledge that is aging out of the profession increasingly lately, I have been observing. It's tempting to blame web development, and its proverbial low bar to entry, but I think the real problem is computer UX getting too good, such that you can accomplish almost anything one would desire with a computer, without having to delve into the nasty implementation details.

I am just barely starting to get grey in my beard (largely from dealing with frighteningly incompetent consulting firms, rather than age...) but I can remember the eldritch incantations dealing with autoexec.bat and DOS memory modes, or the clusterfuck of trying to get printers or new bits of hardware to work, or the panic of trying to fix BSODs when I'd trashed the system installing something dodgy from LimeWire or the shovelware bin at WalMart. The next generation coming through has been shielded from these horrors, and mostly matured in an environment where computers work reliably; and when they do fail, it is usually opaque, inscrutable, and largely hidden from their eyes. Aside from a crash-course in the scientific method for diagnosing and debugging issues, the old dodgy software world exposed one rather harshly to many of the underlying realities of the system, and our current software environments are still mostly built on those foundations, with a few dozen layers of lipstick applied to the pig.

It certainly doesn't help that most instruction in software engineering either hews to the abstract and theoretical or the novel, with passing consideration of the practical realities and the history of the art. Ultimately, we write code that runs on silicon transistors, not ideal Turing machines, and in a great many fields we are retreading extensively explored ground, a hamster wheel of innovation. Every generation seems to have to need to have a go at yet another build system or object database, or rediscover the model-view- controller pattern. We delight in making endless new and exciting and broken wheels, in shameful ignorance of the hard-won lessons of the past.

</comment></comment><comment><USER22> This is why I don't think of database as an interface. Instead, create functional interface with some business meaning (REST API, GraphQL, a Java interface - whatever suits a particular use case), which will be __versioned __and properly maintained with __backward compatibility __where possible (which is, I think, almost always possible). It doesn 't cancel a proper DB design though, but helps a lot when you need to change it. Or move to another DB engine altogether.

You know, every problem can be solved with another level of abstraction. No sarcasm, I think it actually holds here.

<comment><USER13> While a many-to-many DB relationship can in theory model a 1-to-many relationship via constraints and/or domain logic coding, it seems kind of anti-YAGNI to me. Being that ANY 1-to-many relationship can potentially change into being many-to-many, which ones do you "pre many" and which ones are left 1-to-many? My crystal ball is not that powerful. If it were, I'd be competing with Warren Buffett instead of puzzling over database design.

</comment></comment><comment><USER23> Same. I spend about 30% of my time writing out the migration and making sure I haven't missed anything. It saves so many headaches later. It's also one of the reasons I stubbornly re-implemented Rail's whitespace formatting of schema.rb into a rake task. I look at that thing 50 times a day. It needs to be readable, I don't care if it clutters up a pull request review or git diff.

<comment><USER4> I'm sure you already know about this gem, but just in case: [https://github.com/voormedia/rails-erd](https://github.com/voormedia/rails- erd)

</comment></comment><comment><USER24> I worked on a codebase with a similar address problem. Oh, and there were no primary keys. Instead, each row referred back to a separate table with four keyed initials.

Good database design upfront, and vigilant upkeep will keep the application layer tidier.

</comment><comment><USER25> The real problem here seems to be that changing the schema seems prohibitive expensive.

<comment><USER26> That's a huge problem with SQL in general. It _ought_ to be trivial to maintain multiple views of the data to allow you to migrate old clients bit by bit, but in practice it's rarely done.

Also, it's a business problem. They can always ask for more cruft and IT has a huge incentive to take the short-sighted route, get promoted and move on.

<comment><USER13> Re: "[flexible schema change is a] huge problem with SQL in general." \-- I've been a proponent of the idea of "dynamic relational". You can add any column on whim to a row just by including it in an INSERT or UPDATE command, unless an explicit constraint/rule forbid it for a given table or database. You could even make tables similarly create-on-write. No DBA's needed! (within reason) Comparisons have to be done with care, though, as with any dynamic/implied typed system.

But create-on-write doesn't solve cross-table relationship flexibility problems: such as changes between 1-to-1 to 1-to-many and/or to many-to-many. If you already have data, that's usually a tricky domain problem regardless of what kind of database technology you use. It's about the semantics of your data, not machines.

<comment><USER27> _Re: "[flexible schema change is a] huge problem with SQL in general." _

Graph databases mostly solve these problem but they have not seen much uptake, don't know why.

<comment><USER13> Using "Dynamic Relational" (DR) is much more similar to existing RDBMS. You don't have to relearn much. I'm not necessarily saying DR is objectively better or worse than graph DB's, only that DR is a smaller learning curve to those using the most common RDBMS out there.

</comment></comment></comment></comment></comment><comment><USER28> Wrong solution and nothing to do with database design.

Why do the addresses even need to be in the ecommerce system to do the mailing? Couldn't they be in another table? Or a simple CSV? No reason to create fake customer records to send some spam. Something's missing in this story.

But if for some reason they are forced to use the same db, multiple customers sharing the same address doesn't mean they need to share the same row in the table. Keep the 1:many relation _without the unique constraint_. Customers can then have multiple addresses, even if they're shared with others.

Addresses are complicated too, so you might as well just have a country field + the rest and then use an API to standardize, catching errors and making queries easy.

<comment><USER29> Most US sellers use some sort of USPS certified address validation and cleanup software to catch data entry errors and prevent delivery problems. So dumping everything but the country into a single big field isn't necessarily a viable design.

[https://www.usps.com/nationalpremieraccounts/manageprocessan...](https://www.usps.com/nationalpremieraccounts/manageprocessandaddress.htm)

<comment><USER7> DO NOT DO THIS.

Have you ever moved into a new house or apartment on a new street or address? Effectively blocking users because you assume their address is corrupt because your system is out of date. At some point you have to choose what is better, trusting that your users are able to enter their address or that an API (from USPS or one of the dozen or so others out there) is able to understand what is and is not a valid address.

<comment><USER29> Don't trust your users. Use the address validation software, but if the address doesn't work allow the user to specifically choose to use their original entry. That's how most large ecommerce vendors operate now and it allows a manual override for new addresses.

And the address lists are updated very quickly now for any decent software. So it's only a problem for a very limited time.

</comment></comment></comment></comment><comment><USER30> Very shallow post.

Come on, this is not about database design. This is about making the wrong technical choice, the definition of "I have a hammer, so everything looks like a nail".

What about export of the addresses, and using a second service on the export?</comment>