• chevron_right

    Donating to Linux Slackware for OIDC LoRa BitTorrent install

    preptorrent · 5 days ago - 21:18 edit · 5 minutes

Quick Notice: For the other money donation to Gnome Foundation, see this other link. Money donation to Gnome Foundation

Public Post Movim Link

Today I sent Linux Slackware Money for Patrick Volkerding and perhaps others will do so too. #SlackwareBitTorrentOIDCLoRa I attach a trimmed screenshot to show how it was done. I included a message asking slackware to put SimpleSAMLphp (for setting up an OIDC and OAuth2 user registration server) on the distro CDROM ISO and an ability to enter a bittorrent magnet link of another Linux Distro (including another Slackware, be it newer or older to download and install instead or as well as the Slackware version on the ISO CDROM being installed), and a LoRa icon that works like the Wifi icon on the desktop of XFCE in Slackware. If you think about it, even if it took all day long, a LoRaWAN connection could just about send a trickle of data as a magnet-link for a linux distro ISO to a computer, ready to install when a wifi connection (presumably with internet) becomes available, capable of downloading that distro (maybe just be a 50MB DamnSmallLiunx Iso or a larger filesize slackware CDROM). Paypal Donation Linux Slackware Volkerdi So I have uploaded an image file to show how the money was sent so that, if other people wish to send their own money to Linux Slackware Money for Patrick Volkerding, they can see what to click.

The link to use Paypal for this is at this URL, below.

Sending Linux Slackware Money for Patrick Volkerding

Just to confirm this is the same and if you are looking for various donation methods (and please do see the forum link below).

As I used Paypal, I could add a message. Remember to keep such a paypal message half the size of the 'wordcount' shown in the screenshot. Whilst mentioning the Payapal donation transaction ID 243384911N127970H (to uniquely identify it to both the recipient and sender), I have also made a suggestion that slackware slackbook2 languages could be included on the slackware distro CDROM ISO such as via PDF now if they become available. On the translations slackbook slackware website, many languages links for that manual of slackbook are broken-links. I'd say for Slackware linux, create a translation of the slackbook manual in two (mutually intelligible) languages in Hanifi Rohingya script (Rohingya) Ruáingga and also Chittagonian (Bangladesh) চাটগাঁইয়া saṭgãia or চিটাইঙ্গা siʈaiŋga and English, French, portuguese, Hindu-Urdu sanskrit, Chinese (mandarin/unihan), Japanese, Korean, Arabic, Indonesian sanskrit (e.g. pallava script), Russian, Cambodian-Thai Khmer language, Amharic Ethiopian, Swahili language. Obviously other languages like Dutch and German and so on can exist but these main languages cover the world in varius geographic areas and with differing alphabets and languages which can be understood by many as second language (for example like how most chinese people do not speak english as a 2nd language but there are so many chinese english speakers on account of the great many chinese people that the language stills gets good coverage over many a landmass). Portuguese and Spanish people can eventually understand each other (pretty much) if they listen hard and stick to mutually commonplace wordings each. Some Dutch people in Holland would understand something of the language of South Africa, eventually. Ironically of course, they'd probably both know somebody who speaks some part of english too. Elsewhere in blogging, I encourage the translation of slackbook into the languages of rohingya and chittagonian with the #slackbookrohingyachittagonian hashtag.

As I used Paypal, I could add a message. Here it is:

This payment is for: To support a later CDROM (number1 or number2 as the Live CD) ISO file release of slackware15 such as slackware15.1 which you'd make a torrent file for, here is $5 and to ask you to please put SimpleSAMLphp on the ISO file of that distro and for to also have SimpleSAMLphp, thereby making any Slackware CDROM (to HDD) installation (for i586 or amd64) easy to make into a OpenIDConnect (OIDC with OAuth2) server. Include easy LoRaWAN support too shown upon booting like the how a Wifi desktop icon is in XFCE, please. It would be cool (sort of like wubi.exe did but via rtorrent) to have slackware have a boot option to type in a magnet link of a linux distro and attempt to download it (via rj45 DHCP ethernet cat5 home router) in addition to slackware (e.g. kwort or fedora or debian or an older or newer slackware so as to have slackware install it instead or in addition, perhaps dumping it on a fat32 partition on the hdd temporarily and in SWAP space). Keep the distro under 700MB though. Might as well ask just in case you feel like putting these things into slackware 15.1 or 15.2 anyway. Well actually, I'm kind of hoping you'd become inspired to include these things in slackware just by reading this even if the notion is new to you. Also this is to say thanks for making slackware and I hope to encourage others to do a donation for this too. I often recommend slackware to people and have done for about two decades.Sending kind regards from the British Isles, from myself. I saw the forum post about the T-Shirts.My comment has no hate in it and I do no harm. I am not appalled or afraid, boasting or envying or complaining... Just saying. Psalms23: Giving thanks and praise to the Lord and peace and love. Also, I'd say Matthew6.

Pat actually refunded me this $5 and it seems the reason is because he thought it was an "assignment". So donated the $5 again on 23rd September 2023, via Transaction ID 0XK49451SK068444F.

(quote Pat) "Hi, thanks but I don't accept assignments such as this so I'm returning your gift. Best regards, Pat" Transaction ID: 3DK558321H901181B (end quote)

So I just want to make it clear that I DID manage to send him that $5 again after he had refunded it. That way I have made sure that slackware (Volkerding) has the $5 donation. I reckon the 'temporary' refund was on account of just some small confusion as to how the $5 was initially to be donated. If you donate by that paypal link, maybe write "This is not an assignment but just a donation for loving Slackware".

Tempting though, to send multiple small "donations" for small tasks he probably won't do. Maybe for washing the dishes or something. Totally don't do that of course (cough cough). But do donate though.

Paypal Donation Linux Slackware Volkerdi done again

Link to Slackware Donation methods like paypal

Link to Slackware Donation methods like paypal

Link to my post about how slackbook in rohingya and chittagonian could be useful

Link to my post about how slackbook in rohingya and chittagonian could be useful

#linux #slackware #skolelinux #debian #kde #foss #paypal #SlackwareBitTorrentOIDCLoRa

  • Ko chevron_right

    Comment créer un paquet .deb pour Debian / Ubuntu / Mint ? / Korben · 5 days ago - 07:00

Dans le cadre de mon Patreon , j’essaye de varier les sujets et de toujours proposer des tutoriels accessibles à tous ! Parfois, je vous parle de développement, parfois de sécurité, parfois de Windows et bien évidemment de Linux. Et cette semaine, je libère cette vidéo qui n’aurait pas vu le jour sans le soutien des gens inscrits sur mon Patreon !

J’y parle de création de paquets .deb pour Debian et systèmes dérivés comme Ubuntu ou Mint. Vous allez voir, c’est easy !

Merci à vous la team !

  • Pl chevron_right

    dues (or blues) / planetdebian · Wednesday, 17 August - 15:21 · 3 minutes

After I wrote hledger , I got some good feedback, both from a friend in-person and also on Twitter.

My in-person friend asked, frankly, do I really try to manage money like this: tracking every single expense? Which affirms my suspicion, that many people don't, and that it perhaps isn't essential to do so.

Combined with the details below, 3/4 of the way through my experiment with using hledger , I'm not convinced that it has been a good idea.

I'm quoting my Twitter feedback here in order to respond. The context is handling when I have used the "wrong" card to pay for something: a card affiliated with my family expenses for something personal, or vice versa. With double-entry book-keeping, and one pair of transactions, the destination account can either record the expense category:

2022-08-20  coffee
    family:liabilities:creditcard   £ -3
    jon:expenses:coffee             £  3

or the fact it was paid for on the wrong card

2022-08-20  coffee
    family:liabilities:creditcard   £ -3
    family:liabilities:jon          £  3 ; jon owes family

but not easily both. :

When you accidentally use the family CV for personal expenses, credit the account "family:liabilities:creditcard:jon" instead of "family:liabilities:creditcard". That'll allow you to track w/ 2 postings.

This is an interesting idea: create a sub-account underneath the credit card, and I would have a separate balance representing the money I owed. Before:

$ hledger bal -t
            £ -3  family:liabilities:creditcard
             £ 3  jon:expenses:coffee


2022-08-20  coffee
    family:liabilities:creditcard:jon   £ -3
    jon:expenses:coffee                 £  3

Corresponding balances

$ hledger bal -t
            £ -3  family:liabilities:creditcard
            £ -3    jon
             £ 3  jon:expenses:coffee

Great. However, what process would clear the balance on that sub-account? In practise, I don't make a separate, explicit payment to the credit card from my personal accounts. It's paid off in full by direct debit from the family shared account. In practise, such dues are accumulated and settled with one off bank transfers, now and then.

Since the sub-account is still part of the credit card heirarchy, I can't just use a set of virtual postings to consolidate that value with other liabilities, or cover it. Any transaction in there which did not correspond to a real transaction on the credit card would make the balance drift away from the real-word credit statements. The only way I could see this working would be if the direct debit that settles the credit card was artificially split to clear the sub-account, and then the amount owed would be lost. :

Else, add: family:assets:receivable:jon $3
jon:liabilities:family:cc $-3

A "receivable" account would function like the "dues" accounts I described in hledger (except "receivable" is an established account type in double-entry book-keeping). Here I think Pranesh is proposing using these two accounts in addition to the others on a posting. E.g.

2022-08-20  coffee
    family:liabilities:creditcard   £ -3
    jon:expenses:coffee             £  3
    family:assets:receivable:jon    £  3
    jon:liabilities:family          £ -3

This balances, and we end up with two other accounts, which are tracking the exact same thing. I only owe £ 3, but if you didn't know that the accounts were "views" onto the same thing, you could mistakenly think I owed £ 6.

I can't see the advantage of this over just using a virtual, unbalanced posting.

Dues, Liabilities

I'd invented accounts called "dues" to track moneys owed. The more correct term for this in accounting parlance would be "accounts receivable", as in one of the examples above. I could instead be tracking moneys due; this is a classic liability. Liabilities have negative balances.

jon:liabilities:family  £ -3

This means, I owe the family £ 3.

Liability accounts like that are identical to "dues" accounts. A positive balance in a Liability is a counter-intuitive way of describing moneys owed to me, rather than by me. And, reviewing a lot of the coding I did this year, I've got myself hopelessly confused with the signs, and made lots of errors. Crucially, double-entry has not protected me from making those mistakes: of course, I'm circumventing it by using unbalanced virtual postings in many cases (although I was not consistent in where I did this), but even if I used a pair of accounts as in the last example above, I could still screw it up.

Značky: #Debian

  • Pl chevron_right

    Debian turns 29! / planetdebian · Tuesday, 16 August - 11:00

Alt Happy Birthday Debian by Juliette Taka - click to enlarge

Today is Debian's 29th anniversary. We recently wrote about some ideas to celebrate the DebianDay, and several events have been planned in more than 14 locations. You can join the party or organise something yourselves too!

Today is also an opportunity for you to start or resume your contributions to Debian. For example, you can have a look at our list of Debian Teams , install the how-can-i-help package and see if there is a bug in any of the software that you use that you can help to fix, start designing your artwork candidate for the next release, contribute small tips on how to install Debian on your machines to our wiki pages , or put a Debian live image in an USB memory and give it to some person near you, who still didn't discover Debian.

Our favorite operating system is the result of all the work we do together. Thanks to everybody who has contributed in these 29 years, and happy birthday Debian!

Značky: #Debian

  • Pl chevron_right

    Temperature monitoring / planetdebian · Monday, 15 August - 16:01 · 2 minutes

Xiaomi Mijia Temperature Sensor

Xiaomi Mijia Temperature Sensor

I've been having some temperature problems in my house, so I wanted to set up some thermometers which I could read from a computer, and look at trends.

I bought a pack of three cheap Xiaomi IoT thermometers. There's some official Xiaomi tooling to access them from smartphones and suchlike, but I wanted something more open. The thermometers have some rudimentary security on them to try and ensure you use the official tooling. This is pretty weak, and the open-source Home Assistant (HA) has support for querying them. I wasn't already running HA and it looked to do more than I needed right now.


A friend told me that it was trivial to write custom firmware to the devices . It's so easy you can do it from a web-based flasher: in fact, anyone in range can. There's a family of custom firmwares out there, and most move the sensors readings into the BTLE announce packets, meaning, you can scrape the temperature by simply reading and decoding the announcement packets, no need to handshake at all, and certainly no need to navigate Xiaomi's weird security. This is the one I used .

I hacked up a Python script to read the values with the help of this convenience library 1 .

Next, I needed to set up somewhere to write the values.


The study is thankfully cooler today

The study is thankfully cooler today

It's been long enough since I last looked at something like this that the best in class software was things like multi router traffic grapher , and rrdtool , or things that build on top of them like Munin . The world seems to have moved on (rightly or wrongly) with a cornucopia of options like Prometheus, Grafana, Graphite/Carbon, InfluxDB, statsd, etc.

I ruled most of these out as being too complex for what I want to do, and got something working with Graphite (front-end) and Carbon (back-end). I was surprised that this wasn't packaged in Debian, and opted to try the Docker container. This works, although even that is more complex than I need: it's got graphite and carbon , but also nginx and statsd too; I'm submitting directly to carbon , side-stepping statsd entirely. So as I refine what I'm doing I might possibly strip that back.

next steps

I might add more sensors in my house! My scripts also need a lot of tidying up. But, I think it would be useful to add some external temperature data, such as something from a Weather service. I am also considering pulling in some of the sensor data from the Newcastle University Urban Observatory , which is something I looked at a while ago for my PhD but didn't ultimately end up using. There are several temperature sensors nearby, but they seem to operate relatively sporadically.

There's a load of other interesting sensors in my vicinity, such as air quality monitors.

I'm currently ignoring the humidity data from the sensors but I should collect that too.

It would be useful to mark relevant "events", too: does switching on or off my desktop PC, or printer, etc. correlate to a jump in temperature?

  1. I might get rid of that in the future as I refine my approach

Značky: #Debian

  • Pl chevron_right

    The Joy of Easy Personal Radio: FRS, GMRS, and Motorola DLR/DTR / planetdebian · Monday, 15 August - 14:02 · 21 minutes

Most of us carry cell phones with us almost everywhere we go. So much so that we often forget not just the usefulness, but even the joy, of having our own radios. For instance:

  • When traveling to national parks or other wilderness areas, family and friends can keep in touch even where there is no cell coverage.

  • It is a lot faster to just push a button and start talking than it is to unlock a phone, open the phone app, select a person, wait for the call to connect, wait for the other person to answer, etc. “I’m heading back.” “OK.” Boom, 5 seconds, done. A phone user wouldn’t have even dialed in that time.

  • A whole group of people can be on the same channel.

  • You can often buy a radio for less than the monthly cost of a cell plan.

From my own experience, as a person and a family that enjoys visiting wilderness areas, having radio communication is great. I have also heard from others that they’re also very useful on cruise ships (I’ve never been on one so I can’t attest to that).

There is also a sheer satisfaction in not needing anybody else’s infrastructure, not paying any sort of monthly fee, and setting up the radios ourselves.

How these services fit in

This article is primarily about handheld radios that can be used by anybody. I laid out some of their advantages above. Before continuing, I should point out some of the other services you may consider:

  • Cell phones, obviously. Due to the impressive infrastructure you pay for each month (many towers in high locations), in areas of cell coverage, you have this ability to connect to so many other phones around the world. With radios like discussed here, your range will likely a few miles.

  • Amateur Radio has often been a decade or more ahead of what you see in these easy personal radio devices. You can unquestionably get amateur radio devices with many more features and better performance. However, generally speaking, each person that transmits on an amateur radio band must be licensed. Getting an amateur radio license isn’t difficult, but it does involve passing a test and some time studying for the exam. So it isn’t something you can count on random friends or family members being able to do. That said, I have resources on Getting Started With Amateur Radio and it’s not as hard as you might think! There are also a lot of reasons to use amateur radio if you want to go down that path.

  • Satellite messengers such as the Garmin Inreach or Zoleo can send SMS-like messages across anywhere in the globe with a clear view of the sky. They also often have SOS features. While these are useful safety equipment, it can take many minutes for a message to be sent and received – it’s not like an interactive SMS conversation – and there are places where local radios will have better signal. Notably, satellite messengers are almost useless indoors and can have trouble in areas without a clear view of the sky, such as dense forests, valleys, etc.

  • My earlier Roundup of secure messengers with off-the-grid capabilities (distributed/mesh messengers) highlighted a number of other options as well, for text-only communication. For instance:

    • For very short-range service, Briar can form a mesh over Bluetooth from cell phones – or over Tor, if Internet access is available.

    • Dedicated short message services Mesh Network s like Meshtastic or Beartooth have no voice capability, but share GPS locations and short text messages over their own local mesh. Generally they need to pair to a cell phone (even if that phone has no cell service) for most functionality.

  • Yggdrasil can do something similar over ad-hoc Wifi, but it is a lower-level protocol and you’d need some sort of messaging to run atop it.

This article is primarily about the USA, though these concepts, if not the specific implementation, apply many other areas as well.

The landscape of easy personal radios

The oldest personal radio service in the US is Citizens Band (CB). Because it uses a lower frequency band than others, handheld radios are larger, heavier, and less efficient. It is mostly used in vehicles or other installations where size isn’t an issue.

The FRS/GMRS services mostly share a set of frequencies. The Family Radio Service is unlicensed (you don’t have to get a license to use it) and radios are plentiful and cheap. When you get a “blister pack” or little radios for maybe $50 for a pair or less, they’re probably FRS. FRS was expanded by the FCC in 2017, and now most FRS channels can run up to 2 watts of power (with channels 8-14 still limited to 0.5W). FRS radios are pretty much always handheld.

GMRS runs on mostly the same frequencies as FRS. GMRS lets you run up to 5W on some channels, up to 50W on others, and operate repeaters. GMRS also permits limited occasional digital data bursts; three manufacturers currently use this to exchange GPS data or text messages. To use GMRS, you must purchase a GMRS license; it costs $35 for a person and their immediate family and is good for 10 years. No exam is required. GMRS radios can transmit on FRS frequencies using the GMRS authorization.

The extra power of GMRS gets you extra distance. While only the best handheld GMRS radios can put out 5W of power, some mobile (car) or home radios can put out the full 50W, and use more capable exterior antennas too.

There is also the MURS band, which offers very few channels and also very few devices. It is not in wide use, probably for good reason.

Finally, some radios use some other unlicensed bands. The Motorola DTR and DLR series I will talk about operate in the 900MHz ISM band. Regulations there limit them to a maximum power of 1W, but as you will see, due to some other optimizations, their range is often quite similar to a 5W GMRS handheld.

All of these radios share something in common: your radio can either transmit, or receive, but not both simultaneously. They all have a PTT (push-to-talk) button that you push and hold while you are transmitting, and at all other times, they act as receivers.

You’ll learn that “doubling” is a thing – where 2 or more people attempt to transmit at the same time. To listeners, the result is often garbled. To the transmitters, they may not even be aware they did it – since, after all, they were transmitting. Usually it will be clear pretty quickly as people don’t get responses or responses say it was garbled. Only the digital Motorola DLR/DTR series detects and prevents this situation.

FRS and GMRS radios

As mentioned, the FRS/GMRS radios are generally the most popular, and quite inexpensive. Those that can emit 2W will have pretty decent range; 5W even better (assuming a decent antenna), though the 5W ones will require a GMRS license. For the most part, there isn’t much that differentiates one FRS radio from another, or (with a few more exceptions) one GMRS handheld from another. Do not believe the manufacturers claims of “50 mile range” or whatever; more on range below.

FRS and GMRS radios use FM. GMRS radios are permitted to use a wider bandwidth than FRS radios, but in general, FRS and GMRS users can communicate with each other from any brand of radio to any other brand of radio, assuming they are using basic voice services.

Some FRS and GMRS radios can receive the NOAA weather radio. That’s nice for wilderness use. Nicer ones can monitor it for alert tones, even when you’re tuned to a different channel. The very nicest on this – as far as I know, only the Garmin Rino series – will receive and process SAME codes to only trigger alerts for your specific location.

GMRS (but not FRS) also permits 1-second digital data bursts at periodic intervals. There are now three radio series that take advantage of this: the Garmin Rino , the Motorola T800 , and BTech GMRS-PRO . Garmin’s radios are among the priciest of GMRS handhelds out there; the top-of-the-line Rino will set you back $650. The cheapest is $350, but does not contain a replaceable battery, which should be an instant rejection of a device like this. So, for $550, you can get the middle-of-the-road Rino. It features a sophisticated GPS system with Garmin trail maps and such, plus a 5W GMRS radio with GPS data sharing and a very limited (13-character) text messaging system. It does have a Bluetooth link to a cell phone, which can provide a link to trail maps and the like, and limited functionality for the radio. The Rino is also large and heavy (due to its large map-capable screen). Many consider it to be somewhat dated technology; for instance, other ways to have offline maps now exist (such as my Garmin Fenix 6 Pro, which has those maps on a watch!). It is bulky enough to likely be left at home in many situations.

The Motorola T800 doesn’t have much to talk about compared to the other two.

Both of those platforms are a number of years old. The newest entrant in this space, from budget radio maker Baofeng, is the BTech GMRS-PRO, which came out just a couple of weeks ago. Its screen, though lacking built-in maps, does still have a GPS digital link similar to Garmin’s, and can show you a heading and distance to other GMRS-PRO users. It too is a 5W unit, and has a ton of advanced features that are rare in GMRS: ability to pair a Bluetooth headset to it directly (though the Garmin Rino supports Bluetooth, it doesn’t support this), ability to use the phone app as a speaker/mic for the radio, longer text messages than the Garmin Rino, etc. The GMRS-PRO sold out within a few days of its announcement, and I am presently waiting for mine to arrive to review. At $140 and with a more modern radio implementation, for people that don’t need the trail maps and the like, it makes a compelling alternative to Garmin for outdoor use.

Garmin documents when GPS beacons are sent out: generally, when you begin a transmission, or when another radio asks for your position. I couldn’t find similar documentation from Motorola or BTech, but I believe FCC regulations mean that the picture would be similar with them. In other words, none of these devices is continuously, automatically, transmitting position updates. However, you can request a position update from another radio.

It should be noted that, while voice communication is compatible across FRS/GMRS, data communication is not. Garmin, Motorola, and BTech all have different data protocols that are incompatible with radios from other manufacturers.

FRS/GMRS radios often advertise “privacy codes.” These do nothing to protect your privacy; see more under the privacy section below.

Motorola DLR and DTR series

Although they can be used for similar purposes, and I do, these radios are unique from the others in this article in several ways:

  • Their sales and marketing is targeted at businesses rather than consumers
  • They use digital encoding of audio, rather than analog FM or AM
  • They use FHSS (Frequency-Hopping Spread Spectrum) rather than a set frequency
  • They operate on the 900MHz ISM band, rather than a 460MHz UHF band (or a lower band yet for MURS and CB)
  • The DLR series is quite small, smaller than many GMRS radios.

I don’t have space to go into a lot of radio theory in this article, but I’ll briefly expand on some of this.

First, FHSS. A FHSS radio hops from frequency to frequency many times per second, following some preset hopping algorithm that is part of the radio. Although it complicates the radio design, it has some advantages; it tends to allow more users to share a band, and if one particular frequency has a conflict with something else, it will be for a brief fraction of a second and may not even be noticeable.

Digital encoding generally increases the quality of the audio, and keeps the quality high even in degraded signal conditions where analog radios would experience static or a quieter voice. However, you also lose that sort of audible feedback that your signal is getting weak. When you get too far away, the digital signal “drops off a cliff”. Often, either you have a crystal-clear signal or you have no signal at all.

Motorola’s radios leverage these features to build a unique radio. Not only can you talk to a group, but you can select a particular person to talk to with a private conversation, and so forth. DTR radios can send text messages to each other (but only preset canned ones, not arbitrary ones). “Channels” are more like configurations; they can include various arbitrary groupings of radios. Deconfliction with other users is established via “hopsets” rather than frequencies; that is, the algorithm that it uses to hop from frequency to frequency. There is a 4-digit PIN in the DLR radios, and newer DTR radios, that makes privacy very easy to set up and maintain.

As far as I am aware, no scanner can monitor DLR/DTR signals. Though they technically aren’t encrypted, cracking a DLR/DTR conversation would require cracking Motorola’s firmware, and the chances of this happening in your geographical proximity seem vanishingly small.

I will write more below on comparing the range of these to GMRS radios, but in a nutshell, it compares well, despite the fact that the 900MHz band restrictions allow Motorola only 1W of power output with these radios.

There are three current lines of Motorola DLR/DTR radios:

  • The Motorola DLR1020 and DLR1060 radios. These have no screen; the 1020 has two “channels” (configurations) while the 1060 supports 6. They are small and compact and great pocketable “just work” radios.
  • The Motorola DTR600 and DTR700 radios. These are larger, with a larger antenna (that should theoretically provide greater range) and have a small color screen. They support more channels and more features (eg, short messages, etc).
  • The Motorola Curve (aka DLR110). Compared to the DLR1060, it adds limited WiFi capabilities that are primarily useful in certain business environments. See this thread for more. These features are unlikely to be useful in the environments we’re talking about here.

These radios are fairly expensive new, but DLRs can be readily found at around $60 on eBay. (DTRs for about $250) They are quite rugged. Be aware when purchasing that some radios sold on eBay may not include a correct battery and charger. (Not necessarily a problem; Motorola batteries are easy to find online, and as with any used battery, the life of a used one may not be great.) For more advanced configuration, the Motorola CPS cable works with both radios (plugs into the charging cradle) and is used with the programming software to configure them in more detail.

The older Motorola DTR650, DTR550, and older radios are compatible with the newer DLR and DTR series, if you program the newer ones carefully. The older ones don’t support PINs and have a less friendly way of providing privacy, but they do work also. However, for most, I think the newer ones will be friendlier; but if you find a deal on the older ones, hey, why not?

This thread on the MyGMRS forums has tons of useful information on the DLR/DTR radios. Check it out for a lot more detail.

One interesting feature of these radios is that they are aware if there are conflicting users on the channel, and even if anybody is hearing your transmission. If your transmission is not being heard by at least one radio, you will get an audible (and visual, on the DTR) indication that your transmission failed.

One thing that pleasantly surprised me is just how tiny the Motorola DLR is. The whole thing with antenna is like a small candy bar, and thinner. My phone is slightly taller, much wider, and only a little thinner than the Motorola DLR. Seriously, it’s more pocketable than most smartphones. The DTR is of a size more commonly associated with radios, though still on the smaller side. Some of the most low-power FRS radios might get down to that size, but to get equivolent range, you need a 5W GMRS unit, which will be much bulkier.


These radios tend to be powered by:

  • NiMH rechargable battery packs
  • AA/AAA batteries
  • Lithium Ion batteries

Most of the cheap FRS/GMRS radios have a NiMH rechargable battery pack and a terrible charge controller that will tend to overcharge, and thus prematurely destroy, the NiMH packs. This has long ago happened in my GMRS radios, and now I use Eneloop NiMH AAs in them (charged separately by a proper charger).

The BTech, Garmin, and Motorola DLR/DTR radios all use Li-Ion batteries. These have the advantage of being more efficient batteries, though you can’t necessarily just swap in AAs in a pinch. Pay attention to your charging options; if you are backpacking, for instance, you may want something that can charge from solar-powered USB or battery banks. The Motorola DLR/DTR radios need to sit in a charging cradle, but the cradle is powered by a Micro USB cable. The BTech GMRS-PRO is charged via USB-C. I don’t know about the Garmin Rino or others.

Garmin offers an optional AA battery pack for the Rino. BTech doesn’t (yet) for the GMRS-PRO, but they do for some other models, and have stated accessories for the GMRS-PRO are coming. I don’t have information about the T800. This is not an option for the DLR/DTR.


I’ll briefly mention Meshtastic . It uses a low-power LoRa system. It can’t handle voice transmissions; only data. On its own, it can transmit and receive automatic GPS updates from other Meshtastic devices, which you can view on its small screen. It forms a mesh, so each node can relay messages for others. It is also the only unit in this roundup that uses true encryption, and its battery lasts about a week – more than the “a solid day” you can expect out of the best of the others here.

When paired with a cell phone, Meshtastic can also send and receive short text messages.

Meshtastic uses much less power than even the cheapest of the FRS radios discussed here. It can still achieve respectable range because it uses LoRa, which can trade bandwidth for power or range. It can take it a second or two to transmit a 50-character text message. Still, the GMRS or Motorola radios discussed here will have more than double the point-to-point range of a Meshtastic device. And, if you intend to take advantage of the text messaging features, keep in mind that you must now take two electronic devices with you and maintain a charge for them both.


The privacy picture on these is interesting.

Cell phone privacy

Cell phones are difficult for individuals to eavesdrop, but a sophisticated adversary probably could: or an unsophisticated adversary with any manner of malware. Privacy on modern smartphones is a huge area of trouble, and it is safe to say that data brokers and many apps probably know at least your location and contact list, if not also the content of your messages. Though apps such as Signal can certainly help. See Tools for Communicating Offline and in Difficult Circumstances for more details.

GMRS privacy

GMRS radios are unencrypted and public. Anyone in range with another GMRS radio, or a scanner, can listen to your conversations – even if you have a privacy code set. The privacy code does not actually protect your privacy; rather, it keeps your radio from playing conversations from others using the same channel, for your convenience.

However, note the “in range” limitation. An eavesdropper would generally need to be within a few miles of you.

Motorola DLR/DTR privacy

As touched on above, while these also aren’t encrypted, as far as I am aware, no tools exist to eavesdrop on DLR/DTR conversations. Change the PIN away from the default 0000, ideally to something that doesn’t end in 0 (to pick a different hopset) and you have pretty decent privacy right there.


Meshtastic uses strong encryption. But as messaging features require a paired phone, the privacy implications of a phone also apply here.


I tested my best 5W GMRS radios, as well as a Motorola DTR600 talking to a DLR1060. I took a radio with me in the car, and had another sitting on my table indoors. Those of you familiar with radios will probably recognize that being in a car and being indoors both attenuate (reduce the strength of) the signal significantly. I drove around in a part of Kansas with gentle rolling hills.

Both the GMRS and the DLR/DTR had a range of about 2-2.5 miles. There were times when each was able to pull out a signal when the other was not. The DLR/DTR series was significantly better while the vehicle was in motion. In weaker signal conditions, the GMRS radios were susceptible to significant “picket fencing” (static caused by variation in the signal strength when passing things like trees), to the point of being inaudible or losing the signal entirely. The DLR/DTR remained perfectly clear there. I was able to find some spots where, while parked, the GMRS radios had a weak but audible signal but the DLR/DTR had none. However, in all those cases, the distance to GMRS dropping out as well was small. Basically, no radios penetrate the ground, and the valleys were a problem for them all.

Differences may play out in other ways in other environments as well: for instance, dense urban environments, heavy woods, indoor buildings, etc.

GMRS radios can be used with repeaters, or have a rooftop antenna mounted on a car, both of which could significantly extend range – and both of which are rare.

The DLR/DTR series are said to be exceptionally good at indoor environments; Motorola rates them for penetrating 20 floors, for instance. Reports on MyGMRS forums state that they are able to cover an entire cruise ship, while the metal and concrete in them poses a big problem for GMRS radios. Different outdoor landscapes may favor one or the other also.

Some of the cheapest FRS radios max out at about 0.5W or even less. This is probably only a little better than yelling distance in many cases. A lot of manufacturers obscure transmit power and use outlandish claims of range instead; don’t believe those. Find the power output. A 2W FRS transmitter will be more credible range-wise, and the 5W GMRS transmitter as I tested better yet. Note that even GMRS radios are restricted to 0.5W on channels 8-14.

The Motorola DLR/DTR radio gets about the same range with 1W as a GMRS radio does with 5W. The lower power output allows the DLR to be much smaller and lighter than a 5W GMRS radio for similar performance.

Overall conclusions

Of course, what you use may depend on your needs. I’d generally say:

  • For basic use, the high quality, good range, reasonable used price, and very small size of the Motorola DLR would make it a good all-arounder. Give one to each person (or kid) for use at the mall or amusement park, take them with you to concerts and festivals, etc.
  • Between vehicles, the Motorola DLR/DTR have a clear range advantage over the GMRS radios for vehicles in motion, though the GPS features of the more advanced GMRS radios may be more useful here.
  • For wilderness hiking and the like, GMRS radios that have GPS, maps, and NOAA weather radio reception may prove compelling and worth the extra bulk. More flexible power options may also be useful.
  • Low-end FRS radios can be found very cheap; around $20-$30 new for the lowest end, though their low power output and questionable charging circuits may limit their utility where it really counts.
  • If you just can’t move away from cell phones, try the Zoleo app, which can provide some radio-like features.
  • A satellite communicator is still good backup safety gear for the wilderness.

Postscript: A final plug for amateur radio

My 10-year-old Kenwood TH-D71A already had features none of these others have. For instance, its support for APRS and ability to act as a digipeater for APRS means that TH-D71As can form an automatic mesh between them, each one repeating new GPS positions or text messages to the others. Traditional APRS doesn’t perform well in weak signal situations; however, more modern digital systems like D-Star and DMR also support APRS over more modern codecs and provide all sorts of other advantages as well (though not FHSS).

My conclusions above assume a person is not going to go the amateur radio route for whatever reason. If you can get those in your group to get their license – the technician is all you need – a whole world of excellent options opens to you.

Note: This article has a long-term home on my website, where it may be updated from time to time.

Značky: #Debian

  • Pl chevron_right

    RcppArmadillo used by 1001 CRAN Packages / planetdebian · Sunday, 14 August - 14:08 · 1 minute

It is with a mix of pride and joy, but also some genuine astonishment and amazement, that we can share that the counter of reverse dependencies at CRAN for our RcppArmadillo package for R just crossed 1000 packages [1]:


Conrad actually posted this a few weeks ago, by my count we were then still a few packages shy. In any event, having crossed this marker this summer, either then or now, and after more than a dozen years of working on the package is a really nice moment. Google Scholar counts nearly 500 citations for our CSDA paper (also this vignette ), and that ratio of nearly a citation for every two packages used is certainly impressive. We have had the pleasure of working with so many other researchers and scientists using RcppArmadillo. Its combination of performance (C++, after all, and heavily tuned) and ease-of-use (inspired by ‘another popular flavour for matrix computing’ that is however mostly interpreted) makes for a powerful package, and we are delighted to see it used so widely.

Working on this with Conrad has been excellent. The (upstream) package (now at this GitLab repo ) has received numerous releases at a rate that is in fact so high that we now ‘slow it down’ to not exceed a monthly cadence of uploads to CRAN . But the package should always be in release condition at its GitHub repo , and is frequently also installable in ‘rc’ versions via the Rcpp drat repo .

So with that, a big Thank You! to Conrad, to Romain for all the early work laying the package foundations, and to all the users of (Rcpp)Armadillo for helping us along with testing, suggestions, extensions, and bug reports. Keep’em coming!

If you like this or other open-source work I do, you can now sponsor me at GitHub .

[1] The code snippet shows that we remove some possible duplicates in the count (mostly for the total of packages). This is a correction we use across packages for consistency. It does not have an effect for RcppArmadillo .

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Značky: #Debian

  • Pl chevron_right

    Review: Still Not Safe / planetdebian · Sunday, 14 August - 03:38 · 7 minutes

Review: Still Not Safe , by Robert L. Wears & Kathleen M. Sutcliffe

Publisher: Oxford University Press
Copyright: November 2019
ISBN: 0-19-027128-0
Format: Kindle
Pages: 232

Still Not Safe is an examination of the recent politics and history of patient safety in medicine. Its conclusions are summarized by the opening paragraph of the preface:

The American moral and social philosopher Eric Hoffer reportedly said that every great cause begins as a movement, becomes a business, and eventually degenerates into a racket. The reform movement to make healthcare safer is clearly a great cause, but patient safety efforts are increasingly following Hoffer's path.

Robert Wears was Professor of Emergency Medicine at the University of Florida specializing in patient safety. Kathleen Sutcliffe is Professor of Medicine and Business at Johns Hopkins. This book is based on research funded by a grant from the Robert Wood Johnson Foundation, for which both Wears and Sutcliffe were primary investigators. (Wears died in 2017, but the acknowledgments imply that at least early drafts of the book existed by that point and it was indeed co-written.)

The anchor of the story of patient safety in Still Not Safe is the 1999 report from the Institute of Medicine entitled To Err is Human , to which the authors attribute an explosion of public scrutiny of medical safety. The headline conclusion of that report, which led nightly news programs after its release, was that 44,000 to 120,000 people died each year in the United States due to medical error. This report prompted government legislation, funding for new safety initiatives, a flurry of follow-on reports, and significant public awareness of medical harm. What it did not produce, in the authors' view, is significant improvements in patient safety.

The central topic of this book is an analysis of why patient safety efforts have had so little measurable effect. The authors attribute this to three primary causes: an unwillingness to involve safety experts from outside medicine or absorb safety lessons from other disciplines, an obsession with human error that led to profound misunderstandings of the nature of safety, and the misuse of safety concerns as a means to centralize control of medical practice in the hands of physician-administrators. (The term used by the authors is "managerial, scientific-bureaucratic medicine," which is technically accurate but rather awkward.)

Biggest complaint first: This book desperately needed examples, case studies, or something to make these ideas concrete. There are essentially none in 230 pages apart from passing mentions of famous cases of medical error that added to public pressure, and a tantalizing but maddeningly nonspecific discussion of the atypically successful effort to radically improve the safety of anesthesia. Apparently anesthesiologists involved safety experts from outside medicine, avoided a focus on human error, turned safety into an engineering problem, and made concrete improvements that had a hugely positive impact on the number of adverse events for patients. Sounds fascinating! Alas, I'm just as much in the dark about what those improvements were than I was when I started reading this book. Apart from a vague mention of some unspecified improvements to anesthesia machines, there are no concrete descriptions whatsoever.

I understand that the authors were probably leery of giving too many specific examples of successful safety initiatives since one of their core points is that safety is a mindset and philosophy rather than a replicable set of actions, and copying the actions of another field without understanding their underlying motivations or context within a larger system is doomed to failure. But you have to give the reader something , or the book starts feeling like a flurry of abstract assertions. Much is made here of the drawbacks of a focus on human error, and the superiority of the safety analysis done in other fields that have moved beyond error-centric analysis (and in some cases have largely discarded the word "error" as inherently unhelpful and ambiguous). That leads naturally to showing an analysis of an adverse incident through an error lens and then through a more nuanced safety lens, making the differences concrete for the reader. It was maddening to me that the authors never did this.

This book was recommended to me as part of a discussion about safety and reliability in tech and the need to learn from safety practices in other fields. In that context, I didn't find it useful, although surprisingly that's because the thinking in medicine (at least as presented by these authors) seems behind the current thinking in distributed systems. The idea that human error is not a useful model for approaching reliability is standard in large tech companies, nearly all of which use blameless postmortems for exactly that reason. Tech, similar to medicine, does have a tendency to be insular and not look outside the field for good ideas, but the approach to large-scale reliability in tech seems to have avoided the other traps discussed here. (Security is another matter, but security is also adversarial, which creates a different set of problems that I suspect require different tools.)

What I did find fascinating in this book, although not directly applicable to my own work, is the way in which a focus on human error becomes a justification for bureaucratic control and therefore a concentration of power in a managerial layer. If the assumption is that medical harm is primarily caused by humans making avoidable mistakes, and therefore the solution is to prevent humans from making mistakes through better training, discipline, or process, this creates organizations that are divided into those who make the rules and those who follow the rules. The long-term result is a practice of medicine in which a small number of experts decide the correct treatment for a given problem, and then all other practitioners are expected to precisely follow that treatment plan to avoid "errors." (The best distributed systems approaches may avoid this problem, but this failure mode seems nearly universal in technical support organizations.)

I was startled by how accurate that portrayal of medicine felt. My assumption prior to reading this book is that the modern experience of medicine as an assembly line with patients as widgets was caused by the pressure for higher "productivity" and thus shorter visit times, combined with (in the US) the distorting effects of our broken medical insurance system. After reading this book, I've added a misguided way of thinking about medical error and risk avoidance to that analysis.

One of the authors' points (which, as usual, I wish they'd made more concrete with a case study) is that the same thought process that lets a doctor make a correct diagnosis and find a working treatment is the thought process that may lead to an incorrect diagnosis or treatment. There is not a separable state of "mental error" that can be eliminated. Decision-making processes are more complicated and more integrated than that. If you try to prevent "errors" by eliminating flexibility, you also eliminate vital tools for successfully treating patients.

The authors are careful to point out that the prior state of medicine in which each doctor was a force to themselves and there was no role for patient safety as a discipline was also bad for safety. Reverting to the state of medicine before the advent of the scientific-bureaucratic error-avoiding culture is also not a solution. But, rather at odds with other popular books about medicine, the authors are highly critical of safety changes focused on human error prevention, such as mandatory checklists. In their view, this is exactly the sort of attempt to blindly copy the machinery of safety in another field (in this case, air travel) without understanding the underlying purpose and system of which it's a part. I am not qualified to judge the sharp dispute over whether there is solid clinical evidence that checklists are helpful (these authors claim there is not; I know other books make different claims, and I suspect it may depend heavily on how the checklist is used). But I found the authors' argument that one has to design systems holistically for safety, not try to patch in safety later by turning certain tasks into rote processes and humans into machines, to be persuasive.

I'm not willing to recommend this book given how devoid it is of concrete examples. I was able to fill in some of that because of prior experience with the literature on site reliability engineering, but a reader who wasn't previously familiar with discussions of safety or reliability may find much of this book too abstract to be comprehensible. But I'm not sorry I read it. I hadn't previously thought about the power dynamics of a focus on error, and I think that will be a valuable observation to keep in mind.

Rating: 6 out of 10

Značky: #Debian