Apparently my account on the site is/was now more than a quarter of a century old... Gonna try to avoid thinking on that too deeply. :D
There's been a non-zero number of occasions since that time where I've observed situations that mirror the trust-based challenges Advogato sought to solve.
It is perhaps telling that as prescient as Raph's work on trust metrics was he later moved on to the notoriously challenging realm of font rendering--presumably because it seemed more tractable. :D
I encountered the Sony MMCD when I fell down a rabbit hole *checks literal notes* around five years ago while researching Microsoft Encarta MindMaze[0] and its related file formats.
It turns out the data associated with MindMaze (& other encyclopedia data) changed storage format over subsequent releases of Encarta and these changes provide some interesting historical insights--including that if MS had had its way we'd all be writing web pages in RTF rather than HTML[1]. :D
You may ask, "What connection does this have to the Sony MMCD?".
Well, one of the storage formats used with early Encarta data is `.mvb` which is a format used by Microsoft Multimedia Viewer[2] (also known by multiple other names--none of which are any easier to web search :D ).
And, it turns out, "Multimedia Viewer could compile titles for Tandy Video Information System and other Modular Windows systems, as well as Sony Multimedia CD-ROM Player, a portable MS-DOS-based CD-ROM XA reader released in 1992."[2][3]
According to my research the tool "...includes software tools that simulate the look and feel of the Sony player titles on a PC" which is interesting in the context of the emulator for the Discman mentioned in the original post.
Anyway, that's the very short version of the rabbit hole--maybe in another five years I'll get around to writing up the rest...
Oh, sure, rpath/runpath shenanigans will work in some situations but then you'll be tempted to make such shenanigans work in all situations and then the madness will get you...
To save everyone a click here are the first two bullet points from Exhibit A:
* If an executable has `RPATH` (a.k.a. `DT_RPATH`) set but a shared library that is a (direct or indirect(?)) dependency of that executable has `RUNPATH` (a.k.a. `DT_RUNPATH`) set then the executable's `RPATH` is ignored!
* This means a shared library dependency can "force" loading of an incompatible [(for the executable)] dependency version in certain situations. [...]
Further nuances regarding LD_LIBRARY_PATH can be found in Exhibit B but I can feel the madness clawing at me again so will stop here. :)
I vaguely wondered if FreeHand would make an appearance in this thread. :)
Two features that come to mind as IIRC being unique (as compared to Illustrator) were multi-page documents and multiple page size multi-page documents. Ideal for the complete standard set of company branded print documents: business card, "With Compliments" slip, and letterhead. :D
Adobe's acquisition of Macromedia and subsequent killing of (the IMO superior) FreeHand contributed directly to my subsequent decision to avoid closed source application software--especially for creative tools--even if alternatives were "technically inferior".
(And, indeed, "creative tool killed/hampered for business reasons" is a story which has been repeated elsewhere multiple times in the quarter century[0] since.)
While Inkscape is still missing features compared to FreeHand it is however also still here many years later and is what I've used ever since when I need 2D vector design software. (Although I've also been keeping an eye on Graphite: https://graphite.rs)
> I've been thinking about bluetooth and a standard protocol and generic app.
A long time ago I developed a project called "Handbag[0] for Android"[1] based around a similar concept--it targeted the short-lived "Android Open Accessory Protocol" initially over USB & later also over network/WiFi.
(My project notes from the time mentioned a long-term goal of also supporting Bluetooth but that never eventuated...)
Handbag made use of a "generic" Android app for UI display/interaction and an Arduino library that communicated with the app over a binary protocol.
The app would display various UI widgets such as labels/progress bars to display feedback from the accessory and text inputs/buttons to accept input forwarded to the accessory.
While the project did not take the world by storm, I was reminded when digging up these links that at least one person called the concept genius[2]. :)
----
[0] Because it let you "accessorize your Android phone or tablet". :D
"Cregit" tool might be of interest to you, it generates token-based (rather than line-based) git "blame" annotation views: https://github.com/cregit/cregit
I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments discussing issues related to line-based "blame" annotation granularity:
"Cregit" tool might be of interest to you, it generates token-based (rather than line-based) git "blame" annotation views: https://github.com/cregit/cregit
I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments (yours being one I've had open in a tab for a week to remind me! :) ) discussing issues related to line-based "blame" annotation granularity:
"Cregit" tool might be of interest to you, it generates token-based (rather than line-based) git "blame" annotation views: https://github.com/cregit/cregit
I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments discussing issues related to line-based "blame" annotation granularity:
Unfortunately the direct line-number link above doesn't seem to provide the same view as manually choosing "squash_the_stupid_serial_number(...)" rather than "Overall" in the selection/option menu accessible via the page link: https://cregit.linuxsources.org/code/6.13/arch/x86/kernel/cp...
(Apparently the only code directly from Linus' original commit for that function is `, lo, hi`. :) And, unfortunately, being from the pre-git era, it is lacking any sort of informative commit message...)
The linked site contains a token-based (rather than line-based) git "blame" annotation view for Linux kernel releases, i.e. it allows you to discover which commit added a particular token--where "a token is what the C syntax considers a token".
An advantage of a per-token commit attribution view is you don't need to transit through the history of an entire line.
I encountered Cregit recently while doing some "code history spelunking/archaeology" and thought it seemed pretty nifty.
Decided to share the link as there have been a couple of recent HN threads which included discussion about the poor granularity of line-based git "blame" functionality.
Unfortunately, the tool itself seems not to be under active development, the most recently modified branch is from 2 years ago & the main branch was last modified 6 years ago: https://github.com/cregit/cregit/tree/newinter
I'm unsure whether the most charitable reading of your comment is to assume you missed that these linked phrases exist on the original site but were not included in the text copied into the comment above, or something else:
While you may be correct that initial "trolls get flagged", the statement on the Asahi site agrees that while the initial comment may be flagged & killed, the other comments in the subthread are still indexed, visible & tend not to get moderated/flag:
"Unfortunately, when a comment is flagged and killed, its child subthread is not. [...] but the reduced moderation activity enables abuse to continue. Although you don't see those threads, search engines do."
Based on other remarks about the content of such subthreads it seems surprising to claim that follow-on comments are made by "honest nice people".
I'm as much of a fan of adverbs as the next person but using words like "categorically", "extremely" & "patently" doesn't seem to leave much room for nuance of interpretation when written by someone who I'd have assumed was a third party observer?
While I could understand someone describing JWZ's HN-tailored "banner" (I wouldn't suggest researching this if anyone is not already familiar) gauche and immature, it feels like somewhat of a stretch in relation to a plain text message who last sentence starts with "Please".
I would like to first acknowledge the feelings of what I read to be anger, frustration & pain you expressed in your comment. (If I've misinterpreted what you've written, I am open to reading further clarification if that's something you felt like investing effort into.)
While my life experience has been different to yours, from what you've written about how you've been treated by others in your community, as a consequence of who you are, it seems understandable to me that you might experience those feelings--and, even if they didn't seem understandable to me, it is more important to me that you feel heard and your feelings acknowledged as valid and not dismissed.
I hope I have been able to communicate that intent effectively.
----
At the risk of falling into the stereotype traps of "straight white male thinks every rhetorical invitation is a literal invitation for him to say what he thinks" & "straight-splaining" I did want to provide an answer to the question in the last sentence here:
> "As another anecdote, when I talk to my friends about Rust, the subject of "drama" frequently comes up. Why is that? Suddenly my work becomes harder for an entirely unrelated and unmerited reason. That's just me as an LGBT person - imagine how straight people feel."
(I preface the following with an acknowledgement that it's bullshit that you have had to deal with the impact of this rather than the predominantly straight white males who don't want to be made to feel uncomfortable.)
TL;DR:
FWIW, from my perspective as a straight white male I feel the subject of "Public Interpersonal Conflict" attributed to Rust is directly related to values rightfully espoused/embodied by the Rust project/community/language that are at odds with values held by other groups.
Specifically, groups consisting of predominantly straight white males believe that the comfort of predominantly highly skilled straight white males should be prioritized over the physical well-being of other humans; and, also over the security and stability of the software other humans use.
They are also unlikely to agree with this characterization.
Unlike the above group however, rather than targeting resentment at the people whose physical well-being is at risk I choose to direct my resentment at the predominantly straight white males who choose to dismiss important issues as unimportant "drama" because they resent being "made" to think about issues that impact people other than themselves.
----
For anyone who disagrees with my characterization I would point out that we do not know what other contributions Alan Turing may have contributed beyond "Turing Completeness" & "the Turing Test" to current in-demand fields such as AI if he hadn't been persecuted for not being a straight white male.
I would also remind them the ARM CPU attached to that unified memory on which they're running their latest AGI & LLM models is thanks to another person some people in the present day think should be persecuted for daring to exist.
But equally people shouldn't have to trade advancements in the field of Computer Science for the right to exist without persecution.
----
I will acknowledge that its entirely understandable to want to avoid the associated discomfort because from personal experience it is very uncomfortable to have to re-evaluate one's place & responsibility in the world after a lifetime of being told something different.
----
The other ~2,500 words I wrote on the topic was certainly more nuanced but pretty much said the same thing with more beating around the bush with additional personal context.
For any straight white males who may be confused why someone might think as I do, all I can say is that time spent reading/listening to this (unfortunately, archived) resource is likely to be worthwhile, if temporarily uncomfortable: https://geekfeminism.fandom.com/wiki/Geek_Feminism_Wiki
"I do recall a Firefox discussion about how they can't 100% block videos because there will always be another way - eg do animated gifs count, or javascript that shows a rapid sequence of images [...]"
I also recall this being a justification given for auto-playing muted or audio-less video (i.e. because blocking "efficient" muted video playback will just lead to malicious actors using "less efficient" means of "image sequence" playback thus increasing the negative impact further).
On a related note, the other day I also discovered (while debugging why an audio demo didn't work the same way it did six years ago :D ) that there's now also a concept called "Sticky Activation" which can also impact "Autoplay of Media and Web Audio APIs (in particular for AudioContexts)"[1].
> Few maintainers care about the platform in question (to whom it's more a curiosity [...]) and don't have the hardware to test any submitted patches.
Yeah, from some very brief research I could only find a singular Linux kernel developer/maintainer/creator who said[0] "I'd absolutely love to have [the new 2020 Air], if it just ran Linux".
Who knows if that one person has even used Apple hardware before or has access to the necessary hardware to put toward a practical use such as a "development platform" while travelling, or, "doing test builds and boots and now the actual [Linux kernel] release tagging"[1][2], let alone be supportive of experimenting with Rust in the Linux kernel[3].
The history of Linux demonstrates the project doesn't have the resources to go chasing support for a hardware platform just because Linus cares about the platform in question...
...even if at least "173 people, and many more" "contributed both to the Linux kernel side but also to the upstream Rust side to support the kernel's needs" in the initial merge[3].
Background on the "trust metric" implemented on the site: https://web.archive.org/web/20160304000542/https://advogato....
Apparently my account on the site is/was now more than a quarter of a century old... Gonna try to avoid thinking on that too deeply. :D
There's been a non-zero number of occasions since that time where I've observed situations that mirror the trust-based challenges Advogato sought to solve.
It is perhaps telling that as prescient as Raph's work on trust metrics was he later moved on to the notoriously challenging realm of font rendering--presumably because it seemed more tractable. :D