Makes me think of the time when I filed a bug report and discovered that I was quite possibly the Gentoo/sparc32 user. (I stopped using it shortly after).
What are the advantages of Mercurial over Git? I’ve never used Mercurial, but have seen a number of very enthusiastic users of it online. What about it inspires such a strong preference?
A specific thing that looks minor, but went from “neat toy” to “how did I do work without this” in a matter of months: https://selenic.com/hg/help/revsets
Some of those are minor (terms are easy-ish to relearn), and some are major (evolution was a significant productivity improvement for me when I worked it into my workflow about 3 years ago, and we’re on a good path towards working out the lingering problems and shipping it more broadly).
Then there’s some architectural decisions in the codebase. It matters less to typical end-users, but it’s made it feasible for Facebook to do some really neat work around lazy-loading file content, and for some related work that I’ve been doing elsewhere.
Off the cuff, mercurial does the job right, whereas git is a sea of hackery.
Whenever I collaborate with a junior-medium experienced git user, they screw up - regularly, repeatedly, and often, badly. This does not happen nearly to the same extent in HG.
Hmm, that’s reasonable I suppose, but the userspace emulation used instead in the patch that “solves” the problem in this post also looks like the sort of buggy thing I’d be uneasy about relying on for something I cared about (https://github.com/kardianos/osext/commit/b4814f465fb1f92d46e37f7ef84d732ece7c3e3a – manually searching $PATH for something with a matching name).
Without looking into it, I would assume Philip was working on something not really related to procfs but that required changes in that code, ran into problems, asked around and other developers agreed it was bad code and that it wouldn’t be missed. That’s usually how these things get tedu’d.
I don’t know the canonical way to do it on OpenBSD, but chances are that if we don’t have a clean way to do it, it’s because we haven’t had a need. Certainly we never had anything in our own tree that relied on doing it through procfs.
I don’t know the canonical way to do it on OpenBSD, but chances are that if we don’t have a clean way to do it, it’s because we haven’t had a need. Certainly we never had anything in our own tree that relied on doing it through procfs.
I can relate to that. I had the bad luck of hitting 2 pieces of software wanting to use procfs for the same reason (finding the current executable).
First one was dartlang and they do it just to know WHERE the SDK is installed which I think is more proper to do during packaging as it never changes post install.
The second piece of software was syncthing itself and I still would prefer to just tell it ‘this binary lives here’ versus having it use any system facility to find itself.
Ah, another victim of the ruthless pragmatism of OpenBSD. :)
My defense of procfs basically boils down to “Well, we had cool filesystems like proc in plan9 and wouldn’t it be great if we had more filesystems like in plan9 and oh god i wish we had all ended up with plan9”.
For the same reason, I always have mixed feelings about opting in to popularity contest when installing Debian. Maybe I’m the only user of that arcane window manager from the late 90’s!
Makes me think of the time when I filed a bug report and discovered that I was quite possibly the Gentoo/sparc32 user. (I stopped using it shortly after).
Because I don’t want to be an hg island in an ocean of git, I keep talking about hg long after most of my audience has left the building.
What are the advantages of Mercurial over Git? I’ve never used Mercurial, but have seen a number of very enthusiastic users of it online. What about it inspires such a strong preference?
It’s a variety of things, but in broad strokes (for me, anyway):
A specific thing that looks minor, but went from “neat toy” to “how did I do work without this” in a matter of months: https://selenic.com/hg/help/revsets
Some of those are minor (terms are easy-ish to relearn), and some are major (evolution was a significant productivity improvement for me when I worked it into my workflow about 3 years ago, and we’re on a good path towards working out the lingering problems and shipping it more broadly).
Then there’s some architectural decisions in the codebase. It matters less to typical end-users, but it’s made it feasible for Facebook to do some really neat work around lazy-loading file content, and for some related work that I’ve been doing elsewhere.
Off the cuff, mercurial does the job right, whereas git is a sea of hackery.
Whenever I collaborate with a junior-medium experienced git user, they screw up - regularly, repeatedly, and often, badly. This does not happen nearly to the same extent in HG.
I still need to rewrite this response for the Mercurial FAQ, because you just asked a FAQ:
https://news.ycombinator.com/item?id=9467188
Wait wait wait..if I read this correctly, was the
/procfilesystem removed from OpenBSD?Yes, it was buggy and AFAIK was only really used for linux binary emulation where programs would expect
/procto be there.Hmm, that’s reasonable I suppose, but the userspace emulation used instead in the patch that “solves” the problem in this post also looks like the sort of buggy thing I’d be uneasy about relying on for something I cared about (https://github.com/kardianos/osext/commit/b4814f465fb1f92d46e37f7ef84d732ece7c3e3a – manually searching $PATH for something with a matching name).
What was the philosophical justification for removing procfs?
Rather, what are the replacements/syscalls in openbsd?
Without looking into it, I would assume Philip was working on something not really related to
procfsbut that required changes in that code, ran into problems, asked around and other developers agreed it was bad code and that it wouldn’t be missed. That’s usually how these things get tedu’d.I don’t know the canonical way to do it on OpenBSD, but chances are that if we don’t have a clean way to do it, it’s because we haven’t had a need. Certainly we never had anything in our own tree that relied on doing it through
procfs.I can relate to that. I had the bad luck of hitting 2 pieces of software wanting to use procfs for the same reason (finding the current executable).
First one was dartlang and they do it just to know WHERE the SDK is installed which I think is more proper to do during packaging as it never changes post install.
The second piece of software was syncthing itself and I still would prefer to just tell it ‘this binary lives here’ versus having it use any system facility to find itself.
Other way around. What is the justification for keeping code which is clearly broken and therefore provably not being used?
Most of the information available via /proc can be accessed with sysctl() instead.
Ah, another victim of the ruthless pragmatism of OpenBSD. :)
My defense of procfs basically boils down to “Well, we had cool filesystems like proc in plan9 and wouldn’t it be great if we had more filesystems like in plan9 and oh god i wish we had all ended up with plan9”.
So, no really good defense, really. :|
Yes procfs was removed from OpenBSD in v5.7.
source: http://www.openbsd.org/plus57.html
For the same reason, I always have mixed feelings about opting in to
popularity contestwhen installing Debian. Maybe I’m the only user of that arcane window manager from the late 90’s!