Computer Log

In the past this has bitten me so many times. I don’t know if this will remain true and I might have stayed with Manjaro long ago if I knew this one thing. Don’t use the pamac GUI to apply big updates to Manjaro. If you use the pamac GUI to install an individual program make sure to check the Update tab first. Even though your intentions are to install an individual program you must realize that existing updates will also be applied and these updates can hose your system if applied with this GUI this way. At least that has been my experience. Instead install large updates on the command line first by typing sudo pacman -Syu. For example I wanted to install the ghex editor using this GUI and it reported a 400+MB of updates would be required. If history repeats itself, this would have surely hosed my system. Instead I first applied the big updates using the command line then I installed ghex with the GUI which required less than 2MB.

Trying to download a little hex editor and a required ~50MB Rust download is estimated to take over 15min. This is a problem I’ve seen in Manjaro more than a few times before. I think they need more distributed servers.

I decided I’d take a look at Julia again. The SQLite module is very important to me right now. More than important, for me…essential! But I guess I’m too stupid to figure it out. Add to this that some of the documentation applies to different versions. This is something I used early on and got working fairly easily. But it no longer works as it did and the documentation is crap…IMHO. I don’t want to learn the internals of SQLite and/or Julia to tackle a problem. I just want a straight forward way to use SQLite!

Is the problem that in an effort to make the SQLite module do everything there are 10 things you must do before a query (which itself has 50 options/switches) and 10 things after the query. I know I’m not the only one. I read somewhere I’m trying to figure out how to [bla bla bla] using SQLite.jl, but can’t wrap my head around the docs?

To be fair it’s probably or mainly the library and not Julia itself. It’s almost as if it was a personal project that was kindly shared but no effort was given to backward compatibility. If you understand it great if not too bad. There were a few early changes that I adapted to but I don’t want to change my program every time the library changes. I put some programs on github that no longer work. And I’m talking a few month ago not years ago.

What does this example even mean?

DBInterface.execute(db, select) |> DataFrame

Specifically “|> DataFrame”. Is that line a Julia instruction? Is it a julia-ism that I don’t understand at this time. Is it two things? An instruction piped to a DataFrame? If so, the documentation should show it as two steps and leave it to the programmer’s ability to combine them. Don’t show off in documentation. Examples shouldn’t be obfuscated. Explain to a beginner! Why should I care? Because the module will probably be “improved“ in the next version and work totally different anyway.

If I can easily use SQLite on the command line…and I can. Why is it so hard programmatically in Julia?

I haven’t experienced this in Python.

I feel my past thoughts about Zoom seem on track. Security expert Steve Gibson gave his thoughts about Zoom which seem to confirm my thoughts. Steve approaches the subject as an expert. My approached was based more on a feeling based on listening to the CEO and judging his sincerity. And my feeling about how stupid it would be for them to ignore this tremendous opportunity for growth. Also I felt that they were such a large target that it would be foolish for them to think they were smarter than the internet at large.

If they want to be tricky it would be better for them to wait until like Facebook they had such a large user-base that they had the ability to hire the best talent to attempt to be tricky with a huge user-base of largely inexperienced users! Then just deny any knowledge of a problem when they are found! Then fix that and move on to another tricky user exploitation!

I think at some point it will be too lucrative for them to resist the temptation. But for now, prove to your users that you have their best interest at heart, and concentrate on building that user base.

Watched an interesting video about COBOL on YouTube called “The New COBOL” – Benno Rice (PyCon AU 2019). In that video he showed a quote

[COmmon Business-Oriented Language] (Synonymous with evil.) A weak, verbose, and flabby language used by code grinders to do boring mindless things on dinosaur mainframes. Hackers believe that all COBOL programmers are suits or code grinders, and no self-respecting hacker will ever admit to having learned the language.

Wow…such arrogance. I may have said much of this before but here I go again. I wonder how many of today’s programmers would have stuck with programming if this is what they had to use? If it wasn’t fun at the start? There were no personal computers back then to do your own thing. We didn’t have the luxury of choosing from an abundance of languages. We used what was available. You had to program because you loved to solve problems with code. In the case of IBM mainframes you had to debug programs by combing through page upon page (possibly hundreds of pages called dumps) filled with rows and columns of hexadecimal digits. You needed to do hexadecimal math to navigate those dumps. There was no Google. There was no interactive debugger pointing to your error. Even the lowly COBOL programmer had to know some Assembler to go through those dumps. Because a COBOL statement was comprised of many Assembler instructions. And the dump pointed to an Assembler instruction not a COBOL statement. And yes I said page of printed output…not a nice screen output with search ability on a monitor. And to fix your program you had to type or retype instructions on an 80 column card. No pulling up the source code in a nice editor. No cut & paste. Because computer time was shared and limited we couldn’t just change something and rapidly rerun it over and over till we got it right. We may only get 5 or 6 program testing runs a day. Because of this we often had to flowchart on paper more difficult sections of code and play computer, in order to minimize re-running a program over and over.

So “no self-respecting hacker will ever admit to having learned the language”. What a stupid point of view. Nobody says why did cowboys ride horses? What a inefficient mode of transportation. No self respecting cowboy would do their job without a 4-wheel drive vehicle. Well back in the 1800s you didn’t have much choice. There’s a very good reason code grinders didn’t use/choose C or Java or Python or Rust or Go…they didn’t exist! There maybe better programming languages today but COBOL is still reliable.

I’ll say it again. I wonder how many of today’s programmers (with their free compilers, IDEs, Google, books or websites of algorithms (but more likely pre-built libraries for most hackers) and YouTube videos would be programming today if they had to start out the way many COBOL programmers did back in the day!

The following is a very small COBOL program that has dumped. There are only 2 executable COBOL instructions so you don’t really need the dump to solve the problem. I caused the dump by simply dividing by zero on COBOL line 22. It’s been a while but the PSW on page 10 in the PDF is a pointer to the problem. There are all sorts of good/useful things in this dump, such as the registers. Maybe, but not sure at this point (it’s been a long time) around page 29 are areas of this program. For example you can see the string of pound signs that the program displays. The readable text looks like what many today associate with ASCII, but it’s not…IBM mainframes used EBCDIC. This is just a simple example of what COBOL programmers had to work with.

Program & dump

The program is on PDF page 6. The stuff before it is called JCL (Job Control Language). It tells the mainframe how to compile the program, kind of like a C makefile.

Updated WordPress to 5.4! Not like I broke a sweat…just clicked a button.

Copied thunderbird directory from Manjaro to Mint and Thunderbird on Mint gave this lovely message!

No a newer version did not make changes…at least not according to you! As you can see both Thunderbirds report their version as 68.7.0

I really like and have tried to like Manjaro even when there were plenty of problems. But Mint based on years of reliability is what I can rely on. I basically can bounce back to Mint if I find a show stopper on Manjaro, except for one thing…Thunderbird. Right now I can’t move Manjaro’s Thunderbird back to Mint. I need to look at Manjaro’s downgrade which I think I used before.

Whichever way I query on the command line…is usually wrong. It Seems like it use to be prog -v or sometimes prog -V then somewhere along the way it changed to prog -version or perhaps prog -Version now often its prog –version or is it prog –Version? In the preceding sentence it’s hard to tell that preceding the option are 2 dashes. Out of edit mode multiple dashes look like one long dash. Oops did I say dash? Evidently to prove your technical ability today, somewhere along the line you now say tack. So prog dash v…total noob, prog tack v…experienced professional! After all isn’t tack much easier to say than dash? Ummm…no! In 50 years will it be prog ————version…many multiple tacks? One things for sure, it’s going to be the last possible variation I try : (

Light bulb moment. I should write a version script [version prog] that tries them all 🙂

With the latest Mint 9.3 install Thunderbird reports version 68.7.0 (64-bit). My previous Mint 18.3 reported its version was 60.9.0. Current release notes say Version 68.7.0, first offered to channel users on April 8, 2020. Nowhere does it imply beta or testing.

Manjaro however reports Thunderbird Daily 68.7.0 (64-bit) So it appears to be at the same version, however it still says “Welcome to Daily” and also “The Daily release of Thunderbird can be unstable” This is the same daily message I mentioned on Jan. 12th.

When it comes to technology I’m not a very trusting person. And I wouldn’t trust Zoom or most any program with discussing anything sensitive. It’s possible that Zoom tried to be sneaky early on. Bit since it’s explosion my feeling is they (Zoom)…I feel, have tried to address these security concerns. It seems that many of the problems of Zoom had were more to do with the way people used Zoom with the defaults it was supplied with. There is no way they could have imagined how popular it would become. I feel that for the people I most often want to video conference with it is fine. I’m not going to discuss my startups trade secrets or embarrassing medical issues with this conferencing program.

I read that Google banned the popular videoconferencing software Zoom from its employees’ devices. Yes the highly privacy respecting Google who have their own conferencing software banned Zoom. OMG…it must be bad! Basically I trust Zoom like I trust email. Even though for most people it is probably safer than email.