Oliver Kennedy @okennedy@social.xthemage.net

@kyle I’ve had my canon ip4500 inkjet since 2006 or so. I’d been happily printing on it for over a decade on MacOS, manually flipping pages when I needed a 2-sided print until I switched to Linux and noticed a duplex option in the setup (which was not there on the Mac)... ☝️

For B/W it really is plug and play, but color needs work. Color printing just worked on OSX, while I still haven’t gotten my color profiles right on Linux. Another (extreme) case: https://www.davidrevoy.com/article757/the-english-book-printed-project-production-report-3

In memory of the many lost, and the one who brought us joy. May they always know where their towel is.

And as an aside... let me state just how cool it is that by having /home on a different disk you can be fully up and running after completely replacing your OS in < 30 minutes.

Tried out #elementaryOS over the last few days. Comparing it to mainline Gnome3, it's a fair bit slicker. I like the OSX-style dock, and holy crap I've missed column view. On the other hand, some things are frustratingly obtuse: Defaulting to the shortcuts window every time you hit meta, app switching without a pop-up window showing which app you're on, and single-click open in column view are all incredibly frustrating. Charging $5 for a launcher menu editor is also... less than ideal.

@minus @sir This is exactly my viewpoint.

@sir Then you're still stuck with the higher latency of IPC (to say nothing of the richer set of well-understood communications primitives you get intra-process). Shm+Worker Processes are fine for batch processing tasks, but in user-facing or latency-sensitive code (e.g., a game's 3d rendering engine or a live data visualization tool) biting the bullet may be necessary. The same compartmentalization that splitting your process enforces can also be designed into a codebase *when necessary*.

@sir That forces a lot of memory copies if you need to transfer data between the processes or if you have multiple workers that need read-only access to the same data blob.

@sir Event loops/coroutines force you into a trade-off between inefficiently breaking long-running work into smaller nuggets and blocking the core. Threads seem like a good fit for separating operations that need to be low-latency (e.g. user-facing) from longer running tasks that benefit from being in the same address space. Debugging threads becomes infinitely easier if they’re isolated, with stock concurrent data structures mediating between them.

New accept at HILDA. Link Once and Keep It (Loki), is our new approach to streamlining data integration tasks by keeping humans in the loop.

https://odin.cse.buffalo.edu/news/2020-05-03-Loki-at-HILDA.html

It's incredibly disheartening when a peer review includes the phrase "there must be a way to X" without pointers. If you, as the reviewer, think there should be a better way to do something than the authors propose, it's your responsibility to find it. It's irresponsible to expect the authors to conjure up related work that you yourself are not aware of. #reviewer2strikesagain

This is just an awesome use of quarantine time: https://m.youtube.com/watch?v=Fes7gjJO_Z8

@kyle Bread’s component ingredients have a longer shelf life than the finished product. The opposite holds for soup. Probably the right call when one might be called on to lock one’s self away for 2 weeks at any moment. Although it might be fun to get into canning...

@joshfowler @krzym @PINE64 I got about 4-6 hours on Debian+Phosh as of my last round of untethered trials. Low screen brightness, and screen off for good chunks of time, but with Cellular and WiFi enabled. The phone was a nice pocket warmer the whole time through, so I expect there’s plenty of room for improvement.