1. 3

    Great news. We upgraded our 16.03 package based nix deployment to 18.03 and nix 2.X series. That was a surprisingly easy task given our installer complexity and nix usage.

    1. 4

      There’s one interesting service called https://littlebirdie.io/ it’s also doing a similar thing as f5bot, but live and to slack. We created this for our internal team to scan the internet for mentions.

      1. 5

        I’d love to read their post-mortem. They failed at like all possible steps :D

        1. 24

          They appear to have quite a successful business selling multiple locks to infosec bloggers.

          1. 2

            God, that’s brilliant. Just continually create minimal IoT products and trick bloggers into tearing them down after buying them.

          2. 3

            Sure the execution was badly done, but the entire concept was appalling to begin with. Adding fragile battery-powered electronics to a padlock is already pretty stupid. Adding a radio-frequency attack surface to that is stupider. But putting the whole thing on the internet is really the cherry on top. Who the hell buys these products?

            I hope the ridicule this story generates helps a little more of the general public see the implicit “Id” prefix in front of “IoT”.

            All that said…. remember when one of the world’s most reputable bike-lock makers got embarrassed to the point of recalling multiple product lines, all because of a PoC video featuring a Bic pen? Shit happens, in the consumer lock biz no less than anywhere else.

            1. 1

              Well, there’s this, but it’s disappointing. David Tao fucked up massively, and his professional credibility will suffer massively if he doesn’t fix it quick.

            1. 8

              Contrary to most opinions I think that acquisition might be a good thing:

              • Microsoft is a different company now their open source strategy recently is quite good.
              • Github seems in decline for some time, the inability to lock a permanent CEO, low number of new features
              • MS has all the resources to put Github on the next level if they don’t screw it up.

              What could be bad is if MS buys Gitlab, then they would control that space. Gitlab is also a heavily VC backed so investors will seek for an exit at some point.

              1. 10

                Honestly, my hope is that the fear factor of this, convinces more people to consider alternatives.

                I’ve setup gitlab (a few years ago) for a client, and it was a fucking pig. I’ve looked at your solution too, and wasn’t completely sold on some aspects of it (sorry, dont remember what right now) - but these things obviously work for some people, and getting out of this mindset that “GitHub is just what all developer use” is crucial to me.

                Monoculture should scare people a lot more than the boogey man from Redmond.

                This line from the Bloomberg article sums up the issue:

                San Francisco-based GitHub is an essential tool for coders.

                This is honestly like claiming “Windows is essential for technology companies”.

                1. 13

                  Microsoft is a different company now their open source strategy recently is quite good.

                  I’m getting awfully tired of people saying there’s nothing to worry about because they’ve been nicer for the past handful of years. They have been antagonistic to free software for decades.

                  Microsoft changed their tune because it became profitable to do so. If it becomes profitable to be dicks again, they will be dicks again.

                  I’m glad we have a kinder, gentler Microsoft. Don’t kid yourself about their motivations.

                  1. 10

                    Also good to remember: they still routinely attack Linux and related free software by threatening with their patents, and extract patent royalties from many terrified companies who use Linux

                    1. 4

                      They’ve collected over a billion dollars on Android alone.

                    2. 1

                      I never said to not worry about. I’m writing this based on a feeling MSFT will do good with Github. Time will show, and their motivation is quite simple, buy more power and make more money.

                    3. 1

                      That would be very cool that as @nickpsecurity mentioned, RedHat take a shot at gitlab.

                      1. 3

                        Given the high performance has for on-premise installations, that would be a great addition for RedHat, TBH.

                        (I see GitLab, even paid, everywhere at clients and I have yet to see a GH Enterprise installation in the wild)

                        1. 3

                          Riot games had GH enterprise a few years ago, just for their web team. The rest of the company was using perforce.

                          1. 2

                            I’ve got the opposite experience. I’m seeing big installations/companies use GHE all the time, and none of them Gitlab.

                      1. 4

                        I’d said it again:

                        Contrary to most opinions I think that acquisition might be a good thing:

                        • Microsoft is a different company now their open source strategy recently is quite good.
                        • Github seems in decline for some time, the inability to lock a permanent CEO, low number of new features (They have already a plan to put a new experience CEO from MS.)
                        • MS has all the resources to put Github on the next level if they don’t screw it up.
                        1. 1

                          The 2 submissions were merged. Your comment is now a double-post.

                        1. 5

                          this full-throttle tinfoily panic mode of some people right now. “move to hosted gitlab!!1 that will show ‘em!!11”. i’m not anti-gitlab, but hosted gitlab has the same set of problems like github. like, for example, being bought by $EVILCOMPANY

                          if microsoft now decides there will be no more free repos, it’s ok! they can do with their property however they please (just like before that acquisition github could’ve done). don’t bitch about the free lunch not tasting right. that is the deal if you use resources of others for free.

                          1. 3

                            I think for most people, if gitlab took a similar turn, a self-hosted (or pay someone else to host it) OSS version of GitLab would be fine.

                            People use gitlab.com because it’s hands-off, not because it’s the commercial version for free.

                            1. 3

                              It’s not “that will show em” at all. No idea where that is being quoted from.
                              I can say my statement was, IF the MS acquisition bothered you, and there is enough historical precedent that it may reasonably do so for reasonable people, then note that Gitlab does currently have 1-click repository migration from GitHub. In addition that is is also a possibility that Github may unilaterally sever that capability IF the migration becomes a flood. Ergo if you are going to do it, then do so now and don’t wait.

                              1. 1

                                it was a purposely overstated made-up-quote (easily spotted by the liberal use of “!!111”).

                                microsoft is an actor on the market and as a result does things to maximize profits. one only has to take that in account when choosing to use their services. i’m not overly happy with it either, but gitlab is an actor too and plays by the same rules, including the possibility of being acquired. just self host, it’s not even hard, scaleway has prepared images for that for example.

                                regarding the importing functionality: if they break the mechanisms to do that, i guess many other things won’t work as well, like bots acting on issues, etc. i don’t think they will break the whole ecosystem, as effectively that’s what they’ve paid for. maybe they’ll do that in the extended future, like twitter breaking their api for clients.

                              2. 2

                                Imagine what would happen when MSFT after buying GH also gets travisCi , which i believe they will do :)

                                1. 2

                                  It should also be quite a bit cheaper, afaik they never took VC money.

                              1. 9

                                I run a couple of hg servers too. It’s pretty easy to do, and the docs give a good run down of how to do so:

                                https://www.mercurial-scm.org/wiki/PublishingRepositories

                                While we’re diversifying away from github, let’s also diversify on VCSes. :-)

                                1. 1

                                  Do you just use ssh+hg on a private server, or use a ‘package’ (ala gitlab, but for hg)?

                                  Not looking for a suggestion so much as appraising actual usage for a potential OSS project.

                                  1. 1

                                    I use ssh+hg; haven’t yet had to host a server for a large amount of people were manually managing ssh keys wasn’t a possibility.

                                    But yeah, improving Kallithea or Rhodecode or giving gitlab hg support would all be great things.

                                    1. 1

                                      Right - so my plan was actually a more (in my mind anyway) natural progression from what it sounds like you’re using now.

                                      Effectively:

                                      • rely on the system ssh still, either direct as you’re using it for small installs, or via LDAP for larger/multi-server setups
                                      • rely on Filesystem ACL’s to allow group based write access to repos
                                      • use a vcs-specific “shell” for Git, Hg (heck even SVN) sessions

                                      To clarify on the ‘improving’ topic:

                                      • RhodeCode is AGPL or commercial. That isn’t going to fly.
                                      • Kallithea is GPL. That isn’t going to fly.
                                      • Gitlab is IMO a Rube Goldberg machine at this point. The number of services required is crazy.
                                      1. 3

                                        The AGPL is flying quite well in Mastodon. People have been scared of copyleft forever, and great copylefted things have flown.

                                        The constant push back against copyleft is how we got github in the first place: hosts all of the code, shows none of its own.

                                        1. 3

                                          Right, I understand the premise but given that (a)gpl gives rhodecode inc exclusive permission to do a GitHub (which they do, via the enterprise edition) I have zero incentive as either a developer or as a business owner to contribute to that project.

                                          Everything I create (as opposed to forks) is bsd-3-clause, specifically because I see the main targets for things like this as being small/medium business.

                                          1. 1

                                            The only reason it gives them “exclusive permission” is because people like you are afraid of touching the AGPL for no good reason. It’s the fear around the AGPL that does it, it’s the very same undermining of copyleft.

                                            Small/medium business can use AGPLed stuff; it’s not the cancer that people said the GPL was in the late 90s. It’s not some kind of plague to avoid. Rhodecode is abusing that plague fear that others have created.

                                            1. 1

                                              rhodecode inc is able to produce an enterprise edition with closed source additions.

                                              No other entity on earth can do the same thing, either hosted or distributed, because any changes they distribute must be returned upstream.

                                              How is that not exclusive permission.

                                              And frankly the gpl is a cancer. Good companies contribute back to/release permissiviely licensed projects.

                                              Shitbag ones are unlikely to do that regardless of the license.

                                              1. 3

                                                Interesting discussion on this topic. We’re actually in the process of changing AGPL for RhodeCode CE edition into MIT/BSD. We did the same move with our other project already - RhodeCode-Appenlight.

                                                MIT+CLA works fine for Gitlab. We believe this will help RhodeCode, and we’ll execute on this very soon.

                                                1. 1

                                                  I don’t know if you have much content that would fit lobste.rs, but it’d be great to see blog posts or something here about RhodeCode.

                                                  Also, does RhodeCode support FreeBSD?

                                                  1. 2

                                                    We do occasionally post release notes. Lots of our stuff doesn’t fit lobsters and it felt kind of “too much marketing” But if there’s something related to Mercurial, e.g evolve support or narrow support (which is supported by 4.12 release) we’ll post it here for sure.

                                                    FreeBSD is supported if you run rhodecode from source. Afair installer have some problems because of older NIX we used.

                                                2. 1

                                                  You can make private modifcations to AGPLed code. You can grab Rhodecode, modify it in-house, and you don’t have to distribute anything back to anyone.

                                        2. 1

                                          RhodeCode has full SSH Key management together with SSH access in the Free CE edition since few releases.

                                          Source code here: https://code.rhodecode.com/rhodecode-enterprise-ce

                                    1. 4

                                      Thanks for posting this.

                                      A general problem I have with mercurial (I started using it for pet projects I work on at home, never at work), that a lot of material you can google is fairly old and lots of it outdated. Whenever someone refers to a hg extension, one needs to further investigate if this extension is still alive, and still the prefered way of doing things.

                                      1. 1

                                        The feature that this article describes is in core.

                                        1. 9

                                          Just to elaborate, because this is the third or fourth Mercurial discussion coming up in as many days, and I’m getting tired of the same discussion happening ad nauseam:

                                          1. Out-of-the-box, with no configuration done, Mercurial doesn’t allow editing history–but ships with all the functionality required to do that. You just have to turn it on. Turning it on takes up to three lines in a config file and requires no third-party tools whatsoever.
                                          2. Out-of-the-box, Mercurial does come with phases (discussed here) and the associated phase command that allows explicitly altering them. You don’t actually use the phase command that much; phases are actually more for consumption by history editing commands.
                                          3. If you enable any of the history editing extensions–again, which ship with Mercurial–including rebase, which is probably all you need, and histedit, if you do really need the equivalent of git rebase -i, you will find they are phase-aware. In particular, they will allow you to alter changesets that are secret or draft, but not public. Because changesets will become public on push by default, this is by itself awesome, as it can trivially help you avoid accidentally rebasing something someone else might’ve pulled. Having this would’ve eliminated quite a few Git horror stories.

                                          All of the above ships in core. You need to add at most three lines to your .hgrc or equivalent to get all of it. Which is fine, because you also need at least two lines just to set your email and name, much like you’d have to at least do git config --global user.email and git config --global user.name. A couple extra lines isn’t a big deal.

                                          The only thing interesting in this space that doesn’t yet ship in Mercurial, and which I’m really excited about, is something called changeset evolution, which will allow cleanly and easily collaborating on in-progress, frequently-rebased/collapsed/edited branches. But that’s not baked yet, and Git doesn’t have anything equivalent to it yet anyway.

                                          1. 5

                                            The problem is making it clear to new users or users coming from git how to enable those extensions. There’s also the problem that the new tweakdefaults option is trying to solve: that hg’s backward compatibility guarantees mean that new features (e.g. new since hg 1.0) don’t get surfaced in the hg UI unless you’ve customized your setup (or had it customized for you as in a corporate setup).

                                            git’s out-of-the box experience enables a lot of power user features. This certainly isn’t great for safety but it is great for discovery - thus these perennial discussions on forums like lobsters and HN.

                                            I’m hoping with evolve getting upstreamed we might see more projects using mercurial. On the other hand, for open source projects the only real place to host them is either to use hgweb and roll a custom hosting and development workflow (basically what mercurial itself does) or use bitbucket, which is run by people who don’t prioritize or think much about open source fork-based workflows. It would be amazing if there were more competition in this space. Kallithea doesn’t support pull requests. Rhodecode has a questionable past participating in the free software community. I’m not aware of much else in this space.

                                            What would really change things is if one of the big players like github or gitlab decided to add support for other VCS tools although I’m not exactly holding my breath for that to happen.

                                            1. 4

                                              Unfortunately, I agree. I have noodled with basically rewriting Kiln (only not called that because I’m not at Fog Creek) based on changeset evolution and with an explicit fork-based workflow focus, but I’ve been waiting to see if evolution really does get fully into core, and then what the story is with hg absorb, since properly supporting Mercurial and evolution looks really different in an hg absorb-based world than one without it.

                                              In particular, my idea is that anyone can push to a repository, but it’ll automatically go into a new pull request in draft phase. At that point, if hg absorb stays a thing, and a normal user can be expected to just run hg absorb repeatedly as they address issues, then I can rely on obsmarkers. Otherwise, the story empirically gets a lot more interesting; I’ve had trouble on prototypes not requiring the user to know they’ve got a custom branch, basically doing the same kluge as Gerrit, albeit with a different mechanism.

                                              Edit: just to be clear, I’ve prototyped bits of this a few times, but nothing I want to release—doubly so since it’s all in Smalltalk anyway. But it’s been helpful to try to think through what a proper approach to this would work like.

                                              1. 2

                                                AFAIK the only blocker on absorb getting upstreamed is the need to rewrite the linelog interface in C.

                                              2. 2

                                                I’d like to add that RhodeCode is actively supporting usage of Evolve/Phase with changeset evolution. Based on feedback from our users we started to ship evolve extension enabled and within the CE and EE editions.

                                                This works with Pull requests, can be enabled globally or per repository.

                                                You might question the past, but we since almost 2 years provide a open-source free, no limitation version of CE edition of RhodeCode (similar to Gitlab CE/EE). You can use evolve there and it works :) I said it many times, and I’ll said it again. We did mistakes with certain past releases, but currently, our business model is based on a free GPL open-source version. This will be here to stay, we always try to promote Mercurial, and it’s great workflows using mentioned extensions.

                                                I doubt Gitlab/Github will ever support mercurial. They openly said they won’t for many reasons.

                                                We currently work on a simple app for Digitalocean, we hope it’ll make usage of Mercurial hosting much easier for people that don’t want to host it themselves.

                                                1. 1

                                                  Kallithea doesn’t support pull requests.

                                                  Looks like they now do.

                                                  I’m not aware of much else in this space.

                                                  Phabricator, Redmine and Trac also support Mercurial as well.

                                                  However none of them are as convenient as the hosted and “free for open source” offerings of Bitbucket, GitHub and GitLab.

                                                2. 2

                                                  I feel the need to fork hg2k5, which will be mercurial with only the original features. :)

                                                  1. 2

                                                    You’d have to start with forking Python 2.4 so that you could run it.

                                            1. 1

                                              TWe’ve got a similar problem at RhodeCode when we generated archives from git/hg repos. At the beginning we’ve got reports about hash changed of generated archives files, but we found that was the archiver added some metadata files with current date inside. Then we fixed that and used similar logic from Mercurial to create archives from all files inside a repository at particular commit. This resulted in stable archives with same hash every time.

                                              You have to use a consistent pointer via commit to guarantee that.e.g http://server.com/repo_name/archive/a9611b8be70e3dfafdd91d3e64c6636945277636.zip

                                              Our implementation is slower because it requires creating zip files via python code, and iterating all files in the repo, but combined with archive caches it’s good enough.

                                              1. 1

                                                I really like his workspace idea. I’ve sent one patch to three or four projects; there’s no need for me to have a whole clone of them up on github gathering dust.

                                                1. 1

                                                  Would a PR from diff patch would be an interesting concept here ?

                                                  1. 1

                                                    Can you elaborate? I’m not sure what you mean.

                                                    1. 1

                                                      To this day, I’m surprised this isn’t a feature. I often only make one or two changes to a project, and would be happy to just push the refs (or create a patch) rather than forking and remember to garbage collect later.

                                                  1. 6

                                                    Great write up. I’d wish now for a Mercurial problem summary from him now just to lear what are the key problems in his opinion.

                                                    1. 9

                                                      Using nix to distribute RhodeCode was the best decision we made for how we distribute our software. It removed all problems we had with python packaging just using virtualenv. I think the key benefit is that our installation survives system upgrades while we had almost 40% failure rate in this case with previous virtualenv based installer.

                                                      1. 5

                                                        Would you be interested in doing a whitepaper?

                                                        1. 3

                                                          Do you instruct end users to use Nix, or do you have some custom installer that somehow hides Nix from the users?

                                                          1. 5

                                                            We abstract it. End users just run a single binary that creates full nix env, and unpacks all dependencies into a custom nix store.

                                                            Nice things are that on upgrades we still have the full tree of old dependencies, so, for example, rollback to the previous release is just swapping a symlink.

                                                            1. 1

                                                              This reminds me of the guix pack command: https://www.gnu.org/software/guix/blog/2017/creating-bundles-with-guix-pack/

                                                              Would something like that (e.g. ported to Nix rather than Guix) make life easier? I imagine that including Nix itself in the artefacts you distribute would make things quite bloated. (I’ve never used Guix, but I’m a big Nix fan :) )

                                                        1. 16

                                                          I seem to be the only person who moved from git to mercurial and liked git a lot more.

                                                          Here were my impressions:

                                                          • The index (“staging area”) is an awesome feature. I know it trips people up occasionally, but the ability to carefully and precisely stage some of the changes in the working tree is invaluable.
                                                          • I like git’s branch model better than Mercurial’s. It’s more flexible and, at least for me, more intuitive. Maybe bookmarks are equivalent, but we didn’t use them at my work, so I couldn’t say.
                                                          • I like git’s general acceptance of history rewriting. It’s a valuable feature without which you need to choose between committing very carefully or breaking bisect and having a useless history. If you’re worried about corrupting your history, back up your repository (which you should do anyway, history rewriting is not the only way to corrupt a repository). I know it’s possible in Mercurial, but it’s not a first-class citizen and the culture disapproves.
                                                          • Mercurial’s commandline interface is a bit more uniform and predictable, but to be honest, this feels like a very weak benefit. If you’re using it professionally, muscle memory should basically mitigate the difference within at most a few weeks. Also, Mercurial’s interface certainly isn’t perfect, e.g. -l for commit limiting in hg log is wrong (it should be -n).
                                                          1. 12

                                                            index (“staging area”) is an awesome feature.

                                                            hg commit --interactive or hg ci -i is essentially the same thing. What people generally like about the index/cache/staging-area (these were all official synonyms at one point) is the ability to selectively pick apart commits, not so much having an extra, semi-obligatory step between your code and the creation of a commit. With Mercurial’s curses interface, hg ci -i is pleasant and widely loved.

                                                            If you really want a cache/index/staging-area, you can use hg ci -i --secret to start a secret staging commit and hg amend --interactive or hg am -i to keep adding to it. The --secret part is just to make sure it doesn’t get pushed accidentally. Once you’re ready to show the world your commit, hg phase --draft will turn it into a draft that you can share.

                                                            I like git’s general acceptance of history rewriting.

                                                            hg has this too, but better, and not as well-advertised: there’s a meta-history of what is being rewritten. This is called changeset evolution. The basic idea is that there are obsolescence markers that indicate which commit replace which other commit, so that history editing can be propagated in a safe, distributed fashion. No more need to force-push everything and then tell everyone who may have been following along to reset branches. Just push and pull and hg evolve will figure out where everything should be because it has more context.

                                                            Mercurial’s commandline interface is a bit more uniform and predictable, but to be honest, this feels like a very weak benefit.

                                                            My father, may he rest in peace, used to say that people can get used to everything except hunger. Sure, you can get used to git’s widely-derided UI. But why should you have to? If we can come up with a better UI, we should. Indeed, alternative git interfaces are their own cottage industry. Don’t downplay the problems that the git UI cause.

                                                            1. 9

                                                              hg commit --interactive or hg ci -i is essentially the same thing.

                                                              No it’s not. I can (and frequently do) continue to mess with the working tree after adding changes to the index.

                                                              hg has this too

                                                              General, ecosystem-wide acceptance of history rewriting? Not in my experience. When I was using it, the general guidance seemed to be “don’t do that, but if you’re going to do it anyway, here’s how”, whereas guidance for git is more along the lines of “here are some things to be aware of when you do that, now have fun”. No remote solution I used would permit pushing rewritten history.

                                                              The very page you linked to says that evolve is incomplete.

                                                              To be clear, the workflow I’m looking to be enabled here is to commit and push extremely frequently—as often as I save, ideally—and then, once the feature is complete enough for review, squash all those mostly-useless commits together into a single or few meaningful ones. This lets me get both commits willy-nilly and meaningful, bisect-able history.

                                                              But why should you have to?

                                                              Because it took me like three days? “Not ideal” is a far cry from “compellingly bad”. I will certainly agree that git’s interface is not ideal, but Mercurial’s is not better enough to be a compelling feature on its own. (Also, I had to get used to Mercurial’s interface when I started a job that used it. Why did I have to?)

                                                              1. 9

                                                                No it’s not. I can (and frequently do) continue to mess with the working tree after adding changes to the index.

                                                                Have you tried hg ci -i? Combined with hg am -i, it really is the same thing. Creating a commit is, pardon the pun, no commitment.

                                                                The very page you linked to says that evolve is incomplete.

                                                                It’s sadly in a state of perpetual beta, but so was Gmail for about five years and that didn’t stop a lot of people from using it from day one. Evolve is mostly feature-complete, just not completely polished to the usual hg standards.

                                                                To be clear, the workflow I’m looking to be enabled here is to commit and push extremely frequently—as often as I save, ideally—and then, once the feature is complete enough for review, squash all those mostly-useless commits together into a single or few meaningful ones. This lets me get both commits willy-nilly and meaningful, bisect-able history.

                                                                This is exactly what evolve is for. And people can even pull your commits before they’re squashed and if they pull again after you squashed, they won’t even see the difference in their workflow. Their copy of the commits will also be squashed without them needing to do an extra step like git reset and try to figure out exactly what to throw out.

                                                              2. 4

                                                                I agree that the staging area is an unnecessary concept. As a self experiment, I made myself git aliases to not use staging. After a few months of using that setup, I can say that I don’t miss staging.

                                                                (I don’t use Mercurial at all)

                                                                1. 3

                                                                  IMHO hg ci -i is a way better interface than git staging area even with -i. Used both, Mercurial one is way better.

                                                                  However I just recently found that there’s a mercurial equivalent of hg -i for git too as a plugin.

                                                                2. 4

                                                                  what benefit does the staging area give you that cannot be replicated by just committing the changes you would have staged and then doing a rebase to squash all the ‘stage’ commits into one main commit? I use this workflow a lot and find the intermediate stages cleaner and easier to work with than the git staging area.

                                                                  1. 2

                                                                    The index feels cleaner and if I wander away in the middle and forget what I was doing, it’s much easier to unwind.

                                                                    Obviously, there are any number of workflows which provide equivalent functionality, and I doubt anyone can muster more than extremely weak objective support or criticism of any. Having used both git and mercurial, I strongly prefer having the index to not having it. If people push me on it, I’m sure I can rationalize that preference until the cows come home, but I’m not sure how constructive that would be.

                                                                1. 2

                                                                  Glad to hear you’re enjoying Mercurial. Because I’m curious how they feel to a recent Git user: how do you like having local commit numbers that go 1, 2, 3, ... beside the usual unique hashes?

                                                                  1. 3

                                                                    I don’t use it that much but it is kind of nice to have a short hand, linear, way to look at the commits. Just talking about hash’s is pretty useless for anything other than knowing they aren’t the same.

                                                                    1. 2

                                                                      It’s nice to hear that you enjoy rev numbers, too. They are a detail, but one that I am fond of.

                                                                    2. 2

                                                                      Those numbers come in handy. E.g hashes don’t give you a perspective, you can tell quickly how big the project is looking at the numeric number, also comparing abcd...efgh vs 10...20 gives you much easier syntax to understand. Ofcourse this all applies only to local repositories because those numbers are relative

                                                                    1. 4

                                                                      If you don’t need hosted option but on-premise/private cloud you can check out RhodeCode which supports bookmark based Pull requests, Pull Request versioning, Mercurial evolve support.

                                                                      Here’s our blog post on how to use bookmarks via Pull requests: https://rhodecode.com/blog/120/mercurial-workflow-using-bookmarks-how-to-setup-and-use

                                                                      From our perspective using Mercurial to develop RhodeCode, a bookmark based workflow is a much easier to use than branches. And evolve/phases make it easier to simply rebase/reorder your commits, or fix small problems found during code-review.

                                                                      1. 3

                                                                        Evolve is one of the best feat. of Mercurial. We (RhodeCode) are shipping evolve extensions with fully enable per-repository support of it from the previous release.

                                                                        What really surprised us is that lots of folks actually use it. We got lots of feedback and for sure we’ll update support for it.

                                                                        1. 3

                                                                          This article is great. Adds another area to think of when securing your company access.

                                                                          1. 5

                                                                            I also know that some startups offer below average salary, because of options you get as an employee when joining a startup.

                                                                            1. 8

                                                                              This is kind of the same thing though, isn’t it? Options are worthless until there is a liquidation event. By not calling this out, the employer is hoping you’ll add the potential value of the options to your salary to get total comp, but they’re still underpaying you.

                                                                              1. 0

                                                                                Yes, exactly. It’s “virtual” money. It’s one of those things i don’t get why founder try to do such things to the employees.

                                                                              2. 8

                                                                                As I once said elsewhere:

                                                                                Stock options are for when you want to tightly couple your career and investing decisions at a moment when you’re excited and biased and trying to please someone who can offer or deny you a job.

                                                                                Before taking options, maybe ask yourself if you’d invest in this company if you weren’t going to work there.

                                                                                Personally, I consider stock options to be basically worthless, because:

                                                                                • Most companies fail.
                                                                                • Success or failure depends more on business decisions than on my individual code contributions.
                                                                                • Stock options can be complicated and sometimes employees get the short end of the stick vs outside investors
                                                                                • Having options would complicate my decision about when to leave a job for other reasons

                                                                                Getting paid in options makes me an investor in the business, and investing in individual stocks is always risky. Getting paid in cash means I have zero risk, and can invest in mutual funds or whatever seems prudent to me.

                                                                                1. 3

                                                                                  True, the salary is lower but the expected value of the compensation isn’t usually different. Here’s how it works.

                                                                                  Lets say you have a job that pays you $100k a year, no bonuses, and no option to buy into the company. How much do you expect to have been paid after four years, barring any promotions or raises? That’s $100k/yr * 4yr = $400k.

                                                                                  Now suppose you have a different job. It only pays $90k a year, but you get to buy a .001 ownership stake in the company at negligible cost on a four year vest. There’s an 80% chance that the company will fail and go bust when it runs out of money after year four, but a 20% chance that the company could get sold outright for $200M. What do you expect to have been paid after four years?

                                                                                  There are two possibilities. If the company goes bust, you get $90k/yr * 4yr = $360k. If the company is successfully sold, you get your $360k salary plus an additional $200k from the sale of your share of the company, for a total of $560k.

                                                                                  Since you have probabilities for the two outcomes, you can calculate the expected value. You have a 20% chance of earning $560k, and an 80% chance of earning $360. (20% * $560k) + (80% * $360) = $400k.

                                                                                  So the salary in the second job is 10% lower, but the expected pay after four years is exactly the same.

                                                                                  What makes optioned offers so difficult to evaluate is the uncertainty in assigning the odds and payouts of success. Are the odds of liquidity really as high as %20, and will the company really sell for $200M? Or is it more like a 10% chance at a $500M sale? And is that better or worse? Expected value lets you weigh those options.

                                                                                  1. 3

                                                                                    What makes optioned offers so difficult to evaluate is the uncertainty in assigning the odds and payouts of success. Are the odds of liquidity really as high as %20, and will the company really sell for $200M? Or is it more like a 10% chance at a $500M sale?

                                                                                    That’s my problem: either of those numbers could be anything.

                                                                                    Also, imagine the stock and job being decoupled: you don’t work at this company, but you have the chance to invest $10k, with 80% odds of losing it entirely. Would you? I wouldn’t.

                                                                                    you get to buy a .001 ownership stake in the company at negligible cost on a four year vest.

                                                                                    Complication: what happens if you want to leave the job after 2 years? So far I haven’t had a 4-year job in tech.

                                                                                    1. 1

                                                                                      That’s my problem: either of those numbers could be anything.

                                                                                      Like a lot of things, it takes explanation and practice to get a feel for how it works, but the numbers really can’t be anything.

                                                                                      Its fairly common knowledge that nine out of ten startups fail outright. So a ten percent success rate is a pretty reasonable probability to assign if you know absolutely nothing else. The valuation range at liquidity is pretty limited too. A valuation higher than $500M would be outstanding, but $100M to $200M is a lot more common and a safer bet, again if you know nothing else. One way to get a better estimate than that is simply to ask what the founders think. They have to answer that question for investors all the time. Yes, it might be wildly optimistic, but at least you can use it as an upper limit.

                                                                                      Also, imagine the stock and job being decoupled: you don’t work at this company, but you have the chance to invest $10k, with 80% odds of losing it entirely. Would you? I wouldn’t.

                                                                                      Obviously if you can’t afford to be without the $10k for the investment period, or forever, you cant take that bet. But if we’re still talking about a payout on success of $200k with a confident 80% failure estimate, then the expected value math says its a good deal, and I’d certainly take it if I could afford to be without the $10k.

                                                                                      However, those kind of deals (small, lucrative) are usually only made available to employees, as one of the benefits for doing work with the startup. If you evaluated the company and wanted in on the deal, but for some reason didn’t want to work there, you’d have to come up with a much bigger ‘put’ than $10k to buy into it. Think ten times that amount, if they wanted funding partners at all.

                                                                                      Complication: what happens if you want to leave the job after 2 years? So far I haven’t had a 4-year job in tech.

                                                                                      Most companies that aren’t on an immanent failure course will simply exercise their “right of first buyback” on your shares. You’ll get back whatever money you paid for them, and you’ll walk away from the job having made whatever your salary was for those two years.

                                                                                1. 3

                                                                                  One of the SPA i really NOT enjoy using is cloud.digitalocean.com. I constantly keep refreshing the pages to make sure things are shown as I want.

                                                                                  1. 10

                                                                                    Main changes:

                                                                                      Moby = open source development
                                                                                      Docker CE = free product release based on Moby
                                                                                      Docker EE = commercial product release based on Docker CE.