1. 1

    FreeBSD had a Google Summer of Code project for improving its boot environment management. I’m not sure about its status though.

    1. 3

      OK, OK, great, nice, really helpful.

      But all of those tutorials about desktopping on *BSD lack a single convincing point, which I don’t need (I use OpenBSD on desktop more or less actively) but others would appreciate:

      How such BSD desktop solution would be appealing for some casual Ubuntu user who just clicks “ok” button and gets on with things? I don’t want to deprecate or make it feel worse in any way, just looking for some points or features which can be nice for people using some mainstream Linuxes (Ubuntu, RHEL, CentOS, Fedora) on they work/private machines just to click things?

      The only thing like that I’ve seen was “OpenBSD is not for you if…” paragraph in OpenBSD desktop practives howto. But it’s actually an opposite for what I’m looking for :)

      1. 5

        How such BSD desktop solution would be appealing for some casual Ubuntu user who just clicks “ok” button and gets on with things?

        I think we need to find a difference between a ‘desktop’ term for regular people (not IT related) and a ‘desktop’ term for technical IT people.

        My guide is definitely for the second group, such FreeBSD Desktop is not suited for a regular user, the NomadBSD may be suited that way, the TrueOS Desktop may be suited that way but definitely such ‘custom’ setup.

        I am sharing this knowledge as I use FreeBSD on the ‘desktop’ since 15 years and when I wanted to have FreeBSD desktop it was not such easy task as it is now, but still requires some configuration and that I wanted to share.

        Is CentOS/RHEL better suited for the ‘desktop’ then FreeBSD? Depends, Linux has the advantage here that a lot of software out of the box supports these distributions, yet when you compare the freshness and count of packages between these system families its on the FreeBSD side - https://repology.org/statistics/newest - you have to configure many additional repositories with CentOS/RHEL like EPEL and on FreeBSD you just type pkg install so its more friendly here.

        CentOS/RHEL has graphical installer on which You can select to install X11 desktop which is easier for less advanced users, that is the CentOS/RHEL advantage over FreeBSD, but when we compare it that way, OpenIndiana based Illumos distribution is even easier to use and install then CentOS/RHEL as its installer is more easy then the CentOS/RHEL one ;)

        So its a long discussion without end really :>

        1. 4

          How such BSD desktop solution would be appealing for some casual Ubuntu user who just clicks “ok” button and gets on with things?

          The real selling point is “fearless upgrades”. Pushing the upgrade button in Ubuntu feels like russian roulette, you never know what’s going to break this time.

          ZFS is nice - RAID-like resilience, LVM-like convenience, and filesystem snapshotting for history/“undo” for the same amount of admin effort it would take to set up one of those things on Linux - but the biggest feature of BSD for me is more of an anti-feature: they just don’t keep randomly breaking everything.

          1. 3

            The real selling point is “fearless upgrades”. Pushing the upgrade button in Ubuntu feels like russian roulette, you never know what’s going to break this time.

            A somewhat relevant data point: the Fedora folks have been working for a while on atomic workstation, now Team Silverblue. It uses OSTree for atomic updates/downgrades. You pretty much boot in an OS version, similarly to FreeBSD boot environments (of course, the implementation is very different). The idea is to use Flatpak for installing applications, though you can still layer RPMs with rpm-ostree.

            Although it is probably not a solution for a tech user’s desktop. It seems interesting for the ‘average’ user in that it provides updates that don’t fail when yanking out the plug in the middle of an update and offers rollbacks. The OS itself is immutable (which protects against certain kinds of malware) and applications are sandboxed in by Flatpak.

            ZFS is nice - RAID-like resilience, LVM-like convenience, and filesystem snapshotting for history/“undo” for the same amount of admin effort it would take to set up one of those things on Linux

            Ubuntu also supports ZFS out of the box. With some work, you can also do ZFS on root.

            but the biggest feature of BSD for me is more of an anti-feature: they just don’t keep randomly breaking everything.

            I think this is the biggest selling point for BSD. I have given up on Ubuntu for my personal machines a long time ago. Stuff breaks all the time and Ubuntu/Debian/etc. are so opaque that it takes a long time to get to the bottom of a problem. Arch Linux is a reasonable compromise, stuff breaks sometimes due to it being a rolling release, but at least it’s fairly clear where to look. Moreover, the turnaround time of submitting reports/patches upstream and trickling down to Arch is pretty short.

            But I would switch back to BSD in a heartbeat if there was good out-of-the-box support for amdgpu, Intel MKL, CUDA, etc. But apparently (haven’t verified) the Linux amdgpu tree has more lines of code than the OpenBSD kernel.

            1. 2

              I order to be able to easily undelete files I’ve setup zrepl to snapshot my system every 15 minutes. I have these snapshots expired after a while. In combination with boot environments this means I can mess with my system without having to worry about breaking it. I can simply reset it quickly and easily. This is very convenient.

            2. 1

              It’s been so long since I used it that it’s changed names, but TrueOS is the “I just want to have FreeBSD with a desktop and don’t want to learn how to edit kernel modules with vi” answer.

            1. 3

              The AutoAddDevices option is set to restore the old bahavior of handling the input devices (keyboard/mouse/…). Without this there is big chance that You will have to mess with hald(8) which is PITA.

              This is no longer needed. Xorg now has a devd(8) backend it can use to get informed about hotplugged devices instead of hald(8): https://lists.freebsd.org/pipermail/freebsd-x11/2017-March/018978.html That’s working fine for me, even without moused(8).

              1. 1

                Thank you for that information, I added UPDATE 1 to the post regarding that case.

                I also modified the original post to not confuse future readers.

              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. 1

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

                      1. 1

                        Can I ask a potentially ignorant question? Why would someone who’s not already using Subversion choose to run it at this point? What are some of its advantages over Git or Fossil or Mercurial?

                        1. 6

                          For software version control? Probably very little (especially as you included mercurial in the alternatives)

                          I think however, that SVN could be the basis of quite a good self-hostable blob/file storage system. WebDAV is a defined standard and accessible over HTTP and you get (auto-)versioning of assets for ‘free’.

                          1. 1

                            Why would Mercurial in particular stand out on this list? Are you extrapolating from your own experience? I don’t think there are complete and reliable global usage statistic about any of these systems, are there?

                            1. 2

                              On top of what stephenr says, Mercurial has an increasingly solid story for large assets from things like remotefilelog and other similar work from Facebook. That means I’d feel comfy using it for e.g. game asset tracking, at least to a point. Git is getting there too (specifically the work from Microsoft), but it’s a bit less mature at the moment.

                              1. 0

                                Git is not the easiest thing in the world to learn/use.

                                If you just day “why use svn when git exists” it’s easy: because svn is easier to learn and understand.

                                Mercurial muddies that because you get the benefits of dvcs with usability that’s pretty close to svn.

                                I’ve worked in the last few years with entire teams that used no vcs.

                                1. 1

                                  Yeah, very much agreed that hg hits a rather nice middle ground. Their UI design is great.

                                  Still, I don’t think we could infer anything from this about the actual number of users across the various vcs. Not sure though if I simply misunderstood what you meant.

                                  1. 1

                                    Oh I’m not at all claiming to have stats on actual usage.

                                    It was a hypothetical: if hg wasn’t an option, some developers will be more productive with svn than git.

                                  2. 1

                                    why use svn when git exists

                                    I think this sums it up well: https://sqlite.org/whynotgit.html

                                    Not about subversion in particular though, just a bash at git.

                                2. 1

                                  Are you referring to mod_dav_svn? The last time I tried it it was pretty unreliable. It often truncated files silently. That’s probably not Subversion’s fault. Apache HTTPd’s WebDAV support doesn’t seem to be in a great state.

                                  1. 1

                                    That’s the only subversion http server that I’m aware of.

                                    I suspect that post is about mod_dav - WebDAV into a regular file system directory.

                                    Mod_dav_svn provides WebDAV + Svn into a repo backend.

                                3. 4

                                  I know some game studios still run subversion, because of large art assets along side code, and the ability to check out specific subdirectories.

                                  1. 3

                                    SVN is still heavily used by companies that are not pure software dev shops yet still produce their own software, e.g. in the financial sector and manufacturing industry.

                                    I don’t think many people on lobsters still encounter SVN at their place of work, but that is due to lobster’s demographic rather than everyone on the planet migrating away from SVN. That is not the case. (Some people still use tools like ClearCase at work!)

                                    1. 2

                                      For something closer to my heart, LLVM’s official repository is still SVN.

                                  1. 1

                                    There’s a lot of conflation between ‘git’ and ‘github’ here.

                                    Point 3 is utterly bogus. If your needs are so specific, use git, not github.

                                    ‘Setting up a website for a project to use Git requires a lot more software, and a lot more work, than setting up a similar site with an integrated package like Fossil.’

                                    I run a git server at home. All I need is ssh. What’s ‘a lot of software’ about that?

                                    1. 4

                                      The part you quoted talks about providing a whole website for the project, not just repository access.

                                      Fossil seems to have a built-in web server, which provides access to the repository, tickets and wiki. The closest thing distributed with Git is GitWeb, which requires Perl and a web server speaking CGI. It only allows you to browse the repository. For anything else you need even more third-party software like Gitea for example.

                                      So setting up a whole website for a project using Git indeed…

                                      requires a lot more software, and a lot more work, than setting up a similar site with an integrated package like Fossil.

                                      1. 1

                                        Fair enough, but adding JIRA or something is simple enough. What the author is saying is: ‘I want fossil’, which is fine, but isn’t a good reason not to use git.

                                        1. 1

                                          cgit works fine. Often things aren’t packaged together on purpose within linux. This doesn’t mean you can only use gitweb. Also you can send patches over email if you choose. It’s not really fair to call it third party software since literally all of it including git is third party software.

                                        2. 1

                                          I agree with you about the conflation between git and Github. Github doesn’t play very well with cmd line git. you can’t send/receive patches for example. For lots of people git == Github, they are interchangeable, you and I know differently.

                                          like @seschwar said, you seem to have missed the first part of the sentence, “website for a project”. This requires more than ssh and git. Fossil is a statically linked binary that includes it all. And with the fossil ui command you get the entire website and all functionality locally as well, and it will all seamlessly sync with as many other copies of the repo as you want, the server is not special in any way, except that it exists at a safe, well-known address and becomes the main published repo.

                                        1. 6

                                          Can someone explain a reason you’d want to see the descendants of a commit?

                                          1. 7

                                            Following history. Code archeology.

                                            Many people use the VCS history as a form of documentation for the project.

                                            1. 4

                                              But history is the past… you can always see the past in git…

                                              1. 16

                                                Suppose I’ve isolated an issue to this bug fix commit. In what version of gRPC did that commit release?

                                                Github tells you it’s on the v1.8.x branch, so if you head over to the, v1.8.x branch, you can see it landed after v1.8.5, so it must have released in v1.8.6. Easy enough right?

                                                Well that’s not the whole story. That commit was also cherry-picked over to the v1.9.x branch here, because v1.9.x was branched before the bug was fixed.

                                                Besides, that was silly to begin with. Why did you go to the v1.8.x branch and then manually search for it. Why couldn’t it just tell you when it got merged? That would have been nice.

                                                Many projects maintain many release branches. Some just backport bug fixes to older releases, some have more significant changes. Sometimes a bug fix only applies to a range of older releases. Do you want to track all that with no notion of descendants? It’s not fun.

                                                Even just looking at pull requests, it would be nice to see whether a pull request eventually got merged in or not, what release it got merged into, and so on. That’s all history too.

                                                So no, you can’t always see the past in git. You can only see the direct lineage of your current branch.

                                                1. 3

                                                  I used to find this hella handy at Fog Creek, especially for quickly answering which bug fixes were in which custom branch for some particular client. We actually made a little GUI out of it, it was so helpful.

                                                  (Interestingly, while Kiln supports that in Git too, it at least used to do so by cheating: it looked up the Mercurial SHAs in the Harmony conversion table, asked Mercurial for the descendants, and then converted those commits back to their Git equivalents. Because Harmony is now turned off, I assume either they’ve changed how this works, or no longer ship the Electric DAG, but it was cool at the time.)

                                                  1. 2

                                                    Why couldn’t it just tell you when it got merged?

                                                    I don’t know why GitHub doesn’t, but Git can:

                                                    $ git tag --contains b15024d6a1537c69fc446601559a89dc8b84cf6f

                                                    That doesn’t address the cherry-picking case though. I’m not aware of any built-in tooling for that. Generally Git avoids relying on metadata for things that can be inferred from the data (with file renames being the poster child of the principle), so I’m not surprised that cherry-picks like this aren’t tracked directly. Theoretically they could be inferred (i.e. it’s “just” a matter of someone building the tooling), but I’m not sure that’s doable with a practical amount of computation. (There are other operations Git elects not to try to be fast at (the poster child being blame), but many of them still end up not being impractically slow to use.)

                                                    1. 1

                                                      Does Fossil track cherry-picks like this though? So that they’d show up as descendants? In git the cherry-picked commit technically has nothing to do with the original, but maybe Fossil does this better. (It’s always bothered me that git doesn’t track stuff like this - Mercurial has Changeset Evolution which has always looked suuuuper nice to me.)

                                                      1. 4

                                                        According to the fossil merge docs, cherry pick is just a flag on merge, so I imagine it does. I was just highlighting the utility of viewing commit descendants.

                                                        1. 7

                                                          Mercurial also tracks grafts (what git calls a cherry-pick) in the commit metadata.

                                                          1. 5

                                                            This is actually illustrative of the main reason I dislike mercurial. In git there are a gajillion low level commands to manipulate commits. But that’s all it is, commits. Give me a desired end state, and I can get there one way or another. But with mercurial there’s all this different stuff, and you need python plugins and config files for python plugins in order to do what you need to do. I feel like git rewards me for understanding the system and mercurial rewards me for understanding the plugin ecosystem.

                                                            Maybe I’m off base, but “you need this plugin” has always turned me away from tools. To me it sounds like “this tool isn’t flexible enough to do what you want to do.”

                                                            1. 7

                                                              Huh? What did I say that needs a plugin? The graft metadata is part of the commit, in the so-called “extras” field.

                                                              I can find all the commits that are origins for grafts in the repo with the following command:

                                                              $ hg log -r "origin()"

                                                              And all the commits that are destinations for grafts:

                                                              $ hg log -r "destination()"

                                                              This uses a core mercurial feature called “revsets” to expose this normally hidden metadata to the user.

                                                              1. 2

                                                                Right but how much manipulation of grafts can you do without a plugin? I assume you can do all the basic things like create them, list them, but what if I wanted to restructure them in some way? Can you do arbitrary restructuring without plugins?

                                                                Like this “extras” field, how much stuff goes in that? And how much of it do I have to know about if I want to restructure my repository without breaking it? Is it enough that I need a plugin to make sure I don’t break anything?

                                                                In fairness, I haven’t looked at mercurial much since 2015. Back then the answer was either “we don’t rewrite history” or “you can do that with this plugin.”

                                                                But I want to rewrite history. I want to mix and blend stuff I have in my local repo however I want before I ultimately squash away the mess I’ve created into the commit I’ll actually push. That’s crazy useful to me. Apparently you can do it with mercurial—with an extension called queues.

                                                                I’m okay with limited behavior on the upstream server, that’s fine. I just want to treat my working copy as my working copy and not a perfect clone of the central authority. For example, I don’t mind using svn at all, because with git-svn I can do all the stuff I would normally do and push it up to svn when I’m done. No problem.

                                                                And I admit that I’m not exactly the common case. Which is why I doubt mercurial will ever support me: mercurial is a version control system, not a repository editor.

                                                                1. 12

                                                                  For the past several years, as well as in the current release, you still have to enable an extension (or up to two) to edit history. To get the equivalent of Git, you would need the following two lines in ~/.hgrc or %APPDATA%\Mercurial.ini:


                                                                  These correspond to turning on rebase and rebase -i, respectively. But that’s it; nothing to install, just two features to enable. I believe this was the same back in 2015, but I’d have to double-check; certainly these two extensions are all you’ve wanted for a long time, and have shipped with Hg for a long time.

                                                                  That said, that’s genuinely, truly it. Grafts aren’t something different from other commits; they’re just commits with some data. Git actually does the same thing, IIRC, and also stores them in the extra fields of a commit. I’m not near a computer, but git show —raw <commit sha> should show a field called something like Cherry-Pick for a cherry-picked commit, for example, and will also explicitly expose and show you the author versus committer in its raw form. That’s the same thing going on here in Mercurial.

                                                                  And having taught people Git since 2008, oh boy am I glad those two extra settings are required. I have as recently as two months ago had to ask everyone to please let me sit in silence while I tried to undo the result of someone new to Git doing a rebase that picked up some commits twice and others that shouldn’t have gone out, and then pushing to production. In Mercurial, the default commands do not allow you to shoot your foot off; that situation couldn’t have happened. And for experienced users, who I’ve noticed tend to already have elaborate .gitconfigs anyway, asking you to add two lines to a config file before using the danger tools really oughtn’t be that onerous. (And I know you’re up for that, because you mention using git-svn later in this thread, which is definitely not something that Just Works in two seconds with your average Subversion repository.)

                                                                  It’s fine if you want to rewrite history. Mercurial does and has let you do that for a very long time. It does not let you do so without adding up to three lines to one configuration file one time. You and I can disagree on whether it should require you to do that, but the idea that these three lines are somehow The Reason Not to Use Mercurial has always struck me as genuinely bizarre.

                                                                  1. 5

                                                                    Right but how much manipulation of grafts can you do without a plugin?

                                                                    A graft isn’t a separate type of object in Mercurial. It’s a built-in command (not a extension or plugin), which creates a regular commit annotated with some meta-data recording whence it came from. After the commit was created it can be dealt with like any other commit.

                                                                    And how much of it do I have to know about if I want to restructure my repository without breaking it?

                                                                    Nothing. Mercurial isn’t Git. You don’t need to know the implementation inside-out before you’re able to use it effectively. Should you need to accomplish low level tasks you can use Mercurial’s API, which like in most properly designed software hides implementation details.

                                                                    But I want to rewrite history. (…) Apparently you can do it with mercurial—with an extension called queues.

                                                                    The Mercurial Queues extension is for managing patches on top a repository. For history editing you should use the histedit and rebase extensions instead.

                                                                    I just want to treat my working copy as my working copy and not a perfect clone of the central authority.

                                                                    Mercurial is a DVCS. It lets you do exactly that. Have you run into any issues where Mercurial prevented you from doing things to your local copy?

                                                                    For example, I don’t mind using svn at all, because with git-svn I can do all the stuff I would normally do and push it up to svn when I’m done.

                                                                    Mercurial also has several ways to interact with Subversion repositories.

                                                                    mercurial is a version control system, not a repository editor.

                                                                    Indeed it is. And the former is what most users (maybe not you) actually want. Not the latter.

                                                                    1. 2

                                                                      Mercurial’s “Phases” and “Changeset Evolution” may be of interest to you, then.

                                                                      1. 6

                                                                        It’s also worth noting that mercurial’s extension system is there for advanced, built-in features like history editing. Out of the box, git exposes rebase, which is fine, but that does expose a huge potential footgun to an inexperienced user.

                                                                        The Mercurial developers decided to make advanced features like history editing opt-in. However, these features are still part of core mercurial and are developed and tested as such. This includes commands like “hg rebase” and “hg histedit” (which is similar to git’s “rebase -i”).

                                                                        The expectation is that you will want to customize mercurial a bit for your needs and desires. And as a tool that manages text files, it expects you to be ok with managing text files for configuration and customization. You might think that needing to customize a tool you use every day to get the most out of it to be onerous, but the reward mercurial gets with this approach is that new and inexperienced users avoid confusion and breakage from possibly dangerous operations like history editing.

                                                                        Some experimental features (like changeset evolution, narrow clones and sparse clones) are only available as externally developed extensions. Some, like changset evolution, are pretty commonly used, however I think the mercurial devs have done a good job recently of trying to upstream as much useful stuff that’s out there in the ecosystem into core mercurial itself. Changset evolution is being integrated right now and will be a built-in feature in a few releases (hopefully).

                                                    1. 9

                                                      This problem could potentially be used to feed process-controlled data to all tools relying on reading /proc/<pid>/stat using the recommended method (which includes several monitoring tools).

                                                      This was also a problem for sudo.

                                                      1. 8

                                                        This really is an apples to oranges comparison - and it didn’t have to be. Yes, you can tunnel ports with ssh (oranges).. but you can also do full on (layer 1, layer2) Virtual Private Networking (apples)!

                                                        From the ssh(1) man page:

                                                        SSH-BASED VIRTUAL PRIVATE NETWORKS
                                                             ssh contains support for Virtual Private Network (VPN) tunnelling using
                                                             the tun(4) network pseudo-device, allowing two networks to be joined
                                                             securely.  The sshd_config(5) configuration option PermitTunnel controls
                                                             whether the server supports this, and at what level (layer 2 or 3
                                                             The following example would connect client network with
                                                             remote network using a point-to-point connection from
                                                    to, provided that the SSH server running on the gateway
                                                             to the remote network, at, allows it.
                                                             On the client:
                                                                   # ssh -f -w 0:1 true
                                                                   # ifconfig tun0 netmask
                                                                   # route add
                                                             On the server:
                                                                   # ifconfig tun1 netmask
                                                                   # route add
                                                             Client access may be more finely tuned via the /root/.ssh/authorized_keys
                                                             file (see below) and the PermitRootLogin server option.  The following
                                                             entry would permit connections on tun(4) device 1 from user “jane” and on
                                                             tun device 2 from user “john”, if PermitRootLogin is set to
                                                               tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
                                                               tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john
                                                             Since an SSH-based setup entails a fair amount of overhead, it may be
                                                             more suited to temporary setups, such as for wireless VPNs.  More
                                                             permanent VPNs are better provided by tools such as ipsecctl(8) and
                                                        1. 1

                                                          Isn’t simple tunneling over SSH prone to TCP-over-TCP issues? Something like sshuttle would avoid these, as should OpenVPN over UDP.

                                                        1. 9

                                                          I use them to guess at impact of some of my comments. Popularity of specific comments also gives me a feel for what people in this community accept, reject, or find contentious. That’s been useful in adapting style or content to the audience. Sometimes the votes also give me WTH reactions or show no activity in ways I don’t learn anything from. I shrug and move on.

                                                          Now, I could see an optional feature in profiles for people like you that hides the scores of comments. If you turn it on, you don’t see them. I also thought back on HN about something similar for names to force elimination of unconscious bias when reading comments.

                                                          1. 5

                                                            The way I understood @mordae they weren’t proposing to hide the score of comments. These do serve a useful function, as you explain. Instead their idea was to not sum these comment (and story) scores up and display them when logged in (own score at the top right) or at user profiles.

                                                            I actually like that comments are not anonymized. It allows me to get to know users a little over time and therefore better understand the context of their comments. That way it’s possible to understand why they are saying what they are saying without them having to explicitly state that in every single comment.

                                                            1. 2

                                                              If my concept, the anonymization would have a feature to expose users’ identity. Just let you respond unbiased or semibiased before doing that if you chose. I agree with you on benefits of it not being anonymous.

                                                              1. 3

                                                                I, and maybe other crustaceans often search in the comments for security related articles for nickpsecurity though, so anonymity would be to your detriment :)
                                                                Our views on politics differ, but I don’t read many of the political stories on lobsters, or I just ignore the comments. I’d like to think most of us are mature enough to not hold a grudge and down vote every comment from a user. Who knows, maybe that kind of grudge behaviour is automatically detected already?

                                                                1. 2

                                                                  Very kind of you, Sir! :) Yeah, I don’t let politics get in the way of good, tech discussion with interesting people. That’s childish. I also keep an eye out for specific people. The idea I had when I looked into doing that anonymously was to put them on a whitelist that highlights whatever the automatic alias is when it’s someone on the list. You can always do something to reveal the person but knowing it’s one you follow in general or for specific tags might be enough.

                                                                  “ I’d like to think most of us are mature enough to not hold a grudge and down vote every comment from a user. “

                                                                  There was at least one case here in the past. I don’t think it happens much, My tool was more for people voluntarily removing bias from reading or replying rather than just downvotes. It was a general thing I was looking into instead of just for Lobsters.

                                                          1. 2

                                                            How would you write a path that points to a file called ‘..’ in a directory called dir?

                                                            You don’t. The ‘..’ is an implicit hard link and you cannot override it with a link to anything else.

                                                            Is there a system that allows directory and file names to overlap?

                                                            1. 4

                                                              The author writes:

                                                              Yes, then you need to escape dots: dir/\.\.. Sigh. And there even are multiple ways to do that. dir/\.., for example. Bigger sigh.

                                                              I really wonder where they got the idea for backslash-escaping ., .. and /. That simply doesn’t work.

                                                            1. 16

                                                              This article is so confused it actually made me wonder if I might have missed some important information about paths all these years, which could have caused that…

                                                              If /directory/file points to a file called file in a directory called directory, where does /directory//file point? Is it a file called file in a directory called directory/? Is it a file called /file in a directory called directory?

                                                              / isn’t allowed to be part of a filename.

                                                              It turns out this is implementation-specific.

                                                              Only the treatment of // at the beginning of the path is implementation specific.

                                                              Luckily, most of the time multiple slashes are to be treated as a single slash.

                                                              The pathname resolution is covered by POSIX.

                                                              / is a path that points to the root directory, whatever that means.

                                                              As explained in the link above it’s the root directory of the current process, which indeed might not be the same for all processes.

                                                              Escaping / (and other characters) is usually done with a backslash (\) character.

                                                              As mentioned above / isn’t allowed to be a part of a filename. Even if you precede it by \ it is still not part of the filename, but always treated as a path separator. Thus dir\/file refers to a file called file located in a directory called dir\.

                                                              What does ‘/.’ mean?

                                                              The link above states that “[t]he special filename dot shall refer to the directory specified by its predecessor.” And since / refers to the root directory of the process, so does /.. POSIX doesn’t have a concept of file extensions.

                                                              Never mind that not every user need necessarily have a home directory or that the concept of a ‘user’ may not even exist!

                                                              The second link refers to the Wikipedia page for unikernels. I don’t see what a unikernel has to do with a critique POSIX concepts like files or users. It doesn’t implement any of them and therefore is irrelevant in a discussion about them.

                                                              This means that whenever paths are passed as arguments in a list of arguments that is separated by spaces, spaces need to be escaped.

                                                              That’s not an issue with paths themselves, but with how shells treat whitespace. For example there’s no need to escape whitespace when passing paths with C’s execve().

                                                              rm won’t let you remove a symlink to a directory if there’s a slash at the end

                                                              That is because the trailing slash causes the path to be resolved to the target of the symlink, which is a directory, which rm doesn’t remove unless -r, -R or -d (some implementations) is specified. Compare the output of stat my-symlink-to-a-directory and stat my-symlink-to-a-directory/.

                                                              1. 2

                                                                As it turns out, the concept of paths is not unique to POSIX systems.

                                                                1. 3

                                                                  All of these complaints seem to be aimed at specific implementations of that concept, not the idea itself.

                                                                  The implementation in question quite clearly being POSIX

                                                                  1. 1

                                                                    He’s discussing different peculiarities and incompatibilities between different implementations, one of them being POSIX. He mentions many attributes not relevant to POSIX so I would say it’s clear he’s not only discussing POSIX.

                                                              1. 30

                                                                It’s been a pleasure orchestrating this hand-off with both of you, @pushcx and @jcs.

                                                                If any of your experience performance degradation or see any error messages please feel free to reach out. I expect we’ll do some performance tuning as we subject the server to it’s normal load. For reporting slowness, I would also be helped to see a traceroute from your location.

                                                                1. 13

                                                                  Congratulations on a smooth migration!

                                                                  1. 4

                                                                    Thanks for your work. Did the favicon go missing?

                                                                    1. 5

                                                                      They did, yes. Some quirk of the deployment is copying the files into a nested subdir. I’ve manually fixed them for now and we’ll keep debugging.

                                                                      EDIT: This is fixed now.

                                                                      1. 1

                                                                        I can access favicon.ico. Does that link work for you?

                                                                        EDIT: I was seeing a cached entry.

                                                                    1. 9

                                                                      A few other methods:

                                                                      libetc is a LD_PRELOAD-able library, which intercepts opening of dotfiles under $HOME and opens them from $XDG_CONFIG_HOME instead.

                                                                      rewritefs is a FUSE filesystem which lets you configure rewriting of paths similar to Apache HTTPd’s mod_rewrite. You can configure it to perform a mapping of $HOME/.* to $XDG_CONFIG_HOME/* as well.

                                                                      1. 3

                                                                        The description from libetc reads as follows:

                                                                        “On my system I had way too much dotfiles […] For easier maintenance I wrote libetc.”

                                                                        Really, why should I care? They do not pop up during ls, they will be backuped like all other files and the most important ones live in a git repo. LDPRELOADing a lib just to have a clean $HOME seems a lot like being a Unix Hipster. Or maybe I am getting just old…

                                                                      1. 1

                                                                        “FreeBSD continues to defy the rumors of its demise.” That’s a strange opening statement, or did I miss something?

                                                                        1. 2

                                                                          It’s a reference to the long standing BSD is dying joke.

                                                                          1. 3

                                                                            “OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let’s see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts. “

                                                                            Oh wow. This kind of mathematical analysis on determining number of users/systems could get whoever wrote that a job at RIAA.

                                                                            1. 2

                                                                              Fewer than I would have guessed. Thin ice.

                                                                            2. 1

                                                                              Ha! Shows how much I know… Funny though.

                                                                          1. 4

                                                                            This is by the author of Synth who was kicked out of the FreeBSD ports community in a storm of controversy. While I don’t know anything about Ravenports I wish this effort would be spent on making Nix more universal. Or at least implementing Nix in something other than a hot mess of C++ code. And I hate manifest files, why can’t the package manager figure that out for me on install!??!

                                                                            1. 3

                                                                              I guess this is John’s way to make Nix more universal :) Developing dports and retiring pkgsrc moved DragonFly a big step forward.

                                                                              1. 1

                                                                                Would you have any links to the discussion(s) surrounding the switch from pkgsrc to dports? I’m curious about the details.

                                                                              2. 2

                                                                                Wait, what?! I just knew him as a long-time dports maintainer in DFly, had no idea he had since been kicked out of the FreeBSD ports. I guess I missed another layer of controversy in *BSD!

                                                                                For how relatively small all the *BSD projects are, and being all volunteer-based effort, it’s quite amazing how often folks get ‘fired’ from the various projects. Curious — does it happen in the Linux world as often?!

                                                                              1. 2

                                                                                Looking at the solutions for corrupted_text I see I’m not the only one who solved it the easy way. :)

                                                                                1. 1

                                                                                  I just now realized the like to the PostScript version is the wrong one. Here’s the actual link.

                                                                                  1. 4

                                                                                    Zstandard is also being added to ZFS in FreeBSD and will make its way to upstream OpenZFS from there.