LTSpice running fine here too under Wine (8.15). Haven’t noticed anything that didn’t work.
Well, updating the app itself from within LTSpice used not to work (error message), so you would have to install new versions manually, but lately it appears to be fixed (LTSpice 17.1.10), at least checking for updates now works. I’ll see if the actual updating works once they release the next version.
Updating components from within the app has been working fine though.
If the question was about an alternative to LTSpice on Linux that is not actually LTSpice (or that maybe is a native Linux version), then there isn’t really. ngspice is good, KiCad is a decent GUI front-end to it, but if you’re looking for the “LTSpice” experience, it’s not there yet. Note that beyond the actual features, one big “selling” point of LTSpice are the provided models.
If you’re not allergic to using Windows software under Wine, then LTSpice definitely works though.
And, if you are expecting your Linux distro to package LTSpice for you - rather than installing it manually with Wine - you’ll probably be in for a disappointment, as many distros have either given up on packaging it, or have pretty old versions, etc. Installing the official Windows .msi using Wine works pretty well. And I don’t mind too much that my package manager doesn’t automatically update the few Windows apps that I use (with Wine). They get installed locally in user directories dedicated to Wine anyway.
Yes, it works (starts) but loads one core and works slowly, probably it’s better than nothing … I heard that the ngspice 41 update is planned, I wonder if we will see it in the 7th branch?
8-10 years ago there was an active growth of Linux programs, but then everything gradually died out. Many refused to support this platform at all… I am considering engineering programs for 3d 2d cad cam systems …
In which regard?
Contrary to the Windows OS and it’s bindings to things that are controlled by MS under Linux using dynamic library loading is the way it works. It’s up to the binaries to check if the symbols are available in the correct version then. OTOH quite all of the big libraries are backwards compatible or have transient symbols that map internally to the current implementation of newer symbols. If you are need to have bleeding edge functionalities then you obviously need to talk to upstream.
Getting software usable in Linux isn’t that hard if a company wants to do that, but it’s also understandable if all the engineers are trained and working with MS technologies and it the really mostly impossible to also support a Linux variant as this means they have to deal with two completely different stacks of technology, and that’s nobody really want to do. So chose your UI framework wisely before you start the integration.
wxWidgets isn’t Gnome or QT, it’s not that common as these other tool sets, but works on all three big platforms. Getting new or better functionality into the UI framework requires as usual the availability of resources that can do actually the work including the extend of the testing framework afterwards.
what newest features are you talking about ?) from theory to practice ) how much do you know of really working programs for linux suitable for board design? I, for example, 2) how many programs for 3D do you know, for example, I have one) that are really suitable for use and not forever unfinished projects …
at the moment, my developers are implementing new gerbv functions under linux compared to win, there are much more problems … for each new kernel, you have to change something, unlike win, it is impossible to guarantee that an application written for, say, kernel 6 will work normally on version 6.5 … on the win platform, I can run an application that is 10-15 years old and most likely it will work …
That’s literally how Windows works too. It’s just apps can bundle copies of dependencies it needs for itself and keep them there instead of suffer possible breakage in the future, and MS provisioned C and C++ runtimes to be versioned as well so that a 20 year old app can continue to use a legacy C runtime without recompile.
That isn’t the problem and that’s just deflecting.
The problem is the extreme NIHism across Linux. You got different package managers, you got different package dependencies upstream, you got Canonical attempting their newest lame approach of pushing snaps over appimage and flatpak, etc.
In fact, the biggest drawback is you can’t run old software on newer Linux without recompiling it. This is something that’s fine for the average developer that could port/update their builds, but horrible for the average non-programmer user.
Why do I mention this? One of the most important tenants of hardware design has always been not to update your tools for a project after the fact. If I design something in KiCad 5 and SolidWorks 2014, I will keep using those versions if I go back 8 years later to make a simple tweak. You don’t want unknown manufacturing issues slipping in due to software version updates unless you want to spend more time validating it.
In Windows and macOS land, we can literally use the original executables as-is, we don’t need to hire software developers to port it. In Linux land, you better have software devs on standby to port the app to the latest distro version.
Honestly, Appimage, flatpak and snaps are the answer to this. The problem is three of them exist instead of one.
I read an article a little while back that indicates some consensus of some of the large Linux distros that a movement towards flat pack is the way to go in Linux. I know Debian was mentioned and I think Red Hat as also on board.
LTSpice is property of Analog Devices / Linear Tech Subdivision.
It has loads of proprietary code and won’t ever get on Linux.
The good news is, that LTSpice works perfectly fine with WINE. Probably the smoothest program on WINE of all.
Mike is working on a new Electronics Design Tool, which will probably be on Linux.
Maybe you dig into his newest project. Maybe you consider helping KiCad.
Your decision. KiCad is there to circumvent mountains of problems of proprietary software.
It is specifically there for YOU.
To satisfy Linux-Users, who wish for LTSpice (or similar Proprietary Tools like TINA TI etc…)
you know, I heard a similar answer 3 years ago about the possibility of converting altium to kicad, I was told that it was a closed format and this could not be done… however, time passed and everything was done… sometimes you just need to port it and I am more than sure that this will happen in the near future will happen if you need it… Vine virtual machines are all crutches for enthusiasts IMHO
Thanks, I have been using Linux (Debian, Knoppix and finally Kubuntu) for 20 years. I’m the only one in the company using Linux. It is hard for my coworkers to change if they do not have the right tools.
you know, from the point of view of use, it doesn’t matter what operating system you have, it’s important what programs run on it… and unfortunately Linux is much inferior here in engineering programs… if you follow the Linux philosophy that only open source code, then there is nothing at all for engineer compared to win…