Bricscad V13 on Xubuntu 13.10 64-bit beta

Albin Michlmayr

Hi!

As I am still interested in running bricscad on my optimus laptop I tried out the beta of the new Xubuntu version 13.10 which has a basic optimus support almost out of the box. I installed the 64-bit version of the system which worked quite well, but when i wanted to install bricscad the system complained about unmet dependecies. Bricscad depends on ia32-libs but this package seems to have been removed from the repository. To test bricscad with this system anyway I added the 32bit libs with [code]sudo dpkg --add-architecture i386[/code] and installed bricscad with [code]sudo dpkg --install --force-depends BricsCAD-V13.2.11-1-de_DE-amd64.deb[/code].

With this installation I can use bricscad for the first time under linux on this machine without anything crashing, even in 3D mode. The downside of this installation is that I can't install or update any software because the packaging manager always complains about unmet dependencies. So for any installation or update process I have to uninstall bricscad and reinstall it afterwards, which of course is not very comfortable. So I am hoping for the native 64bit support of bricscad linux to be released soon, or at least a new .deb package with new dependecies when the final version of (X)Ubuntu is released.

Patrick Harris

A year after shelling out more than seven hundred bucks for a (don't laugh) "Pro" licence, I'm still waiting for Bricsys to figure out how to package its own software so that I can actually install it. Incredibly frustrating. My Linux licence won't work on Windows, or I'd have switched. Great that nvidia has finally decided to support its hardware for Linux users--better late than never--but I found even on a 32-bit 12.04.3 (with Raring backport and nvidia-319, nvidia-prime etc) the 3D rendering still fell apart. The 32-bit package installs, (congrats, Bricsys), and I could fire up 3D drawing mode et cetera. But drawing 3D solids was about all you could do. Try to extrude or manipulate them and the application falls over. You seem to be suggesting that's not happening for you?

Albin Michlmayr

Unfortunately you are right. Last time I didn't have the time to do more testing, I only opened an existing 3D drawing and turned it around. Now I tried to draw something new - I can draw a polyline, extrude it but when I try to manipulate the solid (eg. rotate it) bricscad freezes.

Brian Marr

"A year after shelling out more than seven hundred bucks for a (don't laugh) "Pro" licence, I'm still waiting for Bricsys to figure out how to package its own software so that I can actually install it. Incredibly frustrating. My Linux licence won't work on Windows, or I'd have switched. Great that nvidia has finally decided to support its hardware for Linux users--better late than never--but I found even on a 32-bit 12.04.3 (with Raring backport and nvidia-319, nvidia-prime etc) the 3D rendering still fell apart. The 32-bit package installs, (congrats, Bricsys), and I could fire up 3D drawing mode et cetera. But drawing 3D solids was about all you could do. Try to extrude or manipulate them and the application falls over. You seem to be suggesting that's not happening for you?"

Another Cad program was generous enough to provide me with a Windows License where my work situation required it. I was able to use their (paid) software on the Windows platform for a while. Bricscad needs to have this flexibility. It may require some manual intervention to provide this but that should not be difficult due to small numbers affected. This would provide Bricscad Linux users some flexibility in maximising their Cad License for their work.

Bricscad Linux continues to ba a work in progress. It is hard waiting sometimes.

Patrick Harris

It is no trivial task that Bricsys has set itself here. It will take time for the Linux version to settle in and I think most of us appreciate that. I love what Bricsys is trying to do here, but the firm has sold me a commercial CAD solution for Linux and hasn't provided it. The software package doesn't work on a clean install of a "supported" OS release and it has been that way for more than a year...while the 12 months' software support that I paid for ticks away.

I find it difficult to accept that Bricsys has released Beta software--and that's what it is--not for free download and testing, but as commercial software. Somewhat controversially it charges the same price for what it acknowledges is an inferior version. Rather than list all of the faults, let me list what I think would help:

1. Let the price of the Linux version reflect its true development status:
    (i)   lower the price
    (ii)  offer free (and better) support and free upgrades to early adopters until the Linux version is ready (i.e., 64-bit versions are in fact 64-bit versions, you've figured out how to package Linux software, you've checked that the dependencies in your package are in fact in the repositories for the "LTS" releases that you claim to have packaged the software for)
    (iii)  let users "turn in" their Linux software key (once only) for a MS Windows key if they are unsatisfied (think about it, marketing people, would you rather they stay with your application on another OS, or switch to the competition on any OS?)
2. Improve your system requirements pages for Linux
    (i)    organise the information better, clearly separating MS Windows and Linux advise by extending to your customers the courtesy of subheadings, bullet points and/or numbering
    (ii)   be very clear about what hardware and software combinations your application works on
    (iii)  include clear advice about video cards and drivers, which ones work, which ones work the best, on which distros and which releases and don't be shy about putting that information into a table
    (iv)  when an abortion of a product like Nvidia's Optimus technology comes along, raise this alert near the top of your Linux system requirements (i.e, not below where you say that you support Nvidia cards) so that people who want to pay you for your software can avoid buying hardware that will prevent it from working
3. Don't just say that you offer 64-bit versions of your software for Linux, mean what you say. Build against 64-bit libraries. Package the build, test against the distros and releases that you claim to support. Do this before you release the software, then after you release it listen to users. If they tell you it doesn't work--if many, many of them tell you repeatedly that it doesn't work--find out what's gone wrong and fix it. Quickly.

What have I missed?

Patrick Harris

Alright. I went back to square one, downloading every Linux distro I could find and installing on partitions on my hard drive. All 64-bit, all fresh installations and all updated from respective repos. None installed with Bricsys' 64-bit installer and none installed for me using the force-install instructions on the Bricsys website. The installers are indeed--and despite what Bricsys' website says--poked. I believe that's the correct term.

But it's not all bad news.

I had two issues. One was the Bricsys' phoney 64-bit installer, the other was the nvidia optimus/x-server debacle. This second issue is now clearer and the good news is that I do have Bricscad running on a 32-bit Ubuntu 12.04.3 (LTS) installed on a laptop with Nvidia Optimus graphics.

Erik Lundberg

 Yeah...  ...I'm having another look at BricsCAD as a possible professionally usable Linux based CAD package.

In the 13.10 release of Ubuntu, they have broken the ia32 bundle of legacy libraries into a collection of legacy libraries called lib32...... The latest BricsCAD thus refuses to install due to broken dependencies. If forced, the system will insist on un-installing the broken package any time you perform any operation on any other package on the system, which is drawing a little line through 'professionally usable' for me.

It is also asking for libGL.so.1.

OpenGL hardware acceleration appears to be working perfectly well for everyone else.  I struggle to understand the difficulty in building the program against 64bit libraries.  I note that, for some reason, this is a real problem for a lot of proprietary software.  I just don't understand why it is so hard when there are so many public examples of how to make it easy.

Patrick Harris

Hello Eric,

As I see it, there few hurdles and no barriers to deploying BricsCAD Linux as a "professionally usable Linux based CAD package" at this time.

I've been in contact with BricsCAD support and they have explained some of the issues that they have faced with 64-bit libraries, wxWidgets, packaging and dependencies. It might have been handled better (using a PPA, releasing a tarball for 64-bit "testing" rather than packages that don't install et cetera) but the good news is that the developers seem to be well appraised of the problems and actively working on a solution.

Their approach now seems to be sound and a genuine 64-bit version (i.e. without 32-bit dependencies) is targeted for release with V14 in December or January with a backport to v13, if I understand correctly. There is a binary already installed and running, but the team is smoothing some "rough edges" and folding it into the next release rather than dumping a minor release on us now. This represents a marked improvement on the previous approach.

Of course, if you want to run 13.2.13-1 right now, you can deploy it successfully on a 32-bit partition as I do, and it works very well.

Looks like we're nearly there.