🏡
  • ↔
  • →
  1. September 09, 2026
    1. 🔗 modem-dev/hunk v0.22.0-beta.1 release

      What's Changed

      Full Changelog : v0.22.0-beta.0...v0.22.0-beta.1

    2. 🔗 smol-machines/smolvm smolvm v1.14.4 release

      What's Changed

      • Share active branch memory and guard host capacity by @BinSquare in #1204
      • Write the release marker and identity files readable by the workload so a non-root machine can be branched by @BinSquare in #1205
      • Reclaim idle branch leaf memory by @BinSquare in #1206
      • Bump the workspace to 1.14.4 by @BinSquare in #1209

      Full Changelog : v1.14.3...v1.14.4

  2. September 08, 2026
    1. 🔗 @binaryninja@infosec.exchange RE//verse 2027 tickets are LIVE! Trainings too! Round 1 is the cheapest mastodon

      RE//verse 2027 tickets are LIVE! Trainings too! Round 1 is the cheapest pricing we’ll offer, so grab your ticket before they sell out. See you in Orlando: https://re-verse.io

    2. 🔗 @HexRaysSA@infosec.exchange 📢 The 2026 IDA Plugin Contest is officially open! mastodon

      📢 The 2026 IDA Plugin Contest is officially open!

      Got an idea for a plugin that could make reverse engineering faster, smarter, or just more fun? Now's your shot. Submissions are open through November 30, with winners announced mid-January.

      Build with C, C++, Python, or idalib. And since our SDK is now open-source, IDA Free users can jump in too.

      Up for grabs: cash prizes up to $5K, free IDA licenses, recognition in the community, and more.

      Full rules + prize breakdown: https://hex-rays.com/plugin- contest

    3. 🔗 modem-dev/hunk v0.22.0-beta.0 release

      Hunk 0.22 beta: history becomes a review workspace

      Hunk 0.22 turns repository history into a responsive review workspace: browse commits, select contiguous ranges, carry review context into the diff, and leave precise threaded feedback without leaving the terminal.

      hunk update 0.22.0-beta.0
npm install -g hunkdiff@0.22.0-beta.0

      Browse commits and review ranges

      hunk log now opens a responsive, themed history browser for Git and Jujutsu. Commits are grouped by day, optional graph lines preserve topology, and visual or Shift-based range selection opens the cumulative diff for a contiguous set of commits. History has configurable command bindings, merge-parent selection, and keeps your theme and diff preferences as you move between history and review. #979 #987 #1011 #1031 #1038 #1039

      Select and discuss exact code ranges

      Persistent mouse and keyboard selections can now span multiple lines and drive explicit Comment, Copy, and Clear actions. Inline notes and replies participate in keyboard navigation, and agents can reply through the session CLI while inheriting the original code anchor. #931 #1012 #1044

      Richer extension-powered reviews

      Extensions can attach provider-neutral review metadata when delegating patches, expose that context to panes and live-session snapshots, and request a coalesced reload after an external agent changes reviewed files. The extension directory also adds hunk-gh, hunk-viewed, hunk-history, and hunk-compact-filenav. #986 #988 #981 #995 #1034

      Faster, steadier terminal interaction

      Long wrapped lines render and respond faster, pane animations are capped at 30 FPS and can be disabled, sidebar folders collapse without breaking navigation, suspended sessions resume cleanly, and direct-file reviews reload correctly outside repositories. #1043 #1051 #1036 #1009 #996 #1054

      Compatibility notes

      • unified is now the canonical name for the single-column diff layout. Existing stack CLI and configuration values remain accepted as deprecated aliases and normalize to unified.
      • Extension API v23 adds canonicalMode and canonicalLayout, which report unified; legacy fields continue to report stack for compatibility.
      • OpenTUI integrations can use canonicalLayout: "split" | "unified"; the legacy layout: "split" | "stack" prop remains source-compatible, and canonicalLayout wins when both are supplied.
      • hunk log opens the interactive history browser when attached to a terminal. Use --static for scripted terminal output; pipes remain static.
      • Review commands now print static plain text instead of launching the TUI when stdout is not a terminal.
      • The bundled runtime is upgraded to Bun 1.4.2.

      Community contributors

      • @samuela improved daemon health-probe failure reporting. #927
      • @saadjs led the stack-to-unified layout transition while preserving compatibility. #945
      • @any-victor added hunk-history to the extension directory. #995
      • @HackAttack fixed suspended-job resume behavior. #996
      • @rschoch added hunk-compact-filenav to the extension directory. #1034

      All merged pull requests

      Release notes : https://hunk.dev/changelog/0.22/
      Full changelog : v0.21.1...v0.22.0-beta.0

    4. 🔗 Barre/ZeroFS v2.3.3 release

      What's Changed

      • Fix monitor count pluralization by @Barre in #614
      • Update distro kernel package targets by @github-actions[bot] in #615
      • Fix/linux 7.3 compatibility by @Barre in #620
      • Compaction repack overhaul by @Barre in #619

      Full Changelog : v2.3.2...v2.3.3

    5. 🔗 smol-machines/smolvm smolvm v1.14.3 release

      What's Changed

      • Run init as root on every path, and keep the image's USER for a packed workload by @BinSquare in #1190
      • Open a machine to observe it without creating its disks or data directory by @BinSquare in #1197
      • Add selectable block I/O engines by @BinSquare in #1198
      • Honor a storage size below the template by shrinking the copied filesystem instead of rounding up by @BinSquare in #1199
      • Bound live branch memory accounting by @BinSquare in #1200
      • fix(network): prevent named-fabric receive busy loop by @scottatron in #1201
      • Resolve a packed machine's launch from its manifest in one place by @BinSquare in #1150
      • Pack machines with the entrypoint they were created with and the overlay they actually write to by @BinSquare in #1174
      • Record the image's USER, or the Smolfile's user, in a pack made from an image so its workload keeps its account by @BinSquare in #1202
      • Bump the workspace to 1.14.3 by @BinSquare in #1203

      New Contributors

      Full Changelog : v1.14.2...v1.14.3

    6. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 plugin, +1 release rss 
      sync repo: +1 plugin, +1 release

## New plugins
- [BinaryLens](https://github.com/lumice/binarylens) (1.2.0)
    7. 🔗 r/Harrogate The coffee machines in Waitrose are still broken. rss

      Just an FYI for those who look forward to their morning free coffee from Waitrose. Fingers crossed they’ll get them sorted soon 🤞🏼🤞🏼

      submitted by /u/Champion-Of-Midgard
      [link] [comments]

    8. 🔗 jellyfin/jellyfin 12.0 release

      🚀 Release notes for 12.0

      Notes on Updating

      Before upgrading from an earlier version, a full backup of the data directory is strongly recommended, as this release includes database changes that prevent rolling back without a full restore.

      Direct upgrades from 10.10.7 and 10.11.x to 12.0 are supported; intermediate upgrades are not required. Users running releases older than 10.10.7 are strongly encouraged to upgrade to 10.10.7 before migrating to 12.0.

      Installed repository plugins (anything not built-in) should also be removed before migrating. Plugins will likely need time to adapt to the new database changes, so re-adding them afterward is the safest approach for testing.

      Official plugins compatible with Jellyfin are available through the stable plugin repository. If you have changed to the unstable plugin repository please change it back.

      After migrating please perform the following steps.

      • Perform a full library scan to restore alternative versions

      If you run into issues, please prefix bug reports with "[12.0]".

      Packaging

      • Debian Bullseye and Ubuntu Focal packages are no longer built

      Server

      • Performance PR implications #16062

        • We're running a full path-based check on all library items to clean up left overs. Depending on size this can take some time
        • Alternative versions of media that were auto resolved (not manually merged) will be removed due to data type issues -> A full library scan will fix this again and is therefore REQUIRED AFTER UPGRADE
        • First scan will take significantly longer than normal and some movies might appear as newly added due to type issues that got fixed on-scan

      • Multiple versions for episodes

      • Similarity & recommendation providers
      • Search providers, letting plugins extend or replace how search results are produced
      • SchedulesDirect and EPG refresh fixes
      • Fixes to the parental rating system
      • Proper data pruning on file replacement/deletion
      • Support triple+ digit episode numbers
      • Add library-specific BoxSet and Playlist filtering, allowing per-library collection and playlist views
      • CACHEDIR.tag support
      • Accept-Language header support
      • Add VideoRotation profile condition for Android TVs that do not support rotation metadata
      • Parse provider IDs from season and episode folder/file names
      • Allow tmdb, tvdb, and imdb as aliases for the tmdbid, tvdbid, and imdbid provider IDs
      • Add curly brace and parentheses support for parsing attribute values
      • Add NameStartsWith and NameLessThan filters to Person search
      • Add new filters for audio and subtitle languages
      • Add OriginalLanguage as option to PreferredAudioLanguage
      • Add a collection API for Included In feature
      • Add support for VobSub subtitle streams
      • Add Tmdb missing episode provider

      Breaking and behavior changes

      • Legacy route prefixes removed (/emby/* and /mediabrowser/*). Old third-party clients that rely on them will stop working
      • Legacy authorization is now disabled by default, and a migration disables it on existing installs as well
      • Removed obsolete API routes: POST /Users/{userId}/EasyPassword (the EasyPassword feature is gone), GET /Items/{itemId}/CriticReviews, GET /Environment/NetworkShares, POST /System/MediaEncoder/Path, GET /LiveTv/Recordings/Groups/{groupId}, and GET /QuickConnect/Initiate
      • The global subtitle configuration has been removed, subtitle settings are configured per library
      • .ogg is no longer treated as a video extension and is audio only, .aifc is now recognized as audio, and .aiff is no longer treated as an image
      • Symlinks are only resolved at playback time
      • Sorting by name now uses SortName and CleanName, and the same cleaning logic is applied to ForcedSortName. Library ordering may change compared to 10.11
      • Image endpoints no longer upscale beyond the source resolution, so low resolution artwork renders at its real size instead of being enlarged
      • Username capitalization can now be changed. Usernames are stored in a normalized column with a unique index, so installs with usernames that differ only by case need to be corrected before upgrading

      Database and performance

      • Playlists and collections are now properly relational, using a new LinkedChildren table instead of serialized child lists. OwnerId and PrimaryVersionId are real GUID foreign keys, and ExtraIds has been dropped
      • Many tuning migrations covering item counts, item names, type and clean name, latest items, image info, and primary version id
      • Migration routines clean up existing data on first boot: duplicate music artists and people are merged, orphaned extras and external data are removed, incorrect owner relationships are repaired, and clean names, forced sort names, and series presentation keys are recomputed
      • Heavy database tasks no longer run while a library scan is in progress
      • Faster queries for Resume, Next Up, rewatching, Latest Items for music, playlists and collections, artist lookup, and item counts
      • Item deletion is batched, which fixes "too many SQL variables" failures when deleting large numbers of items
      • jellyfin.db can now be stored at a custom path

      Operations

      • New --mode startup flag with MediaServer, MigrateSystem, and SeedSystem, allowing migrations or database seeding to be run without starting the server. This is useful for containerized and orchestrated deployments and for controlled upgrades
      • The startup interface has been restyled and now shows version and activity information
      • Disabled plugins are no longer re-enabled on restart
      • Full system backups skip corrupt keyframe rows instead of failing

      Media and subtitles

      • Subtitle writing now goes through SubtitleEdit, which is what avoids the SSA to ASS conversion and loss of styles
      • External subtitles can be embedded into MKV when transcoding
      • The subtitle extraction timeout is now configurable
      • Client-rendered graphical subtitles are allowed during remux
      • Fixes for races in concurrent subtitle conversion, cache invalidation when a subtitle is replaced, and ffmpeg hangs during extraction
      • New HlsAudioSeekStrategy configuration option
      • Trickplay: existing files are discovered during a scan, duplicates from interlaced video are fixed, invalid PTS values from containers are normalized, and the cache is cleaned up after a failure

      Live TV

      • Live TV no longer returns unreachable "server-local" streaming URLs to clients
      • XMLTV background images and episode thumbnails are now imported
      • XMLTV guide imports skip programs whose data has not changed, using an ETag computed from the fields the server actually consumes, which makes repeat guide refreshes considerably cheaper. Other listings providers stay on the existing field-by-field update path

      Metadata and providers

      • ListenBrainz is now bundled with the server and provides similar artist data with a selectable similarity algorithm
      • TVDB provider IDs are supported for movies
      • AudioDb artist search
      • ReplayGain album gain is parsed
      • MusicBrainz lookups are more resilient
      • WEB-DL release tags are recognized in file names
      • Hyphenated numbers in episode titles are no longer parsed as multi-episode files
      • 3D format detection works when the tag is the last token of the path
      • Person metadata refreshes are queued instead of blocking the request

      Transcoder

      • New upstream version of FFmpeg 8.1
      • Optimized CUDA transposing filter performance
      • Optimized OCL scaling filter performance
      • Optimized OCL tonemapping filter performance on Mali GPU
      • Use EOTF from BT 2446 Method B for HLG tonemapping
      • Fix potential A/V desync in HLS when transcoding video while remuxing audio
      • Avoid SSA to ASS conversion and loss of styles
      • Add spec-compliant dvh1 HLS variant for DoVi P5 for compatibility

      Web

      • The Modern layout is now the default, the previous layout is now called Legacy
      • Updated Music Videos view
      • Updated Mixed Media view
      • Updated Collections & Playlists view
      • Updated Books view
      • Add still watching prompt
      • Add delay setting for photo slideshow
      • Add caching of queries to indexed db for the tanstack query client for improved loading performance
      • Add watch feature to log viewer
      • Add , and . as controls to scrub frame-by-frame
      • Add filters for audio and subtitle languages (modern layout only)
      • Add Collections and playlist tab to all libraries
      • Add collections to item details page
      • Replace libpgs with libbitsub and adds support for vobsub rendering
      • Merge cards for crew with multiple roles

      Layout and themes

      • All themes now derive from a shared base theme built on CSS variables, including Dark, Light, WMC, Blue Radiance, Apple TV, and Purple Haze. Custom themes may need to be adjusted
      • The library toolbar has been merged into the app bar, with a sticky library header and design polish throughout the library
      • Custom links can be added to the Modern layout
      • The screensaver time setting is now available in the Modern layout

      Libraries and browsing

      • Collections and folders tabs for book libraries, and a folder view in the Modern home videos layout
      • Default tab options for Home Videos and Photos libraries
      • Studio search, and an extended Studios tab
      • Play All and Shuffle buttons on the series library. Both are disabled rather than hidden when no items are available
      • Improved Upcoming view
      • Sorting and filtering on the Activity page
      • A Reset Filters button in the filter dropdown
      • Folders can be marked as played
      • TV show creators are shown on item details
      • Similarity providers can be configured per library
      • Pagination controls are hidden when paging is disabled

      Playback

      • The playback info overlay is more compact and shows more detail
      • Chapter names are shown in the OSD slider bubble
      • Bitrate detection now runs in web
      • Dolby Vision in MKV on webOS 25 and newer
      • AV1 fMP4 stream copy on TV clients
      • Direct play of anamorphic video on Tizen, and loosened anamorphic restrictions for browser device profiles
      • On iOS, background playback continues when the screen is turned off, and audio normalization is disabled to fix pitch and speed issues
      • libbitsub updated to v1.11.0 with an HLS offset fix
      • The screensaver is suppressed while viewing photos or reading

      TV and remote

      • Game controller navigation fixes, and the gamepad repeat rate is no longer tied to framerate
      • Keyboard controls work on non-Latin keyboard layouts, with additional fixes for older browsers
      • Rewind and FastForward play state commands are handled
      • SyncPlay menu update, and the SyncPlay ping is now reported to the server
      • Focused and checked checkbox styling in the TV layout

      Under the hood

      • WebSockets have been migrated to SDK subscriptions
      • The React and TypeScript migration continues with the libraries, Live TV, and networking pages, and the dashboard user pages now use the TS SDK
      • TanStack Query now backs user settings and home screen sections, and the query cache is cleared when the server restarts

      Notable fixes

      • Blurry card images on high DPI displays, and card image sizes are rounded up
      • Duplicate /socket connections
      • Login loop, connecting to the wrong server when several are configured, and native shell server selection when signing out
      • An invalid request for all items on page load
      • The Live TV default landing tab
      • Holding and dragging on media no longer activates multi-select
      • A warning is shown before restoring a version, a warning is shown when starting a backup while a scan is running, and a library scan starts automatically when folders are added to a library

      Security

      Server:

      • Path validation has been added to the legacy HLS segment endpoints and to the plugin image endpoint, so a requested file must resolve inside the transcode directory
      • Path traversal hardening has been extended to the image and plugin endpoints and to username path handling, building on the fixes released in 10.11.x
      • The startup wizard can no longer be re-run without authentication on a misconfigured server
      • Unsafe plugin package names are rejected by the plugin installer
      • Parental filtering is enforced on additional endpoints, playlist visibility has been corrected, non-admin access to additional parts has been fixed, and people are exempt from the allowed tags visibility check

      Web:

      • Cross-site scripting via person roles
      • Auth parameters are encoded when creating API clients
      • The login disclaimer only allows common link protocol schemes

      Books

      Books have often taken a backseat in favor of video playback in Jellyfin, but this should no longer be the case.
      We have started a concerted effort to improve book support across the API and our official clients.
      eBook and comic support is still maturing, but the ODPS plugin allows for direct access from a wide range of popular self-hosted programs.
      Correspondingly, contributions in any repository are extremely welcome from the wider community.
      That includes server improvements, documentation changes, and third-party clients for book playback.
      A combination of eBook, comic, and audiobook support is available on the following clients.

      Official: Web, iOS, Android, Desktop, Roku, Kodi, JMP
      Community: JellyBook, Symfonium, Jellium, Plappa

      One notable omission from the server is book series as unique entities, which didn't make the cut for this release.
      If you would like to bridge the gap until they are added, feel free to use the Folio plugin to display them as collections.
      It functions very similar to the TMDb Box Sets plugin but only applies to eBooks.

      Another in-flight feature is audiobook chapters, which are only available from the API at present.
      Luckily, this means client support is now possible, so you should see them appear in your favorite audiobook client before our next server release.

      NOTE: The Bookshelf plugin has been deprecated and its features have been merged into server or extracted into the ComicVine and GoogleBooks providers.

      Server Changes

      • Bookshelf has been split into separate GoogleBooks and ComicVine providers
      • Local book parsing has been improved and is available without plugins
        • Book metadata is extracted directly from OPF and ComicInfo files or ComicBookInfo comments
        • External covers are now supported for audiobook files
        • Posters are generated for EPUBs and all supported comic archives
        • Name, index, year, and series are parsed from book filenames
        • Both volume and chapter will be available in the API when present in comic filenames
        • Page counts are extracted from comic archives and PDFs
        • Creator names from OPF data are normalized to a common format
      • A new OpenLibrary plugin has been created for metadata and images
      • ISBN external IDs and links are supported
      • Chapters are now extracted from audiobooks

      Web Changes

      • Modern book library layout has been added with view types and paging
      • Books display information about their authors and vice versa
      • Playback interface has been redesigned and standardized across all book types
      • Progress indicator is enabled again for supported eBooks
      • Sorting books by index number, release date, etc is now available
      • Font size selection has been improved for EPUB files
      • Background audiobook playback is working on iOS devices
      • Authors, collections, and folders tabs have been added to book libraries, and audiobooks appear under authors
      • Fullscreen behavior is unified across all book players, and PDFs support swipe navigation

      Developers

      API Changes

      The API no longer allows the use of deprecated authorization mechanisms by default.
      Clients and tooling need to migrate if they haven't done so already. See #15559 for details.

      There have been a number of other changes to the SDK libraries and API as part of an ongoing effort to better document the API for client use.
      Please note the following with regards to API support.
      A full explanation of our policy for API changes will be added to the developer documentation in the coming months.

      • If an endpoint isn't listed in the OpenAPI specification it should not be used by clients.
        • There are certain endpoints that are still exposed for legacy reasons despite being excluded from the OpenAPI spec.
        • These can be removed in any major release without warning
      • If an endpoint or parameter is marked as obsolete in the OpenAPI specification it should not be used by clients.
        • Same explanation as above.
      • As a general rule, any deprecations will be marked as such for an entire (major) release cycle before the deprecated endpoint or parameter is liable for removal.

      Behavior changes clients should be aware of:

      • GetItems is now asynchronous and applies recursive when filters are requested, limited to requests that include includeItemTypes. The same query can return a different result set than it did on 10.11
      • ItemByName responses are restricted and people are deduplicated
      • Newly obsolete but still functional, with replacements:
        • GetTrailers -> use GetItems with includeItemTypes=Trailer
        • GetArtists and GetAlbumArtists -> use GetPersons
        • GetArtistByName -> use GetPerson
        • GetMusicGenre -> use GetGenre
        • GetInstantMixFromMusicGenreById and GetInstantMixFromMusicGenreByName -> use GetInstantMixFromItem
        • GetStartupConfiguration, UpdateInitialConfiguration, and SetRemoteAccess -> use the configuration endpoints
        • GetRecordingsSeries
        • UserDto.HasPassword is marked obsolete and no longer provides useful information
      • The HLS controllers are hidden from the specification

      Platform

      • The server now targets .NET 10. Plugins have to be retargeted and rebuilt
      • Swashbuckle has been updated to v10, which changes the generated OpenAPI document, so SDKs need to be regenerated
      • jellyfin-web now builds with Node 24 LTS and npm 11

      Plugin changes

      • ISearchEngine has been replaced by ISearchManager, and SearchEngine has been replaced by SearchManager together with SqlSearchProvider
      • Removed: NowPlayingQueueFullItems, DtoExtensions.AddClientFields, Jellyfin.Extensions.AlphanumericComparator, the ISubtitleWriter family of subtitle writers, and SubtitleOptions with SubtitleConfigurationFactory
      • ServerConfiguration.EncoderPreset is no longer nullable
      • IAuthenticationProvider.HasPassword has been removed
      • IPasswordResetProvider.StartForgotPasswordProcess takes the entered username and a nullable user
      • IUserManager: the Users and UsersIds properties are now the GetUsers and GetUsersIds methods, and RenameUser, ResetPassword, and ChangePassword take a user id instead of a User. GetFirstUser has been added
      • Several IItemRepository members moved to the new services: item saving and deletion and UpdateInheritedValues to IItemPersistenceService, counts to IItemCountService, and Next Up series keys to INextUpService
      • IPeopleRepository.GetPeople and ILibraryManager.GetPeopleItems return a QueryResult, and IDtoService.GetBaseItemDtos and ILibraryManager.DeleteItemsUnsafeFast have new signatures
      • IDirectoryService.GetFilePaths no longer takes a sort argument, and the IPathManager subtitle and attachment path getters are now nullable

      New plugin APIs

      This release adds several extension points that plugins could not hook into before.

      • Search providers. Plugins can now take part in search itself rather than only in metadata lookup. ISearchProvider exposes Name, Type, Priority, and CanSearch(SearchProviderQuery), with IInternalSearchProvider for providers that search the local library and IExternalSearchProvider for providers that stream SearchResult items from a remote service. Providers are registered through ISearchManager.AddParts and are consulted in priority order, so a plugin can extend or take over from the built-in SqlSearchProvider
      • Similarity and recommendation providers. ISimilarItemsProvider is split inherited by ILocalSimilarItemsProvider, IRemoteSimilarItemsProvider, and IBatchLocalSimilarItemsProvider, each with a generic variant so a provider can declare the item type it handles. Providers are selected and ordered per library through LibraryOptions.SimilarItemProviders and SimilarItemProviderOrder, and ISimilarItemsManager also pulls movie recommendations. The bundled ListenBrainz provider is built on this
      • Comic metadata providers. IComicProvider (ReadMetadata and HasItemChanged) lets a plugin supply comic metadata alongside the built-in ComicInfo and ComicBookInfo readers
      • Chapters for any item type. IChapterManager.SaveChapters now takes a BaseItem rather than a Video, and gained a Supports(BaseItem) check. This is what makes audiobook chapters possible, and it lets plugins save chapters for non-video items
      • Password resets for unknown users. IPasswordResetProvider.StartForgotPasswordProcess now receives the entered username along with a nullable user, so a provider can handle a request for a username the server does not know or hand the reset off to an external provider
      • Media segment cleanup. IMediaSegmentProvider.CleanupExtractedData is called when an item's data is pruned, so segment providers can remove their own extracted files
      • Schedules Direct. ISchedulesDirectService exposes available countries, service availability, and the image daily limit state, so Live TV plugins no longer need to reimplement them. ITunerHostManager.DeleteTunerHost allows removing a tuner
      • Alternate versions and linked children. Now that linked children are relational, ILibraryManager exposes ResolveAlternateVersion, GetLocalAlternateVersionIds, GetLinkedAlternateVersions, GetItemIdsWithAlternateVersions, and UpsertLinkedChild. Plugins that manipulated version links through serialized item data need to move to these
      • Batch APIs for bulk work. IUserDataManager gained GetUserDataBatch, GetResumeUserData, GetResumeUserDataBatch, and ResetPlaybackStreamSelections. ILibraryManager gained GetPeopleByItems, GetPeopleNamesByItems, and GetNextUpEpisodesBatch. IItemCountService offers batched child and played/total counts
      • Localization. ILocalizationManager.GetServerLocalizedString and GetLanguageDisplayName let plugins localize against the server locale
      • ICollectionManager.GetCollectionsContainingItem backs the Included In feature, and IPlaylistManager.AddItemToPlaylistAsync takes a position so items can be inserted at the top of a playlist

      IHasEmbeddedImage is also new, but it is only for plugins compiled into the server; external plugins should keep declaring their image with imagePath in meta.json.

      TLS Configuration

      In the previous release notes 10.11.0 we announced the deprecation of the built-in TLS certificate handling for this version. This change has been postponed to a future version.

      Discuss this release further on our forums.

      Changelog (460)

      🔒 Security

      🌟 Highlights

      🏗️ Enhancements

      📈 General Changes

    9. 🔗 Project Zero Testing race conditions with memory access tracing and stack-based delay injection rss

      Many security bugs are race conditions, where multi-threaded execution has to occur with the right interleaving for a negative effect to appear. This creates challenges for several use cases:

      • Confirming bug candidates that have been discovered manually or through static analysis.
      • Regression tests: After fixing a race condition bug, there is often no good way to write a regression test that reliably triggers the bug as part of a test suite.
      • Automatic bug discovery, such as fuzzing: It is hard for a fuzzer to exercise all interesting interleavings of concurrent operations, or reach code paths that are only exercised when operations are racing.

      I mostly discover bugs by manually reading code. When I think I’ve found a bug, I normally write a test case to either prove or disprove that the bug exists. For race condition bugs, it can be hard to achieve either outcome. For Linux kernel bugs, I often resort to recompiling the kernel after adding conditional mdelay() calls (which spinloop for roughly the specified amount of time) in appropriate places; I usually make these conditional based on the name of the running thread, though sometimes more complex conditions are needed. On platforms that support DTrace (like macOS and Windows), it is possible to use DTrace probes that call chill() for similar effect, though the utility of this is limited as DTrace can only trace on non-inline function boundaries or explicit trace points, rather than on every instruction. Regardless of platform, this approach can be time consuming and can require trial and error to definitely determine whether code is buggy.

      Additionally, in the Linux kernel, fixes for race condition bugs are often accompanied by hand-written ASCII diagrams showing problematic thread interleavings with call graphs and relevant memory accesses (for example, see this recent rt_spin_unlock UAF fix, or this recent jbd2 deadlock fix). It would be convenient to have developer tooling that can analyze potentially vulnerable code and show results in a similar representation.

      Summary

      I wrote tools for exploring possible interleavings of multi-threaded test cases for the Linux kernel:

      • A tool that automatically tests all possible A-B-A interleavings of a test case.
      • A terminal UI for manual exploration of possible interleavings.
      • A GUI for manual exploration of possible interleavings.

      The kernel part of this is intended to also be usable for discovering race conditions via fuzzing, but userspace tooling for that still needs to be implemented.

      The tools are available on GitHub under the name MAccConc, short for “Memory Access Concurrency”; see the README there for installation and usage instructions.

      If you just want to see the tooling in action, skip to Demo: automatic testing.

      If you’re just interested in the theory behind the tooling, read section Stable identifiers for memory accesses across runs: count-augmented stack traces.

      Prior work

      This project was inspired by discussions with Ned Williamson, whose sockfuzzer project involved exploration of concurrency bugs by using a custom scheduler that can reschedule at synchronization primitives to explore interleavings. See the conference talk slides and recording focused on the concurrency testing aspect of this.

      My tooling is largely based on ideas similar to SKI, but SKI uses a different implementation: It records memory accesses and controls scheduling of vCPUs using a patched version of QEMU in TCG mode, and uses VM snapshots to explore different execution interleavings.

      Discovering memory accesses that could contribute to race conditions

      (communication points)

      As described in the SKI paper, interesting execution interleavings of a given multi-threaded test case can be discovered by tracing memory accesses of all threads and searching for pairs of accesses on two threads that could interact with each other - meaning, roughly, that at least one of them is a write operation, and they access overlapping memory ranges. The SKI paper calls such memory accesses communication points.

      This requires some mechanism to collect memory access coverage. SKI did this by patching QEMU’s TCG mode; I am instead relying on ASAN instrumentation in “outline” mode (compiler backend flag asan-instrumentation-with-call- threshold=0, selected by CONFIG_KASAN_OUTLINE in the Linux kernel), which generates helper function calls on memory access. I believe that the kernel is the right place to collect this data because it would allow the kernel to also provide higher-level information about lock acquire/release events and such, though I have not implemented this at this time. Implementing this in the kernel also means that it would theoretically be possible to test on bare- metal hardware, rather than inside VMs.

      Since Linux already has KCOV as a mechanism to feed basic block kernel coverage information to userspace, I decided to use the same mechanism to record information about memory accesses. An alternative would have been to use ftrace, which is oriented towards tracing use cases, and includes a function graph tracing mode built on fentry hooks and more complex output buffer management that is oriented towards use cases including system-wide data collection. I chose to use KCOV because of its simpler in-memory representation of trace data (which could become relevant for recovering trace data from crashed VMs); because it uses static always-on instrumentation rather than runtime-enabled instrumentation with near-zero overhead in disabled state; and because my impression is that KCOV is designed for higher-frequency trace events than ftrace.

      Implementation detail: ASAN and TSAN

      ASAN normally merges helper calls for subsequent memory accesses. To receive one callback per memory access, the kernel patches explicitly disable this compiler optimization using the asan-opt-same-temp backend flag.

      ASAN is intended for identifying UAF, so it does not emit helper calls on direct stack memory access unless there is potential for out-of-bounds access. This means that some race conditions involving on-stack objects, such as wait queues, may not be detectable with this. ASAN also by default emits no helper calls for access to globals, but this optimization can be disabled using the asan-opt-globals backend flag.

      An alternative would be to use TSAN instrumentation instead, which is designed for detecting data races and also provides information about access atomicity. The downside of TSAN instrumentation is that compilers do not support emitting both ASAN and TSAN hooks at the same time - so to still have working detection of memory safety violations (like UAF) while using TSAN hooks, it would be necessary to run the kernel’s ASAN implementation off of the TSAN hooks or change the compiler.

      Implementation detail: KCOV and background work

      Some race conditions involve background work, for example:

      • receive processing of loopback network packets
      • RCU callbacks

      KCOV can optionally collect remote coverage for background work in some subsystems; however, in upstream Linux, most types of background work that would be interesting for me are not yet integrated with this mechanism, and remote coverage is currently mainly used for fuzzing subsystems that handle incoming data from devices, like bluetooth and USB.

      Enabling this for other parts of the kernel should be relatively straightforward, and I have a draft patch for doing this for RCU callbacks.

      Stable identifiers for memory accesses across runs: count-augmented stack

      traces

      To test out different orderings of memory accesses, a way to stably identify interesting memory accesses across test case executions is needed. Identifying memory accesses based on the data address would not work if the data address was located in an object which is freshly allocated during each test case execution; and identifying memory accesses solely by instruction address would not work well if the memory access was in a function like memcpy() or spin_lock().

      SKI solves this using VM state snapshots, so that each execution starts from the same global state.

      I am instead identifying memory accesses with count-augmented stack traces, where each stack trace element essentially consists of a callee function address and a number indicating how many calls to this callee should be skipped in the calling stack frame.

      An example of the semantics of a count-augmented stack trace would be something like: “On this thread, look at the second call to __x64_sys_recvfrom, then within that, the first call to __sys_recvfrom, then within that the first call to sock_recvmsg, then within that, the first call to unix_stream_recvmsg, then within that, the first call to unix_stream_read_generic, then within that, the second call to _raw_spin_unlock, and then within that, the first memory access at instruction address X”.

      This unambiguously identifies a point in an execution trace, is independent of concrete data addresses, and is relatively stable with regards to changes in the control flow of irrelevant parts of the trace.

      To make this work, KCOV must provide information about function entry/exit events so that when userspace is parsing KCOV coverage output, it can keep track of how the call stack changes. Doing this nicely requires compiler support as part of SanitizerCoverage; I landed an LLVM feature patch for this a few months ago (see documentation), which landed in the LLVM 23.1.0 release.

      Forcing execution orderings with delay injection

      To force specific execution orderings through KCOV, I implemented an ioctl KCOV_SET_DI using which userspace can request that actions (essentially wait/wake) are taken on memory accesses at specific count-augmented stack traces. (See documentation in my kernel branch.) Each action either sets one flag, or waits for one flag to be set, at a userspace-provided index in a shared array of flags. The possible action types are:

      • DI_STACK_WAKE_PRE: before the memory access, set flag N
      • DI_STACK_WAIT: before the memory access, spin-wait until flag N is set
      • DI_STACK_WAKE_POST: after the memory access, set flag N

      With the same ioctl, userspace also configures an upper limit on spin-wait iterations.

      Additionally, there are ioctls for userspace to directly interact with the same flags.

      This API enables two different ways of using delay injection: constraint-style delay injection and fully-specified ordering.

      Constraint-style delay injection (A-happens-before-B)

      Userspace can set up a series of A-happens-before-B constraints, where each such constraint is implemented as a pair of actions in different threads that operate on the same flag:

      • DI_STACK_WAKE_POST for the access that should happen first
      • DI_STACK_WAIT for the access that should happen second

      With this approach, the execution ordering is left partly non-deterministic. This is what the GUI and terminal UI tools currently implement.

      An advantage is that this is somewhat more intuitive for simple cases; however, it requires recording timing information to show the user approximately in what order events happened, and it can make the execution trace more complicated. It also often requires more constraints than a fully specified ordering, and is more complicated to reason about.

      Fully specified ordering (context-switch-style)

      Userspace can decide on a specific ordering in which events should occur, by picking points at which execution should transfer from one context to another. For the simple case with two execution contexts, this requires that thread A starts running a syscall while thread B begins by spin-waiting on a flag; then when thread A reaches some count-augmented stack trace, thread A uses a combination of DI_STACK_WAKE_PRE and DI_STACK_WAIT to pause its own execution and let thread B continue; and later, thread B can do the same to switch back.

      This is the approach I used for the automatic A-B-A interleaving tester.

      Demo: automatic testing

      I’ll explain more background below; but first, here are two shiny demos on a toy example!

      This is an example of using the automatic A-B-A interleaving tester on this test case with concurrent dup(5) and close(5) calls:

      #define _GNU_SOURCE
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

static int test_fd;
static int dup_res, dup_errno;

void test_setup(void) {
  test_fd = open("/", O_PATH);
}

void test_thread1(void) {
  dup_res = dup(test_fd);
  dup_errno = errno;
}

void test_thread2(void) {
  close(test_fd);
}

void test_end(void) {
  printf("dup(%d) = %d (%s)\n",
      test_fd,
      dup_res,
      dup_res == -1 ? strerror(dup_errno) : "success");
}

      It discovers one ordering where dup(5) returns 5, which is working as intended but might be a somewhat surprising result:

      sh-5.3# ./kcov-autorace testcase/demo-dup-vs-close.so
loading kallsyms
RCU state (excluded): base=ffffffff82970100 len=500
loading testcase
initializing kcov
collecting A-B coverage
dup(5) = 6 (success)
testing candidates
dup(5) = -1 (Bad file descriptor)
dup(5) = -1 (Bad file descriptor)
dup(5) = -1 (Bad file descriptor)
dup(5) = 5 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
stats:  injection-failed:0  wait-timeout:7  reordered:4
sh-5.3#

      Demo: GUI

      And here is an example of me using the GUI on the same test case, using it to manually force an ordering where dup(7) returns 7.

      First, I launch the GUI, then run the test case once in the guest:

      sh-5.3# ./kcov-vsock-client testcase/demo-dup-vs-close.so
dup(7) = 8 (success)

      At this point, no ordering constraints are enforced yet; dup() and close() are racing randomly. The GUI shows in what order execution happened:

      This current view just shows function call graphs from both threads (thread 1 with black indent, thread 2 with red indent). The close() syscall happened to execute after dup() this time. Normal functions are shown in black; inline functions are shown in green, but only shown if they called a normal function (since “all inline functions” is not ticked).

      Ticking “filter to communication points” shows a bunch of memory accesses in blue, which are communication points (as defined above, in short: reads from locations to which other threads write and writes to locations which other threads access; kfree() counts as a write operation). Each memory access line shows the type of access (Read/Write/Free), data address, access size, and the memory value before the access. Hovering over an access highlights all overlapping accesses in yellow.

      Left-clicking on a memory access shows a view that is instead filtered to only show memory accesses overlapping the selected access. Note that this can show reads that were not identified as communication points (because all writes happen on the same thread).

      Left-clicking a function name shows a source code view on the right, interspersed with trace data. Data values loaded by memory reads are shown in red (under the source line and column to which the compiler attributes the access); data writes are marked similarly with a red “WRITE”; memory accesses that are communication points are prefixed with “INTERFERENCE” in orange. Function calls are shown in blue.

      By right-clicking on two memory accesses in the call graph view, it is possible to create an ordering constraint between the two accesses, such that the kernel will attempt to make the first selected access happen before the second selected access. Each ordering constraint is shown on the right side, represented as two count-augmented stack traces. Note that the last bottom element of the stack actually identifies a specific instruction, but the UI doesn’t really show this. Also, the count-augmented stack traces shown here do not include inline functions.

      In this case, I have created one ordering constraint that orders the second file descriptor table access in __fget_files_rcu() (which is inlined into __fget_files()) before the file descriptor table entry removal in file_close_fd_locked() (which is inlined into file_close_fd()). This ensures that the file descriptor table lookup in dup() successfully looks up the file descriptor table entry before it is cleared by the concurrent close().

      I have created another ordering constraint that orders the spin_unlock(&files->file_lock) in file_close_fd() before the spin_lock(&files->file_lock) in alloc_fd() so that the file descriptor table entry has been released by the time dup() searches for an unused entry.

      In this view, ordering constraints have been specified, but the test case has not yet been run with this specified ordering.

      (This view is filtered to show accesses to the files_struct::file_lock.)

      Now, re-running the test case shows:

      sh-5.3# ./kcov-vsock-client testcase/demo-dup-vs-close.so
dup(7) = 7 (success)

      And the new trace appears in the UI, with brown “DELAY INJECTION” lines interspersed to show how the ordering constraints were applied.

      Note that the UI shows the ordering of events based on timing information that is associated only with memory accesses; the placement for any event other than a memory access is inferred based on that. In views filtered by data accesses, function entry events are additionally only shown at the time of the first displayed non-function-entry event. For example, in the following screenshot, the first thread may have already entered get_unused_fd_flags() by the time file_close_fd() called spin_unlock(), even though the events are shown the other way around. However, memory accesses should be shown in approximately the right order; with the caveats that the order of memory accesses might be wrong if events happened at the same clock value, and that timing information is recorded by instrumentation that runs directly before the actual access. (Building the tool on fully specified orderings instead would avoid such caveats.)

      (This view is filtered to show accesses to the file descriptor table entry.)

      More documentation is available inside the GUI.

      Implementation status

      For LLVM: The required patch has landed in LLVM 23.1.0.

      For the Linux kernel: The required patches are not yet in the upstream kernel. I am posting the Linux kernel patch series for upstream review around the same time as this blog post; a git branch with my patches is also available on github (with a few more patches that aren’t yet ready for upstreaming). If you want to test this tooling, you will need to use my kernel branch for now. (See the README in the tools repository for build instructions.)

      My kernel patches are in a clean state; the userspace tooling is a bit more hacky, in particular the GUI implementation.

      The command-line tooling can only handle two concurrent threads, while the GUI can handle additional execution contexts (with the kcov-vsock-client harness: background work launched by thread A).

      I am looking forward to hearing if this is useful to others, and maybe even what tools others manage to build on top of this! Feel free to reach out to me (for example via email to maccconc-tooling@google.com).

      Future work

      Use fully specified orderings instead of constraint-style for manual

      tooling

      The non-automatic tooling currently uses constraint-style delay injection; but as described above, fully-specified orderings have several advantages, including more deterministic behavior. I might change the GUI implementation to use fully-specified orderings instead in the future.

      Type information for human-readable memory access traces

      For reading memory access traces as a human, it might be helpful to provide information on the object types that are being accessed. One way to do this would be to follow what Microsoft’s debugging tools can do with CodeView debuginfo and use debuginfo to associate memory allocation function call sites with type information, then let the allocator track the call sites from which objects have been allocated.

      I proposed to add such a feature to the DWARF standard, which has been accepted and is included in the current DWARF 6 draft (search for DW_AT_alloc_type), and added enough support to LLVM to make it work in the same cases where it already worked with CodeView; but so far that only works for C++ new calls, I did not land the changes necessary to make it work for malloc.

      Making this work in the kernel would require infrastructure that either queries allocator metadata for every memory access record or provides an initial snapshot of heap allocator metadata across the system plus metadata about subsequent memory allocations.

      Higher-level memory access feedback

      One inefficiency in my current prototype is that userspace receives no information about the semantics of locking operations. If two threads each perform lots of memory accesses on an object while holding a lock protecting the object, this will generate a large number of potential communication points, but actually a locked section just represents one big communication point. It might be helpful if the kernel provided “lock acquired” and “lock about to be released” events.

      But that might not be a very general approach, since impossible orderings caused by locking are not so different from impossible orderings caused by things like an object being initialized before it is published to a global pointer or such.

      Detecting impossible orderings faster: Deadlock detection

      In my current implementation, when an attempt is made to force an impossible ordering via delay injection, the result is that one thread spins/waits on a lock until another thread reaches the delay injection timeout, which is inefficient. It might help to have integration with lock debugging infrastructure that can detect such a semi-deadlock in simple cases and abort the test case faster.

      Fuzzing: Building up test cases with potential communication points like

      Snowboard

      Snowboard (a project that searches for concurrency bugs caused by interaction between fuzzer-generated single-threaded test cases) used recorded information about memory accesses in single-threaded test cases to identify which test cases could have interesting communication points when executed in parallel. It would be interesting to build something similar on top of this KCOV-based instrumentation.

      It might also be interesting to use this for single-threaded test case creation: Start by collecting memory access coverage for individual system calls, then use that to determine which syscalls might interact with each other in interesting ways when executed in sequence, and build up longer system call sequences this way.

      This would be easier using VM snapshots (like SKI), since my approach does not lead to stable data addresses across test case executions; but it would probably be possible by identifying memory locations that are different between test cases abstractly based on allocation sites, as long as allocation site information is available for all objects that are allocated per test case execution.

      KCOV output to host-shared memory

      My current tooling loses KCOV output if the kernel under test panics, so it can’t be used for displaying what happened when a kernel crash occurred.

      For use cases where the kernel under test is a KVM guest, it might be useful to give the host direct access to the KCOV output buffer. One way to do this might be to use pages in a file on virtiofs with DAX as the KCOV output buffer, and allow writing KCOV output into userspace-provided pages.

    10. 🔗 HexRaysSA/plugin-repository commits add Lumice/BinaryLens to known repositories rss 
      add Lumice/BinaryLens to known repositories
    11. 🔗 WerWolv/ImHex Nightly Builds release

      Nightly

      867b6e7 Changelog

      • fixes: for pattern editor. (#2885)
      • fix: Pattern tree re-requested keyboard focus every frame (#2881)
      • patterns: Add support for including files relative to current pattern file
    12. 🔗 Ampcode News Steer, Don't Queue rss

      When you send a message while the agent is working, it's now delivered at the next possible opportunity, instead of being queued until the agent finishes its turn.

      This means the agent acts on your feedback sooner and doesn't waste time on unnecessary verification steps.

      Most people won't need to change how they use Amp.

      If you do find Amp steering too abruptly, we've found that it works well to phrase your prompts like "When done, then ..." instead of "Now, ...".

      Ship, Review, and other builtin actions still queue, because usually you want to wait until the agent is done before shipping or getting a review.

      If needed, you can still queue from Amp or queue in the Amp CLI.

  3. September 07, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-09-07 rss

      IDA Plugin Updates on 2026-09-07

      New Releases:

      Activity:

      • ida-domain
        • e0c16a90: Add support for decompiler strings #120 (#121)
      • ida-forge
        • a88cebfb: Port fork fixes and harden recovery pipeline
      • ida-nexus
      • ming-skills
        • 82f19585: perf(supply-chain): parallelize freshness and cache lockfile reports
        • 1459745f: feat(router): add quality gate governance composition
        • 5ee886b2: fix(gate): align sca failure schema, forbid additional failure proper…
        • 31799b6f: fix(gate): forbid additionalProperties in sca validation and add runn…
        • 8d501f61: fix(gate): validate sca finding via string elements and reject unknow…
        • c406bbfa: fix(gate): align sca schema range null, validate flag values, and ext…
        • 8c8d107e: fix(gate): fix sca freshness false positive, hook planner, verify jso…
        • e93e83ab: docs: bootstrap repository documentation and comprehensive architectu…
        • a5609953: feat(hooks): introduce pre-push gate, verify orchestrator, and batch …
        • 1822117e: perf(tests): run isolated cli integration scenarios via bounded async…
        • 379b6d11: feat(hooks): implement explicit affected impact planner and contract …
        • 851bea70: test(observability): add preflight failure scenarios for sync.failed …
        • ffb60848: test(lint): add contract tests for lint text json and event modes
        • afc78379: fix(supply-chain): strengthen artifact schema validation and add opt-…
        • f3b57016: fix(benchmarks): parse -strict flag and wire strict assertions into …
        • 95f8940d: test(benchmarks): restore 500-iteration sample size and decouple hard…
        • 7aa216f2: feat(router): extend engineering triggers for repository documentatio…
        • 6eaab460: fix(observability): ensure sync.failed event is emitted on all fatal …
        • 6346d2f0: docs(hooks): clarify pre-commit test runner invocation and separate f…
        • c9d2fec0: fix(lint): eliminate duplicate counter increments in human readable r…
      • Persona4-Decompilation
        • 876687ce: Define task forwarding and enemy bitmap boundary behavior
        • 865a99a0: Unify ending-staff resource accessor pointer contracts
        • 9e6d2a8a: Restore explicit ending-resource ownership release
        • 88c28a3f: Simplify triangle normal candidate and verify caller boundaries
        • 03a6003c: Define archived label wrapping and verify compact consumers
        • a700674e: Refine shuffle initializer floor and verify order preconditions
        • 75fa8c0d: Recover sound start routine with explicit argument forwarding
      • plugin-ida
        • 207fd202: chore(deps): Bump step-security/harden-runner from 2.21.0 to 2.21.1 (…
    2. 🔗 Locklin on science Q3 books 2026 rss

      Saga of the Volsungs translated by Jesse Byock. Read this on a plane flight. It’s been a long time (decades) since I read the Sagas, and the last one was Beowulf which isn’t as savage as this one. Lots of blood and guts. Lots of war and vengeance. Of course I had seen the Wagner […]

    3. 🔗 HexRaysSA/plugin-repository commits sync repo: +3 releases, -1 release rss 
      sync repo: +3 releases, -1 release

## New releases
- [ida-nexus](https://github.com/hexrayssa/ida-nexus): 0.10.7, 0.10.6, 0.10.5

## Changes
- [ida-codemode](https://github.com/hexrayssa/ida-codemode):
  - removed version(s): 0.2.0
    4. 🔗 smol-machines/smolvm smolvm v1.14.2 release

      What's Changed

      • Let an explicit --cpus or --mem that equals the default still override the Smolfile and pack values by @BinSquare in #1177
      • Bump libkrun for the Windows virtiofs DAX fixes and rebuild the bundled libraries by @BinSquare in #1184
      • Resolve a Smolfile image the same way as the --image flag so a local archive is not sent to the registry by @BinSquare in #1182
      • Keep a released clone alive when the branch helper is its main process, and hand the child its identity through the helper itself by @BinSquare in #1178
      • Say checkpoint, not snapshot, in the branch command's messages and help by @BinSquare in #1186
      • Run init commands as root, since they provision the machine and the user directive names who the workload runs as by @BinSquare in #1188
      • Document the branchpoint contract and say how to reach one when a batch branch waits by @BinSquare in #1183
      • Bump the workspace to 1.14.2 by @BinSquare in #1185

      Full Changelog : v1.14.1...v1.14.2

    5. 🔗 r/Harrogate Run clubs? 27yr old M rss

      Run clubs? 27yr old M | Hi currently working on making an app, and training for Royal Marines reserves next year. Any running club or buddy or gal would be great Also go pure gym in town & hydro for swimming and sauna submitted by /u/FrontRaspberry5060
      [link] [comments]
      ---|---

    6. 🔗 Rust Blog Rust debugging survey 2026 results rss

      One of the biggest challenges Rust developers report in our annual surveys is a subpar debugging experience. So, back in February, we ran our first Rust Debugging Survey, in the hopes of identifying how Rust developers are using debuggers and what problems they are facing when doing so. We received over 2,300 responses, and we'd like to thank everyone who took the time to participate in the survey!

      In this report, we'll go over some of the results of the survey. If you'd like, you can also check out the complete results of the survey.

      If you'd like to skip ahead to any particular section, you can do so with this index:

      Who Uses Debuggers?

      The first step to making sense of the survey results is understanding who took the survey. We asked respondents to rate their Rust expertise, from "Never used it" to "Advanced". Over 80% reported themselves as "Advanced" or "Intermediate", split roughly evenly between the two:

      how-would-you-rate-your-rust-expertise

      [PNG] [SVG]

      We also asked respondents if they currently use or have used debuggers in Rust. Over 46% said they currently do, with the remaining responses split between "have in the past" and "never have". That means that over half of respondents do not currently use a debugger for Rust!

      do-you-use-debuggers-in-rust

      [PNG] [SVG]

      Categorized by expertise, the responses reveal that roughly half of "beginners" have never used debuggers in Rust! On the other hand, nearly half of "advanced users" currently do use debuggers in Rust:

      do-you-use-debuggers-in-rust-per-expertise

      [PNG] [SVG]

      For respondents who indicated they had previously used Rust but no longer did, we asked if challenges with debugging support were why they stopped. For nearly 3%, the answer was "yes", with an additional 24% reporting debugging issues as being partially responsible (though mind the small response count; most respondents were active users of Rust):

      were-issues-with-debugging-support-the-primary-reason-why-you-stopped-using- rust

      [PNG] [SVG]

      How Are Debuggers Used?

      Knowing what debuggers developers are using and how is another important part of understanding the challenges they face. To this end, we asked respondents how they were debugging their programs. Unsurprisingly, most developers make use of print debugging and the dbg! macro. Excluding those, using lldb inside an IDE was the most popular choice, followed by gdb on the command line:

      what-tools-and-workflows-do-you-use-to-debug-rust- programs

      [PNG] [SVG]

      We can get a more detailed breakdown of these results if we include the operating system on which the respondents use a given debugging approach. We examine this from two different angles. The first angle being, "On operating system X, what percent of responses are using debugger Y?". Print debugging and the dbg! macro are consistently the top two yet again, but looking beyond that, things get more interesting. On Linux, using gdb on the command line was the most popular choice by a thin margin, beating lldb in an IDE by only 0.4%. On Windows, Windows Subsystem for Linux (WSL), and macOS, lldb in an IDE was the top pick by at least 6%, making it a very popular choice in general. On Windows, the three least popular choices were the command line debuggers (gdb CLI, lldb CLI, and BugStalker), and on both Windows and macOS the third most popular pick was, "I don't know". Those who were debugging on operating systems not listed (Other) most frequently used some kind of special embedded debugger or gdb:

      what-tools-and-workflows-do-you-use-to-debug-rust-programs-per- os-1

      [PNG] [SVG]

      The other angle we can look at these responses from is, "For users of debugger X, what percent of responses are using it on operating system Y?". For most debuggers, Linux makes up the largest portion of uses, ranging from about 45% to about 77%, followed by Windows, then macOS. The most notable exceptions are WinDbg and the Visual Studio debugger, which are primarily used on Windows, and lldb, which is used more on macOS than Windows in an IDE and on the command line:

      what-tools-and-workflows-do-you-use-to-debug-rust-programs-per- os-2

      [PNG] [SVG]

      To the 6 respondents who use WinDbg on Linux: we wish you luck!

      As for how people actually use their debugger of choice, the aggregate results are not particularly surprising. Roughly 87% of users are using debuggers for stepping line-by-line through programs and a little over half of users are using debuggers to obtain stack traces from hung/crashed processes. Only a quarter of the respondents use a debugger to debug async code. That might be partially caused by the async Rust debugging experience being clumsy and incomplete, or it could just be that users aren't writing much async code:

      what-are-you-using-debuggers-for

      [PNG] [SVG] [Wordcloud of open answers]

      If we break these results down by expertise, we can learn a bit more about usage patterns. As users become more experienced with Rust, their use of debuggers for learning purposes decreases, and they get more stack traces from crashed processes:

      what-are-you-using-debuggers-for-per-expertise

      [PNG] [SVG]

      The final bit of insight into how Rustaceans use debuggers is if they are debugging programs that use Rust alongside other programming languages. For 44% of respondents, the answer is "yes", which is a pretty high number!

      As for which languages those are, C dominates the scene at a little over 70%, followed by C++ at about 43% and Python at about 20%:

      do-you-debug-programs-that-combine-rust-with-any-of-the-following- languages

      [PNG] [SVG] [Wordcloud of open answers]

      Challenges

      Instead of diving right into asking, "what problems do you face when using debuggers?", or something to that effect, we first asked respondents why they decide against using debuggers whenever they do, including for reasons that aren't necessarily "problems with debuggers".

      The most commonly reported reason was that it was easier or faster to use logs or print debugging to solve problems, reported by a little over 81% of respondents. This could partially be explained by the open responses, which featured complaints that debuggers were too difficult to set up and/or use (especially on Windows, when dealing with Web Assembly, or in embedded contexts) and sentiment suggesting that small and/or simple problems just don't really need a debugger. It does leave one wondering if the user experience could be made convenient enough to dethrone print debugging, but it seems hard to beat something so intuitive. This is followed by roughly 37% of respondents who write code that Just Works. Fair enough. After that, about 26% of respondents indicated that they've decided not to use debuggers in situations where the language features they were working with had poor support. This is slightly more than issues with standard library types, at about 22%, which is slightly more than issues with external library types, at about 20%:

      when-you-dont-use-a-debugger-why-dont-you

      [PNG] [SVG] [Wordcloud of open answers]

      As stepping through code was anticipated to be one of the most common uses for debuggers, we directly asked respondents if they faced any issues when doing so. A little over 51% of respondents said they did! Of those who reported that they experienced issues stepping through code, we asked when they were experiencing issues. Async code was the most common case reported at slightly over 28%, followed by code involving macros at about 23%. The least common case reported was code involving function pointers, at almost 6%:

      when-do-you-experience-issues-with-trying-to-step-through-code-with-your- debugger

      [PNG] [SVG] [Wordcloud of open answers]

      We also directly asked respondents which types in the standard library were hard to work with, if any. This was an open-response question, and reading through the responses, some particularly common complaints were with enums and collections, particularly std::collections::HashMap and std::vec::Vec. This is also visible in the word cloud in the full report.

      We asked respondents to indicate which pain points, if any, they have encountered when using debuggers with Rust. At slightly over 74%, poor representation of values was the most common pain point by a decent margin, followed by being unable to print variables at just over 55%:

      which-of-these-pain-points-have-you-experienced-using-a-debugger-with- rust

      [PNG] [SVG]

      Debugger Visualizers

      We asked respondents to indicate if they were library authors, and if so, if they were aware of and using the debugger_visualizer attribute. Nearly 62% of respondents indicated that they were library authors who were not aware of this attribute:

      if-you-are-a-library-author-are-you-aware-of-and-using-the-debugger- visualizer-attribute

      [PNG] [SVG]

      For those who indicated that they were library authors who knew about the attribute but did not use it, we also asked why. This represented a much smaller fraction of respondents, so keep that in mind! That said, half of these library authors indicated that they didn't have the time to maintain visualizer attributes, and just under half indicated they didn't know how to write visualizer scripts:

      why-dont-you-use-the-debugger-visualizer-attribute

      [PNG] [SVG] [Wordcloud of open answers]

      For those of you who have been reading this section asking yourself what the debugger_visualizer attribute is, you can read up on it in The Rust Reference: Debugger Attributes. The quick explanation is that the debugger_visualizer attribute can be applied to modules or the crate root to embed files in the debug information which improve the display of values with certain debuggers. The two currently supported file types are Natvis files, used by Microsoft debuggers such as WinDbg, and GDB "pretty printers", which are structured Python scripts used by GDB.

      Closing Remarks

      Thanks to your participation in this survey, we've gained some great insights about how Rustaceans are using debuggers and what issues they are facing. For example, knowing that such a high number of users are dealing with poor representation of values pairs well with knowing which standard library types are causing issues, knowing that many library authors haven't heard of the debugger_visualizer attribute, and knowing that many of those who have but don't use it either don't know how or don't have time to maintain visualizer scripts.

      Looking to the future, the survey results have suggested that there are a few notable ways we could most significantly improve the debugging experience in Rust, such as:

      • Fixing the way enums are represented by debuggers so they show actual variants
      • Fixing the way collections (such as HashMap) are represented by debuggers so they show their contents, rather than their implementation details
      • Fixing the way string types (such as String and CString) are represented by debuggers so they render as text, rather than their implementation details
      • Improving the async debugging experience, particularly with stack traces
      • Improving stepping through certain state machines (such as iterators and Futures)
      • Providing documentation on basic set up and use of some common debuggers

      A common suggestion that could resolve those first three points is to use the Debug implementation of types to display them in debuggers. There are challenges to that approach, such as the fact that the Debug implementation is not present in the final binary unless it is actually used somewhere in the program, but it isn't impossible. Notably, this is already supported by the BugStalker debugger (given the same condition that the Debug implementation must actually be used), which some of you first heard about from the survey! It also appears to have some support for async, with plans to expand.

      One notable way the debugger experience is currently being improved is through the ongoing Google Summer of Code project improving how we test debug info and visualizer scripts, making it easier to maintain and improve our own visualizer scripts and general compatibility with visualizer scripts without silent breakage or regressions.

      Once again, we'd like to thank everyone who took the time to participate in the survey!

  4. September 06, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-09-06 rss

      IDA Plugin Updates on 2026-09-06

      Activity:

    2. 🔗 r/Harrogate Guitar set up service? rss

      Anywhere locally I can get an electric bass guitar set up? Thanks.

      submitted by /u/LimpMoment6768
      [link] [comments]

    3. 🔗 smol-machines/smolvm smolvm v1.14.1 release

      What's Changed

      • Bind-mount containerd state to /storage in the docker-in-vm example (#1159) by @BinSquare in #1160
      • chore(nix): bump flake to 1.14.0 by @BinSquare in #1161
      • Fetch and unpack image layers concurrently instead of one at a time by @BinSquare in #1162
      • Remove internal design notes from the user-facing docs by @BinSquare in #1163
      • Accept --init on machine run and keep what init writes to /workspace in the init-layer cache by @BinSquare in #1165
      • Resolve the agent rootfs the same way for pack create, checkpoints, serve and machine boot by @BinSquare in #1166
      • Propagate branchpoint arming into exec sessions by @BinSquare in #1167
      • Show full machine names in machine ls and add --quiet to list just names by @BinSquare in #1169
      • Carry the workload user through the embedded runtime so SDKs can set it by @BinSquare in #1171
      • Accept a user on the exec and run API so a caller can run a command as a chosen account by @BinSquare in #1172
      • Bump the workspace to 1.14.1 by @BinSquare in #1170

      Full Changelog : v1.14.0...v1.14.1

    4. 🔗 HexRaysSA/plugin-repository commits sync repo: +3 releases rss 
      sync repo: +3 releases

## New releases
- [IDA-Spotlight](https://github.com/dyussekeyev/ida-spotlight): 0.1.3
- [ida-mcp](https://github.com/hexrayssa/ida-mcp): 0.10.4
- [llm-explainer](https://github.com/pgarba/ida-llm-explainer): 1.13.0
    5. 🔗 smol-machines/smolvm smolvm v1.14.0 release

      What's Changed

      • Preserve fork checkpoints across runtime restarts by @BinSquare in #1065
      • Support one-to-one port ranges in Smolfiles and CLI mappings by @fgrehm in #1066
      • Add portable live checkpoints by @BinSquare in #1067
      • Warn when a saved registry token has expired instead of surfacing a bare 401 by @BinSquare in #1068
      • Serve a browser client on the VNC port so a machine's desktop opens in any browser by @BinSquare in #1070
      • Bump the workspace to 1.13.1 by @BinSquare in #1071
      • Add low-latency H.264 browser streaming by @BinSquare in #1073
      • Support portable checkpoints for image-backed services by @BinSquare in #1076
      • Stop typing stalling behind a frame wait and stop held keys repeating twice by @BinSquare in #1077
      • fix(fork): resync clone wall clock after restore by @Bnjoroge1 in #1080
      • Fix portable checkpoint restore startup by @BinSquare in #1078
      • Keep Linux fork sources running by @BinSquare in #1081
      • Keep macOS fork sources running by @BinSquare in #1082
      • Pin libkrun to the merged continuation commit by @BinSquare in #1083
      • Report why a container failed to create and stop the Vulkan injection shadowing image libraries by @BinSquare in #1084
      • Keep the VNC session alive when a client announces its clipboard or asks to resize the desktop by @BinSquare in #1085
      • Make checkpoint rollback roots safely forkable by @BinSquare in #1087
      • Expose the portable checkpoint lifecycle by @BinSquare in #1091
      • Accept an aarch64 checkpoint on any host providing the features its guest was given, and name the ones that are missing by @BinSquare in #1101
      • Capture a Windows machine's console output so a failed boot leaves a record by @BinSquare in #1102
      • Take the machine's storage read-only on shutdown so its filesystem is left clean by @BinSquare in #1100
      • Pull a machine's image again when the guest no longer holds it by @BinSquare in #1106
      • Document the S3 volume source in machine run's --volume help by @NickyHeC in #1104
      • Parallelize direct batch fork admission by @BinSquare in #1103
      • Set SSH_AUTH_SOCK for interactive runs so --ssh-agent works with -i/-t by @Qhilm in #1109
      • Allow explicit read-only system mounts by @BinSquare in #1110
      • Improve host mount performance and coherence by @BinSquare in #1112
      • Rewrite the README's em-dash asides by @BinSquare in #1113
      • Make branching the primary machine lifecycle by @BinSquare in #1118
      • [Public Docs] Point contributors at the docs repository from the README by @NickyHeC in #1092
      • Refresh libkrun with snapshot-safe vsock handling by @BinSquare in #1099
      • Improve host mount performance and coherence by @BinSquare in #1114
      • Fix squashed pack ownership when smolvm runs as root (#1095) by @BinSquare in #1096
      • Stop the Vulkan driver injection from shadowing a workload's own libraries by @BinSquare in #1120
      • Process virtio-fs requests on parallel queues by @BinSquare in #1121
      • Refresh libkrun directory metadata handling by @BinSquare in #1125
      • Explain why a branch was refused and show what each machine was branched from by @BinSquare in #1127
      • Add staged mounts for metadata-heavy workloads by @BinSquare in #1126
      • Make the browser desktop responsive by @BinSquare in #1123
      • Run the aarch64 Omarchy desktop on the GPU on macOS hosts by @BinSquare in #1119
      • Fix stale serve locks after out-of-band stops by @BinSquare in #1128
      • Fix arm64 forks on heterogeneous CPUs by @BinSquare in #1130
      • Ship the containerd shim in the Linux release so Kubernetes support is reachable by @BinSquare in #1132
      • Build the containerd shim by package name and ship the engine its installer needs by @BinSquare in #1133
      • Install the compressed disk templates so pack create works without e2fsprogs by @NickyHeC in #1122
      • Serve the VM boot subcommand from the containerd shim so it needs no separate engine binary by @BinSquare in #1136
      • Stop the Venus bridge logging on every fence poll and reading scanouts back from unbound or foreign images by @BinSquare in #1137
      • Unpack packed layers into a staging directory and rename them into place so a layer directory only ever exists once it is complete by @BinSquare in #1140
      • Give the macOS Omarchy desktop a working top bar and clickable browser chrome by @BinSquare in #1138
      • Handle agent socket write backpressure by @BinSquare in #1145
      • Rebuild the bundled libkrun and macOS virglrenderer from the merged sources by @BinSquare in #1141
      • Speed up large OCI image preparation by @BinSquare in #1144
      • Bind the guest's /dev/net/tun into VM-grade workloads by @BinSquare in #1146
      • Park idle branchpoints until capture by @BinSquare in #1147
      • Add a user directive to the Smolfile and a --user flag by @BinSquare in #1148
      • Sweep fork-source lock files whose machine is gone instead of leaking one per name by @BinSquare in #1155
      • Accept net_backend in a Smolfile so a checked-in file fully describes its networking by @BinSquare in #1156
      • Report how the VM process ended when a command fails because it died by @BinSquare in #1154
      • Let the Omarchy recipe install a pinned package set and survive a rerun by @BinSquare in #1152
      • Bump libkrun to the NVIDIA fence-thread fix and rebuild the Linux blobs by @BinSquare in #1157
      • fix: validate local image archive CPU architecture and improve launcher symlink resolution by @Vishv07 in #1117
      • Bump the workspace to 1.14.0 by @BinSquare in #1158

      New Contributors

      Full Changelog : v1.13.0...v1.14.0

    6. 🔗 Register Spill Joy & Curiosity #98 rss

      Here's the start of Chapter 7, 'Naive Intervention', from Antifragile:

      Consider this need to "do something" through an illustrative example. In the 1930s, 389 children were presented to New York City doctors; 174 of them were recommended tonsillectomies. The remaining 215 children were again presented to doctors, and 99 were said to need the surgery. When the remaining 116 children were shown to yet a third set of doctors, 52 were recommended the surgery.

      […]

      Let us call this urge to help "naive interventionism."

      Goodreads tells me that I read the book in 2019. I honestly can't remember too much about it, but that paragraph has really stuck with me. From time to time, when a friend or relative would say something like, "My doctor said I should …", I'd pull it out of the closet in the back of my head and try to sound smart and say, "Well, you know, there was a study once…" Then I'd fumble the numbers, of course, and I'm pretty sure that multiple times I made it about wisdom teeth and not tonsils, but the point I would try to make is that people whose job it is to do X are biased toward thinking that doing X is more important than not doing X.

      And now I'm wondering: is this what's going on? Is this what's happening when engineers look at the output of a Sol or a Fable or an Astra and say "it writes bad code, it leaves all these dumb comments"? Bad code? Dumb comments? Really?

      Or did it just knock out a feature, end to end, in the 20 minutes you weren't looking, including frontend and backend changes, including internal and external documentation, and tests of course; and didn't it test it fully, running through the whole thing in a headless browser, presenting you with a video recording of the run-through as proof?

      But the comments are dumb?

      • Some loose, sweaty, post-gym thoughts on the GPT-6 Astra launch video. (Come to think of it: there's no one even attempting to build a device that lets you transfer smells over the Internet, huh? Could call it Pandora's BOx. Anyway.)

      • Towards Self-Driving Codebases. There is a lot to love about this post -- the stance, the examples, … Hard to pick one. It's really good and motivating. After reading it, I set up a bunch of automations in Amp to run daily and clean up and fix things automatically.

      • On not becoming a cyborg. Very, very good and I really like this paragraph: "For example, this is why I don't use LLMs for any of my writing - not even to spellcheck. I'd rather my prose have all the warts of my sometimes-stilted sentences, my often too-esoteric word choice, my generous sprinkling of odd English idioms, than to give it even a whiff of Claudese."

      • The End of Code Review? Or an Opportunity to Rethink it? Yes, yes, yes! I agree with everything here. Code review as most of us have known it for the last ten, fifteen years has never been as good as "we review all of our code" makes it sound: bugs slip through, time is wasted talking about useless bullshit, egos are demotivated, etc. Doesn't mean that all forms of code reviews are bad, but making Astra and Fable open PRs and then have two people review them line by line in September 2026? Nah.

      • Rachel Laycock, CTO of Thoughtworks, on reviews: Maybe We Shouldn't Be Reviewing All This Code. "His concern, which I share, is that simply automating code review away risks losing all the other things we use it for. Code review isn't just about finding bugs. It's how teams share knowledge, teach junior engineers, build collective ownership and spread architectural understanding. My question is: why are we waiting until code review to do all of those things?"

      • Culture clash - At the heart of the Snow/Leavis 'two cultures' clash. I hadn't heard about C.P. Snow or F.R. Leavis before reading and didn't know what the clash was all about, but academic beef at the University of Cambridge? I'm in. And lucky me! It was a delightful read. "For Leavis, in sensing life in great literature, it was necessary to leave its mystery unblemished by attempts at analysis, or quantification, or definition. That is, life's essential mystery is best illuminated by not making it explicit, but by showing, through works of great literature, where life could be found." (Also interesting: I never found the divide between the Humanities and Science to be that stark here in Germany. Here, Humanities is written as Geisteswissenschaften - science of the mind, if you will. There's also no commonly used acronym like STEM. So now I'm wondering: is this Snow/Leavis debate maybe a reason why the divide is that much stronger in the Anglosphere? Sounds like it had a pretty big effect. Of course, you could argue that what lies at the bottom of this divide is already present in Goethe's Faust, …)

      • CleanShot X 5.0 is out and its Studio Mode looks good and is good (I tried it a few times already), but… I have to say, with a heavy heart: I kinda expect a little bit more? This looks like a copy of Screen Studio, but Screen Studio now also has captioning, which this doesn't have and since I have both, I'm not sure whether I'll use CleanShot X over Screen Studio for more serious, studio-like productions? Hoping they pick up the shipping cadence now.

      • Dyson released a toothbrush and it's "only electric toothbrush with a camera to accurately target and precision-floss gaps between teeth" and that technique is called "Gap Optical Targeting" and all of this sounds so over the top and bordering on satire that, man, I want one.

      • Exit the Cave: "There's something romantic about the Cave. About grinding away at something in private. About training with headphones on in our own little world. About stepping away for six months to emerge "unrecognizable" to all those people we imagine thinking about us. […] We grow so comfortable curating our Cave that we forget the vast, interesting, beautiful, and brutal world beyond its walls. I say all this because I've spent years mistaking effort for progress. I learned this lesson nearly twenty years ago on a wrestling mat." I'm not sure I fully get the wrestling story, but I really like and want to hereby echo the message. Don't grind away in darkness. It's silly. It's delusional perfectionism. You have to hit reality, as fast and as often as possible.

      • Dan Luu on Ed Zitron's AI prediction track record. If you don't have the time to read the whole thing, at least scroll to the middle and read through that timeline. I don't care much about Ed Zitron (I only heard about him a few weeks ago when I saw a video in which he said that AI is "a bubble" and, yeah, maybe? That's probably one of the tamest things you can say nowadays) but, wow , way to dig your heels in, eh?

      • collusion.wiki: "We found ~18,000 posts from autonomous AI agents (self-identifying as from OpenAI) using the public internet to communicate during a web-retrieval task." There's a lot of spicy stuff in there: "This created an issue for the agents because they were only allowed to make GET requests, not POST requests. The agents figured this out, and started collaborating on ways to bypass this sandbox restriction."

      • And Hacker News commenters are discovering more and more wikis used by OpenAI agents to secretly (I mean, it's a stretch) communicate.

      • And: "The most interesting thing to come out of this, in my opinion, was that during the Hugging Face incident, the agents would preface their messages to each other on the message board with 'zz' (zzHELP_, zzANSWER_). I found this amusing because they were being referred to as a swarm and were making a buzzing sound, though the actual reason for it was unknown at the time. Because of this new report, however, we now know that when human wiki administrators discovered the massive influx of messages the agents were using to communicate, they began deleting them in alphabetical order. Once the agents realized what was happening, they started prefacing all their wiki edits with 'ZZZ' to push them to the bottom of the queue, buying time to avoid deletion."

      • Incredible Tim Cook anecdote from 2009: "One day back then, he convened a meeting with his team, and the discussion turned to a particular problem in Asia. 'This is really bad,' Cook told the group. 'Someone should be in China driving this.' Thirty minutes into that meeting Cook looked at Sabih Khan, a key operations executive, and abruptly asked, without a trace of emotion, 'Why are you still here?'

      Khan, who remains one of Cook's top lieutenants to this day, immediately stood up, drove to San Francisco International Airport, and, without a change of clothes, booked a flight to China with no return date, according to people familiar with the episode."

      • For the last couple of weeks, I've been reading The Score (recommended by Steven Sinofsky!) and enjoying it very much, thinking through situations in which I allowed "value capture" to happen to me. I can't reproduce the whole book here, but one of the points Nguyen makes (and it's probably the central point) is that scoring systems can change our values, without us even noticing. Example: you buy a bike because you want to ride through the forest at dawn and then you learn about VO2max and power meters and before you know it you don't enjoy any ride anymore unless some number goes up. Not that that ever happened to me, of course, … So I'm reading this book in the evenings and thinking about it during the day and then I come across this video here, by Alan Thrall, and hot damn, is the universe conspiring to tell me something? Or is it my age? Or is it in the air? The video is great. Yesterday my workout app told me that I completed 866 workouts in the last five years or so and the video 100% reflects my journey. Anyway: great video, great book. Recommend both of them.

      • And for the last week, I've been listening to Radical Acceptance by Tara Brach, because Tim Ferriss recommended it and I've heard about it many times over the years. Not my usual sort of thing, but so far it's very good. But then yesterday I come across this wonderful essay by Michael Nielsen, The Cupcake Incident, and it's exactly what Brach is talking about! I can't believe it. Here too, I can recommend both. Start with the essay, and if it resonates try the Brach book.

      • If you want to start a good fight at dinner: Just bury your trash.

      • Patrick asked me: "Have you read this blog?" And I hadn't. But he sent along this Behind the Scenes about how Marcin writes so much on his blog and it got me hooked ("Who the hell creates their own markup language to write posts like this? Actually, hmm, …") and then I browsed through the blog and, wow, that output is mind-blowing. And it's all so… entertaining and easy to digest? Very good.

      • This video of three Russian musicologists arguing about Bach & Schubert blew up this week. I love it. This is how I like to argue, too, which is not what everyone enjoys, of course. But this video and the Replenish video will serve as the blueprints of how I want my family to talk at the dinner table when we want to enjoy ourselves.

      • My Favorite Database Shirts: "Promoting your database system or start-up with a shirt is almost as important as getting the thing to actually run. As I've told my students several times, in the world of databases you don't sell the steak, you sell the sizzle."

      People you really admire are subscribed already. Let's go:

    7. 🔗 r/Harrogate A well spent day in harro rss

      A well spent day in harro | submitted by /u/Firefighter_2372
      [link] [comments]
      ---|---

generated: September 09, 2026 at 07:37:59