The more you deviate from “standard” on Linux, the less people there are who do the same as you, which results in older packages and less maintenance done by others an more dependence on your own knowledge.
I have a few Beaglebones and Cubieboards myself, but I would not use those for my “daily computing” tasks. For that I stick to AMD64. Even with well maintained distributions such as Linux Mint some packages are a year old or do do not get updated at all.
KiCad V5.1.4 is quite old now:
Just curious: What sort of processor is in that windoze PC? I’ve never done much comparison between ARM and other architectures to do any speed comparison.
Have you ever considered dual-boot?
An unusual, but very effective way for dual boot is to add an extra SSD to your PC for Linux. Then remove the Windoze SSD during install of Linux (so grub does not detect it) and plug it back afterwards. Then you can use your BIOS function to select from which SSD your PC boots.
If you’re willing to throw a few bucks at it:
These days’ you can buy a second hand PC, or even a laptop with a third or forth generation i5 for below EUR200, including a decent SSD.
And all those laptops have an extra monitor port and USB for a “real” keyboard and mouse and are plenty fast for normal desktop use.
I think it would not be wise to use KiCad on devices prior to RPi4 but this one looks promising. On the other hand, Raspberry Pi OS repositories use an old version of Kicad and it is built as 32bit (armhf).
I’d like to built as aarch64 and promote on schools in the near future after the release of v6. In the mean time we’d get some RPi4 and so I can test it.
I’m running on 64 bit RPi4 with 8 GB memory, and it works very well. I do not have the knowledge to be able to compile for arm, so I hope someone out there will do the job and do the compilation. I know several people who are running on similare hardware, and it’s sad to be running 32 bit software on 64 bit HW.
Yeah, I’d like to know the windows specs also. I run KiCad on both Windows 10 and Linux, I haven’t seen any significant difference in performance between the two.
I have an old motherboard.: ASUS Z170-PRO
Processor: Intel Core i7 4 GHz.
32 GB RAM
1 TB SSD disk
General problem with Microsoft is file opening, which is much more complicated and slower than on a Unix / Linux system.
Starting KiCad goes pretty fast on both systems, but the PCB-progam is MUCH slower (about 20 s) on the windows machine, while on RPi 4 it takes about 2 seconds
I have been running Debian 10 buster for awhile now.
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
I started out many moons ago with kicad 5.01, IIRC.
Then eventually uprgraded to 5.15. SInce then I have been updating kicad, along with
my operating system by running: #apt-get update && apt-get upgrade
every night. Doing this updated kicad to 5.1.6 on May 18, to 5.1.7 on Oct2 2nd, and to 5.1.8 on Nov. 5th. Version: 5.1.8+dfsg1-1~bpo10+1, release build
Here’s my sources.list:
user@solydk1:$ cat /etc/apt/sources.list
deb https://repository.solydxk.com solydxk-10 main upstream import
deb http://deb.debian.org/debian buster main contrib non-free
deb http://security.debian.org buster/updates main contrib non-free
deb http://deb.debian.org/debian buster-updates main contrib non-free
An i7 (of any generation, I’ve got a first gen. I7-870 myself ) should have plenty of horses inside to run KiCad smoothly.
It could be that it has something to do with this bug:
Because KiCad is now pretty close to V6 and V5.99 which I installed recently does not seem to be hampered by the above bug, I have not made a bug report for it.
Err:7 https://repository.solydxk.com solydxk-10 InRelease
The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 4F368A56A4A214F7
W: GPG error: https://repository.solydxk.com solydxk-10 InRelease: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 4F368A56A4A214F7
E: The repository ‘https://repository.solydxk.com solydxk-10 InRelease’ is not signed.
N: Updating from such a repository can’t be done securely, and is therefore disabled by default.
I don’t understand the GPG error. If you are running solydxk, I suggest that you take the error message to the solydxk user forum Someone there might understand what caused it.
Search for “GPG” at the Solydxk forum in the upper left corner. Search for the thread named “Re: SolydK Buster update SNAFU” and see if the advice there can be applied to the armhf architecture.