Lockstep Salaries Are Making a Comeback - <AUTHOR> http://techcrunch.com/2015/05/24/lockstep-salaries/ <comment><USER2> So instead of negotiating pay, candidates will negotiate titles (except for women, presumably, who will continue putting themselves at a disadvantage in a new way). And instead of salary envy you get title envy. And instead of uncertainty and negotiation over raises, you get uncertainty and negotiation over promotions. And by the way, if you have ever worked for a large corporation with salary bands, you know that this is _exactly_ what happens there.

I fail to see any material difference.

<comment><USER3> I think that is a good point, and I'm sure approaches like this don't solve the issue, but there is a difference in transparency.

Pay isn't public, but titles are. So if you are in the company you can see the landscape and know if you should be in the group of people with the better title. This would mean that although women might not be as inclined to negotiate, it would become clearer to people where themselves and others should be with their titles, so discrepancies between performance and title and pay would be more obvious.

</comment></comment><comment><USER4> Seems like a great way to ensure you have mediocre talent.

Maybe I've just been on my own too long, but I at least want the allusion that I'm being paid a fair market rate, instead of that which is 'fair' to my co- workers or company.

Those of us who are passionate about what we do, and work very hard, should run from something like this. I'm very open to conversation as to why that's not a good idea.

Buffer is an example of what seems like a cool product and company...but their salary system, IMO, favors Buffer. Not the people building the product. I'd never work for them.

<comment><USER5> As a counter example, most of the most profitable and selective law firms are lock-step top to bottom.

<comment><USER6> The causality may run the other way. Lock-step salaries work best when the key driver of the firm's success is not the knowledge and skills that individual employees bring to the firm, but rather pre-existing market advantages that the firm itself has that let its employees be more productive and make more money. Otherwise, the firm has a strong incentive to acquire those individual knowledge and skills to make itself more profitable.

The most profitable and selective law firms are such because they've built up very strong brand names and client relationships over time. They make an employee's career; an employee doesn't make the firm's success. As a result, the employee doesn't have the negotiating leverage to demand a higher salary, and the firm has a strong incentive to ensure harmony and control costs among its workers.

</comment></comment></comment><comment><USER7> Sounds like a great way to collect a company of low performers. Since all the people who can do great things will go elsewhere, where they will actually be paid for being above average in their skill & efficiency.

</comment><comment><USER8> How about software developers form a programmers association and learn to negotiate and hire agents and lawyers and all that to make sure they're fairly compensated?

If you're going to have lockstep salaries then you also better have solid onboarding and training programs and an actual promotion process other than "if you aren't bored and stay a while you'll get promoted".

<comment><USER9> Oh, you mean like a union? No couldn't do that, we're not communists.

<comment><USER10> No, like a professional association.

<comment><USER11> What's the difference?

<comment><USER8> one doesn't get tarred and feathered and lose their jobs when they call it an association.

for example:

* screen actors guild * nhlpa - national hockey league players association

</comment></comment></comment></comment></comment><comment><USER12> I've been appalled to find out how much more I make than some of my colleagues, even though we have the same job title. Now, I feel like I produce more than they do (and higher quality, to boot), so maybe my higher pay is justified, but really, I don't think it's _that_ justified.

I would much rather have levels with merit bonuses than have to rely on being a good negotiator. I could be the best programmer in the world sitting next to the worst programmer in the world, but if she negotiates better than I do, she makes more. Or vice versa. And I don't think that's particularly fair.

<comment><USER13> > I've been appalled to find out how much more I make than some of my > colleagues...

Have you done anything about this?

<comment><USER12> I did complain to my immediate boss, and then when I became a manager, I went to HR fought to make the pay more equitable. Not a whole lot happened, as far as I can tell.

To be fair to them, it's not quite so easy though. You can bring underpaid people up to "fair", but you can't really bring overpaid people down, so you still wind up with some unfair (imo) compensation going around.

Incidentally, the last time I got a raise was when I became a manager and became more aware of the exact compensation numbers for the rest of my team. My plan for the next time I get a raise was to ask them to give it to some of my underpaid team members instead, but I'm leaving this company soon, so I won't be able to see if that strategy would work or not.

</comment></comment></comment><comment><USER14> Should basketball teams pay the same salary to their players, based on their 'experience'?

<comment><USER15> Well, for the NBA at least, the minimum salary you can be paid does scale with your years in the league. There is also a a salary cap (per-team) and a maximum salary for any one player based on your previous salary and years of experience. One of the interesting things to happen because of this is that the top-tier players are underpaid by their teams (relative to their competition), and end up making more money from their shoe and advertising deals than their team salary. It also means that veterans who are willing to take minimum salary may find themselves priced out of the league since their minimum is higher than less experienced players.

<comment><USER16> >It also means that veterans who are willing to take minimum salary may find themselves priced out of the league since their minimum is higher than less experienced players.

Actually, the NBA CBA has that loophole covered. If a veteran player accepts a minimum salary contract, the team only has to pay the minimum salary for a player with 3 years of experience. The league pays the difference, and the difference does not count against the salary cap.

So, the minimum salary scale for veterans is not a disincentive against hiring a veteran who is willing to play for the minimum.

</comment></comment></comment><comment><USER17> Up or out is a supremely effective way to drive people to meet organizational goals. On the down side, you have to be super careful about what you measure. Enron made extensive use of up or out. It worked really really well, right up until it didn't.

If that's really going to happen, executives are going to need to be at least as precise than an assembly programer when setting metrics.

<comment><USER18> Bad things happen when the "competition knob" is turned to 0 (everyone free- rides) and 11 (everyone cheats).

> you have to be super careful about what you measure.

Do you really think you can design metrics so perfect that they won't be gamed? Even if it were possible (I'm pretty sure it isn't), could you do it without undermining cooperative team dynamics that create organizational value? I'm not saying all metrics are bad, but I _am_ saying that turning up the heat with up-or-out is the equivalent of turning the "competition knob" to 11 and that it has a large number of obvious failure modes which make me puzzle over your declaration of its efficacy (unless you meant it in the tautological sense, but that would be silly?).

I'm further puzzled that you brought Enron up as an example of incentives done correctly. Most people think of them as a case-study in runaway incentives and how turning the competition knob to 11 inevitably causes, well, exactly what happened to Enron. When the choices are "cheat or get fired," your company will inevitably fill itself with cheaters. Unless your metrics are perfect, of course, but are you willing to bet your company on it?

<comment><USER17> > Do you really think you can design metrics so perfect that they won't be > gamed?

Nope. I think it's super super hard. I think a lot of executives will say, oh we'll just add "Up or out" to dial up the competition knob, and then they'll self destruct.

Executives make great decisions all the time. Unfortunately most of those decisions involve "close enough" thinking. Up or out introduces razor sharp edges. Everything appears better than fine, hell it appears fantastic. Until it isn't. and when it isn't it's terminal.

I used assembly specifically to highlight the care that must be taken. I wanted to evoke images of bricking devices. Very few executives have the mindset that if i'm not certain i'm right, then i'm wrong. Often their thinking is squishy at the edges, and that's just the cost of doing business.

I do think if it's possible to do "Up or out" effectively, that corporation would be formidable. If gaming the metric advanced the corporation's goals, that would be amazing. But, super hard. Folks selected for being the smartest guy in the room are most likely to fool themselves into thinking they can handle it.

<comment><USER18> I think where we fundamentally disagree is that you believe it's generally possible to design an incentive system which is well-behaved in the asymptote of extreme competition whereas I do not, except under select conditions where the sum total of value provided by an individual is trivially quantifiable and separable from the contribution of his peers (e.g. assembly line work).

"Care must be taken" simply doesn't cut it; the comparison to assembly programming is ridiculous. For most devices it's hard to screw up badly enough to brick them and even if you do you are out, what, a few hundred dollars? Also, the feedback is unambiguous and instantaneous. Screw up a big organization and you are out millions or billions with only vague, ambiguous feeback that arrives years after you institute the policy. Even a comparison to rocket science doesn't come close to capturing the difficulty involved because rockets are designed to be separable into subsystems which obey well- characterized physical laws whereas most creative processes can't be broken down so rigorously.

The hypothetical perfect incentive system is like the hypothetical analog computer which gives you infinite accuracy and precision for free: it only appears to be an exciting possibility if you neglect all of the factors that limit its efficacy in practice.

<comment><USER17> I think it works really well in adversarial contexts. I'd guess the best is probably law. Win cases, bill hours. Lack of ethics are exploited ruthlessly by the opposition - that's grounds for appeal.

Somewhat less effectively, sales. Car salesmen have horrible reputations, but lots of technical sales are smart, knowledgeable and helpful. I think the long term relationship aspect helps.

Even less effective, but still clearly in use is finance. Insider trading and collusion are tough to prove, and there's not much incentive to keep the system in check. But finance clearly takes advantage of up or out.

Bricking a device is a fine analogy. Sometimes the slippery slope argument is not a fallacy. I think this is one of those times. You seem to agree, we're just not clear on stakes. I think the slippery slope exists in a 2 person startup all the way up to microsoft or google.

Perfect anything is a pipe dream. "It has been said that democracy is the worst form of government, except all those others that have been tried". If somebody wants to try a social experiment with their investors money, best of luck to them. It's unlikely i'd invest or be interested in working there though.

</comment></comment></comment></comment></comment><comment><USER19> Whatever. People will figure out ways to game this system too.

</comment><comment><USER20> Whereas Stack Ranking uses greed to estimulate achievement on projects, Lockstep uses greed to solely achieve a job title.

Therefore, Lockstep salaries are more vulnerable to office politics and employees pretending to achieve, in order to 'look good' and get a better salary.

</comment><comment><USER21> This reminded me of the transparency thing they had going at Buffer ([https://open.bufferapp.com/introducing-open-salaries-at- buff...](https://open.bufferapp.com/introducing-open-salaries-at-buffer- including-our-transparent-formula-and-all-individual-salaries/)), but it looks like they're moving away from it now (to "self-managed salaries" [https://open.bufferapp.com/buffer-in-march-5-9m-annual- reven...](https://open.bufferapp.com/buffer-in-march-5-9m-annual-revenue-self- managed-salaries-more/))

</comment><comment><USER22> It's a really good idea to pay average talent an average wage.

Instead of negotiating for salary, just negotiate for title, if you have a title that no one else has all the better.

</comment><comment><USER23> They say they are making a comeback and then list one place that is using lockstep salaries.

</comment><comment><USER10> Awesome, then we can make promotions tenure based and make it virtually impossible to fire someone for incompetence.

</comment><comment><USER24> "Outside of reduced competition, two other advantages to lockstep are eliminating salary negotiations and increasing transparency"

I never knew that this was called "lockstep salary", but it's essentially how all of the unions work.

It hurts many employees because it takes away all your negotiating power.

</comment><comment><USER25> > On the first, few people effectively negotiate with their employers for > salary increases, and a lot of people fail to negotiate at all.

Boo-fucking-hoo.

Grow the fuck up. If one cannot learn how to effectively communicate, then one will face the consequences.

</comment><comment><USER26> > the ecommerce startup launched by Marc Lore, which uses a form of the > lockstep model. Lore described his company's system in an interview. > "Everyone at the same level makes the same comp. Everyone knows that no one > is getting paid more at a similar level,"

revealing this could easily lead to having staff hired away once the levels are figured out.</comment>


I Hate Myself Because I Don't Work for BuzzFeed - <AUTHOR> http://www.theawl.com/2015/03/i-hate-myself-because-i-dont-work-for-buzzfeed

<comment><USER2> I agree with the reply, It's very much an overreaction. Everyone gets jealous about other people's jobs, but not to that extent. Sounds like a personal problem to do with the regret of not getting the buzzfeed job.</comment>


Ask HN: Why are airlines overselling tickets? - <AUTHOR> In the wake of the United debacle, I wonder why overselling tickets for flights is seemingly common practice for airlines... Is this just bad software or is this an intentional practice? <comment><USER2> It's common practice for airlines overbook flights. It's low margin business. Statistically speaking few passengers will always cancel at the last minute. I don't see nothing wrong with this. It's just that United handled it wrong.

There are two economic solutions:

* They should have been raising the offered compensation until they get somebody to volunteer. Auctioning who leaves makes everybody happy.

* Another solution is reverse auction during ticket sale. Customers gives the sum for witch he or shie is willing to take later flight when they buy a ticket.

</comment><comment><USER3> Because people don't show up for the flight.

Arlines know a certain percentage of people will miss their connection, fly standby on an earlier flight, or reschedule. Margins are so unbelievable thin (airlines make more money selling food than seats) that they want every flight to go off full. There's nothing wrong with this practice. It's efficient. The problem was how United handled it.

That said, the United flight wasn't oversold. They needed seats to transport the crew for a different flight.

</comment><comment><USER4> No, that's intentional.

A certain percentage of every flight is no-show - they bought a ticket, but never showed up for the flight. So by overselling, you actually get a fuller plane and more tickets sold.

This starts to break down when the no-show ratio drops for single flights, though.</comment>


Google is testing internet speeds straight from search - <AUTHOR> https://www.engadget.com/2016/06/29/google-is-testing-internet-speeds-straight-from-search/?sr_source=chetangole.com <comment><USER2> >Google is actually lagging in consumer speed testing, because in addition to Ookla and Netflix, rival Bing already shows speed test results straight from search.

Bing doesn't seem to show anything either, at least from Poland.</comment>


A New Asteroid Mining Operation supported by Google Execs and James Cameron - <AUTHOR> http://www.technologyreview.com/blog/mimssbits/27776/?ref=rss <comment><USER2> The economics of this could be better than you think.

A fair-sized chunk of an asteroid could contain a few trillion dollars worth of platinum group metals. If money can be found for it, a sample return mission to a near earth asteroid could probably be accomplished SpaceX-style.

A key step in all of this could be the mining of water from the asteroid Ceres, which is a much more practical destination than mars. At that point you could set up a solar or nuclear powered water cracking factory that would make large amounts of fuel available. Any needs for water in space could be so satisfied.

<comment><USER3> It's only worth a few trillion dollars if you don't actually sell it to anybody. Every kilogram they actually introduce into the market reduces the total scarcity of the resource, which means every kilogram they introduce has a lower marginal value.

<comment><USER4> It is true that increased supply -- all else equal -- decreases price, but, 1) we will find uses for the element that we don't currently use/know about and 2) we will never find infinite amounts of any resource so this means that. Prices will decrease marginally, but theres no way to know to what extent prices would fall.

Thought experiment: SpaceX is able to lasso up a 100% diamond asteroid and bring it to earth. Suddenly supply of diamonds is 1000x what it was expected to be that year. Diamonds will be worth marginally less as a result, however, it does not mean all that diamond asteroid is worthless. I am sure diamond mines would close for a bit as that asteroid is likely cheaper per unit than some other methods. Suddenly because diamonds because relatively cheaper they can begin to be used for all kinds of currently uneconomical uses. Maybe diamond fiber becomes the next typed of networking cable, or diamond asphalt makes our roads last forever, or diamond knives become all the rage for top chefs -- I don't know, but we'll find a way to use cheaper diamonds, and that asteroid is going to be worth a boatload no matter what.

Wish I had more time to think about this, but work calls.

<comment><USER5> As far as diamonds go, we already have more than enough here on Earth, and the price is being kept artificially high by a cartel. Industrial diamonds are only worth 1/1000th of what you pay for jewelry diamonds, so there's not much incentive for that.

But I see your argument.

Personally though I would want to keep the minerals up in space, figure out how to refine them there, and then use them up there. Since the cost of getting large quantities of materials up there is still rather expensive.

</comment></comment></comment></comment><comment><USER6> Coming soon: a James Cameron movie featuring _real_ footage from a space mining operation interlaced with a rather stereotypical love story. Title: _Avatanic_.

<comment><USER7> I'd watch it.

</comment></comment><comment><USER8> Seems like the most valuable and obtainable natural resource in space is energy (solar or He3). Raw materials are a distant second, especially since almost all new technologies do more with less (how many physical gadgets does one smart phone replace?)

<comment><USER9> Space may not be the best place to get raw materials (being, after all, mostly empty space) but you are mistaken about falling demand for materials. Commodity prices alone should tell you that demand is hitting the limits of current production. One smart phone may replace N others gadgets, but only 500 million people had the other gadgets, and _everyone_ wants a smartphone.

<comment><USER8> I didn't say overall demand is falling. But per capita demand is, if not falling, decelerating -- your car is made of less metal, one gadget does what ten heavier gadgets used to, etc. otoh almost all of us are using more power.

</comment></comment></comment><comment><USER10> Armageddon?

Is there anywhere James Cameron doesn't want to go? He was just at the bottom of the ocean last month. He and Richard Branson should have a race into space!

</comment><comment><USER11> You are too much empiric, there is no need to build something right now: writing some generic patents will to the job.

</comment><comment><USER12> Prob. want to use a Hulk fitted with some T2 lasers. Scordite's trading pretty high right now in Jita.

</comment><comment><USER13> <http://spacewealth.org/>

</comment><comment><USER14> No web site, nothing on google, I'd start by creating a marketing department

Seriously, I'd buy some shares even if its a very high risk venture, if I knew how too.

</comment><comment><USER15> Concept video is a bit rough though <http://bit.ly/J3YOnt>

</comment><comment><USER16> Oh come on! No-one stands the remotest chance of getting viable amounts of rock down from space for another two generations. We don't have any mechanism to get the rocks down (a space anchor - not even remotely close to necessary material strength / weight ratio), let alone the ability to survive journeys to closest rocks.

Give it 20 years of people living on the moon or Mars and solving the supply, radiation and working problems, then I will believe we might risk throwing a megatonne of iridium at Earth orbit.

But great way for rich dreamers to hob nob with other rich dreamers. Enjoy it folks. Just don't invest.

<comment><AUTHOR> I can see a way to get the rocks down. Cut off chunks of particular size, cover them in nets and tie the nets to a little robotic space tugboat, that uses rocket power to pull the rocks into earth orbit and then lands with the rocks in a parachute. The space tug boat will be reusable of course.

Radiation is also a tough problem. Most space metals should be radioactive. They have been swimming in space radiation for millions of years, so even metals that are usually non-radioactive, like iron should get plenty of opportunity to get activated. And once a metal is radioactive we have no way to fix that. The only fix is to wait for it to deplete itself. And that is usually a very long wait.

But now that I think of it, perhaps in an asteroid only the outside metals are radioactive. Perhaps the inside of the asteroid gets shielded by the metals on the outside that absorb all incoming particles. If that's the way things work, one should be able to mine non radio-active metals on the inside.

So I see nothing impossible, but it will be difficult.

<comment><USER17> <http://www.webelements.com/iron/isotopes.html>

Radio isotopes of iron. Unlikely that you'd have to worry too much about it. Did you have a particular nucleotide you were concerned about?

<comment><AUTHOR> Why is that something that we should not worry about? (I am not being sarcastic, honestly asking, nuclear physics is not my primary expertise.) Yes many of them seem to have short half-lives but one of them has a half life of 1.5 million years.

Also I am not sure these are the only iron isotopes. This seems to be a list of "naturally occurring" iron isotopes which usually means "naturally occurring on Earth".

Also another thing to worry about is the isotopes of platinum and platinum group metals that seem to be the main and most lucrative target of space mining.

<comment><USER3> > Yes many of them seem to have short half-lives but one of them has a half > life of 1.5 million years.

Which means it's completely safe. If it has a half-life that long, it won't be releasing radiation at a very high rate. Hardly enough to register above background. The isotopes you have to worry about are the ones with in-the- middle half lives- long enough that they don't deplete themselves in a conveniently short period, but short enough that they produce a dangerous power output.

<comment><AUTHOR> That depends on concentrations of the isotope in the metal and the amount of metal we will be using. I have no idea what the concentrations of iron isotopes in meteors are and which iron isotopes are there, but I do not think it is correct to automatically say that radioactive isotopes with long half- lives are completely safe.</comment></comment></comment></comment></comment></comment>


The Ultimate Guide to Pinball - <AUTHOR> http://www.hopesandfears.com/hopes/now/pop-stuff/213447-the-ultimate-guide-to-pinball

<comment><USER3> The article isn't really covering the modern pinball scene. While Stern is definitely the major manufacturer in play, Jersey Jack is growing and there are several more boutique manufacturers including:

Multimorphic - Offers the P3 pinball system integrating a full LCD panel with motion tracking into the playfield (as opposed to the backbox like JJ.) They also offer the P-ROC which allows replacing the CPU (a 6809/ASIC combo!) with a Spartan3 system allowing you to reprogram the rules on most 90's+ games.

Spooky Pinball - Ben Heck designed the America's Most Haunted machine, an "unlicensed" theme that is quite fun to play. I believe the first run was for 150 machines, with the next title to be announced in the near future.

Heighway Pinball - Manufacturer out of England with one title in production (Full Throttle, a motorbike theme) and are working on a licensed Alien themed pin.

There are a couple others including current and former game designers working on their own or with one of the manufacturers. This also says nothing of the pinball modding community, custom one-off games, etc.

EDIT: Completely forgot Planetary Pinball who is remaking late 90's pinball machines with modern electronics. First machine is Medieval Madness and is shipping now.

<comment><USER4> I'm curious if Planetary ever resolved their licensing issues and how they did it.

The prototypes they once showed were using MAME running on a Beaglebone Black to emulate the old Williams hardware.

<comment><USER5> Planetary's Medieval Madness remake does indeed use a BBB as a core CPU, connected to a driver board. I don't know exactly what it emulates, if it's emulating the original CPU or it's new code (I presume some emulation layer).

<comment><USER4> It's definitely an emulation layer. The original game was written in 6809 assembly language along with talking to custom hardware, some of it in an ASIC as well as an Analog Devices DSP for sound playback.

There's a branch of MAME called PinMAME that emulates this hardware, and that's what Planetary showed in their demonstrations.

</comment></comment></comment></comment><comment><USER6> Slightly offtopic since not really about the article, but if you're even a _little_ bit into pinball and you live anywhere near the Bay Area, you owe it to yourself to check out the Pacific Pinball Museum[1] in Alameda.

$15 for an all-access pass to over 100 machines, all on free play -- you can get lost in there (and I have). It's awesome.

[1] [http://pacificpinball.org/visit](http://pacificpinball.org/visit)

<comment><USER7> Also if you like Pinball and are near the bay area, come to California Extreme July 18-19th. It's fantastic, hundreds of pinball games and classic arcade games for one glorious weekend each year in Santa Clara. [http://www.caextreme.org](http://www.caextreme.org)

<comment><USER8> California Extreme is awesome; my wife and I went last year, and were heartbroken when we realized we wouldn't be able to attend this year. We're going to mark it in our calendars to make sure we don't book a trip for that weekend in the future because it's a really great experience.

</comment></comment></comment><comment><USER9> It's mentioned in the article, but if you're in NYC, take a trip down to Modern Pinball ([http://www.modernpinballnyc.com/](http://www.modernpinballnyc.com/)).

I'm no aficionado, but paying $12 for unlimited play on around 20-30 machines for an hour was a no brainer, even just to see the difference in mechanics and design between modern day and old machines.

<comment><USER10> And if you're in the San Francisco Bay Area, check out the Pacific Pinball Museum in Alameda ([http://pacificpinball.org/](http://pacificpinball.org/)). Even more machines for a couple bucks more, and as a museum it has machines that go all the way back to the beginning of the game.

<comment><USER3> If in Austin, check out Pinballz Arcade - easily more high end pinball machines than you'll find most anywhere.

</comment></comment></comment><comment><USER11> There's a great documentary by Greg Maletic called "Tilt: The Battle to Save Pinball" \- [http://www.tilt-movie.com/](http://www.tilt-movie.com/) \- highly recommended, and it blows my mind that he made the whole thing himself.

</comment><comment><USER12> If you want to see a fun game: [https://youtu.be/9GGbCLWZIfk?t=21735](https://youtu.be/9GGbCLWZIfk?t=21735)

</comment><comment><USER13> I highly recommend buying an old pinball machine and refurbishing it yourself. You'll learn a ton about how these great machines work. I got an old Creature From the Black Lagoon (1993) [1] and stripped down and rebuilt all of the playfield and the cabinet. There's lots of info on the web about how to fix them, and many companies sell spare parts.

[1][http://www.ipdb.org/machine.cgi?id=588](http://www.ipdb.org/machine.cgi?id=588)

<comment><USER14> I second this - and am happy to see an ipdb.org link - there is a ton of information there. I picked up an old Xenon - [http://www.ipdb.org/machine.cgi?gid=2821](http://www.ipdb.org/machine.cgi?gid=2821) \- worked it over with guides online and it still runs great 10 years later. If I had the room I'd have more!

<comment><USER5> Thirded. One of the most satisfying restorations we've ever done was a sand- it-down-to-the-wood repaint/restore of a Space Shuttle. There's an extra level of satisfaction to play a machine where every screw, bolt, wire, and switch is something that you personally put in place.

</comment></comment></comment><comment><USER15> Kind of surprised it didn't really talk about the modern pinball "emulation" scene.

Here's an example of a custom build [https://www.youtube.com/watch?v=H4hP9RipKg0](https://www.youtube.com/watch?v=H4hP9RipKg0)

And some software [https://en.wikipedia.org/wiki/Visual_Pinball](https://en.wikipedia.org/wiki/Visual_Pinball)

<comment><USER8> What are the physics like for that? Does it feel like the real thing? I've tried some pinball games on steam and they always feel "floaty", for lack of a better term. Building a pinball emulator sounds like a fun project, but only if the experience is pretty faithful to the original.

</comment></comment><comment><USER16> I feel fortunate, in that I traded 8 hours of software authoring for a 1971 Bally Sea Ray machine. The client was using it as a paper goods storage surface.

I brought it home, repaired the power cord, and played. It was so-so. I then started researching, found a trove of data on restoring/repairing, learned to be careful of the back panel art as well as the right kind of wax for the playing surface, and much more.

I also found companies offering replacement rubber kits, as well as spare bulbs, springs, etc. Armed with that and a repair manual, I went through the machine, taking all of the play field apart (after photos), waxed the play field surface, carefully cleaned the parts, put them all back together, replacing burnt bulbs, broken springs, and so on. There was also a lot of cleaning of copper contact points, as well as removal of oxide from the solenoid shafts and housings (some 20 or 30 of them).

New rubber _completely_ changed the dynamics - What a blast! The ball was suddenly flying around, sometimes even hitting the glass top.

It is all solenoids and relays, with one main motor that controls timing. When the ball contacts a target, it has a conducting back surface that comes into contact with another vertical contact situated right behind each target - <USER2> completed circuit energizes a specific relay, "saving" the state that the target was hit for the next subsequent rotation of the controlling motor. Without this "save" the target hitting occurs far too rapidly to be caught by the electro-mechanical machine to be scored.

The motor steps/rotates one step with each registered score (or multiple scores, again due to timing), with the appropriate "score" going to either a 10 point mechanical wheel or a 100 point wheel and each energized relay de- energized (re-armed, as it were). The motor shaft also has several (6?) discs with raised tabs at strategic places on the edge that are "read" by micro- switch followers to control various parts of the scoring electronics. The score wheel rims are labeled with the score digits, rotating like an older odometer (or gasoline pump display) with the current status (points, games remaining).

All the smaller targets hit also serve to rotate an axle that has some 20 or so copper wipers that may or may not come into contact with a random assortment of contacts laid out on a circuit board - This completes the circuit and lights up the next "randomly" lit target(s) (imagine your hand with fingers out-stretched rotating around the center of your palm with the tips of the fingers touching on a surface that may have contact points and you get the idea).

I also re-enabled the tilt-mechanism - A plumb-bob-type affair suspended within a conducting frame - Move the machine too much and another circuit is completed from the plumb-bob touching the frame, through to the tilt-circuit.

After all of that work, rather than fit an opaque back to the back box (the original was missing), I used a sheet of Plexiglas - You can see electricity arcing during operation with the room lights turned down.

Lots of fun, time to clean it again.

</comment><comment><USER17> I've been collecting pinball machines for nearly 20 years now and the recent resurgence in popularity has really breathed new life into the industry.

It was a dark time for pinball after WMS closed their pinball division in 1999, leaving second place Stern alone in the market, at a time when their quality was nowhere near what WMS was doing at the time.

Now there's a new breed of collectors who exclusively buy brand new Sterns and add all kinds of modifications to "bling" them out, and the cost of the nearly-20-year-old WMS games has skyrocketed.

Pinball has never been stronger.

<comment><USER18> The only thing is that you have to seek out good machines these days, and there are relatively few in public unless you know where to look. I got into pinball in junior high right when TAF came out. At that time I could randomly walk into any movie theater, bar, or video arcade and find new pinball machines. These days when you find a random pinball machine, it's either a new Stern (rare) or it's run down to the point that you can't even play it seriously.

I wish I had space to start a collection, but even if I did I would the casual competitiveness of the golden age. No one gives a shit about your high score on your home machine, but the time I got Lost in the Zone twice and scored 6B on the TZ in a bar in London (The Pipeline FWIW), that turned a few heads.</comment></comment>


ShowHN: Hacker-News inspired forum - <AUTHOR>

Simple.  Minimal.
The code is written in Perl, and Redis is used for storage.
Code: https://github.com/skx/gathering/
Demo site:
http://spam-box.co.uk/ <comment><USER2> Props for using Redis. I've been hacking on a project that uses Redis only and it's been an enjoyable experience.

I have to agree with mean anonymous comment guys that the interface could use some work, though. Too much whitespace, and I personally don't care for the grey background.

<comment><AUTHOR> The layout is the hardest part for me - but yes I agree it needs work.

I've killed the whitespace in the index and reset it to black on white for the moment. I'll have to work on the layout some more over the next couple of days.

Redis is very pleasant to use..

</comment></comment><comment><USER3> Clickable: [http://spam-box.co.uk/](http://spam-box.co.uk/)

</comment><comment><USER4> Is there a way to combine tags? Similar to how on reddit I can do /r/webdev+golang?

<comment><AUTHOR> This is now possible.

[http://forum.spam-box.co.uk/tag/gui,bug](http://forum.spam- box.co.uk/tag/gui,bug)</comment></comment>


Digger - CSS selectors for databases - <AUTHOR> http://digger.io/

<comment><USER2> I don't get it</comment>


Neurological evidence for chaos in the nervous system is growing (2014) - <AUTHOR> http://nautil.us/issue/15/turbulence/your-brain-is-on-the-brink-of-chaos <comment><USER2> Alan Turing connection, Chemical Basis of Morphogenesis, [https://en.wikipedia.org/wiki/The_Chemical_Basis_of_Morphoge...](https://en.wikipedia.org/wiki/The_Chemical_Basis_of_Morphogenesis;) noise is useful for producing patterns.

<comment><USER3> Your semicolon got added to the link. Here's the working link for anyone else who got stuck in the bowels of Wikipedia: [https://en.wikipedia.org/wiki/The_Chemical_Basis_of_Morphoge...](https://en.wikipedia.org/wiki/The_Chemical_Basis_of_Morphogenesis)

<comment><USER2> Thanks!

</comment></comment></comment><comment><USER4> And, thus, John Conway's Game of Life edges ever closer an accurate analog for the behavior of actual life.

Cellular automatons, requiring complete end-to-end simulation to determine the end result of a chain of events, with limitations on calculating shortcuts, by skipping states in between.

So, now, too, the real answer for why we would be required to "live" life, if we were, in fact, "souls" from a parallel dimension, fated to inhabit corpses passed through a one-way temporal dimension, in order to answer questions about the experience of an individual life.

To wit: One cannot know the outcome of a sufficiently complicated deterministic system or the seemingly apparent implicit results of running its course, without actually living through the intervening states all the way to completion.

</comment><comment><USER5> A most creative chaos it seems.</comment>


Why we're switching to calendar versioning - <AUTHOR> https://www.cockroachlabs.com/blog/calendar-versioning/ <comment><USER2> > Among other things, it includes a cost-based optimizer that can complete the > TPC-H benchmark, CDC, and two major enterprise security features. But was > this enough of a value jump to merit the leap to 3.0? Or was this a 2.2? > Strictly following the semantic versioning rules would specify 2.2, as there > are no backwards incompatible API changes. But with that logic guiding the > major version bump, we could potentially remain on 2.x forever.

The whole point of semver is that it allows people to know if they can upgrade version without hitting incompatibilities. So yes, this would be a 2.2 and those on 2.1 would know that they could upgrade to it without worrying about fixing their own integrations.

The calender version 19.1 tells me nothing other than when it was released, which is of no interest whatsoever when evaluating what it does. Sounds like a triumph of marketing over useful information.

<comment><USER3> > The whole point of semver is that it allows people to know if they can > upgrade version without hitting incompatibilities. So yes, this would be a > 2.2 and those on 2.1 would know that they could upgrade to it without > worrying about fixing their own integrations.

No. Semver states quite clearly that "Major version MUST be incremented if any backwards incompatible changes are introduced to the public API.".

It does NOT state that the Major verson MUST NOT be incremented if the api has no backwards incompatible changes.

You can increment the MAJOR component of the version number at your will. So this is quit clearly a 3.0.0 release. Or it could be a 40.0.0 release and it would still be valid semver.

<comment><USER4> IMO it's kind of implied by semver that a major version increment means breaking changes. If you increment major version without breaking changes then you aren't really doing semver IMO.

It's like if you have a fire alarm that goes off when there's a fire but which also goes off randomly all of the time. People are going to stop listening to it, because even though it reliably rings when there's a fire the fact that it rings is unlikely to mean there's an actual fire.

In the same way, if you keep incrementing the major version without breaking changes then people can no longer rely on the version number to be alerted about breaking changes.

By all means, increment your major version number when you feel like it. Just don't call it semver. Because even if you are technically allowed to, it goes against the spirit / point of semver IMO.

<comment><USER5> Just add an unnecessary breaking change and everything's perfect.

<comment><USER6> This is the correct answer! IMHO.

A perfect solution that strikes the balance between an engineer's unrelenting desire for correctness and the marketing departments seemingly irrational need for perceived progress.

</comment></comment></comment></comment></comment><comment><USER7> > Since we release on a 6 month cadence, we're starting to name releases by > season and year, which means our next release is now CockroachDB Spring '19.

Ugh. You'd think the creators of a multiregion database would realise half the planet has Autumn the same time as the other half has Spring.

> It also eliminates the mental gymnastics needed to figure out how old a > release is

I guess not.

<comment><USER8> Best thing about moving to the US was that all those phrases "coming summer 2019" actually make sense! In Australia we don't really use seasons as references (the seasons aren't as distinct as they are here) - and because they were then flipped as well I never really thought they had a real meaning.

I guess I must have known they did have a real meaning, but my "consumer" grasp of them was more like vague marketing fluff that meant "will probably be out eventually"!

<comment><USER9> What a brilliant observation, I love finding things like that where you never really thought consciously about something.

I'm similar to you, though I don't even have the excuse of living with different seasons - I just never really thought about it.

<comment><USER10> As an also-Australian, my brain just doesn't process seasons like Americans.

If someone says "coming in the Spring" I literally have no idea when that is. The dates of seasons are meaningless.

<comment><USER11> As a Polish person, my brain hates these too, even though we have proper seasons here. When I see "coming in the Spring", my mind is all "that's 20-ish of March, I think... or maybe April... no, December is definitely winter, so it must be March!".

Seasons are dumb. I remember reading a rant on the Internet once that advocated that we should recognize two seasons - summer and winter. You could put the boundary at equinoxes, with summer encompassing both traditional summer and spring, and winter encompassing traditional autumn and winter. The definition would be simple: summer is when it's kind of warm most of the time, winter is when it's kind of cold most of the time. I remember this resonating with me much more than the traditional definition.

Going back to temporal coordinates, the older I get the more confident I am in feeling that, for terrestrial use, anything that's not an ISO 8601 date is garbage and should not be used.

<comment><USER12> > and winter encompassing traditional autumn and winter. The definition would > be simple: summer is when it's kind of warm most of the time, winter is when > it's kind of cold most of the time.

At least in the part of the US I'm from, we only used "Fall" for "Autumn", because colloquially it was already defined as a simple and pretty tight (but often slightly different each year) period: When the leaves on trees have changed color, but not yet all fallen off.

</comment></comment></comment></comment></comment></comment><comment><USER13> This feels like the "product version" has taken over again.

I promote semver internally primarily for wiring together build automation. But I also try to make it clear that there can be a _completely different_ "product version" that can mean whatever the hell we want it to be. Calendar versions are great product versions.

Many people, frequently product managers, are very uncomfortable with this distinction.

So many places use the product version as "the version", which then becomes the main justification for monolithic version control, even for distributed applications or multiple product lines. So now, you re-build and/or re-deploy everything, even things that had no changes, purely to stay in sync with "the version".

There are usually good _technical_ reasons for monolithic version control, but doing it just to slap a product version on everything usually ends up with an alarming amount of waste.

<comment><USER14> This!

Semver uses the version number to convey useful information. Getting rid of semver just eliminates that information.

If you want to bump versions for marketting, that's perfectly valid. Just use a separate product version.

My SVN commit numbers and git hashes also fail to convey useful marketting information, but that's no reason to get rid of them!

</comment></comment><comment><USER15> Seems like most folks here are missing the really interesting part about the article: > But was this enough of a value jump to merit the leap to 3.0? Semver said nothing about "value". Semver only talks about breaking changes and added functionality vs. purely fixing bugs. For many users and libraries this is more than sufficient, because it allows you to manage risk when upgrading. However, lets enter some false preconceptions and more importantly Enterprise:

False preconceptions: Historically major versions of software, pre-semver, had major new features. Many people still have the expectation that this will be the case. This still gets reinforced by many software products (as opposed to libraries). We'd all be surprised if Apple released a new iOS major version and it has no new significant features, but just breaks some APIs that had been deprecated. This is what server would dictate, but would break human expectations.

Enterprise: I am sure CockroachDB has support contracts with some larger companies. What are the terms? Are there some support durations that are based on major version numbers? Now majors aren't free anymore. Even if their support contracts don't care about major vs minors, you want your customers to upgrade ASAP, because the older the version you have to support, the more different is that code base from what you are actively working on and the fewer other customers will benefit. A fix on your latest version will likely be with the product forever, whereas a fix on a version that's three years old might not even be relevant to your latest. A major release in server has per definition breaking changes. So this won't be a zero-cost upgrade. Many enterprises in addition have much heavier procedures to upgrade a major dependency, especially for something like a database. This makes for a lot of reason not to upgrade. So now you need some very good carrots to get users to upgrade.

Even if you don't have paying customers, breaking changes without a big carrot can be a problem. Nobody wants a mess like Python 2.7 vs. 3.

It seems like CockroachLabs just has passage of time make the decision for them now. I'd be very curious to see how this will impact how far behind latest their customers will be.

</comment><comment><USER16> Why not just move to 3.0? Semver only says that a breaking change MUST be an increase to the major version. It doesn't proscribe an increase of the major version without a breaking change.

<comment><USER17> Yes! Semver is very precisely specified and the specification ain't very long. How on Earth could they mess it up?

<comment><USER18> A point not highlighted in OP article is that Enterprise customers are shy to upgrade to a "next major version" because they will _assume_ there are breaking changes in there (even though semver allows bumping the major number without breaking changes).

Calver side-steps this user bias.

<comment><USER19> Why are developers always insistent on trying to trick the user into doing what they want them to do, or what they think is best, instead of letting users do what users want to do?

Users shy away from major version numbers because they are allowed to change things in incompatible ways. When you jump a major version you're signaling that stuff might _intentionally_ break, and they make their decisions accordingly. The solution is not to make your communication with user even worse!

<comment><USER20> This could easily be solved by something along the lines of "Version 3.0 maintains full compatibility with Version 2.2" at the top of their release notes.

I dislike the idea of going away from SemVer just for marketing purposes. At least as a user when I'm going to upgrade versions then I could see that "oh, this version doesn't break compatibility"

</comment></comment></comment></comment></comment><comment><USER21> > helps us (and our users) avoid the confusion around the significance of a > release.

I think you mean "makes it impossible to know if a release includes backwards incompatible changes without looking at the release notes, while still having a release number say nothing about other aspects of the significance of a release."

<comment><USER18> > I think you mean "makes it impossible to know if a release includes > backwards incompatible changes without looking at the release notes, while > still having a release number say nothing about other aspects of the > significance of a release."

The compatibility guarantees of CockroachDB do not change with this. It's always been the same: version X+1 will remain backward compatible with X but may break compatibility with X-1. Deprecation notices for definitive changes in version X+2 are introduced in version X.

<comment><USER22> > version X+1 will remain backward compatible with X but may break > compatibility with X-1

That is literally impossible; a breaking change from X-1 to X+1 must have been introduced in one of the intervals X-1 to X or X to X+1. It the latter, X+1 breaks compatibility, if the former, let X' = X-1 and X'+1 breaks compatibility.

Presumably you mean that X always includes warnings about breaking changes in X+1, which is a vast improvement on _some_ projects, but knowing that a problem exists doesn't mean it _doesn 't_ exist.

<comment><USER18> > That is literally impossible; a breaking change from X-1 to X+1 must have > been introduced in one of the intervals X-1 to X or X to X+1. It the latter, > X+1 breaks compatibility, if the former, let X' = X-1 and X'+1 breaks > compatibility.

No, that's not how it works. The deprecation is introduced in version X-1; the new behavior is introduced but is opt-in; in version X, the new behavior becomes opt-out; in version X+1 the old behavior is removed.

<comment><USER22> That breaks backwards compatibility _twice_ ; once in X when 'do_thing' breaks and has to be rewritten as 'enable_thing;do_thing', then again when X+1 causes 'enable_thing;do_thing' to break.

</comment></comment></comment></comment></comment><comment><USER23> Seems to be a few critics in here but I think a good usecase for calendar versioning is crypto and security critical libraries.

You hear about about WPA3 being broken in April 2019. It's obvious your WPA3 18.10 lib is vulnerable, WPA3 19.04 is not.

It's a lot simpler to parse and can lead to less mistakes.

<comment><USER24> Is it just me or are you implying WPA3 revisions should be coupled to Ubuntu release schedule?

</comment></comment><comment><USER25> Decoupling feature releases from API changes is the best option. Your API follows strict semver, but your new features can use whatever versioning scheme you want, this date-based scheme is fine.

So the new version is 19.1 [API 2.2].

Most of this thread is debating the relative value of using a single number to communicate feature additions vs breaking changes, but these two things are (mostly) orthogonal. _So use two numbers._ This even allows releases where there are awesome new features but _no_ API changes at all!

<comment><USER26> > So the new version is 19.1 [API 2.2].

The article says they decided to 'rename' 2.2 to 19.1. There is no separate versioning for features and API, only 1 version for everything.

<comment><USER25> I thought it was clear enough that I meant:

> So the new version _would be_ 19.1 [API 2.2]

</comment></comment></comment><comment><USER27> The main reason I don't like timestamp based version schemes is that it makes builds inherently difficult to reproduce.

I wrote some code for a specialized piece of equipment earlier this year. One of the requirements on this equipment is that all package installs contain a unique version string (ie. you can't install the same version twice). So I based build versions on git hash and timestamp. This turned out to be a problem because it made it impossible to reproduce builds without hacking the build system clock. So I switched back to semver for releases.

<comment><USER28> What is the point of a reproducible build if you need to rebuild it to test its the same?

<comment><USER27> The entire point of a reproducible build is that you can rebuild it to test that it's the same.

<comment><USER28> No.. the entire point of a reproducible build is so that you can rebuild the same thing given the same inputs across the world different servers.

Testing that md5sum(software A) works just like md5sum(software A) is just pointless?

</comment></comment></comment></comment><comment><USER29> Why not simply separate versioning into product and technical like Microsoft Visual Studio as an example: Product version: Visual Studio 2019 Technical version: 16.0.1

It fits good for marketing and for developer people.

<comment><USER19> Because it causes even more confusion. Given a Windows 10 version number like 10.0.16299.522, you need a lookup table to determine that it is called 1709 by all the documentation.

</comment></comment><comment><USER10> Just so you know, season based names make no sense since the Southern Hemisphere exists.

Also there's no such thing as Fall in a lot of places.

<comment><USER30> As an Australian, "Coming Summer 2019" may as well just say "Coming 2019".

I don't care to research the country of the developer and then the dates that are considered summer in that country just because they were so ignorant they used a season as a timeframe.

</comment></comment><comment><USER31> I feel like a lot of semver purists have never maintained software with a lot of downstream dependencies. The gray area about what is a breaking change is huge and it's hard to usefully improve software without making changes that are breaking under some definitions. The broadest is that, if a downstream program was working against version x.y, then it should always work unmodified against x.z.

One obvious case is bug compatibility and undocumented behaviour - it isn't that uncommon for software to depend on bugs or undocumented/unintentional behaviour. But if you're exposing a language like SQL, it's even messier. E.g. if cockroach added a new feature to the SQL dialect, then it could break downstream software that was assuming a particular SQL string would return an error. Or if you extend existing functionality, say supporting a wider range of arguments in some function.

There's also unspecified behaviour and implementation details - e.g. if a query without an "order by" happened to reliably return rows in a particular order before an upgrade, but it changes after an upgrade because of an algorithmic change, is it a breaking change? Common sense would say no, because it's not documented behaviour, but pedants could disagree.

And of course there's performance changes - if a query runs 100x slower after an upgrade, but returns the same result, is that a breaking change?

If you take the most pedantic interpretation of semver, you either have to bump the major version number all the time or you are very limited in how you can improve the software.

</comment><comment><USER32> I never found stric following of semantic versioning to be a good fit for product versions. It makes sense only for libraries and packages.

<comment><USER33> Why not?

<comment><USER32> Because a backward incompatible change can be required to implement a small feature or even fix a bug, which does not justify major version bump from the production life cycle perspective.

<comment><USER33> What about the "production life cycle perspective" requires that major version numbers not bump in those cases?

If version pattern is thought of as "compatibility.feature.fix" then there is no reason that feature and fix changes cannot also bump the right most number [as compatibility is broken].

EDIT: for clarity

<comment><USER32> > If version pattern is thought of as "compatibility.feature.fix" then there > is no reason that feature and fix changes cannot also bump the right most > number [as compatibility is broken].

We think about it as "product(Management)Version.developmentIteration.emergencyPatch".

First number is incremented only in coordination with business/PR/marketing.

Second number is incremented after every development iteration (mostly one, but sometimes multiple sprints), regardless of new features being introduced or just code stabilisation is being worked on, and regardless of it being backward compatible or not. As someone mentioned, release notes are there to communicate that part.

Third number is incremented only if we're fixing some emergency issue on one of the release branches. E.g. customer running version 4.2, reports a bug. We fix it on the branch and release 4.2.1

<comment><USER33> Then you don't have SemVer but some Frankenstein combination of marketing and technical versioning. One with few advantages to traditional, arbitrary versioning which still requires IT digest every releases' changes to get a sense of the magnitude of the changes.

Not saying that's wrong for everyone. But I for one prefer versioning that clearly communicates compatibility before any marketing concerns.

</comment></comment></comment></comment></comment></comment><comment><USER34> "But with that logic guiding the major version bump, we could potentially remain on 2.x forever."

That's WAI if you don't break compatibility.

I think the only reason behind moving is to have a better sense of progress or freshness. It seems like semantic versioning should support having some date on the minor numbers.

<comment><USER35> Semver _allows_ non-breaking changes on major release. It also supports tagging which could be a date tag.

The entire spec is like a 10 minute read. Anyone using semver should have at least read the semver spec. Anyway, the bullet on tagging:

"Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85."

</comment></comment><comment><USER36> These decisions are often driven by marketing or product folks and rarely engineers.

The marketing team would probably even push further toward 1, 2, 3, or anything that could make a big splash once or twice a year. The product team would probably prefer dates because it makes their planning easier.

<comment><USER18> Engineers like calver too! (I do.) Calver tells me very clearly how old a release it and what was the technical landscape when it was released.

For example I know precisely how old ubuntu 16.04 is and what I can expect to (not) be in there.

<comment><USER37> And not much else.

</comment></comment></comment><comment><USER38> If semver says the next version is 2.2, then it's 2.2, what discussion is there to side step?

<comment><USER39> Marketing maybe? If you are good about being backward compatible, you never release n+1, which might be mistaken for being stale vs your competitors.

<comment><USER33> Can't marketing just focus on the minor part as Java does?

<comment><USER39> Marketing will, of course, do whatever they want. 3.x, 95, 98, ME, XP, NT, Vista, 7, 8, 10. Or just change the name when they want, ala macOS.

Edit: added Vista... thanks!

<comment><USER19> XBox -> XBox 360 -> XBox One... If the next console from Microsoft is controller that live streams games from the cloud I expect it to be called the XBox ExBox.

<comment><USER40> And if it's a full console, the next Xbox should be the 'Xbox 361'. Or the 'Xbox -359', maybe?

<comment><USER39> _" with Office 365 integration"_

</comment></comment></comment></comment></comment></comment></comment><comment><USER41> In one of the startups that I worked marketing people really wanted us to quickly go through version 1, 2 and reach version 3 because "many corporations aren't even looking at tools if they are not version 3 yet" :D They didn't really care what features should be included in those versions :) Fortunately sanity prevailed and we stayed with semver.

<comment><USER42> Trick question: was the startup successful?

Not that I agree with ditching semver, but the way you stated it actually sounds like a good argument _for_ doing it, not against. Sometimes marketing people have a point.

</comment></comment><comment><USER43> The versionings are not mutually exclusive. In our company we use calver, it is used mainly for planning and business purposes and works well. During the quarter or whatever period there can be multiple semantically versioned releases made. The only problematic is the YY format choice. Lots of people confuse 19.3 with March 19th in our country.

</comment><comment><USER44> they had the worst reason possible. "not remain on 2.x forever".

nobody cares about stability anymore. staying on 2.x by not breaking backward compatibility forever is a great feat to celebrate, sad to see marketing getting the best of it.

I personally like traditional versioning + security patches by date. but I'm on the minority.

</comment><comment><USER45> So, because of a hypothetical concern that semver could unnecessarily declare a non-breaking change as breaking, they got rid of non-breaking changes altogether?

This seems a pretty roundabout way to tell users they don't want to be backwards compatible anymore.

</comment><comment><USER46> All this means is that users will need to read changelogs to know if this update has breaking changes. A really bad move a database provider, you're the backbone of near all applications you should be rocksolid.

</comment><comment><USER47> > how much time has elapsed between two releases

If they really wanted to communicate that clear without having to read extra docs they should have used 2019 version instead of 19.

> Our Spring '19

The world is big, bellow the line of the equator the seasons are opposite so that could lead to more confusion to the lower half of the planet.

In summary, whatever works for them, SemVer is not the clearly the winner in market share, so we as devs always have to check and double check when upgrading things but IMHO the arguments provided in the article are not strong enough to justify the move.

</comment><comment><USER48> This is a hilarious coincidence, we (a database with opposite tradeoffs of Cockroach) just did the same thing a month ago:

`npm install email@example.com`

This means no breaking change.

How old/new of a version you are on.

Month+day the bug got fixed.

It was the compromise between intense debates within the community. It is the one thing everyone could agree too.

Looks like it is already catching on! I hope more projects adopt it.

</comment><comment><USER49> 'Spring' is a useless indicator for versioning. Most developers publish from the northern hemisphere so their Spring is March through May; mine is September through November down here in New Zealand.

Cockroach Labs should rather copy Apple's model, free of hemisphere bias: Early 20XX, Mid 20XX, Late 20XX.

</comment><comment><USER50> An item about versioning is always a good time to revisit Rich Hickey's thoughts on growing software and his criticisms of semantic versioning.

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

</comment><comment><USER51> Semver really isn't good for anything. Do you trust it so much you'd deploy patch increments to prod without tests? Minor increments?

I've said it before: software is too complex to be described by three numbers. Write tests and read the changelog. The version doesn't matter at all.

</comment><comment><USER52> Seems to me, there's version and there's compatibility. They are not one in the same. Trying to make a single field do double duty is so often never a good idea. Why is this any different?

Perhaps it's time to rethink this?

</comment><comment><USER53> Bad choice. If I ever build and maintain a database I am going to managethe vefsioning and releasing the way postgresql does, no need to get fancy with this, keep your user happy and not busy with distractions like this.

</comment><comment><USER54> This is terrible imo, but does is further evidence that semver should have a fourth, non-semantic marketing prefix. Because otherwise people will do ... "things" like this.

</comment><comment><USER55> I don't see why these things need to be mutually exclusive.

For years I've released things with semantic numbering but a YYYYMMDD build number.

</comment><comment><USER56> Funny. Not everyone knows what "Spring" is. It's not the universal season you think it is.

Definitely year.month is superior.

</comment><comment><USER57> It turns out semantic versioning hurts sales.

</comment><comment><USER58> Wow, people really, really seem to care about this. Does it matter, or is this just dev wanking?

</comment><comment><USER59> This made me respect cockroachdb less.

</comment><comment><USER60> It's called romantic versioning</comment>


Ask HN: The state of social games - <AUTHOR>

Hi HN,
I wanted to ask your opinion about the state of social games today. I've been thinking about what I want to do for the rest of my life, and I found the answer could be games. So I'm aligning myself to learn the domain via choice of where I work (social analytics company), my pet projects, what I read/watch/learn, etc.
Upon starting my adventure, I came across videos such as Mark Pincus' Stanford talk, Siqi Chen's presentation, and a bunch more. They talk about the importance of analytics, testing, and metrics driven decision making.
Thinking about it, I realized that these companies are actually marketing optimizations; they don't optimize for game experience first. Never in the history of game development has anyone built a game around analytic performance, because the goal of games were to immerse the player in an experience, not to rapidly grow a userbase. Maybe thats why I don't find social games like Farmville to be very fun (I guess I'm a hardcore gamer), but 80 million casual players can't be wrong.
Do social games today suck? Rather than optimizing for distribution, can you optimize for user experience? If you were to start a game company, what could you do differently than the big players today? <comment><USER2> I think that's right. If social games are going to continue to exist, and I think they are, there's going to be an arms race which focuses on quality.

People may have got sucked into Farmville by the viral aspect of the game, but having been fooled once they've developed an immunity to straight-out viral games. (Also, so has the platform -- games are no longer allowed to publish more than one message to your friends' newsfeeds.) So future games will have to focus on having a gameplay experience which makes people actually want to play them.

Of course, writing a really _good_ game isn't easy. And if you're capable of writing a really good game, why not sell it for ten bucks on iPhone/Android/MacOSAppStore/whatever instead of giving it away for free and trying to shoehorn in enough ads to cover costs?

<comment><AUTHOR> Price points on apps is still something evolving. From what I've seen, its extremely difficult to get users to buy apps past a certain price range (99 cents?). And if you can't get massive adoption, its not really a "social" game, is it?

<comment><USER2> It's still a social game if people can play it with their friends who also have it. You don't need 60% market penetration for that, you just need it to be sufficiently good that people say "Hey, this game is awesome, you should get it too!"

<comment><AUTHOR> I suppose so, but mobile games and games on Facebook are a different breed, the distribution mechanisms are very different.

</comment></comment></comment></comment><comment><USER3> Don't accidentally overlook one of the most important aspects of social games: The most stimulating part of the game for many people is how it fosters more interactions with those you already know. Many people despite having many friends on occasion still feel lonely and disconnected from those they know personally. Social games help overcome that by creating a habitual fabric of interaction between the player and the people they know. This ultimately fosters interactions outside the game, possibly in via instant messaging or conversation over a coffee.

A good social game optimizes for social interactions outside the game as well as gameplay inside the game.

Hardcore games permit escapism, whereas social games permit connectivism.

Examples of features that I've see work well and conversations they fostered in real life:

\-- feeding fish "Hey did you remember to feed my fish as well?"

\-- stealing crops "Stop stealing my crops!"

\-- giving bath to your avatar "dude, your creature is filthy, there are bugs flying around him and everything. give him a bath once in a while"

</comment><comment><USER4> I don't think the player experience and distribution are mutually exclusive - bad games just don't spread and marketing can't ultimately change that. If a game is popular it's because on some level people are having a net positive experience - I don't see the fun in building a farm, but I bet those people wouldn't see the fun in Transport Tycoon either which I played the crap out of.

I would expect Zynga etc work extensively with optimizing the player's experience since the longer you play my game, the more opportunities I have to x.

I work all day on in-game analytics, coincidentally I've had some success using analytics to improve my games:

<http://playtomic.com/blog/post/10-an-update-on-trickochet>

</comment><comment><USER5> While not strictly on the state of social games, Sebastian Deterding's (@dingstweets) presentation "Pawned. Gamification and its Discontents" has some very prescient thoughts on how to make a great game, as well as why so many social add-ons to non-game systems simply suck. A good reflection on why many social games in themselves suck.

Enjoy: [http://www.slideshare.net/dings/pawned-gamification-and- its-...](http://www.slideshare.net/dings/pawned-gamification-and-its- discontents)</comment>


Building Better Teachers - <AUTHOR> http://www.theatlantic.com/magazine/archive/2014/09/building-better-teachers/375066/?single_page=true

<comment><USER2> > Student achievement does not correlate strongly with teachers' years of > experience in the classroom (beyond the initial few) or with the caliber of > their preparation—whether they have acquired certification, earned a > master's degree in education, or aced state licensing exams.

AFAIK this is as measured by standardized test scores on evaluations that aren't designed to measure teacher performance, and in fact are not even capable of it.</comment>


Seevl surfaces new music on YouTube - <AUTHOR> http://thenextweb.com/apps/2012/11/09/seevl-music-discovery-assistant-for-youtube/

<comment><USER2> +1 for being an Ireland startup...don't see many of those. Congrats guys.

</comment><comment><USER3> really cool app. wonder how this will affect the rdio's of the world.</comment>


Reddit: Rally to Restore Your Rights on July 4th - <AUTHOR> http://blog.reddit.com/2013/07/rally-to-restore-your-rights-on-july-4th.html

<comment><USER2> Currently at the top of the front page! So fantastic to have their official support.</comment>


Surprising new study:controversial drug HCQ helped Covid patients better survive - <AUTHOR> https://www.cnn.com/2020/07/02/health/hydroxychloroquine-coronavirus-detroit-study/index.html <comment><USER2> If taken early (hospital admission), by someone with a healthy heart, alongside Zinc, it works (French studies).

If taken too late (ICU admission), by someone with a risky heart, without zinc, it's harmful (US studies).</comment>