[12:05] <jrwren> Oct 28 07:59:44 delays kernel: [1198951.317775] Uhhuh. NMI received for unknown reason 31 on CPU 4.
[12:06] <jrwren> Oct 28 07:59:44 delays kernel: [1198951.317777] Do you have a strange power saving mode enabled?
[12:06] <jrwren> Oct 28 07:59:44 delays kernel: [1198951.317778] Dazed and confused, but trying to continue
[12:06] <jrwren> before I noticed those were from kernel, I thought I'd been hacked and someone was using write
[12:06] <cmaloney> heh
[14:44] <greg-g> Weird
[14:49] <jrwren> https://duckduckgo.com/?q=NMI+received+for+unknown+reason+31&t=osx&ia=web  i guess it is common enough
[14:49] <jrwren> great messages though, lul
[15:38] <jrwren> greg-g: congrats on ditching gerrit ;)
[15:38] <greg-g> :) :)
[15:42] <cmaloney> Never used Gerrit, so don't have opinions on it, but curious what the tool does since I haven't used it.
[15:42] <cmaloney> https://www.gerritcodereview.com/ is a good start, but not really seeing the power of it yet.
[15:43] <cmaloney> Though I'm getting the feeling that the major issuw with Gerrit is being a Google product and the benevolent neglect therein.
[15:45] <greg-g> we had a whole huge consultation about it: https://www.mediawiki.org/wiki/GitLab_consultation
[15:45] <greg-g> discussion: https://www.mediawiki.org/wiki/Talk:GitLab_consultation
[15:45] <greg-g> summary of that huge talk page: https://www.mediawiki.org/wiki/GitLab_consultation/Discussion_summary
[15:45] <greg-g> tl;drs at the top :)
[15:47] <greg-g> really, gerrit is truer to git mechanics than github/gitlab. In fact, pretty much everything in Gerrit is stored in Git (not mysql).
[15:48] <greg-g> but, it's intractable for new users
[15:49] <jrwren> Gerrit is not bad... but it just isn't as nice for most things as GH PRs are.
[15:49] <jrwren> I used Gerrit to great success and just fine at spacemonkey.
[15:50] <jrwren> but yeah, what greg-g said.  not easy for new users... but really any dev, even a junior should be up to speed on it in mere minutes. It is just a tiny learning curve.
[15:50] <jrwren> but it is never as beautiful.
[15:51] <greg-g> yup
[16:11] <cmaloney> ah, ok
[16:12] <cmaloney> kinda like sourcehut and it's "user interface"
[16:55] <jrwren> hahahahaha Hirsute Hippo
[20:30] <jrwren> is there a faster tool to use for splitting files than dd bs=1 skip=<offset> ?
[20:31] <cmaloney> making floppies? :)
[20:32] <jrwren> actually... kinda almost :)
[20:32] <jrwren> I've got an MSI that is built by appending a CAB. I'd like to split it back out ot have just hte cab.
[20:32] <cmaloney> I haven't looked into the problem long enough to understand if there's a better way
[20:32] <jrwren> the opposite of cat 1 2 > 3, when I know the offset of 2
[20:33] <cmaloney> The only other command I've used for dd like things is pv and that doesn't seem to have a skip
[20:34] <jrwren> isn't that just a display tool?
[20:34] <cmaloney> in some cases yes
[20:35] <_stink_> not sure i follow what you're trying to do - what about split?  i use that to split big tarballs into segments for uploading to cloud storage.
[20:35] <jrwren> i couldn't see an option in split to say only split once.
[20:35] <_stink_> ahaa
[20:35] <jrwren> basically, I have a 1.6MB file. I want to throw away the first 300k
[20:37] <jrwren> dd works fine, but dd bs=1 is DIRT SLOW. a more specialized tool would be much nicer.
[20:37] <jrwren> hell, i could write one in a few minutes.
[20:37] <jrwren> cut -b might work the same.
[20:43] <jrwren> oh, well, still no good solution, but it isnt' concatenated the way I thought anyway.
[20:55] <cmaloney> jrwren: could you bump up the bs?
[21:01] <jrwren> skip skips blocks.
[21:10] <cmaloney> ah
[21:10] <cmaloney> so it needs to be 1 byte blocks
[21:10] <cmaloney> which is going to be slow with dd
[21:11] <jrwren> yup.
[21:11] <jrwren> it is ok. i've moved on.