Site Sponsors:
Linux: Fixing Cura Installation Mishaps 
If you are one of us who likes to install several things at a time using "sudo bash," then from time to time you might be tempted to run what you have installed as "root."

When upgrading to the most recent version of FreeCAD & Cura, I recently made such a mistake.

In as much as I was running as 'root' - and in as much as Cura decided on creating my ./usr/local files in my login-account's home folder, the problem was that I could not access the same when running under my default account.

When NOT running as 'root,' not only did I have to perpetually re-define my 3D printer defaults, but from time to time Cura itself would simply stop responding ("hang") whilst attempting to do so.

Ignoring the temptation to simply re-boot, I had no choice but to `ps -al`, then kill it.


Rather than removing & re-installing everything, the solution - obviously - was to simply change access to the Cura file set. For the uninitiated, we must note that changing permissions is merely a matter of using `chown` and `chgrp` on the above rooted-folder set.

Of course, one could also just blow it all away, then simply run Cura once again from your default account login:

--Sharing is caring!


p.s: If you are looking for a PPA designed to allow us to use Cura under Ubuntu, then click here.

For a nice overview of how to install Cura on Ubuntu, you can click here.

Finally, in as much a links tend to come and go, here is my update to what the above link tells us to do:

sudo rm -rf ~/.config/cura/*
sudo rm -rf ~/.local/cura/*
rm -rf ~/.config/cura/*
rm -rf ~/.local/cura/*
sudo add-apt-repository ppa:thopiekar/cura
sudo apt-get update
sudo apt install cura cura-plugins-all cura-extra-plugins-all

Note: When using your own login, using the 'sudo' command (as shown above) will keep us from accidentally running Cura - or anything else - as 'root.'

[ add comment ] ( 65 views )   |  permalink  |  related link
Backing Up Files Across Multiple Devices 
There you have them - sitting in a box. --From lots of CDs / DVDs, to far too many USB sticks to contemplate.

Rather than sitting there - waiting for us to toss them out - wouldn't it be nice if we could use them to backup our 'stuff?

Backup Splits

Much like in the days when we had lots of drive-tapes, the challenge is to split a `too-big` collection of files, across a `too-small` series of media. A problem almost as old as computing itself, fortunately all POSIX systems come with a program called `tar`!

sudo mkdir /d_backup 2> /dev/null
sudo chmod 777 /d_backup
cp $0 /d_backup
cd /d_backup
name=`date +d_drive_%Y_%j.tar`
echo Creating $name from $0
tar -cf ./$name /d_drive/
split -d -b 4480m ./$name

In the above, my task is to routinely back-up /d_drive into a folder named /d_backup. Once created, I want to split a julian-dated backup file into 4GB slices, from there to manually burn them out to a 2nd generation DVD drive. (*)

Splits Restored

To restore the files, all we need do is to (1) undo the `split,` by copying (2) all of the media-content to the hard drive, then (3) un-tar the concatenation:

cat * > d_drive.tar
tar xvf d_drive.tar

(*) Note that while the above `split` uses 4480 for the splits, that one should adjust the size to match the least-common size-denominator for any and all external media.

Sharing is caring!


[ add comment ] ( 118 views )   |  permalink  |  related link
Downgrading Java on Ubuntu 16.x 
Just a quick note to let everyone know that - after installing LTS 16.04 (so far a very pleasant & stable release - recommended!) that I discovered that the default JDK ("9 internal") does not work.

java -version
openjdk version "9-internal"

--The failures are so bad, that the kernel actually dumps core!

(Forgive the imp, yet note the bug -Halloween is around the corner!)

Sadly, removing the "9 internal" by conventional means results in only a partial removal... very nasty. What will work however, is to remove everything via a hand-grenade:

sudo apt remove --purge "^openjdk.*"

Followed by a dependency purge:
sudo apt-get autoremove

Then re-install a version that actually works:
sudo apt-get install openjdk-8-jre

Ultimately, once we have what we need installed, don't forget to associate that new JRE by right-clicking on a .jar file, so as to:

In addition to those old 'ol reliable versions of Oracle (I like to test under many JVM's), here is the OpenJDK that worked for me on LTS 16.04.1:
openjdk version "1.8.0_91"
OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-3ubuntu1~16.04.1-b14)
OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)

Sharing is caring!


[ add comment ] ( 404 views )   |  permalink

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | Next> Last>>