1. 3

    This got me wondering about fd which I’d heard about recently, and sure enough the README for it has: https://github.com/sharkdp/fd#integration-with-other-programs :-)

    1. 2

      Yes, I noticed that in some of the examples in the README too. I’ve been too quick to rush through docs like this in the past, and I’m enjoying paying more attention and also thinking more about things.

    1. 3

      I miss working with Sun hardware. They were things of beauty and care and really good design.

      I had a bunch of the V245’s predecessors, the V240s (as well as V210, V490 and probably some others I’m forgetting), which were purple-fronted. That purple front pulled down to reveal the drive bays and the key slot for locking the machine on or off. The lid was hinged in such a way that you could lift just the front few inches to access the intake fan array and hot-swap them. Lifting the entire lid off revealed a very well layed out machine. Everything was in its right place, easy to access, with a diagram of how to remove covering parts or screws to access things.

      In contrast I often found HP ProLiant machines a cramped and tangled mess.

      Working on Sun machines was much like working on Apple machines. The software and hardware were in pretty good harmony. Lights-out access was great (especially compared to HP ILO, which requires a license).

      A couple of servers we had were similar to this V245 - the T2000 - which we also installed graphics cards in (because my boss was weird and insisted that the management servers could be used as local desktops in the DC if necessary), so we had the full CDE experience locally on a server :-)

      1. 2

        One of my first career jobs started as working on the Sun hardware you described doing hardware maintenance. Drive and PSU swaps, memory/CPU replacements, etc. I always liked working on them, the colors and design gave them personality and always looked cool lined up in racks in data centers.

        There are some days I miss that type of work; getting the morning email with failures, checking in-house stock and putting in warranty claims to get parts we didn’t have on hand, then driving around the rest of the day to the different DCs doing the repairs. Wasn’t exciting or really challenging, but made me appreciate how much work goes into keeping the hardware layer online.

        1. 2

          Sun servers were always nice to work with. The clear lime green tabs on everything made it easy to work out what your were supposed to lift/press.

          While I’ve mostly got experience with the cheaper X2100 and X2200s (x86), I also got to play with the nicer T5120 and T5240 SPARC servers. They were beauties and a joy compared to SuperMicro servers and to a lesser extend Fujitsu.

          1. 1

            and to a lesser extend Fujitsu.

            Which is actually kinda funny because some of Sun’s servers were rebranded Fujitsu machines. The M-series were all Fujitsu (you could buy the same server as Sun-branded or Fujitsu-branded) and were just as nice to work with and had hot-swappable everything.

        1. 9

          This exact problem had plagued me for so long and it is so annoying. It was pretty much the final straw that made me move back to MacPorts.

          1. 6

            Similar issues are what sent me to nix.

            1. 2

              100% Agreed regarding Nix!

              My current home setup is Nix for everything & MacPorts for things I can’t get on Nix yet.

              1. 2

                I’ve been experimenting with Nix too. It’s nice, although port is so simple to use, whereas nix-env feels clunky/complicated in a very rpm way and the Nix language is… not straightforward :-)

                1. 2

                  Yeah, nix-env is super clunky. I never use it unless I have to. I’ve got everything built declaratively. Nix the language definitely takes a minute to onboard, agreed.

                  1. 1

                    Last time I try it, I got oom.

              2. 3

                Agreed! There a lot of good things about MacPorts.

                1. 1

                  Why did you migrate to Homebrew in the first place?

                  1. 9

                    Good question, and one to which I don’t really remember the answer. I’ve been using MacOS since 10.3 and had tried both Fink and MacPorts in the early days. My vague memory of both in the early days was they were fairly clunky, but Homebrew just worked.

                    Homebrew has since morphed into this huge, slow thing that has become pretty annoying to use, whereas MacPorts now feels fast and slick in comparison.

                    1. 4

                      Yeah. It feels like with this and other changes made over the last few years, Homebrew is coming close to falling off the back of the package manager treadmill.

                      Homebrew in its early days was good because it was lightweight, fast (for (as it was then) a package manager that could only build from source, at least), didn’t try to do stuff that was too clever, and also acquired a fairly nice and large package library fairly quickly thanks, I think, to a relaxed contribution policy that didn’t require individuals to take complete responsibility for packages. (I don’t know if Max Howell explicitly realized that keeping a package manager up to date with new versions of packages would be something a whole user community could do together if it were made easy enough, or if it just happened to work out like that, but in any case it did work very well in practice.)

                      Now it insists on automatically refreshing the package index every. time. I. do. anything. which makes startup slow, and is also doing this too-clever-by-half thing of trying to work out which packages I actually wanted to install and which just came along for the ride as dependencies. (Which isn’t how humans work: if one day I type ffmpeg and it happens to be there, it’s not necessarily clear to me that I only have it because I installed get_iplayer and it brought ffmpeg along, rather than having installed it myself explicitly on some now-forgotten date in the past. Computers have a far better memory for why things are installed than humans do, and humans will always get confused when things change because of implicit rules based on the computer’s perfect recall.) Meanwhile it’s also got stupider in some other ways, such as no longer being able to do builds from source with custom ./configure options etc.

                      I have similar memories of MacPorts being a pain to use, but who knows? It’s been ten years or something now. Maybe it’s worth another look.

                    2. 3

                      I’ve been a FreeBSD user for a while so MacPorts always fit better for me. If my memory is correct, Homebrew had an initial learning curve that was shallower than the curve for MacPorts back in the day.

                  1. 6

                    I’m really intrigued by these devices. I’ve heard a lot of good things about them, but the thing that’s putting me off is that you seem to have to use their cloud service to sync PDFs and notes, and the hand-written stuff seems to use a proprietary format.

                    There’s also a reviewer on YouTube called “My Deep Guide” who loves the rM2 but he has some valid criticisms of the software not being as good as the hardware, especially compared to competitors.

                    1. 4

                      I’ve refused to connect my device to their cloud and have had no problem - it is a bit unfortunate that this means losing the handwriting recognition, but everything else I care about works just fine.

                      You can sync files over usb, the remarkable pretends to be a network adapter and serves a webpage on 10.11.99.1 which you can drag files onto/off of. I’ve also sshed into the device and created a script to back it up with restic (just a normal piece of backup software, not remarkable specific) ;)

                      The hand written notes format is proprietary, but it’s simple and has been reverse engineered. It’s not hard to export the notes to another format.

                      I’d generally recommend it, as long as you understand it as “paper + pdfs printed onto paper + bare bones linux” and not anything more.

                      1. 2

                        This section is titled “jailbreak,” which is actually a bit of misnomer because the reMarkable runs Linux and you can ssh into it with ease.

                        1. 3

                          I’m not sure how that really makes it a more usable device. Instead of being able to plug it in with a USB cable and sync files as a removable drive, I have to put it on the network and use a non-standard feature?

                          1. 3

                            You can plug in a USB cable, it just shows up as a network interface instead of as a storage device. It’s probably not the most usable option, but it does make it easier to see and interact with the device as a computer instead of as a fancy flash drive.

                            1. 3

                              When you connect a reMarkable to your computer via USB, the computer sees a USB network adapter. Then use DHCP or set an IP manually for that adapter. Usually the reMarkable will use 10.11.99.1 for itself and 10.11.99.2 for “your side”.

                              So even when you use USB, you can ssh into it.

                              1. 1

                                I would check out the Awesome list, specifically the APIs and Cloud Tools sections. I also use scp fairly often to just grab the files directly, or even export them using the app.

                                I’ll check out “My Deep Guide,” I haven’t really read many reviews of the device myself. I’m also not really aware of any competitors?

                          1. 2

                            It’s great to see a modern example of someone configuring jails (with the new jail.conf format).

                            I was fiddling with a jail host yesterday and getting frustrated with Bastille because its docs are quite unclear.

                            My hunch is most of the jail admin tools were created before the jail.conf format existed and jail creation relied on rc.conf knobs etc. Now I suppose they exist to template jail.conf files, set up networking, and many of them also manage ZFS datasets. Maybe using a configuration management tool would be better, although sadly FreeBSD isn’t a well-supported platform by most.

                              1. 1

                                Thank you! It’s been a while since I tried to understand the vnet bits with jails, and had I found this guide then it would have been really helpful.

                              2. 3

                                Most of the jail admin tools are about doing things like keeping the base system up to date, managing packages, and so on. They’re probably overkill if you just want a VPS. I’d love to see decent tooling in the base system for:

                                • Installing a minimal jail
                                • Keeping it up to date
                                • Installing packages without needing all of the pkg infrastructure inside the jail (pkg -J currently just jexecs pkg in the jail, I’d like it to run outside the jail and just jexec any post-install scripts if necessary).
                                • Automatically configuring firewalls / NAT (IPv4 and IPv6).

                                You can’t boot a FreeBSD base system with /etc in a separate filesystem to the root, because it needs to be able to read /etc to be able to mount other filesystems, but to be really useful for container / jail deployments to have all of the defaults moved out of /etc and so /etc would not be part of the base system image at all. /etc, /usr/home, /usr/local and /var would be separate read-write ZFS datasets and all jails could share a read-only mount of a ZFS filesystem as a base image. This is something that’s been discussed a lot over the last decade but never implemented.

                              1. 10

                                I’m not really sure I understand the complaint. They seem to be complaining about GitHub as it’s always been (pre-Microsoft) but using their dislike of Microsoft to add some spice.

                                1. 1

                                  But only for code, not for commit messages I assume? Or is there a good argument for limiting commit messages to 80 columns too? It’s enforced at my job but I can’t think of any good reason for it.

                                  1. 3

                                    Absolutely:

                                    From Linus:

                                    https://github.com/torvalds/subsurface-for-dirk/blob/a48494d2fbed58c751e9b7e8fbff88582f9b2d02/README#L88

                                    Another good explanation:

                                    https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

                                    TLDR: If you use git in a terminal, viewing logs of properly formatted messages is much nicer.

                                    1. 3

                                      I do see that both offer advice to manually wrap the text within less than 80 characters, but in both cases the only reason given is “it looks nice with git log”.

                                      When I git log in the terminal (macOS), commit message bodies that are not manually wrapped are auto-wrapped within the window bounds, albeit per character and not per word, which I consider a limitation of the terminal and not of the rule of thumb.

                                      GUI tools such as Tower properly wrap commit message bodies per word, like any other prose.

                                      1. 2
                                        1. 2

                                          Thanks for that link!

                                          And the tool you use to visualize things cannot know.

                                          I would argue that tools know how to wrap common prose very well. Text editors have done this for at least 30 years.

                                          However:

                                          Some things should not be word-wrapped.

                                          What if a (part of a) message is not common prose? For code, you’ll manually wrap it to never go outside the screen width, so auto-wrapping should never affect code. Indeed, Linus refers to:

                                          They may be some kind of quoted text - long compiler error messages, oops reports, whatever.

                                          If I understand correctly he says that having automatic word wrap is not nice when a quote is better left in a single long line and you want it to go off-screen, typically a log message. I can see how in this exceptional case you don’t want to your tool to auto-wrap.

                                          However this is an argument to not uniformly enforce an 80 character limit.

                                          With any kind of enforcing, you’d need to make exceptions for these log lines. Perhaps by allowing markdown and making an exception for code blocks? But if you want to go that far, I would argue it would be equally involved to look for a message viewer/editor that knows how to exempt certain annotated lines from auto-wrapping instead.

                                          Taking Linus’ points into account, so far I would conclude that enforcing an 80 character limit on commit messages is never a good idea:

                                          • If a message is common prose, any tool can properly auto-wrap it.
                                          • If a message is not common prose, it is either:
                                            • Code, which we want to manually format to never reach the screen limit so auto-wrapping should never affect it,
                                            • A special case where a line needs to extend beyond the screen limit. If we want to account for this, we need to invest in more advanced tooling anyway because a fixed 80 character limit won’t work. In this case we get a higher benefits by configuring a message viewer that knows how to make an exception for these long lines and auto-wrap the rest.
                                          1. 1

                                            So yeah, as Linus says:

                                            Sure, the alternative would be to have commit messages be some non-pure-textual format (html or similar). But no, that’s not how git does things.

                                            You are basically arguing for markdown or “non-pure-textual format”, which is reasonable. The point is, hard wrapping and a 72 column limit is still the best option given that git is pure text, and that this is unlikely to change.

                                            With any kind of enforcing, you’d need to make exceptions for these log lines.

                                            Yes, this is annoying. It’s a wart of the pure text solution. But the alternative (throwing out line length standards for commit messages) is worse imo.

                                            Also, note that offloading soft-wrapping to editors or terminals is not as well supported as you’d think. While every editor/terminal can soft-wrap at the window’s right margin, most cannot soft-wrap at a specific column width. For example, in a full-screen window in nvim or Terminal, I can’t (afaik) make it soft-wrap at 80 columns. So if I don’t want to read long horizontal lines, I am forced to resize the window itself to make the not-hard-broken lines readable. This sucks.

                                            1. 1

                                              Wouldn’t you agree that given pure text, the following holds for any (part of a) message:

                                              • If it is common prose, any tool can properly auto-wrap it. EDIT: except for cases like suspending vim after working in a multi-column layout or maybe working in a fullscreen terminal window but still wanting an 80-character limit.
                                              • If it is not common prose, it is either:
                                                • Code, which we want to manually format to never reach the screen limit so auto-wrapping should never affect it, or
                                                • A special case where a line needs to extend beyond the screen limit. With pure text there no solution to accommodate this and auto-enforce an 80-character line limit.

                                              So I would conclude that the only reasons to enforce a manual / hard-wrapped 80-character width for commit message bodies, the subject line is different, are rather exceptional scenarios where the tool setup does not (always) support auto-wrapping prose to a desired line length.

                                              The latter may well be an argument to keep this rule, but I think it might be worth doing a poll of how many people within the organization actually use tooling that have this limitation.

                                              1. 1

                                                If it is common prose, any tool can properly auto-wrap it. EDIT: except for cases like suspending vim after working in a multi-column layout or maybe working in a fullscreen terminal window but still wanting an 80-character limit.

                                                This is the incorrect assumption imo. The problem is that soft-wrapping, as a feature, is typically coupled to window width.

                                                As I noted in my last response, vim cannot soft wrap at a specified column length – only at the the window’s edge. Thus I can only “properly auto-wrap” by controlling window (or buffer) size, which is an unacceptable proposition. The bad case is not limited to suspending a split-window vim and dropping back into terminal (though that’s a good example). It includes closing one of my vertically split-window buffers so that the remaining buffer now fills the screen, or resizing my window for other reasons, changing my columns-per-character when I change font size, and on and on.

                                                Mac Terminal itself (afaik) similarly lacks a configuration for soft-wrapping at a column width (regardless of window width). I don’t know about iTerm, but I suspect the lack of this feature is the norm rather than the exception in most tools and editors.

                                                A special case where a line needs to extend beyond the screen limit. With pure text there no solution to accommodate this and auto-enforce an 80-character line limit.

                                                Agreed. And it’s a problem because if you want the 80-char rule, it’s a lot better to enforce it at the CI level. I would be in favor of a simple GH action, say, that does enforce it and allows some simple escape hatch like surrounding the exceptional lines by --- or a # linecheck-disable comment or some such. It wouldn’t be hard to write one. Of course we’ve now broken “pure text” and introduced our own (albeit tiny) markup language. But “lesser of evils” is the best we’re going to get here, I think.

                                                The latter may well be an argument to keep this rule, but I think it might be worth doing a poll of how many people within the organization actually use tooling that have this limitation.

                                                I think this affects almost everyone who prefers reading prose at reasonable widths and also uses full-width windows sometimes.

                                                As a side note (not saying this is an issue for you), the hard-wrapping requirement is hardly an inconvenience if you have a hotkey for doing it in your editor. It would be quite annoying otherwise.

                                                1. 3

                                                  This is the incorrect assumption imo. The problem is that soft-wrapping, as a feature, is typically coupled to window width.

                                                  As I noted in my last response, vim cannot soft wrap at a specified column length – only at the the window’s edge.

                                                  Maybe this is getting a bit off-topic, but this has annoyed me for years. There is no good modal editor for prose (that I know of) and this is one of the problems of using Vim/Neovim for normal writing. People try to hack around it with plugins like goyo that create a lot of empty buffers around your document, but that has limitations.

                                                  Not that I have time to work on it, but every now and then I get the urge start writing a new editor from scratch for this purpose.

                                    2. 2

                                      I believe I’ve heard the argument that if you need more space to describe what you changed, you should break it into smaller commits.

                                      1. 1

                                        typical style for commit messages (in git) is a subject line of up to 50 characters, then a blank line, then a multi-line description no more than 72 columns wide.

                                        1. 2

                                          Do you have any argumentation for why you wouldn’t want commit messages to be word-wrapped automatically by the tool you are using to view or edit them?

                                          1. 3

                                            A short subject line (50ish) allows viewing and skimming commits, one per line to see what has been done.

                                            1. 1

                                              That’s a good point for subject lines. I’m not sure if there would be an easy way to enforce a size on the first line only…

                                            2. 2

                                              nearly every UI that displays a list of commits will have a layout that is optimized for subject lines of 50 chars or less. Beyond that, whether the first line will be trimmed or wrapped (and at what position it will be trimmed/wrapped) will vary substantially from client to client. The web views in github and bitbucket work very consistently when this rule is followed, but not as consistently when it isn’t. git log --pretty=oneline also benefits tremendously from this rule of thumb since every line also includes the full commit hash, which is 40 chars wide.

                                              1. 1

                                                Thanks for these pointers. Indeed for the subject line a limited line length seems very useful.

                                                This does not answer the question why the body of the commit message should be hard-wrapped at 80 lines as well though.

                                                Again, I can imagine that it is hard develop a git hook to consistently enforce that only the subject line has a limited length. But although I may be missing edge cases, it doesn’t sound impossible either.

                                                1. 2

                                                  git log will indent all lines with 4 spaces. when it softwraps because the terminal isn’t wide enough, the wrapped lines wind up unindented. If you have any line breaks at all, you’ll wind up with mixed indentation levels.

                                                  a pre-commit hook is still opt-in and client side, so it’s not really enforceable if you’re using some sort of star topology like github/gitlab/bitbucket/etc, which is how the majority of projects and teams use git. Most providers of git servers don’t permit custom pre-receive hooks, since you’d have to allow the execution of arbitrary code. For github, it’s an enterprise feature. Rejecting PR’s in CI is pretty common but generally toolsets expect that rejected PR’s get updated and eventually merged, not deleted entirely. You can rewrite history in PR’s in most toolsets but the experience is often lackluster.

                                                  1. 1

                                                    That is a good point, if your commit message relies on indentation, auto-wrapping will not work for it. However as far as I can see, typical prose will not depend on indentation, right?

                                                    A pre-commit hook backed by a blocking CI rule is what we use now to enforce the 80 character limit, this seems to work pretty well so far. Indeed rewriting history is the common approach here. As far as I have experienced, github PRs deal with that pretty well.

                                              2. 1

                                                Pretty much for the reason Daniel gave in the post: humans typically struggle with long lines. If I run git show on a commit and my terminal happens to be quite wide, git won’t reflow the text for me (and nor should it). Hard breaks in the commit message mean that everyone reads the commit message the same way.

                                                1. 1

                                                  That’s interesting, so there are scenarios where you have a wide terminal window but you don’t want wide lines? Wouldn’t it be more convenient to size the terminal window to the width of your personal preference and have the lines adapt?

                                                  1. 1

                                                    so there are scenarios where you have a wide terminal window but you don’t want wide lines?

                                                    Yes. I typically have the terminal wide so that, for e.g. in vim I can have a vertical split with two files open side by side.

                                                    Wouldn’t it be more convenient to size the terminal window to the width of your personal preference and have the lines adapt?

                                                    For some cases, yes: e.g. when scanning through log files I’d prefer it to wrap (journalctl’s default of chopping rather than wrapping is maybe the most annoying thing), but for my use-case above I really do want a wide terminal with two (or more) files open with narrower text; but when I suspend vim to commit changes or review commits, I don’t want the commit messages filling the entire width of the terminal. I just can’t read long lines easily like that.

                                                    1. 1

                                                      in vim I can have a vertical split with two files open side by side.

                                                      But wouldn’t vim be able to wrap lines for every individual column in this case?

                                                      1. 2

                                                        Yes, but:

                                                        I suspend vim to commit changes or review commits, I don’t want the commit messages filling the entire width of the terminal.

                                                        And sticking to a relatively fixed line length means as I add or remove splits, the code isn’t reflowed, so I remain looking at the same things and don’t lose context or focus by having to figure out where things moved in a reflow.

                                                        1. 1

                                                          I see, so we can conclude that there are certain scenarios in which (a specific use case of) the tooling is not able to auto-wrap prose reliably.

                                                          1. 1

                                                            I think it’s fairer to say there are cases I’d prefer not to need tooling to auto-wrap. Not just prose; prose and code.

                                                            1. 2

                                                              That’s indeed a better way to put it, thanks for refining.

                                          1. 2

                                            Not working. I haven’t taken enough downtime this year. As someone new to WFH it’s even harder to switch off, and the pandemic putting a halt on travel has made me forget that I should still take time off work.

                                            I’m going to try and catch up on some of my book backlogs (technical and non-technical). I recently acquired A Philosophy of Software Design and so far it’s an interesting read.

                                            1. 10

                                              devops should have installed some kind of error tracking

                                              This reads as if there is a team called “devops”?

                                              DevOps is a practice or principle - so an extra learning you could take away here is that as a dev you could try and work more closely with ops to ensure things like proper monitoring of your own systems are in place. Don’t assume that an ops team will magically know what to monitor!

                                              1. 7

                                                At most places there is such a team.

                                                1. 7

                                                  And every time I see one I cry a little… It’s good if a company wants to follow DevOps practices but having a centralised team is often a smell they’re not actually doing it well.

                                                  1. 3

                                                    I think it’s connected to metrics for compliance instead of enlightenment.

                                              1. 3

                                                I remember trying BeOS in ~1999/2000, around the same time as I’d started toying with Linux and FreeBSD. My desktop machine at the time was this Frankenbeast that I’d gradually cobbled together and at one point it had a whopping 1.1GB of RAM. (Why 1.1? I’d acquired two 512MB sticks and had a 128MB leftover, so thought, why not?)

                                                When I tried installing BeOS on that machine, it’d panic on boot. I asked on a mailing list, and it turned out I had too much RAM. Dropping below 1GB made it work. It was a lovely OS to use - very slick interface compared to Windows and GNOME of the day. Alas, the lack of software (and all that RAM going to waste in a drawer) meant I didn’t use it for very long.

                                                1. 4

                                                  One I find useful for Linux (or any system that uses X Windows) is xpaste. For example:

                                                  ls -l | xpaste
                                                  

                                                  will copy the output of ls -l to the X windows primary selection (-s for the secondary selection, and -c for the clipboard selection). I wrote the opposite, xselect, to obtain the selection from from the command line. You might think “why? Isn’t that what the middle button, or ^C is for?” Because X allows multiple selections. I have a fragment of a web page highlighted in Firefox, and from there, I can select the following for as the selection:

                                                  • TIMESTAMP
                                                  • TARGETS (this list)
                                                  • MULTIPLE
                                                  • text/html
                                                  • text/_moz_htmlcontext
                                                  • text/_moz_htmlinfo
                                                  • UTF8_STRING
                                                  • COMPOUND_TEXT
                                                  • TEXT
                                                  • STRING
                                                  • text/x-moz-url

                                                  I don’t use them often, but when I need to, I’m glad they exist.

                                                  1. 5

                                                    xpaste

                                                    There’s also xclip for piping stuff into selections and out of them.

                                                    1. 3

                                                      There are three on OPENSTEP / macOS that are great and now have X / XDG equivalents:

                                                      • open (xdg-open) opens a file with the default association. Great for popping into a graphical editor. It’s also really useful to do open . to open the current directory in a graphical file browser if you need to do some tasks that are easier in the GUI than the command line.
                                                      • pbcopy and pbpaste (xpaste, not sure if there’s an xcopy?), to transfer data between the standard in/out streams and the pasteboard. Somewhat depressingly for 2020, the simplest way of copying a short file between two machines if often pbcopy < {file} locally and then cat > file command-V on the remote one.
                                                      1. 1

                                                        Really? You might want to check out rsync, it comes with your PC.

                                                        1. 3

                                                          I don’t have rsync installed on most of the machines I access, but I could do scp. That requires another connection and copying the target path though, whereas pbcopy in one terminal and cat in another, when I have both open already, doesn’t require any new SSH handshakes and is very fast.

                                                          1. 1

                                                            The problem with rsync (or scp) is if you are forced to go through a management server first. Especially if you are working from home. Right now, to get to some of the servers at work, I have to ssh from my local computer (at home) to my computer at work, from there ssh to a management server, then ssh to the server itself.

                                                            1. 2

                                                              If you’re using rsync over SSH this is solveable using ProxyJump. In your ssh_config(5) you can do:

                                                              Host management-server
                                                                ProxyJump office-computer
                                                              
                                                              Host target-server
                                                                ProxyJump management-server
                                                              

                                                              Then from your local computer if you ssh target-server it will follow all those jumps. The same goes for rsync as it just execs ssh. (Or you can rsync -e "ssh -J ProxyJump office-computer,management-server".)

                                                              1. 1

                                                                Is there a technical term for the type of management server you mentioned? I’d like to learn more.

                                                                1. 2

                                                                  I know it by the term “management server,” but it’s really “only server within a datacenter that allows people to log in from outside said network. [1]” There’s no production service on said server, it’s just there to let us access the rest of the production servers.

                                                                  That said, I’m in development, not devops, so I only go on said servers when absolutely necessary (usually to help test a new deployment). It’s rare that I have to copy a file to or from a production server, but when I do (pull down some critical data files to generate some stats from them [2]), I have to copy the files to the management server first.

                                                                  [1] Said management server has a few interfaces, all on private IP addresses, and only one interface forwarded to our office network.

                                                                  [2] I think I’ve done that three times in the past decade. Like I said, it’s not very often.

                                                        1. 2

                                                          Cap’n Proto, Users:

                                                          • Cloudflare
                                                          1. 2

                                                            Added, thank you!

                                                            1. 1

                                                              Somewhat. I’m only aware of a couple of things using CapnP. There are probably more services using gRPC (protobuf).

                                                            1. 26

                                                              If you use squash, you don’t have to literally squash your whole changeset into a single commit. You can use squash in conjunction with the interactive rebase to maintain meaningful history without spammy commits like ‘fix typo’, ‘fix compile error’, etc.

                                                              E.g. you wrote a feature, committed, then wrote a test, commited. you end up with

                                                              -1 feature (changes to src/code.py)
                                                               0 test    (changes to tests/test.py) (HEAD)
                                                              

                                                              Then, say, you run a linter/code formatting tool/whatever – you ended up with changes to both files. What’s the right thing to do?

                                                              Personally, I’d use interactive staging (add -p) to stage the changes to src/code.py and tests/test.py separately and commit separately too:

                                                              -3 feature (changes to src/code.py)
                                                              -2 test    (changes to tests/test.py)
                                                              -1 fix src/code.py
                                                               0 fix tests/test.py (HEAD)
                                                              

                                                              , then I’d use interactive rebase to reorder as -3, -1, -2, 0 and squash together -3 + -1; -2 + 0, which results in a nice atomic history:

                                                              -1 feature (changes to src/code.py)
                                                               0 test    (changes to tests/test.py) (HEAD)
                                                              

                                                              Another neat rebase trick you could use is to reorder the test commit and feature commit:

                                                              -1 test    (changes to tests/test.py)
                                                               0 feature (changes to src/code.py) (HEAD)
                                                              

                                                              , and checkout HEAD~1 and run the test to ensure it actually fails without the feature commit.

                                                              1. 3

                                                                I used to do it just as you describe, and then I discovered git commit --fixup <SHA>. With your example this becomes:

                                                                git add -p src/code.py
                                                                git commit --fixup <SHA of -3>
                                                                git add -p tests/test.py
                                                                git commit --fixup <SHA of -2>
                                                                git rebase --autosquash -i <SHA of -3>^
                                                                

                                                                This saves me having to put the commits to squash in the right order in the interactive rebase.

                                                                1. 1

                                                                  You may enjoy using git-absorb which automatically finds the SHA hash for --fixup commits.

                                                                  1. 1

                                                                    Seems interesting, but the description doesn’t make it clear how it works so it seems a bit too “magic”. What does it do if you have multiple commits touching the same file(s)?

                                                                    1. 1

                                                                      It doesn’t just look at the file, but actual changes (since you first git add [-p] all the changes you want to absorb). I believe it just picks the most recent commit touching the same change set. I haven’t needed to use it when the commit I’m wanting to fixup is multiple commits back on the same change set (which I believe would conflict and need a manual rebase anyways).

                                                              1. 3

                                                                I’ve taken the week off work. This is my first break all year.

                                                                I might look at some personal projects that haven’t been touched for a while, but mostly I don’t want to be sat in front of a computer else I might as well still be working.

                                                                1. 3

                                                                  You deserve it, 2020 has been a lot

                                                                1. 20

                                                                  Category 5 is cheaper, but can only support speeds of 100 Mbps. Category 6 is slightly more expensive but you will need it to get full gigabit speeds.

                                                                  This isn’t entirely correct: cat5 is only rated for 100Mbps, but cat5e will do 1Gbps just fine and is significantly cheaper than cat6a and more flexible.

                                                                  This is a pretty good read on the differences between cat5e/cat6.

                                                                  1. 7

                                                                    While YMMV, I agree here and offer my experience. My house was built and wired in 1998 just before the change over from cat 5 to cat 5e. I did an addition in 2003 with cat 5e. I run gigabit on a mix of both of those cable types with no problem. I figure that there are two reasons for this. First, as the wikipedia article says, most cat 5 cable actually meets cat 5e specifications even though it wasn’t tested that way. Second, with regard to bandwidth, drop length matters at least as much as the cable you use. My longest drop might be 35 meters. My average drop is probably just under 10 meters. At those lengths, it was a good bet to replace my 100Mb/s switches with Gigabit swtiches and cross my fingers/keep the receipts.

                                                                    1. 5

                                                                      My house was built in the early 90s, probably just after they switched from installing 4-wire copper phone cables to installing Category 3 cables instead. However, these Category 3 cables still support gigabit speeds without issue (I use it every day with our symmetric 300 Mbps Internet connection), despite being stapled to the struts.

                                                                      I’m not saying all Cat 3 will do this, just that some cables do indeed meet higher specifications, per above.

                                                                      1. 3

                                                                        My desktop currently speaks 10GbaseT to my main switch via ~20ft of cat5 (not e). And the other end is a 10GbaseT SFP+ adapter which only claims 30 meters over cat6, vs the 10GbaseT standard 100 meters.

                                                                      2. 2

                                                                        However if you plan to use Type3/4 PoE devices, the thicker wire gauges found in Cat6/6a/7 are recommended.

                                                                      1. 9

                                                                        Great list of tips!

                                                                        cmd+shift+4 pops up a crosshair to take a screenshot of a region.

                                                                        And pressing space after cmd+shift+4 lets you screenshot a particular window.

                                                                        And since 10.14 (I think) taking a screenshot now gives you a little preview in the bottom-right of the display which delays it writing to a file. If you just want it to write the file and skip the preview, cmd+shift+5 gives you an Options menu where you can disable “Show floating thumbnail”.

                                                                        1. 11

                                                                          Don’t miss the fact that ⇧⌘5 can also do screen recordings, with or without audio. Previously you had to run QuickTime Player and find it in the menu.

                                                                          1. 5

                                                                            Pressing control along with either of those just copies the image to the clipboard, ready for pasting!

                                                                            1. 1

                                                                              The nice thing about that floating thumbnail is that you can drag & drop it like a real file. Sometimes I’m screen shotting just to share with someone in chat, and that dragging that thumbnail over means I can send images without ever having them written to disk.

                                                                              1. 2

                                                                                Mentioned in the other comment but yeah– pressing control along with wither hotkey just copies to clipboard inmediately which I’ve found to bw the best path for this usecase. Then I’m able to just Cmd + V in the target.

                                                                                1. 2

                                                                                  On Catalina (not sure about previous versions), you can also hit cmd + shift + 5 and select the clipboard as the default destination. Then you won’t need to add control for screenshots to go to the clipboard.

                                                                            1. 3

                                                                              Hey, author of the post here! Really happy to see it on Lobsters, and I’d be happy to answer any questions and/or comments you have!

                                                                              I encountered this “bug” while working on rewriting my iOS app with the new App and Scene structures introduced during WWDC2020. The project is nearing completion, and I’m really excited about how its turning out.

                                                                              Enjoy!

                                                                              1. 12

                                                                                Unfortunately not related to the content, but for me the font choice made the post too difficult to read.

                                                                                1. 3

                                                                                  Understandable. I was attempting to make it “retro,” though I’m going to change the font when I rewrite the site (soon) to make it clearer and load faster.

                                                                                  1. 2

                                                                                    I agree with you. Try using Reader View if your browser supports it. It’s much better.

                                                                                    1. 2

                                                                                      Pictures/videos also don’t work in Safari 14.

                                                                                      1. 1

                                                                                        Yeah, they’re in .webm which for some reason is not supported by Safari despite massive size reductions from mp4. Going to need to add mp4s.

                                                                                    2. 3

                                                                                      Nice post! Happens to all of us :-)

                                                                                      That’s what you get for populating static items in a list. I’m a little confused about the sorting (or whether it works as needed):

                                                                                      • Completed tasks are at the bottom. Ongoing tasks are at the top.
                                                                                      • Higher priority items are at the top of their category (completed/ongoing).
                                                                                      • After above two points, ordering is done ascending, by task name.

                                                                                      The above statements sound nice, but:

                                                                                      • the UI fails to show important (high prio) tasks
                                                                                      • sorting by name is not visible, as the point above. Looking at the videos your provided, it appears sorting is random (although it may not be)

                                                                                      I’m not an Apple user, but I would enjoy having a task list with the following features:

                                                                                      • Priority items clearly marked (color/“hotness” or font weight)
                                                                                      • Completed tasks with a “greyed out”/“disabled” state (the strikethrough helps)
                                                                                      • Sorting based on the timestamp when the item was created/modified/completed
                                                                                      1. 1

                                                                                        Thank you for the great suggestions!

                                                                                        Some clarifications about sorting:

                                                                                        • The exclamation marks on the trailing side are supposed to be the main indicator of priority, which I understand might be too small of an indicator.
                                                                                        • The “ascending task name sort” is just a fancy way of saying alphabetical order. Because it’s the third priority it may seem a little random, but what it does is sort all tasks of the same priority and the same category (completed/ongoing) in alphabetical order.

                                                                                        Feature suggestions:

                                                                                        • I love the idea of color/weight indicators for priority! Definitely going to implement that going forward.
                                                                                        • Completed tasks are grayed out in addition to the strikethrough in the main app, I’ve just yet to implement it in the rewrite.
                                                                                        • The timestamp sort would be an important thing, but a big feature of the app is that tasks get deleted at midnight every day so that would be a really short-term thing. I will consider adding it as an additional sort method, though.
                                                                                    1. 5

                                                                                      This is quite similar to the approach I take, so it’s good to see others doing similar. I also use the git add -p approach to force myself to review each change so I can make note of the “why” in the commit message - or perhaps omit a hunk to put into a separate commit.

                                                                                      I tend to write commit messages for “future me”. Sure I’ll remember the context of the change for the next few days, perhaps a week or a month, but after that I’m guaranteed to have fogotten exactly why I did a thing, so I try and document the “why”. It’s not uncommon for me to write a commit message that’s two or three paragraphs for a one-line change.

                                                                                      1. 2

                                                                                        Is there no mode that would share the physical network port but tag all IPMI traffic with a VLAN you configure?

                                                                                        1. 6

                                                                                          Many HPE servers have a dedicated network ports for the iLO card but can also optionally share one of the regular network ports if needed. When in shared mode, you can indeed configure a VLAN tag for the management traffic, which can be different to the VLAN tag used by the host operating system normally.

                                                                                          1. 1

                                                                                            Unfortunately, in the same way that chris explained that a any compromised host might be able to switch the device IPMI mode from dedicated to shared, using a VLAN for segregation can have a similar problem. If the compromised host adds a sub-interface with the tagged VLAN to their networking stack they now can gain network access to the entire IPMI VLAN.

                                                                                            1. 2

                                                                                              In addition there are other annoyance with using a shared interface. Because the OS has control of the NIC it can reset the PHY. If the PHY is interrupted while, for example, you’re connected over Serial over LAN or a virtual KVM, you lose access. If you’re lucky, that’s temporary. If you’re really unlucky the OS can continually reset the PHY making IPMI access unusable. A malicious actor could abuse this to lock out someone from remote management.

                                                                                              That can’t happen when you use a dedicated interface for IPMI (other than explicit IPMI commands sent over /dev/ipmi0). Generally switching a BMC from dedicated mode to shared mode requires a BIOS/UEFI configuration change and a server reset.

                                                                                              (Speaking from experience with shared mode and the OS resetting the NIC. The malicious actor is merely a scenario I just dreamt up.)

                                                                                              1. 1

                                                                                                Indeed, although I suspect in many cases these IPMI modules are already accessible from the compromised host over SMBus/SMIC or direct serial interfaces anyway - possibly even with more privileged access than over the network. That’s how iLOs and DRACs can have their network and user/group settings configured from the operating system.

                                                                                                1. 4

                                                                                                  The increased risk mostly isn’t to the compromised host’s own IPMI; as you note, that’s more or less under the control of the attacker once they compromise the host (although network access might allow password extraction attacks and so on). The big risk is to all of the other IPMIs on the IPMI VLAN, which would let an attacker compromise their hosts in turn. Even if an attacker doesn’t compromise the hosts, network access to an IPMI often allows all sorts of things you won’t like, such as discovering your IPMI management passwords and accounts (which are probably common across your fleet).

                                                                                                  (I’m the author of the linked to article.)

                                                                                                  1. 3

                                                                                                    The L2 feature you are looking for is called a protected port. This should be available on any managed switch, but I’ll link to the cisco documentation:

                                                                                                    https://www.cisco.com/en/US/docs/switches/lan/catalyst3850/software/release/3.2_0_se/multibook/configuration_guide/b_consolidated_config_guide_3850_chapter_011101.html

                                                                                                    1. 1

                                                                                                      In a previous life at a large hosting we used this feature on switch ports that were connected to servers for the purposes of using our managed backup services.

                                                                                          1. 3

                                                                                            This explains why I was taught to do “sync; sync; halt” in the late 80s, and still encouraged to do this in the late 90s at my first sysadmin job.

                                                                                            I’ve always wondered when and why this was no longer needed.

                                                                                            1. 3

                                                                                              I started a Solaris sysadmin job in 2008 and was being taught “sync; sync; sync; halt” as late as that! My colleagues knew that you’re supposed to type each one out to let buffers flush, rather than all on one line, but it’s interesting that these old habits really do die hard.

                                                                                              (Prior to that job I’d only worked with Linuxen and BSDs.)