Amitai Schleier
@schmonz@schmonz.com
If your business makes software, I might be good for your business.
Alt...
Whole Spelt K’nockers
@schmonz I, too, like to spell "spelled" as "spelt" to bait people into claiming that it's incorrectly spelled, even though it's a valid spelling in British English.
tick.
You're the only name in the log. (-:
https://git.parabola.nu/abslibre.git/tree/pcr/jdebp-redo
I'm just giving the packagers (those that I know about and are easily contactable, at any rate) a tap on the shoulder before the rest of the world explicitly learns that #redo 1.5 is up.
https://jdebp.uk/Softwares/redo/
(Po-Chuan Hsieh of #FreeBSD is still using a URL that has not worked since Brexit. 17 million people voted that I should not have my domain name. (-:)
#djbwares 10 is next.
My fault assuming the existence of a published 1.5 tarball meant it was fully cooked. (I also saw FreeBSD Ports using it, so my fault accepting social proof as sufficient, too.) But also it's generally troublesome for packagers when published tarballs change size/checksum/etc. in place. Better to not publish until the URL contents can be stable, and/or publish new changes under new URLs.
Also, I was surprised to see your build wanting to know how to generate its own binary package. I guess that's typical for Debian and others, but unusual for pkgsrc and I imagine other ports-style trees. No harm done, of course, but I've given pkgsrc that part of the job.
I'm curious how knowledge of the 1.5 source archive even reached any packagers.
That was not listed on the WWW pages at all but only on a GOPHER site that's explicitly for people to get bonus content such as access to in-development source, and comes with an explicit warning in the GOPHER menu.
The published source archives listed on the WWW, as well as the GitHub snapshot, were still at 1.4. I had only just ticked them over to 1.5 when I sent that nudge out. (-:
It has always been capable of building its own packages, by the way. (And since it's slashpackage, one can by design just package/compile it self-contained and not do the subsequent packaging step.)
https://jdebp.uk/FGA/slashpackage.html#OSPackaging
It's not a Debian thing. Quite the opposite. For a long time no-one packaged any of this at all, so I made packages for people myself. Even now, no-one at all packages djbwares and there is only one that packages nosh.
I think that you possibly hadn't noticed before because it wasn't NetBSD; but now I've ported all three of #redo, #djbwares, and #nosh to NetBSD (testing on a non-amd64 architecture, no less!), as you've probably seen over the past few months. So now there's a system for building #NetBSD packages alongside Debian's, FreeBSD's, and OpenBSD's.
I actually looked for contact details for Po-Chuan Hsieh, for the FreeBSD port, so that I could let xem know how messed up that port was; as I noted before. But there's only a wildly (a decade) out of date LinkedIn listing and an opaque FreeBSD account.
The Parabola packaging of redo is several versions out of date, and has the pre-pre-Brexit URLs. Arch is on 1.4 at least but using the pre-Brexit URLs.
I don't even know about Void, Hyperbola, et al.
![[?]](https://schmonz.com/snac/schmonz/s/506a4e5be3c4eba4d0539c833aea957a.jpg)
![[?]](https://media.cosocial.ca/accounts/avatars/112/751/474/529/026/003/original/ae24d7cc1676ebea.png)
![[?]](https://social.notqmail.org/notqmail/s/0d5728c5aea4d6c6a2405eb736aea730.png)
![[?]](https://cdn.masto.host/mastodongamedevplace/accounts/avatars/109/309/602/442/320/801/original/dc11889cd8710cff.png)
![[?]](https://cache.treehouse.systems/accounts/avatars/109/362/090/220/152/482/original/afdb73ac99388754.png)
![[?]](https://d35e9bfo1msux2.cloudfront.net/accounts/avatars/109/535/770/898/980/239/original/6841a27af2c37e48.png)
![[?]](https://social-coop-media.ams3.cdn.digitaloceanspaces.com/accounts/avatars/114/410/919/361/779/495/original/cd22eb60837819af.png)
debian/ packaging automation alongside code, but not accustomed to seeing upstreams ship BSD packaging automation. As a packager, my experience of pkg_create is indirect. Very cool that you wrestled it into submission. Have you seen folks use your supplemental BSD package repositories?(I intend in the fullness of time to package nosh, and to figure out what to do with djbwares -- possibly treat it as the new upstream for all its constituent packages. But @notqmail@social.notqmail.org is also in dire need of a fresh batch of my attention.)
You may have seen my request for better pkg_create doco. (-:
I don't track the logs, and the repositories were down for a long time as the machine hosting them vanished.
That said, when I brought them back up just recently, aside from all of the search engine spiders immediately jumping on there was one machine that stood out dutifully checking the Debian repository every day. It seems to belong to some kind of housing collective in #Tokyo. They are in for a surprise. (-:
@JdeBP Do you have any guidance (or a HOWTO) for how to begin to use #nosh as the init and service manager on a FreeBSD system from start to finish?
The last time I tried (FreeBSD 13.x), I never managed to get it working.
Having a canonical way to do it for the distributions/OSes that interest you might also help garner a following around nosh, redo et. al?
There is a fairly lengthy guide, in addition to the manual pages. It's on-line, as well as available packaged up and viewable off-line.
http://jdebp.info/Softwares/nosh/guide/
The package repository doco tries to explain the -run- packages.
http://jdebp.info/Softwares/nosh/freebsd-binary-packages.html
But what you probably want when 1.41 comes out is this:
http://jdebp.info/Softwares/nosh/timorous-admin-installation-how-to.html
(-:
I will be updating that latter before the 1.41 release, by the way. It dates from 2015. Some of the manual information has since expanded and been split out onto its own pages.
There might be short-term package problems because the build machine is fundamentally an old PC-BSD machine. I'm hoping to replace it with a new from-scratch up-to-date #GhostBSD on ZFS machine; but the plan is currently for that to happen, which will need to involve new hard discs, after the 1.41 release.
@JdeBP Thank you for the prompt reply!
I should probably have specified that I was trying to build nosh (and therefore redo) from source on FreeBSD with the aforementioned aborted attempt to get redo, nosh et al. working.
That's possibly a good approach with 1.41, until I sort out the #GhostBSD machine.
You can take the first step in trying it again, right now. #redo version 1.5 is out.
(Ignore the one in ports. Whoever is in charge of that hasn't made it past version 1.2 and is still using a WWW site that preceded the WWW site that I lost to Brexit half a decade ago.)
As you can see from package/debian/control it has a build dependency upon perl; but I think that that and base are all that you need.
I'm doing #djbwares 10 next; right now, in fact (although I need to make a trip to the shops).
When I put it out, that's a good intermediate step to try next. It will test that you have a working redo without being a massive build that builds hundreds of things (as is the case for nosh).
It has the same basic command workflow as for building redo. There's a new accompanying Guide that details building from source but there aren't any real surprises over building #redo.
You don't need to do anything with #djbwares 10. It's just exercising some of the building from source mechanisms that it shares with nosh without the massive source base.
You *can* try out things like the host command or
> sntpclock $IP | clockview
to see that you've built working executables, if so moved.
#nosh 1.41 itself is going to be a little while yet. I have a Debian KVT niggle to fix (It isn't disabling the kernel's cursor.) and some doco to review and update.
@JdeBP Thanks for the pointers.
My FreeBSD machine is pretty old, hasn't been turned on in a while, and probably needs a bunch of updates to be current.
Because it is using an AMD FX-8350 CPU, I also used to build everything from source to get a "free" +5-12% performance boost, using jmarino's `synth` tool. I don't know if that is still supported on newer FreeBSD versions, however.
In short, I have a bit of researching and updating to do before I can offer you the feedback you are asking for.
How old? I'm currently building on FreeBSD 10. Are you newer than that? Or older? If older, you should probably advance at least as far as 10, because there were some problems with pkg_ng in earlier versions. If newer, you might be alright as-is. (-:
@JdeBP Newer (13.x IIRC).
And I've apparently pulled out the SATA SSD it's installed on, so now I'm running around like a headless chicken trying to remember where I put it so I can re-install it in the box in which it belongs.
*Le sigh*
@JdeBP OK, found the SSD and got the bloody thing started. It's at 13.2 currently (with custom kernel build even). I can see it has _a_ redo installed to /usr/local/bin, but I can't see which version of redo it is (there's no --version argument).
Will give it a go now.
@JdeBP Got both redo-1.5 and djbwares-10 built as standalone executables (not FreeBSD packages). The examples you shared work.
If I run `bsd/rules clean build binary |& tee build.log`, I get the following error:
```
(...)
Building control file for leapsecs.
Building package djbwares-guide
pkg: manifest parsing error: error while parsing <unknown>: line: 40, column: 102 - 'numeric value out of range', character: '5'
*** Error code 1
Stop.
make: stopped in /usr/home/ermo/src/djbwares-10
```
Ah! The black art of pkg manifests.
Take a look at line 40 of bsd/djbwares-guide/+MANIFEST .
On my system column 102 is right in the middle of a sha256 of a file. For which the digit "5" being out of range is a bizarre error.
I'm guessing that the +MANIFEST is different on your system, which implies that there's something different about either sha256 or stat. What did they actually put into the file for you?
I was pointing out the poor state of the #pkgsrc doco in #NetBSD a little while ago. This is the area where #FreeBSD is equally bad with #pkgng.
FreeBSD's pkg-create(8) manual page assures us that +MANIFEST files must have "file" entries one per file. But the actual code for the pkg command only looks for a "files" object with an array of files.
Making manifest and "build-info" files for these tools is not a case of doing what the doco says to do.
https://github.com/freebsd/pkg/blob/main/libpkg/pkg_manifest.c#L114
@JdeBP As requested, line 40 of bsd/djbwares-guide/+MANIFEST looks like this on my system:
```
"/usr/local/share/doc/djbwares/commands/html/dnscache-showctl.html": { uname:root; gname:wheel; sum:56
3e64205b997125c75e8a051c8ea0949175381888cb39f7ae80d448af07d84a; perm:644; }
```
The best I can tell, column 102 is `:` right after `sum`.
HTH.
@JdeBP So just to confirm: I should redownload the djbwares-10 tarball from your site, and I will get the new version?
Do you by any chance host an up to date git repository anywhere public...?
Yes. At the moment, because it's unreleased, that's tracking development. I save a fresh archive every so often, and I have saved the changes that I just made for the packaging and ifconfig. There's a similar archive for djbwares 11, now, as that's where development now is. That has the same fix for the package control file generation, that I hope, sans any doco, will work.
I don't track development with git; only releases go into git.
@JdeBP Getting a similar failure:
```
Building package djbwares-guide
pkg: manifest parsing error: error while parsing <unknown>: line: 101, column: 94 - 'numeric value out of range', character: '7'
pkg: Error parsing bsd/djbwares-guide//+MANIFEST
*** Error code 1
```
Line 101 looks like this:
```
"/usr/local/share/doc/djbwares/commands/html/tcprules.html": { uname:root; name:wheel; sum:7202e7161b84571464069af4189a0d22f278c546d1c3e63510c5872bd6e00c72; perm:644; }
```
Column 94 is `:`.
There's a new djbwares-11.tar.gz file up that has a revised gencontrol script that quotes the checksum. I did the same fix to both softwares, and it works with the version of pkg that I have at any rate.
Version 11, though. 10 is released and frozen.
@JdeBP At this point, my thinking is that I can continue drip-feeding you current FreeBSD issues (and I'm happy to), or you could perhaps be convinced to do a basic, currently suppported FreeBSD 13.x or 14.x install and see which issues you are getting with your own eyes?
Again, happy to continue reporting issues. FWIW, neither djbwares-10 nor -11 successfully generate FreeBSD packages on my (now updated) 13.5 FreeBSD install.
LMK how you would like to proceed (if at all!).
What we're doing is fine. Whilst you've been running things, I've written several of the nosh Guide pages that were on the to-do list, and I'm attacking that Debian KVT bug that needed fixing.
You might enjoy the new guide/building-from-source.html chapter .
I'm fairly sure that you've either pulled the old djbwares-10 archive again, or we've not synched on the djbwares-11 one. Because that generated snippet you showed is not in the format that that file has now.
Alt...
A screenshot of a Z shell session in a terminal emulator, with a coloured prompt and running the sed and sha256 commands, to show (respectively) 1 line of a +MANIFEST file and the checksum of a .tar.gz archive file.
I'm fairly confident that the file format change, assuming that the 13 pkg is as happy with it as the 10 pkg is, will overcome the one remaining hurdle to package generation working. It has done all of the rest of the build process, by that point. (-:
Unfortunately, that #GhostBSD installation that I mentioned before will be a comparatively *huge* undertaking, and it seems to me that at this stage we're close to the point where the build problems that you had years ago are fixed.
@JdeBP I can build a FreeBSD package using the newest djbwares-11.tar.gz now, though not a freshly fetched djbwares-10.tar.gz -- 10 still fails for me on the +MANIFEST checksum parsing stuff (in case that is unexpected).
nosh-1.41 w/ sha256sum `17c982a1af29f476e401b8e8137a0503237b0aad5d46b8e2b8a5173891a5c640` fails to compile for me on 13.5 w/ clang 19.1.17:
https://gist.github.com/ermo/82be9beb5c5b79888a96bf590589bb6e
This is a different error to on 13.2, and might be caused by increased compiler strictness w/ 19.1.17?
Alt...
screenshot showing sha256sums for djbwares-10 and-11 FreeBSD tar.gz source archives
#djbwares 10 is always going to fail. What's going to happen is that I'll push 11 out soon with these fixes in.
This is good news, because I really wasn't planning on doing updated FreeBSD beyond FreeBSD 10 until *after* the #nosh 1.41 release. But now we've almost got things working for FreeBSD 13 before 1.41 gets released.
The u32string thing should be an easy fix, as it's a known change. It's a question of how bleeding edge one can be on older compilers, though. Let me test.
@JdeBP FWIW, I am happy to also check this on FreeBSD 14.x for nosh, djbwares and redo, should you find that useful.
I do think it would be wise to get all three softwares into the FreeBSD ports if at all possible, so if doing the miles here with you helps a kind soul plug things into the ports tree (on the assumption that I can help you demonstrate that the bsd packages build and work), that might go a long way towards lowering the barrier of entry for people to try out nosh etc.?
That may well be useful.
#redo version 1.2 (sic!) is in the #FreeBSD ports tree. I was just talking to @schmonz about the state of that port and how I have no real way to let the person behind it know that it's in very poor shape.
Neither #djbwares nor #nosh are in the FreeBSD ports tree. Presumably there are people working on ports, but that one of them was a decade ago an undergraduate on the other side of the planet shows the kind of barriers in place here.
It looks like the old compilers do not complain. I don't have a clang 19 system to test, but I it's well-known what the fix for this is and I've just put it into place.
So there's another 1.41 archive up, now.
@JdeBP It looks like the new nosh-1.41 version gets most of the way there now, even if it doesn't fully succeed:
https://gist.github.com/ermo/c8c7cf6218904cc431f6e8105a9bea0c
It has build almost everything apart from that 1 service, and that was just a missing list file, which I have now fixed and uploaded a fresh archive for.
You should get well into the package building part, now.
@JdeBP Looks like the latest nosh-1.41 FreeBSD pkg build completed.
Here's the build log, in case you spot something you would prefer to fix before releasing:
https://gist.github.com/ermo/2694d499c2803a2eccf745596c5c4ee9
Just the nullptrs in the FreeBSD-only code paths, and they won't change actual functionality.
It looks like everything has built.
Here are some fairly innocuous commands that you can try straightaway:
command/ifconfig -a
command/ps -Ad | unvis
command/printenv
command/console-decode-ecma48 --input
what command/*
I suggest not experimenting with any of the -run- stuff until you've looked at what commands and shims you want.
pkg info -F on the packages might help with that.
@JdeBP All of the `command/(...)` stuff appears to work.
Next step has to be to read the documentation to get a better feel for how to set up nosh on my system.
Thank you for the help in getting this sorted, and I hope it wasn't too much trouble. ^^'
No worries. This was stuff that I was going to have to do anyway, just a bit earlier than planned. And it is quite good that I can push 1.41 out and not have the prospect of people coming back straightaway saying that they couldn't build it on newer versions than my build machine, and having to keep explaining that a build machine upgrade was the next step.
Quite the opposite of trouble. (-:
I was writing Guide pages whilst you were doing things, and I still have 1 to write.
@JdeBP I can confirm that redo-1.5, djbwares-11, and nosh-1.41 build packages just fine on both #FreeBSD 13.5 and 14.3.
Build logs on 14.3 in case you end up spotting something interesting:
- redo-1.5: https://gist.github.com/ermo/98d627c15c7768e16c42d460356bbd7e
- djbwares-11: https://gist.github.com/ermo/238af242324aabca481bb9ebd37e1ff4
- nosh-1.41: https://gist.github.com/ermo/166ecefe1599104e668cf7dafd833263
@JdeBP I have compiled the ncgopher client and tried reaching gopher://repository.jdebp.info:70/1/ to no avail (it is listed at the bottom of http://jdebp.info/Softwares/djbwares/ and is advertised as "Bonus GOPHER content").
gopher://jdebp.info:70/1/ is reachable with ncgopher, but appears to be empty.
Am I missing a trick?
DNS problem at my end. The secondary server polls every half day or so, and last polled at mid-day, so it is going to take a little while for the fix to appear.
@JdeBP To me, one of the benefits of e.g. a git-based dvcs workflow is that the git ref of the tip on the main branch serves as a hash sum, with the dual benefit of having a commit log to follow.
Even if you don't use git, could you perhaps think of a way to approximate this particular benefit somehow?
Perhaps sha256sums could be auto-generated for the in-development software versions you upload, such that it is simple to check whether currently downloaded archives have seen an update?
Sounds a bit complex. (-:
Debian apt-ftparchive source actually makes checksum lists for source packages.
No handy equivalent in pkg repo, though.
It's not going to be high on the priority list. I could possibly modify the .do scripts to do something non-standard.
In the meantime, the HTTP Last-Modified: response header is right and the If-Modified-Since: request header is respected by Bernstein publicfile. For what that's worth.
@JdeBP After confirming that my local redo copy works and can build a working djbwares-10 suite, I tried fetching and building http://jdebp.info/Repository/freebsd/nosh-1.41.tar.gz (which I assume to be the current development sources?) and got the following error output:
https://gist.github.com/ermo/857bdc266183065e6a1327888f81aae7
I have included my list of installed packages, as it looks like I might be missing some necessary ports?
Guidance welcome. If this is all PEBKAC, I apologise in advance.
That's a good sign. Only ifconfig is failing for you, and only on a socket capability flag, which I shall check in a moment.
The failures of the try*.cpp programs are expected. This the Bernstein style of autoconfiguration, where the redo script for a header compiles a tiny program, sees whether it builds, and writes the header accordingly.
tryevdev.cpp and tryupdwtmpx.cpp are supposed to fail on a FreeBSD system. Those are Linux and GNU libc things. You aren't missing a port.
Yup. A deleted flag in a later version of FreeBSD. Fixed.
https://github.com/freebsd/freebsd-src/commit/17eea3202a2c0f3d5549fe1459149e79be35c5ca
I'd prefer #NetBSD: https://schmonz.com/2024/06/07/small-arms/
Staged latest shairport-sync for #pkgsrc. Builds on NetBSD, #macOS. Normally I'd commit, wait for evbearmv6hf-el binary package, forget.
Trying something new today: https://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/doc/HOWTO-use-crosscompile
@schmonz Oooh, I’ve been meaning to get my shairport-sync box off raspbian. I was thinking Free- but I haven’t had an excuse to pull out Net- since I ran it on a Sega Saturn.
Progress on getting shairport-sync cross-built, but not there yet.
- Less principled, coherent, systemic
- More expedient, forgetful, surprising
In short: even riskier.
If there were such a thing as expertise in managing software risks, you’d want that, right?!
@schmonz “Managing” as in “promoting?”
@schmonz I thought you meant having a computer write the code was intended to encourage risk. 🥹🤣
(Developers at every level can be thinking about how well the two are correlated. A good way to acquire seasoning.)
@schmonz @logosity Klein’s /Sources of Power: How People Make Decisions/ is good on expert decision-making. “When it feels good” can be a symptom of tacit knowledge being put to use.
https://www.goodreads.com/book/show/65229.Sources_of_Power
Building up such tacit knowledge takes time.
After — no, during! — I knew it was forever.
Today I paid my respects to the musician who made me a musician.
Alt...
Sergei Rachmaninoff’s gravesite
@schmonz I went in expecting a video of young Amitai in a top hat and tailcoat, playing the grand piano in a concert hall. I am extremely disappointed.
1. More coherent code is cheaper to change, sometimes by an order of magnitude
2. The average change reduces overall coherence
Economic constraints on augmented coding:
1. Same
2. Saaaaame
If your business makes software, I might be good for your business.
1. Technical breadth and depth
2. Proven delivery experience
3. Thoughtful communication and teaching
4. Bridge-building across roles, silos
5. Team culture and developer happiness
6. Respected industry voice
Alt...
TI-84 Plus CE Python
I asked if they were proud of their work; they were; I gave each a shiny nickel.
What are some other stereotypical shenanigans you might expect That Dad — who I now clearly am — to pull?
@schmonz
When they get older you can send them to the hardware store for self-tapping U-bolts. 🤣
@schmonz Just imagine U-bolts with both ends being self-tapping. Now imagine installing it somewhere.
A new #blog post appears!
I built a native GCC 14.2.0 for Mac OS X 10.4 Tiger PowerPC.
https://briancallahan.net/blog/20250329.html
#macos #macosx #tiger #powerpc #power #unix #bsd #freebsd #openbsd #netbsd #dragonflybsd #linux #solaris #illumos #gcc #llvm #clang #compiler #compilers #assembler #linker #toolchain #freesoftware #opensource #gnu
Onesday
Twosday
Threesday
Foursday
Fivesday
Sixday
Sevenday
Kinda almost. Also arguably superior.
Added Webmention support for links (Markdown-style or direct) written in a post.
Added new command-line options for list maintenance.
Display custom emoji in more places (contributed by dandelions).
Mastodon API: fixed infinite scroll in many clients (thanks to cheeaun for giving me the clue), added /api/v1/accounts/.../lists endpoint (contributed by dandelions).
Email notifications can now be sent via libcurl SMTP instead of spawning the /usr/sbin/sendmail program. To use this new feature, some additional server configuration is needed, see snac(8) (contributed by shtrophic).
If you find #snac useful, please consider buying grunfink a coffee or contributing via LiberaPay.
I submitted a Pull Request to update MacPorts' snac to 2.76 here:
https://github.com/macports/macports-ports/pull/28373
GitHub Actions Continuous Integration checks passed!
It's up to someone else with write access to merge it.
Thanks to you and dandelions and shtrophic (and anyone else I may have missed) for the continued contributions and improvements!
(these modest diffs were prepared in part while listening to "Garlic Braid" by LMNO & D-STYLES: https://d-styles.bandcamp.com/track/garlic-braid [the 1st single from the upcoming full length album: Three Mimes & an Elephant)
#snac #MacPorts #OpenSource #ActivityPub #Mastodon #NoDatabaseNeeded
#NoJavaScript #NoCookiesEither #NotMuchBullShit #snacAnnounces
Debian users will have to be patient; I can't upload to unstable/backportar because of the release freeze. I'll do that as soon as possible :)
Google Summer of Code 2025 NetBSD projects
https://blog.netbsd.org/tnf/entry/gsoc2025_welcome_contributors
Alt...
“Mary our Mother”
Thanks, man. It's been 7 years and every day I do this I'm better off.
The year is 2025 and people are still telling me that TDD only works "in theory".
A large-scale study of dev activity in the IDE found that only 1.7% of developers did TDD at least *some* of the time.
This is a number worth remembering when listening to strong opinions - positive or negative - about TDD.
@jasongorman Most of what is called "TDD" these days, is really "not-quite-end to not-quite-end" tests written after the code, by programmers who regard it, justly, as a tedious chore.
It bears no resemblance to our TDD.
@GeePawHill ...and it's often the "TDD" they're talking about when they say "TDD doesn't work in practice"
@jasongorman @GeePawHill then again, TDD also really suffers from No Real Scotsman.
There's probably a term for it but I think TDD reached the point where the term is used so often incorrectly that the term has little value anymore. Like what happened with agile or even Scrum
@mark @GeePawHill I think TDD is pretty clearly defined and it's very easy to tell if someone's doing it.
@mark @GeePawHill The problem has always been that the vast majority of developers have never seen anyone do it. And that's understandable, because - thanks to the "birds of a feather" clustering effect - if you're not in that 1-2% bubble, you're unlikely to get to work with someone who is.
@jasongorman @mark (I don't. Too many fifth rate epigones have destroyed it.)
@GeePawHill @mark It's true that, e.g., YouTube is awash with "TDD tutorials" that don't show TDD. But it's easy to tell that they're not doing TDD 🙂
@mark @jasongorman Fair enough, Mark. But let me ask you, outside of you noticing how our movement turned in to a corrupt nothingness we all decry, be that movement "agile" or "scrum" or "TDD", what would you a) have rather we should have done, vs what we did, and/or b) want us to do now?
There's a very high probability that their opinion's based on no experience - doing or seeing - of TDD at all.
@jasongorman I think the trouble is they have learned the skills from someone, who learned them from someone, who learned them from who knows where. It’s the broken telephone game. Which means that the underlying principles and practices have been pragmatised to nothing.
The conclusion I have come to is people don’t want to learn because they don’t want to think. They want something that “just works” - in other words, they want Fred Brooks’ proverbial silver bullet. We just don’t learn, do we?
@jasongorman Building on this, I think the saddest thing I now realise is many folks don’t want to learn is because what they do is “good enough”. There are simply no consequences since the rewards for doing things right are delayed, and invisible to the annual accounts bottom line. Eg. things like reliability, failure demand, downtime, cost of change etc
@jasongorman well I read the book … ok I read the book’s title … ok I haven’t actually developed code in 20 years. I don’t see how TDD can work. 🙄
@jasongorman actually @schmonz started helping me with TDD (his oldest son’s age) years ago.
@jasongorman I recently worked with a PM that does “Practical Agile” because “Agile only works in theory”.
Of course “Practical Agile” was just codeword for waterfall.
Strong suspicion I could swap out #macOS for #Linux, do better with #Minecraft and most everything else, and not do much worse at macOS-specific stuff like #GarageBand and Messages under #OSXKVM (https://github.com/kholia/OSX-KVM).
Anyone done this, or something similar?
@schmonz ooh! I have a 2017 iMac that is quite long in the tooth. This might be a good idea for it, too.
@schmonz The kvm for osx doesn't support the gpu. macOS uses gpu acceleration for basic ui, this makes anything beyond ssh'ing into the vm for programming tasks a horrible experience. If you need Messages and GarageBand it won't end well.
@schmonz Last I checked, and it's been a while since I have, gpu passthru required 2 gpus and a board that supports passthru.
Just spent some time converting 11 years worth of resume updates into a Git repository.
I had an existing Git repo for this that contained... one commit.
One of the advantages that Git has over some other SCMs is that you can declare a specific date that the commit will record. In other words, you can lie to Git about when you're committing a tree and it will record the date and time you give it.
This is handy for making retroactively building Git repos for archival purposes.
Put another way, you don't have to do it the old-fashioned way:
MyResume-20230115.pdf
MyResume-20230823.pdf
MyResume-20241212.docx
You can use the mtime of the file as the Git author date/commit date and check-in "MyResume.pdf" and the metadata of when that file was edited will be recorded in the commit. And nowhere else, so don't think "git checkout" will preserve this mtime for you.
This means (1) fewer stray DOC/PDF/TEX files in your ~/resumes directory with "guess what I was for" names like "Resume_send-to-Gary_at_TechnoCorp-20220404.doc", (2) having an archive of your documents, and (3) the ability to use branches to track to whom you're sending your resumes.
You can keep your resume naming simple and maintain multiple concurrent Git branches for TechnoCorp, FAANG, goverment positions, et cetera.
I do wish other SCMs had this ability and made it more prevalent or well-known. I settled on Git because I know Git does this. Other investigations I've made into competitors haven't ended with any good equivalent workflows.
Programmatically it's easy to just run "git add Resume.doc" and "git commit -m 'checkin'" but that will lose any tribal knowledge you have about why you wrote that specific resume, so caveat emptor.
In my opinion, the only two resumes that matter are your last one and your next one. If you want to maintain different flavors of resume based on different career goals, you can still do this, either with different file names, directory names, or branch names.
One of the reasons I've been putting off this project was the mild annoyance of having to write the tools to do the finding, renaming, and committing. I spent a little time this morning asking ChatGPT to give me Perl scripts.
While "opendir(); while (readdir()); closedir();" is a pattern I've written countless times[0], I just didn't feel like writing it yet again from scratch, and I couldn't remember any recent script I could scoop out and repurpose. So ChatGPT it was, and after reading its code, it looked good enough to try and I was pleased to find it did exactly what it said on the tin.
While Perl has a reputation for being a write-only language, AI tools are quickly making it a "write-never" language, easy enough to generate one-off scripts that can be read, reviewed, run, and then pushed into a repo for reuse or eventual abandonment.
At the very least this process isn't also taking 30 minutes of my time I'll never get back.
[0] Or, as I prefer, IO::Dir->new, etc, etc.
Experiences with #dreckly / #pkgsrc on obscure Unixes:
#UnixWare - bootstrap succeeded! Just needed a few simple fixes.
#OpenServer - see UnixWare.
#BSDOS - kernel panic during installation. Support incomplete.
#HPUX - kernel panic during installation.
#QNX - bootstrap success! No changes needed.
#Haiku - bootstrap failed due to open() behaviour. "Invalid argument".
If you have a shell on an #IRIX or #HPUX machine, please let me know!
@washbear this is all good, but I don't understand why we'd support Irix, but say hard luck if you use older #NetBSD (even the oldest supported branch such as 9 when we get to the time when 11 is branched). To be clear I am in favour of supporting both.
I will try to boot my Irix on my Indigo2 though if I can.
@jmcwhatever @washbear Perhaps I'll try #pkgsrc on RISCiX just to really piss myself off. I remember it being painful to get GCC running on Irix back in 1995, I can't see it having got better since.
@jmcwhatever @sborrill @washbear And that's why the IRIXNet people eventually gave up and went for rpm https://forums.irixnet.org/thread-2072.html
@sehnsucht @jmcwhatever @sborrill The bootstrap version of awk was also a big problem on other platforms - it seems it got updated over the years without the consideration for keeping bootstrap on old platforms in working order.
@washbear I've been trying to get pkgsrc to bootstrap on HP-UX 11.11 (11i v1) on PA-RISC. I did not succeed because I'm an idiot.
@thomholwerda @washbear Do you have some way to allow other people access to the machine, for example with ssh?
@sehnsucht @netbsd We have an HP9000/715 running HP/UX 9.04 with guest access https://connect.sdf.org
- Things always go as you, your teammates, and your customers expect, or
- Nobody cares about the costs when they don’t
@schmonz
- You're never going to come back to this code/system.
@gdinwiddie @schmonz There are times where TDD is an investment today that gives me a corpus of tests that might be useful in the future.
There are times when TDD helps me go faster today. This hour. In the next minute.
@JayBazuzi @schmonz
Yeah, I had a manager who gave me a last-minute feature that "had to go out tonight" and said to skip my usual testing to save time. I wrote it TDD because that was the fastest way I knew to work. What I didn't write was tests at the UI level.
As we were leaving, his phone buzzed because the build failed. I had forgotten to check in one new file. ;-)
:; jq -r '.id' < $(ag -l 'six thirty twelve meters' ~/sites/schmonz.com/snac/data/user/schmonz/public)
https://schmonz.com/snac/schmonz/p/1743383179.235112
@schmonz I just "discovered" snac on Friday, set up my instance on Saturday and suddenly I'm seeing posts about how everyone is using it. Damned Baader-Meinhof phenomenon.
@schmonz um well ok
@schmonz you're the real snac
![[?]](https://cdn.fosstodon.org/accounts/avatars/109/365/831/503/742/210/original/03fdfce036de4ad4.png)
![[?]](https://media.mstdn.social/accounts/avatars/109/708/132/843/164/223/original/7579afae421d5ee9.jpeg)
![[?]](https://files.mastodon.social/accounts/avatars/109/252/708/329/707/951/original/852b5f7e63555f35.png)
![[?]](https://media.mstdn.social/accounts/avatars/109/257/708/633/043/958/original/90198ffa4b75b132.png)
![[?]](https://media.bsd.network/accounts/avatars/000/001/285/original/f9255f9b1a538310.jpg)
![[?]](https://comam.es/snac/susie.png)
![[?]](https://cdn.fosstodon.org/accounts/avatars/114/438/964/131/884/381/original/53887395065aa19f.jpg)
![[?]](https://snac.bsd.cafe/r1w1s1/s/avatar-a407a557617b316743a014a69dd362e9.jpeg){kind=avatar}
![[?]](https://snac.bsd.cafe/teajaygrey/s/2d49dbf4b3c8576152b35aef1cffac46.gif)
![[?]](https://snac.sergiodj.net/sergiodj/s/16ec2759afabe38a09a8e3d2888a2f0f.jpg)
![[?]](https://media.bsd.network/accounts/avatars/108/079/638/271/639/066/original/3d97dea8eae9629b.png)
![[?]](https://media.bsd.network/accounts/avatars/109/207/430/504/108/566/original/b37198ec33972825.png)
![[?]](https://files.mastodon.social/accounts/avatars/108/235/755/317/521/000/original/ce07bac0a2181f3c.png)
![[?]](https://media.mastodon.cloud/accounts/avatars/000/297/928/original/f8498e4b4a632d99.jpeg)
![[?]](https://files.mastodon.social/accounts/avatars/108/193/376/617/364/330/original/f3fc0128b5118cb3.jpg)
![[?]](https://media.tacobelllabs.net/accounts/avatars/109/536/017/410/375/666/original/67dad60311a9a673.png)
![[?]](https://cdn.hosted.spacebear.ee/sb-27ceb02753a3a5193358f6bb2e831c93/accounts/avatars/109/309/592/107/553/186/original/857caf6f10ffd7d2.jpeg)
![[?]](https://media.hachyderm.io/accounts/avatars/109/796/980/674/312/938/original/9639d06225da6091.jpg)
![[?]](https://media.hachyderm.io/accounts/avatars/109/411/321/567/750/487/original/620be35c1a92bb69.png)
![[?]](https://sfo3.digitaloceanspaces.com/mastodon353/accounts/avatars/109/397/487/063/934/017/original/04cdd3dcabc7f141.png)
![[?]](data:image/png;base64, iVBORw0KGgoAAAANSUhEUgAAAEAAAABAAQAAAACCEkxzAAAAUUlEQVQoz43R0QkAMQwCUDdw/y3dwEvsvzlL4X1IoQkAisKmwfAFT3RgJHbQezpSRoXEqeqCL9BJBf7h3QbOCCxV5EVWMEMwG7K1/WODtlvxAYTtEsDU9F34AAAAAElFTkSuQmCC)
![[?]](https://media.bsd.network/accounts/avatars/000/006/167/original/e75afaaddd11c4a4.jpg)
![[?]](https://mastodon.sdf.org/system/accounts/avatars/114/205/366/579/623/449/original/2eeba344bc5e17ba.png)
![[?]](https://justfollow.me.uk/system/accounts/avatars/109/320/306/219/107/803/original/abdeb1bbb89e40f5.jpg)
![[?]](https://mastodon.sdf.org/system/accounts/avatars/113/852/316/881/773/766/original/55c2da0a575daf13.png)
![[?]](https://social.sdf.org/system/accounts/avatars/109/401/156/849/789/988/original/ff2be95c26347a0e.jpg)
![[?]](https://federate.me.uk/system/accounts/avatars/109/309/886/224/077/101/original/5413a04479190d6c.jpg)
![[?]](https://media.exquisite.social/exquisite/accounts/avatars/111/365/987/696/347/830/original/5ad937a691cf17c2.jpg)
![[?]](https://mastodon.sdf.org/system/accounts/avatars/108/233/134/134/174/252/original/75cf6c02b16edbb2.png)
![[?]](https://mastodon.sdf.org/system/accounts/avatars/109/252/633/168/051/835/original/487160775622bbc8.jpg)
![[?]](https://files.mastodon.online/accounts/avatars/109/271/673/612/992/945/original/b47d5101929ca824.jpeg)
![[?]](https://media.mstdn.io/mstdn-media/accounts/avatars/000/132/680/original/56b712baa48c2e14.png)
![[?]](https://files.mastodon.social/accounts/avatars/108/193/245/242/726/097/original/1f4098bccc0625c0.jpeg)