Feeds:
Posts
Comments

Archive for the ‘Software’ Category

Printing from MAC OS X Catalina is hard, when your printer is a Xerox 3260. Somehow the procedures I described a few days ago no longer work (and yes, they did work when I wrote them up). As far as I can remember there were no OS X updates, no printer driver updates, etc. to explain the fact that my measures no longer work… Perhaps there is interference from the old Xerox driver, which is probably still hiding somewhere on the hard disk.

My conclusion remains, however: Xerox has to come up with a solution!

 

UPDATE: just as I published this post, I noticed that Xerox (finally) published a driver update: the Phaser 3260 Mac 10.15 Driver v1.08 is out since yesterday, March 5. I haven’t tested it yet, but I’ll be doing that tomorrow!

Read Full Post »

Contrary to most pure hardware tools like a hammer, software tends to evolve over time. These days, software evolves faster than ever before – and at the same time most pieces of software that we use regularly are also interconnected with other software. Think of your smartphone, where the operating system updates the apps running on the device, while some – if not most – of the apps require connections to other infrastructural software and “platforms” from the likes of Google, Apple, and many others. Synchronising account and application data is getting more important every day, the more so now that more and more people have more than one device. No wonder then than sometimes things take a turn for the worst…

Case number one: I have been using a couple of home-brewed scripts to get the daily production numbers of our solar panels from the SMA monitor to an Xubuntu computer, and then transfer them to a Google Drive for storage. I used Grive2 to sync new or renewed files to Google Drive, until that failed as I reported on December 15th. Google started restricting OAuth access rights in November 2019, and that poses a problem for tools like Grive2.

My replacement solution using Jdrivesync is actually victim of the same OAuth change, although it is less evident: it can still add files to Drive but fails when reading the metadata of Drive files (and hence is incapable of replacing them as well).

Today I took the time to tackle the issue head-on, and started by re-reading the instructions on Grive2. That answered my question of a few months ago: I now know why Google changed its approach. The Grive2 site also explains how to circumvent the limitations, by creating your own Google API project and OAuth credentials. It’s not the fault of the Grive2 author, but man oh man, what a convoluted process is that. You get to answer a pleiad of questions that may be easy to understand for a seasoned Google developer, but not for an end user trying to get a simple sync script to work again! In the end, after a series of dire warnings by Google during the process, things started working again. Which is nice. But I’m still not sure for how long this will continue to work. That’s not reassuring for a solution that is supposed to work without a hitch for at least 10 more years or so.

I think the burden here is on Google: it would be nice if they could figure out a way for single end users to get a single application instance (project) up and running on a single account in an understandable process. Because that is what I needed: a way to tell Google that MY Grive2 script will sync MY data from MY computer to MY Google Drive. A simple process does not need to bother me with questions about GSuite domains, privacy declarations, consent screens, and what more. Please, Google?

Case number two: since a few weeks I’m a happy user of KeePassium. I use it on my iPhone as well as on an iPad, where both devices open the same KDBX file. Since I also still have an Android device running Keepass2Android, I store the KDBX file in DropBox. This setup seemed to work OK, until a few days ago when a new account added on the iPad did NOT show up on the iPhone nor in Keepass2Android. After a few tests and trials I ended up with saving the file explicitly to DropBox and reopening it on both the iOS devices, and later synced Keepass2Android as well. The latest changes in the file are now visible on all three machines, so that’s good.

However, I fear that I may have lost one earlier password change. I’m not in any position to blame either DropBox, Apple’s Files app, or KeePassium, since I cannot (yet?) explain what happened. So while the situation is “under (manual) control” now, I keep wondering what will happen when I apply the next changes to the KBDX file. Here, like in the case above, the synchronisation should ideally happen without any special interaction on my part. Unfortunately, as long as I’m not certain that the complete setup works “as expected” I may as well continue to sync by hand – and that is exactly what smart software is supposed to automate, no?

Conclusion? As a developer of sorts, I’m familiar with all aspects of software, good and bad alike. I know things can go awry, and I know how to try and figure out what goes wrong and how to try and resolve the issue. But I’m part of a minority, speaking globally, and I can imagine that many (most) people would just declare defeat and call the software they were using “buggy” or “bad” or “useless”. While that may true in some cases, it mostly shows that developers and publishers of software will need to take more care when building their products: no software is an island, and many if not all software tools will have to talk to others – hopefully in a polite and productive manner. Not an easy task, but possibly essential if the tool has to be around for a long time.

Read Full Post »

Somewhere in the second half of January, Samsung managed to publish another software update for the Samsung Galaxy S7 – I was late in installing it, but here is the resulting situation:

The latest situation on the S7 in terms of software

At least the machine now has the December 1, 2019 security patches.

By telling you this you know that I’m still using the S7 occasionally, although mostly as an alarm clock (there is no longer a SIM card installed in it). It’s a bit a shame not to use such a capable device; with better software support many smartphones, this one included, could have a longer productive life.

For those of you who care: the Samsung Galaxy S Plus (SGS+) I wrote about in the past (5 years ago, that is!) is still somewhat usable. That means nothing more than that it still starts up, running CyanogenMod 12, and its battery still holds out for a substantial time: it just dropped from 100% to 60% overnight – not bad for a device bought in December 2011!

Read Full Post »

In November 2019 or thereabout my youngest daughter upgraded her MacBook to Mac OS X 10.15 (Catalina). Ever since she has had trouble when trying to print to the family’s Xerox Phaser 3260 laser printer: sometimes it would work, if only for one or two pages, and mostly it failed. And when I upgraded my Macbook Pro, I encoutered the same problems, of course. Luckily there’s the old and faithful Mac Mini, still on 10.12 and perfectly capable of printing with a 32-bit printer driver from Xerox…

The cause of the printing problem is not hard to find: Xerox so far has failed to deliver a 64-bit printer driver for many models, including the Phaser 3260. Which is unforgivable, since they are still selling that printer model without a clear warning that it won’t work on the latest Mac OS X version!

For those of you having the same issue I can offer two workarounds that so far seem to work without limitations when it comes to simple print jobs.

The first is to go into the Phaser 3260 settings and enable (and configure) AirPrint in the “Network Settings”. If you also own an iPad and/or iPhone you may already have done so, since it allows those mobile devices to use the printer directly as well. To use this protocol from your Mac as well, you have to go into the “System Settings” of your Mac, and define a new printer using the “AirPrint” driver. That should do the trick.

There is a second way to print from your 10.15 Mac, but it isn’t supported wholeheartedly by Xerox (although it is referenced in the Xerox support forums): you just have to install the “Xerox macOS Common Print Driver from a closely related product”… The hardest part of this solution is figuring out which printers are already supported by this driver. I have been clicking around and had success with the Phaser 3330:

(Click on the image to go to the download page)

The installation of the driver is pretty standard stuff, and once you define a new printer in the “System Settings” of your Mac you will be able to select any of the supported Xerox printers as the driver for your 3260 model. I tried the 3330 model, and so far have not encountered any problems with the printing of PDF’s and HTML pages. Am I just lucky? I hope not!

Having workarounds is nice, but Xerox should wake up and do the right thing: adapt the driver software (and their support website) to accept the 3260 and any other printer still on sale into the Mac OS X 10.15 driver package!

Read Full Post »

A good month ago, I had to switch from Grive2 to Jdrivesync on my little Xubuntu machine, because Google doesn’t like the former software. Unfortunately, Jdrivesync is not without problems.

The biggest issue is that Jdrivesync is not capable of updating an existing file in de Google Drive with a fresher version from my machine. And it turns out that I’m not the only one (nor the first) one to experience this error, as detailed in this Github error report called “Error if updating a remote file“.

I’m the first one to admit that software without bugs is very, very, very rare ;-)

But a bug report without response in more than 20 months is a clear sign of abandoned software. So I’m looking for another solution – suggestions are more than welcome (I’m not in a position to start learning the ins and outs of the Drive API to see if I can find the cause of the problem).

Read Full Post »

As mentioned earlier, my ‘Grive2’ solution stopped working around November 25, and that is still true today. I have copied the daily updates by hand for a few days, but that is not a permanent solution.

That left me no choice: I needed to find another tool to replace ‘Grive2’. Luckily I had already been experimenting with ‘Jdrivesync‘ somewhere in 2018. The scripts I created at the time should still have worked today (I had kept everything in place), but a first attempt failed with an unclear exception message about OAuth.

Just to be thorough I checked the app access settings on my Google account. I found no sign of ‘Grive2’, just mention of an ‘Ubuntu’ app. So I thought: let’s get rid of that and try again. But that didn’t improve the situation. Strange, because in theory ‘Jdrivesync’ was now supposed to ask for a new authorisation key, and it did not do so.

Looking in my home directory on the Xubuntu I quickly found the culprit: the file .jdrivesync does contain the accessToken and refreshToken required by Google/OAuth. Deleting the file finally did what I wanted: Jdrivesync requested a new authorisation code and ran as it is supposed to do. Nice, although I should point out that Google again complained about not having verified Jdrivesync and did I really want to continue whit that app? Of course I do!

Now I just have to adapt crontab ;-)

PS. I will also keep an eye on the ‘google-drive-ocamlfuse‘ project. That would allow me to mount the Google Drive file system on the Xubuntu machine, giving me an opportunity to learn how to use rsync… But that’s for another time!

Read Full Post »

I have been using Grive2 for a couple of years, to help me get the numbers from our photovoltaic panels into Google Drive storage. That has been going very well… until today.

The new or updated files from my panels did not show up today, although they had been created correctly on the EeePC. When I tried the Grive2 synchronisation by hand, the tool reported a 401 error: access not allowed. I suspected an issue with the Apps authorisation for the Google account concerned, so I deleted the existing ‘grive’ App and launched a new registration request. Alas, to no avail; this is what Google had to say:

Why, oh why, Google?

All I can say is: come on, Google! This has been working fine for a couple of years – why cut it off now? If you really had to cut off access, why not alert the its users first? And what is “temporarily”: a day? a week? forever?

I will copy the files by hand for a few days, but that solution won’t last long. After all, we automate processes so we don’t have to remember doing them, the more so when the process is tedious. Copying files by hand is tedious, and error-prone too…

Read Full Post »

Older Posts »