SoylentNews

Here's the story.

Note: I submitted this article as a regular story, however the editors ignored it for quite some time. So I have deleted it from the submissions queue and present it here in my journal instead. Given the interest in book of the month and the many other references I see to books and movies here on soylent, I thought it might be of interest to some of our denizens anyway. So, then:

I should first point out that I didn't have anything at all to do with the above-linked article; but when I read it, all I could do was nod — a lot — and try not to allow my temper to get the better of me.

I have a longstanding (about 50 years) direct business connection to high end science fiction & fantasy publishing. I can confirm that this has become a significant problem in the industry — and also that this did not use to be the case. Resistance based on perception of characters as that relates to "author validity" is increasing, and is now a major factor in what ends up getting published. Or doesn't.

I don't have a solution (at least, not a solution that doesn't involve lining people up against a wall and shooting them), but the issue definitely has my attention.

If we can expect a work to fail in the marketplace because it will be attacked in such a manner, we simply can't see it through to publication. Doing so would kill our business.

Capitulation? Yes, essentially that's exactly it. It's either that or get jobs at McDonalds. This is one of those ways that the world is changing, and not for the better.

Right now, I'm surfing the Soylent waters using this procedure:

1. Go to my user preferences / comments page
2. Assign an automod of -6 to foes
3. Assign an automod of -6 to anonymous posters
4. Save my user preferences
5. Set the viewing threshold to 0 and [✓] Save and then click change in a story's comments
6. Assign trolls as a "foe" by clicking the little face by one of their posts
   • Repeat #6 as needed

So what the above should do is bury comments (stop them from being expanded in a comment listing) posted by the trolls I have placed in my foes list, and also all anonymous posters, which also should keep the trolls who use anonymous posts to get past the foes list automod (and those who are simply trolling anonymously) buried as well.

The annoying downside of this approach is that anonymous posts from non-foes also get buried, because the Soylent code doesn't know who the anonymous poster is, so it cannot determine if the anonymous poster is on my foes list.

That lack of knowledge could be addressed for logged-in users, as the Soylent code does know who it is when logged-in users [✓] Post Anonymously, but short of requiring log-in to post, that isn't possible.

Having actually tried the above -6,-6 setup now, I have found the general burying of anonymous posts to be less painful than accidentally reading the various troll garbage (I read very fast, gulping down whole paragraphs at a glance... so to even glance at a post is to peruse a good chunk of it, no matter how troll-ish and/or awful it is.)

Further, I know that anonymous posters could just as securely create a unique pseudonym and post as logged-in users with no loss of anonymity, other than that people would know both post A and post B are both from the same author (a total win, frankly.) Considering this, I see no decent excuse for posting without logging in anyway, and so feel quite justified in brushing off those who can't be arsed to log in.

I could live with the above -6,-6 setup, except... it doesn't actually work.

The Top-Level Comment Bug

Soylent's "Apply automod" feature does not obey its settings when a comment is at the outer, or "top" level of a story's comments. Not if the commenter is anon; and not if they're in my foes list. Top-level comments appear no matter what the automod is set to. Ouch. Garbage out, ...garbage in.

But it's even worse than that. If you click on a comment link (for instance, one that has replies on your user page, or on the replies notification page), then first-level replies in the resulting comment subset also don't obey the automod(s.) It doesn't matter if the comments aren't actually top-level in the entire comment stream; if they're first-order comments to the comment one is now looking at, then the bug manifests again.

I humbly submit that this should receive dev attention ASAP; the whole point of automods is made moot by these behaviors.

--
I'd agree with you, but then
we would both be wrong.

Right now, the only way to effectively block a logged in time waster is to::

1. Make them a "foe" by clicking the little face by one of their posts
2. Assign an automod of -6 to foes and save the prefs
3. Set the viewing threshold to 0 and ✓save and then click change in a story's comments

Now, no foes show up (except at the top level of comments, because top level comments are broken, apparently on purpose, but that's a different complaint, I guess.)

The main problem with this is that many AC posts get unfairly modded to -1. Those will also disappear. That's a loss.

Further, if a registered user decides they're going to post anon to get around this, you could assign a -1 mod to anons... which will work, but also cut off the anons completely unless someone mods them up. And of course, some of our trolls are using sock puppet accounts to mod themselves up. So that's not foolproof either. But it at least requires them to work harder.

So what to do? It would be much, much, much better if we could say "foes are -10" and threshold is -1, the lowest a post can normally go with a hand mod — that's assuming the points system is still used to do this. That would really go a long way towards solving the problem, because anons would not be penalized by this, we could keep our reading threshold at -1 without a problem, because foes would be automatically submerged below -1.

Might not be that easy. TMB could throw an oar in here, codewise.

Or, just "if in foes list, collapse the post", which would be much better — and at some level, the system's already doing most of that, because presence in the foes list is the only way it knows to assign the automod.

The troll anon posts would still be there, but remember, there's always that little [-] button in the subject bar of each comment. You can nuke those exceptions pretty easily.

But I still don't want to ever see some of these registered users. Any time at all they take is a waste.

So anyway: the site would be much improved if we could mute at least the registered user trolls. Of which we definitely have a few. So for now, foes are -6 and my threshold is 0, which almost works, barring the loss of mis-modded anons (sad face) and the top level comment hiding being broken.

For quite some time, I collected classic audio gear, ca. 1960-ish to 1980-ish. My favorite high-end units had fairly extensive front-panel controls. They had to have them, because there was no practical way to build a menu-driven system at the time.

I love the way those units work. You want to do something? You just reach out and do it. And they were, quite frankly, beautiful.

Fast forward to now. I have a fairly high end pre-pro — that's very like the receivers most people are familiar with, but a pre-pro uses external amplifiers. The range of things it can do through its menu interface is very large, and sure, I appreciate that it can do them. But the level of convenience using those menus? It is flat-out awful.

But you'd never get all that shoehorned into front panel controls, or at least, if you didn't want to take up a floor-to-ceiling rack doing it. And remotes... well, stock remotes tend to have a bunch of preprogrammed functions, and you're stuck with whatever is there, and missing whatever isn't — so back to repeated menu-surfing. Ugh. So you just can't do it.

Or... could you? What if you could get directly at the controls you want to use most often?

For me, I'm talking about volume, bass, treble, and/or EQ, input selection, speaker and mono / stereo / reverse / dolby-whatever / etc. settings, loudness, high-blend and high-blend crossover, various balance configurations (preset or variable), mute, monitor selection, active zone...

These are the sorts of things that you (or at least, I) am constantly menu-surfing to get at. You might choose the specific operations you want access to differently, but how can a manufacturer meet that kind of need for flexibility?

So I imagined a design with soft knobs and buttons, with a dedicated small display over each control. A nice large single display, too. Push a specific knob in, and you do get a menu. But the menu lets you select what that knob does. Push again to select, or push-and-hold to cancel. All the knobs are optical encoders, so capable of considerable precision. All the control displays are dot-matrix, so capable of text, bar graphs, etc.

Same for buttons. Push to use, push and hold to get a menu/submenu to choose what it does, quick push to select the function, or push and hold again to cancel.

You could even set up a knob as a "meta" control knob, where it would step through various control configurations you have already set up. All knobs but that one are EQ knobs, for instance. Then right back to everything else with one adjustment of that "meta" knob.

And of course, you could still menu surf on the main display (or a monitor, if connected) to pick and choose and set anything and everything.

But how would you know what these controls did if they were all soft?

Easy: You put a small display above every control that labels each one as to its currently selected function. And all knobs and buttons would label themselves when a "meta" set was changed, so there'd be no confusion there, either. Talk about flexibility!

Now you have a front panel that is no more crowded than the classic audio units of yore, but much, much more flexible and personally, and completely, tunable to your preferences.

I'd want one physical option per knob as well: detents, or not, programmable. Some things I want smooth, some things I want stepped, and I want to choose which functions act which way. So they would need an indent mechanism that could be disabled or enabled according to how you want the knob to act. That can be done with a knob's back wheel with spaced steel inserts and an energized, or not, coil to provide the knob detents with classic, actively programmable physical feedback. Nothing difficult or particularly expensive about it.

From the manufacturer's perspective, each knob and button assembly would be an identical unit. Just those two kinds of things. So mass producible and easily integrated with a front panel and motherboard. Or perhaps they could just plug into each other, so various designs could use more or less of them, and they could talk to each other and the host CPU over that bus. That would be very nice from a design and manufacturing POV.

Man, I could really go for a unit like that.

General

This is a post / TFS text pre-processor designed specifically for use with soylent.org

There are three interrelated projects involved.

One is Python(2) CGI that must be installed upon a webserver, and is then used via the web page it generates. This can be used to prepare posts for use on, for example, soylentnews.org.

Another is a Python(2) library that can be used to create your own project of a similar nature. This library is also used in the above project.

The other is a Perl library (module) with the same general functionality as the Python(2) library that is specifically designed to work easily with the soylentnews.org TFS system.

Here is a summary of features and capabilities as of 20190216:

Instance Types:

• Full bore web page for pre-processing your own posts
• Python class suitable for implementing your own handler
• Perl class suitable for implementing your own handler
    (specifically intended for soylentnews.org)

Capabilities:

• Generates tag pairs with terminology expansions for caps / numbers / caps+numbers sequences
  • Over 1000 term expansions (as of Jan 1st, 2019)
  • Can expand electronic components such as R2, VR5 and IC44 (default on)
  • Can ignore specified terms on-the-fly
  • Can list all expandable terms (default off)
  • Flags unknown terms that may be expandable on the web page
  • Handles pre-existing tag pairs when you want to add one-off uses
  • Handles HTML and won't try to expand within HTML tags
  • Includes test code to verify file containing expansions, generate statistics
  • Includes command line tool to check to see if term already present in expansion list
  • Python and Perl stand-alone term expansion classes
  • Ability to add editor's markup either everywhere or within blockquote regions
• Built-in macro language
  • Can list available macros (default on)
  • Multiple random/selected user signature generator (default off)
  • Includes macros to make posting easier (you can add as many as you like):
    • blockquote {bq quoted text}
    • strikeout {strike struck text}
    • bold {b bolded text}
    • italic {i italicized text}
    • bulleted lists {ul item|...|item}
    • numbered lists {ol item|...|item}
    • links, canned and/or on-the-fly {link URL|linked text}
    • temperature display and conversion {f NN}, {c NN}
    • let me google that for you {lmgtfy search term}
    • smile (emoji) {smile}
    • shrug (character art) {shrug}
    • escapes: {vb}=|, {ls}={, {rs}=}, {sqig text}={text}
• Convenient unicode-to-unicodeEntity converter
• Provides optional Soylent-style post preview (default off)
• Handles unicode posting
• Incorporates basic self-test when run from command line
• Can use local configuration file to prevent update from repo resetting your preferences

The project can be found here on Github.

General

This is a post / TFS text pre-processor designed specifically for use with soylent.org

It is Python CGI that must be installed upon a webserver, and is then used via the web page it generates.

Capabilities:

• Generates <abbr> tag pairs with terminology expansions for caps / numbers / caps+numbers sequences
  • Over 1000 term expansions (as of Jan 1st, 2019)
  • Can expand electronic components such as R2, VR5 and IC44 (default on)
  • Can ignore specified terms on-the-fly
  • Can list all expandable terms (default off)
  • Flags unknown terms that may be expandable on the web page
  • Handles pre-existing <abbr> tag pairs when you want to add one-off uses
  • Handles HTML and won't try to expand within HTML tags
  • Includes test code to verify file containing expansions, generate statistics
  • Includes command line tool to check to see if term already present in expansion list
• Built-in macro language
  • Can list available macros (default on)
  • Multiple random/selected user signature generator (default off)
  • Includes macros to make posting easier (you can add as many as you like):
    • blockquote {bq quoted text}
    • strikeout {strike struck text}
    • bold {b bolded text}
    • italic {i italicized text}
    • bulleted lists {ul item|...|item}
    • numbered lists {ol item|...|item}
    • links, canned and/or on-the-fly {link URL|linked text}
    • temperature display and conversion {f NN}, {c NN}
    • let me google that for you {lmgtfy search term}
    • smile (emoji) {smile}
    • shrug (character art) {shrug}
    • escapes: {vb}=|, {ls}={, {rs}=}, {sqig text}={text}
• Handles unicode posting
• Incorporates basic self-test when run from command line

The project can be found here on Github.

--
If ignorance is bliss, why aren't more people happy?

General

This is a post / TFS text pre-processor designed specifically for use with soylent.org

It is Python CGI that must be installed upon a webserver, and is then used via the web page it generates.

Capabilities:

• Generates <abbr> tag pairs with terminology expansions for caps / numbers / caps+numbers sequences
• 677 term expansions (as of Dec 7, 2018)
• Built-in macro language
• Can list available macros (on by default)
• Can list all expandable terms (off by default)
• Multiple random/selected signature generator
• Flags unknown terminology that may be expandable on the web page
• Handles pre-existing <abbr> tag pairs when you want to add one-off uses
• Handles HTML and won't try to expand within HTML tags
• Handles unicode posting
• Includes test code to verify file containing expansions
• Incorporates self-test when run from command line
• Includes command line tool to check to see if acronym already present in expansion list

The project can be found here on Github.

--
Entropy is a bitch.

IMHO, links on SN should specifically accept target="_blank" so that when a reader clicks on a link, they don't have to be taken away from SN, but instead get a new tab (or window, if that's how they've set their browser up.)

At it stands now, adding that to a link results in it being stripped out.

The default behavior of a link in HTML is to change the current page context. In some cases, that's what you want. Perhaps even (slightly) in the majority of cases. But in the case of a conversation, leaving is not generally what you want.

In fact, I wouldn't be in the least opposed to the default behavior of placing a link on SN always adding target="_blank"

As per this discussion, I am interested in making it easier to read posts and submissions that contain abbreviations and acronyms.

I suggested that a capability to illuminate such things be added to Soylent, which was met with somewhat of a yawn. Oh well. :)

But I thought I'd do it for my posts, and so I did.

It is a webapp that runs on a webserver, and you can use it as well if you like, presuming you have access to a webserver you can install it on.

Basically what it does is looks at all-caps and/or number sequences and looks them up, surrounds them with <abbr> tags, and pops the explanation into the title element of the tag.

It also provides a powerful macro engine you can use if you like. This can enhance the ability to post quite a bit, provide randomly selected signatures, etc. The limits there are pretty much set by your imagination. For instance, to produce <abbr>, I have this macro in the macro file:

[style tag <tt><b>&lt;[b]&gt;</b><tt>]

To use it in my post, I simply enter:

{tag abbr}

The project is located here.

So the next time you are thinking WTF when you read an acronym or abbreviation in my posts, you can just hover mouse pointer over it and be greeted with a short explanation.

I would be delighted to accept additions to the acronym file on Github, too. The more, the merrier.

And of course, if the coding gods at Soylent wanted to use the acronym file to implement this capability for use with TFS and perhaps even people's posts in general, that would be sweet.

So I open Soylent this morning, and I'm greeted with a story where TFS started with:

ASUS Comments on Intel Shortages, U.S.-China Trade War

ASUS this week released its...

I'm thinking "WTF is ASUS???"

We're deluged with acronyms. It's difficult to know if one cares about something when TFS is more opaque than it really needs to be, unless you go digging deeper — and I generally don't go digging deeper unless I'm already interested.

So I thought it would be cool if there was a collapsed-by-default region at the bottom of the article that contained the apparent acronyms found in the article, if any were present. The detection would be simply catch all-caps "words" and look them up in a Soylent-local acronym dictionary.

One of the things in the article edit / update would be to catch any that exist, and list any that aren't in the dictionary with a place to define them when the article is submitted / edited /updated.

If the reader sees an acronym they aren't familiar with, they just open the collapsed-by-default region, learn what it means, and experience a "TIL" TFS instead of a "WTF" TFS.

It doesn't seem like it'd be that big of a pushup to code, and it would serve a reasonable purpose.

Example (faked with <spoiler>):

*SPOILER* (click to show) *SPOILER* (click to hide)

ASUS - 華碩電腦股份有限公司 — ASUSTEK COMPUTER INC
 TIL - Today I Learned
 TFS - The Fucking Summary
 WTF - What The Fuck

Or:

As a (poor) substitute, if the <spoiler> tag could have an optional text field, for example...

<spoiler "Acronyms">

...so that it wouldn't show as "spoiler" but instead as...

*Acronyms* (click to show)

...but perform the same function, then the author of the article or the editor could populate it on a per-TFS basis. It would result in considerable duplication of effort to constantly redefine such things (and that's why I suggested an automated process) but it would still provide a means to make TFSs (and comments) better, and it has the merit of probably being a lot easier to do, which would likely appeal to those who would have to implement it.