Free Software's Four Essential Freedoms

Free Software's four essential freedoms:

A program is free software if the program's users have the four essential freedoms*:

  • The freedom to run the program as you wish, for any purpose (freedom 0).
  • The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
  • The freedom to redistribute copies so you can help others (freedom 2).
  • The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

A program is free software if it gives users adequately all of these freedoms.

* Free software's four essential freedoms as described here are taken from GNU's Free Software Definition.

Connecting to your single board computer with VNC

Introduction
This is a short walkthrough for installing xtightvncserver on your small board computer running Debian GNU/Linux or a Debian derivative, so that you can connect a vncviewer and interact with the device's desktop remotely.

This tutorial was developed with an Olinuxino Lime2 single board computer running Debian 8. This is a tiny single-board ARM computer with a dual core processor suitable for light to medium loads. The Olinuxino was chosen because it supports using entirely free software (unlike some other single board computers). This device's uptime as of this writing should give some hint of its potential usefulness:

$ uptime
02:52:06 up 316 days, 16:33, 2 users, load average: 1.06, 1.14, 1.16

Though created with single board computers in mind, there's no reason that this process can't be used on any local or remote Debian or derivative system having an X server installed. For that matter, the process doesn't differ much for non-Debianish systems.

Recommended is reading the instructions through all the way before beginning. They're short.


Installing
SSH into your device for the installation. If you don't know its IP address, but you are pretty sure it's up and running (evidence from blinking lights on the device, for example), you can run a "quick scan" on Zenmap of your local network (for example, on 192.168.1.*).

Once at the shell prompt of your device, make sure that xtightvncserver is installed with the following command:

sudo apt install tightvncserver

You'll (probably) need to supply your password for sudo.

Starting the Server
To start the server, type

vncserver

at the shell prompt. Sample output:

New 'X' desktop is smallbox:1
Starting applications specified in /home/myusername/.vnc/xstartup
Log file is /home/myusername/.vnc/smallbox:1.log

The line about "New X desktop is smallbox:1" means that vncserver is running. Your device's hostname will appear in place of the word "smallbox".

Connect to your VNC session by running a vncviewer and connecting to 192.168.xxx.yyy:1 (fill in your IP address; the :1 is the session number from the message above.)

Stopping the VNC server
At the shell prompt of your single board computer, run the following command:

killall Xtightvnc

Note the capital "X". This will shut down all running VNC server processes.

Setting Your Password
When you run the vncserver for the first time, it will ask you to establish a password for VNC access.

$ vncserver

You will require a password to access your desktops.

Password:
Verify:
Would you like to enter a view-only password (y/n)? n
Creating default startup script /home/myusername/.vnc/xstartup


Changing your password(s)

One way to change the password(s) for the VNC server is to stop the VNC server, then delete the password configuration file with the commands below.

killall Xtightvnc ; rm ~/.vnc/passwd

The next time you run vncserver, it will ask for new password(s).

Troubleshooting your session

  • No menu? Try right-clicking on an empty area of the desktop for a menu.
  • Still no menu? You may need to look at your default startup script (its filename is ~/.vnc/xstartup ).

Sample xstartup (your configuration may differ slightly):

#!/bin/sh
xrdb $HOME/.Xresources
xsetroot -solid grey
export XKL_XMODMAP_DISABLE=1
/etc/X11/Xsession

Also see: Never Do This: How Not to Give a Single Board GNU/Linux PC a Static-y IP Address

Short tutorial, "Connecting to your single board computer with VNC". Originally written Tue Nov 28 12:29:49 EST 2017. Copyright 2017 J. Public. License: WTDHPL

Amd Ryzen Problems #3 (SOLVED)

Previous installments:
AMD Ryzen problems, Part 1
AMD Ryzen problems, Part 2

For the same system in a previous article, AMD has been very helpful, and they have talked me through working on making sure that I have optimal cooling and that my AGESA version is sufficiently new.

The system had been exhibiting a "Linux Marginality" problem described by Michael Larabel of Phoronix. My Debian GNU/Linux system would sometimes generate errors under highly parallel loads, such as compiling software; this problem seems to affect early Ryzen chips manufactured before week 24 or 25 of 2017. Mine had been manufactured in week 5.

The conclusion to the problem? AMD Issued me an RMA. They also paid shipping both ways. This doesn't seem to be standard practice, and I appreciate the tech that I worked with going to the extra trouble for me. AMD received the RMA processor at their center in Miami, FL on March 30th, and I received the replacement on April 11th, 2018, which I thought was pretty good turnaround time.

The new chip, stamped with date code 1737, meaning week 37 of 2017 (September), is a gem and a wonder. The previous chip would tend to run near its thermal limits (around 68C or 69C)* under full load, whereas the replacement chip will barely reach 64C. Plus, of course, no evidence of the previous problems. PROBLEM SOLVED with the replacement processor. And lesson learned reinforced about buying new technology at its first release (I had ordered the Ryzen chip within a few days of its launch day).

I posted a few videos of the test on the old chip in Part 1 and Part 2 of this article, but it doesn't make sense to post a video of the new chip *not* failing; it would simply be a very, very long video of nothing happening except a Ryzen properly compiling the GCC suite.

I want to thank Mr. Larabel for helping me to understand what was going on through the high quality reporting on his website, and especially AMD for being friendly, helpful, and effective.

As borne out by my media encoding benchmarks and by synthetic benchmarks, the Ryzen 7 1700X is fully 100% faster than the AMD FX 8300 that I bought it to replace, so even with the brief timeout to RMA and with the learning experiences, I consider it a good deal overall. The Ryzen even keeps up with a 10 core Xeon I also have. It's not only cost-effective, but *fast*.

* The previous videos show much cooler temperatures because the chip, a 3.4 GHz Ryzen 7 1700X, was clocked through BIOS at only 3.0GHz, to eliminate questions over whether the failure was due to heat, or due to some other internal cause.

AMD Ryzen: Testing Part 2

For the same system in a previous article, AMD has been very helpful, and they wanted to see if having a newer BIOS on the motherboard with a newer version of AGESA would help things out any. Seems a reasonable request, as the BIOS on the motherboard was a year old, so I flashed a new BIOS and tried it again.

Trouble in paradise manifests around 11m:50s, and AMD has sent me a short RMA form to fill out and return.

Updated information from this time around:

Motherboard BIOS Version:
- Before flashing: E7A34AMS.120 03/2017
- After flashing to newer version: E7A34AMS.1C0 01/2018

New Bios Screenshots:
BIOS Screenshot - Shows updated BIOS version.
BIOS Screenshot - Shows voltage readings under new BIOS. (Spoiler alert: they haven't changed.)

Temperatures:
- Ambient (room) temp about 22 degrees C.
- No appreciable load, around 30 - 35 degrees C according to k10temp
- Under load, peak in the low 50s degrees C per k10temp
- Temperature at failure point, 52.4 degrees C according to k10temp

New, Improved Information Video:
- Slideshow, sensors for k10temp, top, tail -f /var/log/kern/log
- https://github.com/Oxalin/ryzen-test (very mild stress test)
- Camera monitoring inside of PC (showing cooling live as it happens)
- At failure time (11m:50s), evidence appears in ryzen-test and tail kern.log windows.
- Video online: https://youtu.be/26x56Ft8EZ8
- Video download: The_AMD_Ryzen_Linux_Testing_Part_2.mkv [138MB]

Never Do This: How Not To Give A Single Board GNU/Linux PC A Static-y IP Address

This method isn't limited to single board computers (such as the Olinuxino Lime2 from Olimex, which inspired this kludgy effort); it would also work on a laptop whose wifi got a random IP address on connect, for example. Or any machine running Debian GNU/Linux or a Debian derivative. Or any networked Unix(like) system with rc.something, networkmanager and the ip command.

In the "old days", one might edit the /etc/network/interfaces file and mention the desire for a static IP address, and it was almost magically so. But with the advent of networkmanager and its pretty GUI interfaces (and the CLI tool nmcli), that avenue is no more. Debian and its derivatives use networkmanager by default, and the single board ARM computers generally come with Debian (or a derivative such as Armbian). Thus, barring networking structural changes, you will need to either work with networkmanager, or around it. The instructions on this page do the latter. Never do thisTM.

This method is based on the powers and outputs of the ip command, which you probably already have installed. If not, then...
sudo apt-get install iproute2

First, make a script under /home/yourusername/bin called add-our-ip-address.sh:

#!/bin/bash
#
# Never Do This IP address script
# (c) 2018 Freworld.info
# This is free software, licensed under
# the WTDHPL version 1 or any later version:
# http://wtdhpl.info/
#
# Adds a desired static-y IP address in addition to any already present.
# Advisory: script must be run with privileges of the root user.
#
if [[ $(/bin/ip addr|/bin/grep 192.168.50.89) ]]; then
	echo Desired address 192.168.50.89 is already present.
else
	echo Adding desired address 192.168.50.89.
	echo If you are not root this will probably not work.
	ip addr add 192.168.50.89 dev eth0
fi

The address 192.168.50.89, the username yourusername, and the interface name eth0 may need to change depending on where and why you are (definitely not) doing this. This script checks whether the desired address is already in use, and if not, tries to add it to the desired network interface.

Make the script executable like so: chmod +x /home/yourusername/bin/add-our-ip-address.sh

Tip: If you don't know the name of your interface, you can ask what interfaces your system has with the following command: ip link.

Example output of ip link:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: tunl0:  mtu 1480 qdisc noop state DOWN mode DEFAULT group default 
    link/ipip 0.0.0.0 brd 0.0.0.0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether aa:ff:bb:ee:cc:dd brd ff:ff:ff:ff:ff:ff
4: usb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff

Here, your interfaces are lo, tunl0, eth0, and usb0. lo is the local loopback (not a real interface), tunl0 is a vpn interface (not a real interface), and usb0 is a special interface for when the Olinuxino is connected as a USB device. That leaves the name of the real ethernet device: "eth0".  If you don't have an eth0, but you do have something that looks like enp25s0, then that one's probably it.

Next, make a similar script under /home/yourusername/bin called add-our-ip-address-run-at-boot-time.sh:

#!/bin/bash
#
# Never Do This IP address script Number 2
# (c) 2018 Freworld.info
# This is free software, licensed under
# the WTDHPL version 1 or any later version:
# http://wtdhpl.info/
#
# Advisory: script must be run with privileges of the root user.
#
/bin/bash /home/yourusername/bin/add-our-ip-address.sh
sleep 15
/bin/bash /home/yourusername/bin/add-our-ip-address.sh
sleep 15
/bin/bash /home/yourusername/bin/add-our-ip-address.sh

This script simply tries a few times to assert the preferred IP address.
Again, chmod +x /home/yourusername/bin/add-our-ip-address-run-at-boot-time.sh

Third, edit the file /etc/rc.local as root and add the following line just before the 'exit 0' at the end:

/bin/bash /home/yourusername/bin/add-our-ip-address-run-at-boot-time.sh &

This causes a few blind tries at boot time to add your chosen ip address to whatever other IP address may be present (from dhcp or what-have-you). (You may need to create the file /etc/rc.local -- if so, make sure to chmod +x /etc/rc.local afterwards.)

The above should be enough. But if you find that your system doesn't reliably pick up its IP address when booting, or you find that it sometimes loses the address, then you can have the system periodically check to make sure your selected IP address is available. To do this, crontab -e as root to add a line to the end of root's crontab as follows:

*/5 *   *   *   *    /home/yourusername/bin/add-our-ip-address.sh > /dev/null

This will try once every five minutes to see if the desired IP is in use, and if not, to make it so. Maybe that's overkill, but even so, it shouldn't hurt.

After completing the above steps, you should find that you can reliably have a particular IP address on the target host. But admittedly, this isn't "the right wayTM" to do it (far from it, in fact), and so you should... Never do thisTM.

If this doesn't work for you, or you still have problems, you might leave a question in the comments section so that someone may be able to help you out.

Also See: Connecting to Your Single Board Computer with VNC

Scripts listed on this page are free software released under the terms of the Do What The Darned Heck You Want To Public License, version 1 (WTDHPL v1), or any later version. Please review the license terms (they work for your freedom); free software is important to our culture.

AMD Ryzen: From Buggy to Bountiful

Requested information for SR #{ticketno:[8200766680]} Service Request: {ticketno:[8200799002]}

--------------- Introduction ---------------
Below is a video showing a Ryzen 7 1700X PC with Debian GNU/Linux running the ryzen-test program from https://github.com/Oxalin/ryzen-test/ -- complete with video feed showing the CPU and case cooling at work. Ryzen-test is a very mild stress test consisting of compiling GCC, which any CPU should be able to do with no problems. Certain early Ryzen chips seem to fail at this test every time. The presentation running at top left helps relieve some of the boredom with some system config information and problem description; otherwise it's mostly just the temperature very slowly climbing into working range. Spoiler: The video gets more interesting around 12m:36s, which is about when the test fails. Any good CPU should pass this test without any segmentation faults. I made this video to help AMD understand my issues as part of the process of getting an RMA on this CPU. Other information within this post was also listed to help in that regard. Things with personally identifying information, such as the original invoices, were sent separately; this is just the good stuff for both AMD's private and everyone's public consumption.
--------------- --------------- ---------------

Motherboard: Micro-Star International MSI B350 TOMAHAWK (MS-7A34) (per BIOS screenshots)

Motherboard BIOS Version: E7A34AMS.120 03/16/2017 (per BIOS screenshots)

Make and Model of RAM:
- DIMM Bank A: 2x GeIL CL15-15-15 D4-2133 (per BIOS screenshots), GeIL EVO POTENZA Desktop Memory Model GPR416GB2133C15DC (per Newegg Invoice)
- DIMM Bank B: 2x Team Group TEAMGROUP-UD4-2400 (per BIOS screenshots), Team Elite Plus Desktop Memory Model TPRD44G2400HC1601 (per Newegg Invoice)
- GeIL RAM Info: https://www.newegg.com/Product/Product.aspx?Item=N82E16820144924
- Team Group RAM Info: https://www.newegg.com/Product/Product.aspx?Item=N82E16820313741
- Total RAM GeIL 8 + GeIL 8 + Team Group 4 + Team Group 4 = 24GB
- DDR Speed: 2133MHz (per BIOS screenshots)

Make and Model of Power Supply Unit (per Newegg Invoice):
- Make: APEVIA
- Model: ATX-JP1000W 1000W ATX12V SLI CrossFire 80 PLUS BRONZE Certified Power Supply
- Further information: https://www.newegg.com/Product/Product.aspx?Item=N82E16817148060

Voltages (per BIOS screenshots):
- CPU Core: 1.208 [Auto]
- CPU NB: 0.904 [Auto]
- DRAM: 1.200 [Auto]
- System 3.3v/5v/12v: 3.360/5.160/12.288

Cooling strategy:
- CPU Cooling: Air
- Cooler Model: DEEPCOOL ICE BLADE 200M
- Cooler Rating: "For 130W CPUs" per mfr.
- Cooler Features: Dual 8mm direct-contact heatpipes, Dual 92mm Fan Push/Pull.
- Heat Sink Grease: Arctic Silver (Not the Deepcool OEM grease)
- Cooler Info: https://www.newegg.com/Product/Product.aspx?Item=N82E16835856001

Temperatures:
- Ambient (room) temp about 23 degrees C.
- No appreciable load, around 30 - 35 degrees C according to k10temp
- Under load, peak at around 52 degrees C per k10temp
- Temperature at failure point, 51.9 degrees C according to k10temp

Information video:
- Window: Impress presentation (Good Info)
- Window: https://github.com/Oxalin/ryzen-test (very mild stress test)
- Window: watch -n .3 sensors \|tail -9\|cut -d "\(" -f 1 (monitor AMD-related temperatures)
- Window: Camera monitoring inside of PC (showing cooling live as it happens)
- Window: tail -f /var/log/kern.log |grep segfault (watch for specific problems)
- Window: top (see top CPU processes)
- At failure time (12m:37s), evidence appears in ryzen-test and tail kern.log windows.
- Temperature at failure observed to be 51.9 degrees C.
- Video online: https://www.youtube.com/watch?v=Pc10dtRaXso.
- Video download: The_AMD_Ryzen_Linux_Bug_-_What_it_looks_like.mkv [140MB]

Test system:
- Debian GNU/Linux "10" Buster/sid
- MSI Radeon RX 460 using "amdgpu" kernel driver
- Kernel uname -a: Linux quiz 4.15.2-amd64-1 #1 SMP Sat Feb 10 20:41:29 EST 2018 x86_64 GNU/Linux (from Kernel.org; compiled on this system)

Bios Screenshots:

BIOS Screen Shot: OC Page with motherboard model, BIOS version and date and voltages

BIOS Screen Shot: Settings Page showing configuration information

BIOS Screen Shot: RAM Info for DIMM A1

BIOS Screen Shot: RAM Info for DIMM A2

BIOS Screen Shot: RAM Info for DIMM B1

BIOS Screen Shot: RAM Info for DIMM B2

An explanation of why Software Patents are not like other patents

Patents exist in our society to strike a balance between the good of the few and the good of the many. The U.S. Constitution puts it this way: "The Congress shall have Power To...promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries...." (from Article I, Section 8 of the U.S. Constitution.)

So, here we have rights granted to "inventors" for their "discoveries" for the period of "limited times."

Let's start with some definitions.

"Inventors" are people (or companies) who invent things.
"Discoveries" are the "non-obvious" things they invent.
"Limited Times" are, in the U.S., usually about 14-20 years.

The idea is to encourage innovation with a reward: If you invent something useful, you and you alone have the legal rights to your invented discovery for a certain period of time, during which you reap any rewards, and after which it belongs to all the people.

The problem with applying this to software is that "software" is a set of instructions for a computer to do things it by definition already knows how to do, and patenting these pre-extant steps, whether individually or in groups, doesn't encourage innovation at all.

Though there are software procedures that are genuinely novel, such as certain complex compression algorithms and cryptography procedures, the vast majority of software patents are for trivial things like "Showing text with color coding (#7529804)" and "Pressing page-up and page-down (#7415666)."

The problem may not be obvious at first glance, because they are typically described in dense technical language. The two trivially silly patents above are described as "System and method for comprehensive automatic color customization in an email message based on cultural perspective" and "Method and system for navigating paginated content in page-based increments." It's still just color-coding and pressing page-up and page-down, but now with legalese. If the reader (quite properly) believes that such inanely obvious things can't be patented, he or she is encouraged to read the linked patents above.

Software, being little more than a recipe for how a computer should put together instructions already present in its CPU, may be hard to understand for many who are not programmers nor computer engineers. But something else that uses simple lists of instructions is food recipes--the ones we use in cooking.

Like software, a particular recipe can be copyrighted, but unlike software, the individual steps are generally not subject to patent. If recipes were subject to the same rules as software patents, then after the first company patented "Add milk, butter, and eggs to the flour" then no one else could ever make a cake during decades of the patent term. Near the end of that term we'd be likely to see a new patent on "Add milk and butter to a flour mixture containing eggs." When that one was about to expire, it wouldn't be a big surprise to see a patent on "Binding eggs and milk products such as butter together with flour." And so on. Patenting variations on a theme for a particular (simple) process could remove that process from the use of any but a single patent holder for centuries.

As you might imagine, this wouldn't encourage innovation in the technology and arts of ever-more delicious cakes--it would make cake-baking effectively illegal and kill all innovation in that area stone cold dead.

With that in mind, here's some food for thought as to why software patents are arguably a bad idea:

- Hi, welcome to This Restaruant(tm). I'll be your server. What are you having today?
- I'll have the BLT.
- I'm sorry, Some Other Restaurant(tm) has the software food patent on "A method for using porcine-derived high-fat cooked foodstuffs to offset the health benefits of crisp vegetables," so we legally can't make one of those. Legal would kill us!
- How about a Reuben?
- Well, Reubens Restaurant Holdings(tm) still holds the software food patent on "A process for combining thinly sliced deli meats and cabbage-based sauerkraut products into a bread-conveyed device", so I'm afraid...
- Didn't that one expire?
- No, that was their earlier one, "A method for combining bread-based products and pickled garden harvested goods into a roast beef-conveyed device."
- Ah. Okay, maybe something simple like a ham sandwich then.
- Oh, I'm so sorry, Super Relevant Food Tech(tm) actually sued us last year for using sugar-cured, table-prepared pork products in violation of their legally valid software food patent portfolio.
- Who're they?
- A "software food patent holdings" group. They used to make phones that did email, but changed their business model and their name when people stopped buying their products. Ironically, before that, their company name was the name of a food.
- They don't even make software foods?
- No, but they hold the sacred trust of software food patents on how to combine many different things to make a finished product. It's a very valuable role.
- Doesn't sound like it.
- Well, no, but that is what legal makes us say. Anyway, what can I get you for lunch?
- Is there anything you can legally serve me?
- Well, arguably, no, even the software food that we ourselves have patented probably violates innumerable other patents. That's the consequence of allowing patents on any trivial step of making any recipe, I guess. Besides, Agri Chem Conglomerate(tm) has that patent on using water in other things, and everything contains some amount of water...
- But that's crazy.
- You're telling me.

CNN Invokes "Think of the Children" and Bad Math to Fan Flames of "Opioid Epidemic."

On March 5, CNN posted a story to their news website breathlessly trumpeting a "study says" headline (excerpts below):

OPIOID OVERDOSE AMONG CHILDREN NEARLY DOUBLES, STUDY SAYS
The number of children admitted to hospitals for opioid overdose has nearly doubled since 2004, according to a new study. The study, which published Monday in the journal Pediatrics, looked at children between ages 1 and 17 who were admitted to hospitals and pediatric intensive care units with opioid-related diagnoses from 2004 to 2015.[...] "When they come in, they're going to fall into one of two categories: either they're teenagers with intentional or drug-seeking behavior because of recreational or self-injurious behavior, or they're kids who got into their parents' medication," said Dr. Jason Kane, an associate professor of pediatrics and critical care at Comer Children's Hospital in Chicago and a lead author on the study.[...] "What was really striking to me is just how sick these kids are and that almost half of them end up in the ICU," Kane said. "The reason why that's important to recognize is that nationwide there's only about 4,100 pediatric ICU beds, which is in contrast to the number of adult ICU beds, which is closer to 78,000.

[...] This study comes at a time when opioid use among adults in the US has reached epidemic proportions. According to the CDC, more than 42,000 people died in the US from opioid overdose in 2016, more than any year on record.

The problem with this news bombshell is the numbers involved. The study points to about 797 kids total the earlier period, and "nearly double" as many, 1,504, during the later. That's not per year--it works out to about 200 per year 2004-2007 vs. 376 per year 2012-2015. No deaths were reported during the periods involved.

Something else CNN didn't do is compare this number to, for example, kids seen in hospitals for playground injuries in the US (200,000 injured per year, with about 15 deaths per year; excerpts below):

Each year in the United States, emergency departments treat more than 200,000 children ages 14 and younger for playground-related injuries (Tinsworth 2001).

  • About 45% of playground-related injuries are severe–fractures, internal injuries, concussions, dislocations, and amputations (Tinsworth 2001).
  • About 75% of nonfatal injuries related to playground equipment occur on public playgrounds (Tinsworth 2001). Most occur at schools and daycare centers (Phelan 2001).
  • Between 1990 and 2000, 147 children ages 14 and younger died from playground-related injuries. Of them, 82 (56%) died from strangulation and 31 (20%) died from falls to the playground surface. Most of these deaths (70%) occurred on home playgrounds (Tinsworth 2001).
  • In 1995, playground-related injuries among children ages 14 and younger cost an estimated $1.2 billion (Office of Technology Assessment 1995).

Sure, technically, CNN is right. "Nearly doubled" means "not double," and 376 is not double 200.

But, by CNN's numbers, schools, daycare centers, public parks, and other play areas are over 50,000% more dangerous to our children than opioids are in terms of risk of hospitalization or death.

Needless injury to children is never a good thing, but the question here is this: Is this responsible reporting, simply inflammatory fluff for the "Zounds! Opoids" story, or somewhere in between?

Related link: https://xkcd.com/882/