@zhenech laugh out loud funny when the result doesn’t work for some reason (1 time every 10?)
New blog post: Our study, 2025 https://jmtd.net/log/study/2025/
This talk on user interface design by Scott Jensen is excellent. https://youtu.be/1fZTOjd_bOQ?si=GPyZlEwHlpPCj1Rj
I’ve never paid attention to Ubuntu summit before. Perhaps I should!
I’ve never paid attention to Ubuntu summit before. Perhaps I should!
@liw the triple-b releases broke my brain so much I often wonder if the release team had intended them to. At the very least I’d like Debian to move to leading with the version as you illustrate, in all official docs and communications.
@db awesome to know, thanks!
@neal @andrew_shadura Thanks for expanding. We agree that it's important to clearly distinguish between upstream and the distro changes; and that carrying too many changes at the distro level has serious drawbacks. Where we differ seems to be whether Dgit will make those matters worse or not. Frankly I don't know, but it's a concern worth taking seriously.
@sxa I don't, but that sounds like a useful tool.
@db which app? I did a copy edit of a book with acrobat once. It was a little clunky.
New blog post: Remarkable https://jmtd.net/log/remarkable/ #hardware
@neal @andrew_shadura that said, the most common source layout in debian packaging *with* git is for the source outside ./debian to be unmodified, and a stack of patches in debian/patches. IMHO this is a pain in the arse to work with: it lacks the convenience of "source as it is built", and the separation of "only ./debian is tracked". The worst of both worlds. It looks like Dgit encourages a move away from this.
@neal @andrew_shadura I think I understand better where you are coming from. Interestingly, pre-git it was more common to work with a fully split repo as you describe: with e.g. svn-buildpackage teams (inc. games team) typically kept only ./debian in the VCS.
Most packages moved to "upstream source present" in the debian branch with the move to git, partly because it was much more convenient to work with.
Most packages moved to "upstream source present" in the debian branch with the move to git, partly because it was much more convenient to work with.
Hi Neal
mangling packaging data into source code. I really wish they'd change how the source packaging model worked to firmly split it.
Would you be prepared to expand on this, please? I don't understand it. Perhaps it's because my historical experience is the inverse of yours (familiar with Deb, not too great with RPM).
From my POV Debian has a firmer split than RPM-style (orig.tar.gz; ./debian sub-dir; etc) so I must be missing something.
The sheer scale of the downloads that Anna‘s archive are offering, the Spotify stuff and other stuff, really blows my mind. I’m struggling to move 70 GB of photos off of my camera!
@mcc Haskell has that problem too
Idle thought: what if hyper-efficiency (e.g. tiled window management, which prompted this thought) results in more efficient procrastination or attention-deficit rather than designed-task efficiency?
Technically, this isn't a christmas song, right? But those bells make it sound so
c.f. https://jmtd.net/log/christmas_songs_that_are_not/(2012)
https://dizl.de/@JBsWhatsOn6/115734514174311762
c.f. https://jmtd.net/log/christmas_songs_that_are_not/(2012)
https://dizl.de/@JBsWhatsOn6/115734514174311762