- Roundtable - muug.ca

gOOgle/gmail prying eyes
by eh＠eduardhiebert.com 13 Feb '22

13 Feb '22

Hi, Pertaining reasonable privacy concerns one key question, but first the qualifiers. Any and all email crossing gOOgles hands whether their user or NOT gets copied and data mined. If a non-gmail address sends one email to multiple contacts and one of them is on gmail or to any of gOOgle's cloaked and hidden email service account provider such as for the CBC, gOOgle has access to it. My question is, if an email is sent to multiple parties and even if one of these is gmail, but should those who are on BCC (the non gmail ones) still somehow be visible to gmail? Thanks, Eduard

4 5

Reminder: MUUG Online Meeting, Tonight, Feb 8, 7:30pm -- Tactical RMM
by Gilbert E. Detillieux 08 Feb '22

08 Feb '22

A reminder that the MUUG online meeting will be on BBB this evening... The Manitoba UNIX User Group (MUUG) will be holding its next monthly meeting online, on Tuesday, February 8th, at 7:30pm: Tactical RMM This month's presentation is on Tactical RMM, a powerful, self- hosted tool for managing large amounts of Windows computers. Chris Audet will demonstrate some common use cases for TRMM such as patch management, client system health checks, and remoting into client computers to provide support. This will once again be an online meeting. Stay tuned to our muug.ca home page for the official URL, which will be made available about a half hour before the meeting starts. (Reload the page if you don't see the link, or if there are issues with connecting.) The group holds its meetings at 7:30pm on the second Tuesday of every month from September to June. (There are no meetings in July and August.) Meetings are open to the general public; you don't have to be a MUUG member to attend. For more information about MUUG, and its monthly meetings, check out their web server: https://muug.ca/ Help us promote this month's meeting, by putting this poster up on your workplace bulletin board or other suitable public message board, or linking to it on social media: https://muug.ca/meetings/MUUGmeeting.pdf -- Gilbert E. Detillieux E-mail: <gedetil(a)muug.ca> Manitoba UNIX User Group Web: http://muug.ca/

1 0

Re: [RndTbl] Holy fanless computing, batman... (eh@eduardhiebert.com)
by Brock Wolfe 06 Feb '22

06 Feb '22

One Canadian source with prices for the MB's mentioned http://www.atic.ca/index.php?page=newsearch&searchterm=M11SDV-8CT-LN4F&x=51… http://www.atic.ca/index.php?page=newsearch&searchterm=A2SDi-H-TF&x=34&y=5 Brock

3 2

Holy fanless computing, batman...
by Adam Thompson 05 Feb '22

05 Feb '22

SuperMicro’s A2SDi-H-TF : * 2.2GHz Denverton (Atom C3758) CPU architecture, 8 cores w/16MB each but not superscalar, no Turbo, and no HT. Still plenty fast enough for most applications. * Up to 256GB of ECC RAM. * Dual 10G onboard. * 13 x SATA ports (including 1xSuperDOM), 8 of them delivered via 2x Mini-SAS HD ports * 1 x PCI-E x4 * 1 x M.2 * 1 x internal USB 3.1 (type A) port * IPMI and remote mgmt. subsystem onboard And although there are 4 fan headers, this is a Mini-ITX (!) board that runs a cool 25W (i.e. fanless!!!). There’s an entire series of them this year from SuperMicro, all having slightly different configurations. I know I’m getting old, but this is as incredible to me as my current equipment would have been to 10- or 20-years-ago me. -Adam

3 3

Slackware 15 is released
by Alberto Abrao 03 Feb '22

03 Feb '22

A few days after the newsletter, here it is: http://www.slackware.com -- Sent from a phone.

5 4

MUUG Online Meeting, Tuesday, Feb 8, 7:30pm -- Tactical RMM
by Gilbert E. Detillieux 01 Feb '22

01 Feb '22

The Manitoba UNIX User Group (MUUG) will be holding its next monthly meeting online, on Tuesday, February 8th, at 7:30pm: Tactical RMM This month's presentation is on Tactical RMM, a powerful, self- hosted tool for managing large amounts of Windows computers. Chris Audet will demonstrate some common use cases for TRMM such as patch management, client system health checks, and remoting into client computers to provide support. This will once again be an online meeting. Stay tuned to our muug.ca home page for the official URL, which will be made available about a half hour before the meeting starts. (Reload the page if you don't see the link, or if there are issues with connecting.) The group holds its meetings at 7:30pm on the second Tuesday of every month from September to June. (There are no meetings in July and August.) Meetings are open to the general public; you don't have to be a MUUG member to attend. For more information about MUUG, and its monthly meetings, check out their web server: https://muug.ca/ Help us promote this month's meeting, by putting this poster up on your workplace bulletin board or other suitable public message board, or linking to it on social media: https://muug.ca/meetings/MUUGmeeting.pdf -- Gilbert E. Detillieux E-mail: <gedetil(a)muug.ca> Manitoba UNIX User Group Web: http://muug.ca/

1 0

PHP undefined vars / array indices
by Trevor Cordes 24 Jan '22

24 Jan '22

Any PHP coders out there? So PHP really did it in 8.0: They really made accessing undefined vars *and* array indices a full warning rather than a notice. I had written in past newsletters that I hoped this didn't mean what it sounded like it meant. But it does. They really did it. https://wiki.php.net/rfc/engine_warnings I finally had to face the music with the upgraded MUUG server which now uses PHP8. It was coming for me in Fedora 25 anyhow (maybe 4 more months to postpone that change). The MUUG server is about 80% code that Allan Pollard wrote (thanks Allan!) and 20% my own code. Neither wrote according to PHP8's magic new requirements. Anyone here who does PHP and hasn't treated it as a typed / declared language, because it is not one, is in for a great deal of pain when they are forced to upgrade to PHP 8. I'm not sure I've ever come across existing PHP code where the dev treated it as a language where you must pre-declare everything. Of course, such people must exist, as exhibited by the voting record for this PHP RFC. Perhaps they are people who only recently took up PHP and/or are coming from stricter languages. And that is my main beef: if you want a strict language, use a strict language. Why take a loose language, which has always been loose and is loose by design, and suddenly make a major change that is going to spew out errors all over everyone's screen (if display_errors is on) for 90% of all legacy code? If I want strict variable declaration, I'll use one of the zillion languages that force you, and even do nice compile-time checks for you. And you just know that while, at the moment, this change is limited to making it a warning, the tyrants are itching to make this a full explosion error. You can see it in the voting ("Change undefined variable severity to?": vote 36 to 28). Luckily for us PHP requires a 2/3 majority to pass an RFC. To "fix" these errors in code, you can in most cases use a lot of tricks, like massive use of ?? everywhere. But that makes the code look really ugly and I start to question why? And if you use list() to capture results of a function which can return variable type of variable length arrays, you're really in trouble as there's no current syntax to combine ?? or isset() with that. Sure, you can go in and turn your PHP into C by pre-declaring every variable, if you can spot them all in complex functions or global scope code. But that only helps you with the "undefined variables" thing, not the "undefined array index" thing. The latter is far more insidious because your index can be a variable itself! So for that case you must always use isset() or ?? or some other trick. I could go into more examples of what I had to do to the MUUG code if anyone is interested. So what can you do in the real world? The first thing you do is turn off display_errors, which is probably off on production boxes anyhow (but wasn't on "hobby" boxes like MUUG, but it is now). Then make sure those warnings are being logged. Then sit back and let people use your site and wait for the MBs of log lines saying undefined this and that. Then you have a choice: a) ignore it all and set your logrotate to a short period of time so you don't fill your log disks; or b) fix every error that shows up. I did (b) on MUUG and it's not fun, and that's just a small code base. In either case you must pray the PHP tyrants don't soon vote this into a runtime exception error, as when you retrofit your old code you're almost never going to find every instance of this. Compare this situation with perl strict. Perl introduced "strict" mode with "use strict" a long time ago. That makes you my() every variable and its dog or you get a full blown error. But I'm pretty sure it doesn't affect array indices. In any event, if you don't agree with the perl devs, you just write "no strict" (or just disable this specific strict). No tyrrany. Freedom and choice. Perl, like PHP has never been strictly typed or declared. Perl will never force you to use strict. Never. So why is PHP? PHP could have made it a configurable option. It would be really easy. But they didn't. I have some projects with over 100k lines of PHP code. The simple fact that "fixing" this will make my code look extremely ugly, harder to read, less maintainable, and probably more prone to bugs is all the reason I need to decide that I will never "fix" my code. Not to mention it will be probably 20k lines of code that need to be "fixed", and it's a pointless pursuit because in the end I'll never find them all. (grep -P '\[' ... ya right.) So it will be log & ignore, or not log at all (though I still will need to see legit warnings somehow); or git clone php and change 2 lines of code and maintain my own version forever. In fact, it may be time to do a fork of PHP: sane-php or something. Lastly, I'm willing to debate the philosophical points, especially using the RFC's wording as a basis; however, I'm not sure anyone is interested in taking the other side (please, hardcore PHP programmers only). I'll leave you with the arrogant wording from the RFC: In most cases, accessing an undefined variable is a severe programming error. The current low classification is a legacy from the Dark Ages of PHP, where features like register_globals made conditionally defined variables more typical, and code quality standards were lower. [...] However, throwing an exception may complicate the upgrading of legacy code that currently suppresses the generation of notices wholesale, as the issue can no longer be ignored. Some people have even suggested that the use of undefined variables is a legitimate coding style choice. "Legacy", "Dark Ages" indeed. Nice framing. "Legitimate coding style choice." How gracious.

7 19

Re: [RndTbl] Electronic filling in Manitoba Public Insurance Forms: Billing Travel etc medical expenses
by eh＠eduardhiebert.com 21 Jan '22

21 Jan '22

I use a different email program for these MUUG exchanges and for whatever reason the bells and whistles said it was sending to the group, but after the fact appears it was only sent to Adam. So my apologies I hereby correct my error. Eduard -------- Original Message -------- Subject: Re: [RndTbl] Electronic filling in Manitoba Public Insurance Forms: Billing Travel etc medical expenses Date: 2022-01-21 04:52 From: eh(a)eduardhiebert.com To: Adam Thompson <athompso(a)athompso.net> Reply-To: roundtable(a)muug.ca In short, Adam thanks for sharing of your insight and experience. As a result of your timeliness, as you can see, thanks to yours I will now have an early start. Simultaneously I will add I am literally on an unrelated task focusing on toolmaking, both its functional capacities to do more with less effort. But in short, in areas of my own life, like you I too have more than enough history of been there done that working my way into dead ends. But of course not always Hope can spring eternal and through the collective of MUUG I am now a more comfortable user of safe email and with you having so much more tech background in the area now under discussion, as can be seen from my request, did not want to leave a reasonable stone unturned. But many thanks for turning this stone for me without me having to repeat history. Many thanks and this in such a timely way! Truly Happy New Year to one and all as we do individually and collectively what reasonably can be done, including so to say chewing our own food. Thanks! Eduard On 2022-01-20 20:28, Adam Thompson wrote: > [Replying off-list, since it's not even remotely UNIX-related.] > > Been there, done that. You may as well start the manual filling, > typing, or writing as soon as you get up. Sorry :-( > I'm *very* familiar with those MS Word "forms" that aren't really > forms in any programmatic sense. You could write an app in VBA to do > it, but that would take a LOT longer than just filling them out > yourself. (I should know, I tried.) > MPI takes handwritten forms as well as typed or filled out in MS Word. > (Not everyone has a computer, or Word, or a working printer, or...) > That may or may not be easier for you - depends on how fast you type > and mouse versus how fast you can write, I guess? > -Adam > > > -----Original Message----- > From: Roundtable <roundtable-bounces(a)muug.ca> On Behalf Of > eh(a)eduardhiebert.com > Sent: Thursday, January 20, 2022 9:40 PM > To: roundtable(a)muug.ca > Subject: [RndTbl] Electronic filling in Manitoba Public Insurance > Forms: Billing Travel etc medical expenses > > With all that knowledge among members, if readily and easily possible > without a significant learning curve, can anyone direct me to a program > or how to, to easily transfer data I already have in a text file to the > attached forms? > > MPI has refused my multi pages of billings unless literally on their > forms as attached. > > I plan on doing it tomorrow and will start the manual method as my last > resort by noon. > > Thanks, > > Eduard

1 0

Electronic filling in Manitoba Public Insurance Forms: Billing Travel etc medical expenses
by eh＠eduardhiebert.com 21 Jan '22

21 Jan '22

With all that knowledge among members, if readily and easily possible without a significant learning curve, can anyone direct me to a program or how to, to easily transfer data I already have in a text file to the attached forms? MPI has refused my multi pages of billings unless literally on their forms as attached. I plan on doing it tomorrow and will start the manual method as my last resort by noon. Thanks, Eduard

1 0

HDDs FS
by Sean Cody 15 Jan '22

15 Jan '22

Hey folks, I have a decent pile of 1,2,3 and a smaller set of 4TB & 6TB 3.5" SATA drives that could use some new homes next week. $10/TB, message me _off_list_. Also have some smaller SAS/2.5", and some 24" monitors left (open to non-insulting offers). -- Sean

1 0