State of BricsCAD on Linux
Amid growing frustration among users and developers alike that got voiced in several posts in this forum, I thought it might be useful to bundle the discussion in a dedicated topic.
As it stands now, the situation can hardly be satisfying for neither side - Bricsys will lose money (I bet) because of the small customer base and the high cost of support, and users seem to be increasingly unwilling to accept the price tag for a software that is apparently never getting out of beta.
Finding a solution for this is probably not trivial, but here are my (maybe silly) ideas:
1.) The release policy is simply not working and has to be changed.
New releases have often been too flawed to be usable, but replaced the existing installations nonetheless, which is not acceptable in a professional context.
I think that there is no way around splitting the releases into a 'stable' and a 'development' branch. While it may at first sight look even more expensive to do so (maintaining two separate code bases), I think it will in fact be the opposite - the support system would not have to deal with the (supposedly) large amount of SR created by untested releases, and the program might gain acceptance as a true alternative for professional use. The 'development' branch would install besides the 'stable' version, and be available to registered customers who want to help test new features, but receive no support except through a dedicated forum/wiki where users can discuss bugs and provide feedback (with occasional comments by the developers, hopefully).
2.) The rush for feature parity with the windows version to justify the 'same price on all platforms' policy should stop, since it has a negative impact on quality. The 'stable' Linux version should only contain mature functionality, and its price would have to reflect this in comparison with the pricing on windows. At the moment, this would probably mean that Linux would just have the 'classic' flavor, since 3d is still too much work in progress and should be further refined in the development branch (IMO, the 'stable' version should ship without RedSDK).
3.) Support on Linux should be narrowed to a single Linux flavor and version.
Given the deplorable state of the Linux market (fragmentation and incompatibilities between distributions), it seems impossible to maintain more than a single platform. The choice of ubuntu's LTS releases as main development target makes sense to me, since they seem to come closest to a commercial OS. I think compiling on the oldest supported LTS and testing on the latest is all that can reasonably be expected from Bricsys - figuring out how to get the program to run on other distros/releases would be left to a wiki (to be created) and the forums.
Since Linux users tend to be more technically inclined, the development branch could provide a testbed for new features and usability improvements and thus serve the windows platform as well.
Does this make sense to someone?
As it stands now, the situation can hardly be satisfying for neither side - Bricsys will lose money (I bet) because of the small customer base and the high cost of support, and users seem to be increasingly unwilling to accept the price tag for a software that is apparently never getting out of beta.
Finding a solution for this is probably not trivial, but here are my (maybe silly) ideas:
1.) The release policy is simply not working and has to be changed.
New releases have often been too flawed to be usable, but replaced the existing installations nonetheless, which is not acceptable in a professional context.
I think that there is no way around splitting the releases into a 'stable' and a 'development' branch. While it may at first sight look even more expensive to do so (maintaining two separate code bases), I think it will in fact be the opposite - the support system would not have to deal with the (supposedly) large amount of SR created by untested releases, and the program might gain acceptance as a true alternative for professional use. The 'development' branch would install besides the 'stable' version, and be available to registered customers who want to help test new features, but receive no support except through a dedicated forum/wiki where users can discuss bugs and provide feedback (with occasional comments by the developers, hopefully).
2.) The rush for feature parity with the windows version to justify the 'same price on all platforms' policy should stop, since it has a negative impact on quality. The 'stable' Linux version should only contain mature functionality, and its price would have to reflect this in comparison with the pricing on windows. At the moment, this would probably mean that Linux would just have the 'classic' flavor, since 3d is still too much work in progress and should be further refined in the development branch (IMO, the 'stable' version should ship without RedSDK).
3.) Support on Linux should be narrowed to a single Linux flavor and version.
Given the deplorable state of the Linux market (fragmentation and incompatibilities between distributions), it seems impossible to maintain more than a single platform. The choice of ubuntu's LTS releases as main development target makes sense to me, since they seem to come closest to a commercial OS. I think compiling on the oldest supported LTS and testing on the latest is all that can reasonably be expected from Bricsys - figuring out how to get the program to run on other distros/releases would be left to a wiki (to be created) and the forums.
Since Linux users tend to be more technically inclined, the development branch could provide a testbed for new features and usability improvements and thus serve the windows platform as well.
Does this make sense to someone?
0
Comments
-
... Regarding the pricing issue: If you consider the fact that BricsCAD for Linux is a (small) niche market, a point could be made for a higher price for the Linux version.0
-
Traditional UNIX vendors always claimed this - that's why they don't exist anymore...0
-
Hi Knut, thank you for starting this post.
Speaking for myself, you are very correct regarding growing frustration.
I like your ideas, hope Bricscad team will consider it seriously. Linux is community based and the community can contribute even in cases of a non GPL program, if the price reflects this. Hope it will catch on.0 -
All three points makes sense for me. And by my opinion, it is a good way how to make Linux version stable and usable.0
-
I know the frustration and the various versions of Linux out there. Remember windows is way ahead in enterprise use. I use Linux solely now as of this year. I appreciate all the work and investment Bricscad has made. I just recently got a MS Project app that I can use safely and daily (LibreProject). If I needed all full stable cad features for revenue generation then I would be dual boot or virtual machine to a windows version for that program. Thanks for all the progress. I have to say I respectfully do not follow the thinking as posted but I understand that line of thinking.Respectfully,Michael Harold0
-
Good post.
1. Agree completely. Two code bases and much better engagement with the Linux community--the great advantage that Linux offers. Done well, this will not just stem the tide of ill feeling, but it might well generate commercially useful ideas back to the main branch helping all versions.
2. There seem to be two points here and one doesn't automatically follow the other.
I agree that the stable branch has to work--indeed it irks me having to say so since it should be obvious. Releasing software that doesn't install, or crashes constantly is a bad idea--you're advertising incompetence and eroding the brand. Bricscad is excellent software with growing brand value and a tremendous future. I think that the Linux market holds great early-mover potential for Bricsys (no serious competition, huge scope for growth off a very low base) provided that the company addresses the market with respect--respect for its own brand and respect for professionals who choose to work on a Linux platform. I think if the choice is between stable software that encourages professionals to invest time and money in so they can get back to work versus software that has all the bells and whistles and a broken axle...it's pretty clear to me.
I am not at all sure that it's as simple as ditching the 3D rendering engine or associated 3D functions since for many users this is the most compelling reason to purchase Bricscad in the first place. I may be wrong.
3. Couldn’t have put it better myself. Honestly, I have no preference for Ubuntu especially. I used Red Hat for years at work and Open Suse and home, along with Debian and friends. From a commercial perspective, why fight the tide? Ubuntu is the way to go right now. Let stability and success on Ubuntu encourage experts from other distros to offer their packaging assistance free of charge further down the track.0 -
I hope you guys are realizing that the negative way of addressing the issue are in fact undermining BricsCAD and equally the purpose of improving the software. I really like this software! It is a full-worthy replacement for AutoCAD at a fraction of the price, and my company is depending on its development.
Can BricsCAD have the same price on windows and Linux despite some differences? Yes! The cost of a fully equipped Linux workstation is still just 15% (purchase cost, even less when it comes to life cycle cost) of a windows equivalent for my company, when counting the costs we can cut by using FOSS alternatives for all the things we are not true experts on (like replacing adobe design suite, windows licenses, acrobat professional, CMS systems, data base tools, email clients... with FOSS) and only paying for our niche software, like CAD and 3D-rendering.
I think the idea of a stable and a testing branch is great, where different versions can be installed and tested at the same time on a single computer. For stable releases of BricsCAD, naturally stability is very important.
Second. I have had issues with Autodesk products as well. My old company with 500+ Architects finally disabled hardware 3D acceleration on all their windows workstations with Revit Architecture last year, after coming to the conclusion that crashes caused by its instability was not going to be resolved. And that software is 19k dollars for each license!
Then try to file a bug report to Autodesk and get response (from anyone except a salesman who has absolutely no influence on solving the issue) if you are not the IT director of lets say Toyota or General Motors... dead end!
The BricCAD development team on the other hand has replied to every single topic I have filed as a bug. They have kept me updated on the progress of solving the issue and fixed them one by one. That support is just the best I have ever seen and I think this attitude is exactly what we need for a good Linux CAD platform.
Regarding the proposal to support only one distribution; Even though I am on Ubuntu LTS myself I think it is important to stress that Linux comes in many flavors, always will and always should be encouraged to do so (freedom you know). A mix of niche and mainstream distributions is one of the strengths (besides FOSS, security and superior CLI) of the Linux platform, where the niche communities has most of the knowledge and the main-streamers (like myself) would cut their own legs if they started acting like they would be better off alone. As an example; ArchLinux and the Arch wiki has pretty much taught me everything I know about handling an operating system. I could never manage a cluster of corporate workstations and servers today without that generous sharing of knowledge and I will always remember that.
Sure focus on one distribution for testing and release only one binary package, as long as a generic tar.gz package is released as well. But to be honest, stability is not a matter of supporting a single dist. Take Thea Render for example; Commercial 3D-rendering studio, very stable software and only releases a generic tar.gz linux package.
Maybe an interesting model would be if a few dist communities were invited (as payed consultants maybe) to help out compiling BricsCAD for their distribution (without releasing the source code). I think this would boost stability and give important feedback about issues before new versions are released. Try to find anyone out there who can beat the Debian team when it comes to releasing stable releases of not always so stable software branches (and if they are not interested I am sure Mark Shuttleworth will be, as a second option
.
Keep up your efforts Bricsys!0 -
Oops, the first time a post of mine is generating such amount of feedback...
@Patrick
as to 2.):
I certainly don't want to suggest that there is an easy way to arrive at a 'stable' version - but I got the impression that many complaints were in fact related to hardware accelerated graphics and thus to Redway, who - as far as i can see - simply did not deliver what they promised (hardware support is still shaky, and the software fallback is a joke).
My proposal did not mean to deprive Linux users of 3d functionality - it would stay available in the development branch, just made clear that it is work in progress with no warranty whatsoever (besides, the full set of ACIS functions is available without switching to 3dcontext - I think this command is somewhat misleading).
But the main problem has IMO been that Bricsys pushed out major versions where some of the announced functionality was still missing ('to be implemented'), and then tried to fix bugs and add functionality at the same time in minor releases, which lead to 'maintenance releases' that sometimes created more problems than they solved.
as to 3.):
I don't really like ubuntu either - while other distros often tried to turn Linux into a windows clone, they opted for mac os, and I'm not sure which one is worse. But I see the need for some consolidation in the Linux world, and I am ready to put my personal preferences a bit aside if this increases the chances of commercial software being ported.
BTW thanks for putting things into proper English, I am struggling there...
@Michael:
I sincerely hope that my post is not 'undermining Bricsys'. I am grateful for every vendor who takes the risk to venture into the FOSS world, and I am particularly attached to BricsCAD, since they offered me the possibility to choose the OS I like when there was no viable alternative. But I don't think keeping your mouth shut when things seem to take a wrong turn is helpful, nor would I subscribe to your suggestion that Bricsys may well charge a higher price on Linux since the lower TCO of running Linux workstations would compensate for this (not everybody is a corporate customer).
I completely agree that the level of support that Bricsys offers sets them apart, and I would never consider returning to Autodesk. But it is frustrating to invest time in writing bug reports, just to read about them getting fixed in the windows release notes, while the respective linux version fails to materialize.
And I think it is short-sighted to narrow the perspective to Bricsys vs. Autodesk - with Dassault pushing Graebert and steady progress on 2d and 3d in the FOSS world (qcad and Freecad), there will be competition from all sides.
I completely share your views on Arch (or Gentoo), I am also relying on their documentation whenever I run into problems, but I doubt they will ever be a target for commercial vendors - and their users can probably cope with that.
The idea of dropping distribution specific packages all together and just providing a generic .tgz is something I would certainly not object to. The official Blender releases come in a simple archive that contains most dependencies, and thus seem to have very few problems to run on a variety of distros. E.g. Ubuntu then re-packages their own .deb versions, which are much smaller (since compiled against the system libs), giving their users the choice.
But if this might work with closed source seems less obvious to me...
But enough for now - 13.2.13 is just out, let's check if this makes everybody happy!0 -
At last: 13.2.13 does install, does contain X-Solids.lsp and does handle 3D solids insertion and editing functions released initially as part of the 13.2.xx bundle. I've not done anything wild with it, but it seems to be functional. Good news.
"...Bricsys pushed out major versions where some of the announced functionality was still missing ('to be implemented'), and then tried to fix bugs and add functionality at the same time in minor releases, which lead to 'maintenance releases' that sometimes created more problems than they solved."
Absolutely correct and plain as day to those who care to check the release notes (hint: search for "crash"). It's pretty clear that the February release (13.2.1) caused much of the pain. Look for bugs fixed in minor releases and it's hard to conclude it went through an effective testing protocol. Hands up if you've tried that before. Hands up if you got away with it. That's what I thought.
I too have found Bricsys' support for Linux to be very responsive. I like to think that developers peruse these forums from time to time and, if so, I am confident that the constructive criticism from its customers--let's all remember that we are customers and not (just) a fan club--will help to make BricsCAD a force to be reckoned with.
In the meantime, back to my (now) fully armed and operational CAD station!0 -
I just upgraded to 13.2.13 on a Dell Latitude laptop and all is well. Everything seems fo work perfectly. I too have found the Bricsys Linux team to be most helpful and responsive and all that I can say is Kudos to the lot of them. Keep up the good work fellows!0
-
3.) Support on Linux should be narrowed to a single Linux flavor and version.
Given the deplorable state of the Linux market (fragmentation and incompatibilities between distributions), it seems impossible to maintain more than a single platform. The choice of ubuntu's LTS releases as main development target makes sense to me, since they seem to come closest to a commercial OS. I think compiling on the oldest supported LTS and testing on the latest is all that can reasonably be expected from Bricsys - figuring out how to get the program to run on other distros/releases would be left to a wiki (to be created) and the forums.
Since Linux users tend to be more technically inclined, the development branch could provide a testbed for new features and usability improvements and thus serve the windows platform as well.
Does this make sense to someone?
It makes sense to Bricsys to concentrate to just one flavor of Linux. It makes no sense not to support this version not perfectly.
As ubunto is so close to Debian, the support could easly be made to that as this is quite often in use. I think I could do that, but
if I ask some questions, none is seriously answered.
As ist was mentioned before, support for Linux is really nor satisfying. Here, AutoCAD on XP has to be used, but to hope that XP
ist too old for attacs with viruses is ridiculous. Bringing XP to internet is much too dangerous. Changing to Unix means to kill AutoCAD, but
this is not possible in Vienna. There also is no way to have a virtual machine with XP and AutoCAD, it ist too slow.
Bricacad could be the chance to have a secure way to internet when working on Linux. So I don't understand the way of thinking.
For instance the city of Munich completly changed to Linux it ist funny to think there only would be a market too mall.
As mentioned before I repeat that i would help to bring BricsCAD to debian. But there has to be a little bit more support.0 -
I find it disappointing and embarrassing that Linux users would openly advocate for the support of one Distribution over the other. It is an indirect way of saying that these distros truly differ at the core ... something that is totally false. Apart from package management and branding, it is essentially the same code running. I don't see how that affects Bricscad. I don't use Ubuntu and if Bricsys buys into this line of thought, you can be sure I WILL NOT SWITCH. I do not experience the instability mentioned here, and if I did, my first reaction would be to file a support request --- that is how Linux users approach things (they file bugs and patches).
So far Bricsys has been wonderful in many ways. Only one thing remains to complete there awesomeness and that is to port BIM-Module to Linux.0 -
I find it disappointing and embarrassing that Linux users would openly advocate for the support of one Distribution over the other. It is an indirect way of saying that these distros truly differ at the core ... something that is totally false. Apart from package management and branding, it is essentially the same code running. I don't see how that affects Bricscad. I don't use Ubuntu and if Bricsys buys into this line of thought, you can be sure I WILL NOT SWITCH. I do not experience the instability mentioned here, and if I did, my first reaction would be to file a support request --- that is how Linux users approach things (they file bugs and patches).
So far Bricsys has been wonderful in many ways. Only one thing remains to complete there awesomeness and that is to port BIM-Module to Linux.Hi everybody,Thought I do use bricscad on ubuntu, I think Onyeibo has a point. The program works fine and smoothly. We bought the license and think pricing is fair: development takes money and they are doing a great job.I also join the request for the BIM Module porting, for it may become soon a serious lack for the linux world (any distro...)regards,Nicola0 -
@Onyeibo Oku:The existing BIM module will definitely not be ported to LINUX. But we are working on something better and which is planned to run on all platforms: Windows, Linux and Mac.Best regards, erik0
-
@Onyeibo Oku:The existing BIM module will definitely not be ported to LINUX. But we are working on something better and which is planned to run on all platforms: Windows, Linux and Mac.Best regards, erikThank you Erik, I'm looking forward!Nicola0
-
@Onyeibo Oku:The existing BIM module will definitely not be ported to LINUX. But we are working on something better and which is planned to run on all platforms: Windows, Linux and Mac.
That's music to my ears
Could you grease our anticipation by divulging the estimated time of release? :-)0 -
@Onyeibo Oku:The existing BIM module will definitely not be ported to LINUX. But we are working on something better and which is planned to run on all platforms: Windows, Linux and Mac.Best regards, erik
Cool - nice to hear this.0 -
I wanted to buy a copy to run under 64 bit Ubuntu. But the trial was far too buggy. In fact, I never completed one single drawing. The toolbars wouldn't stay put. Tools that work on the Windows version did not work in the Linux version.I have to say, I would leave Windows in a heartbeat if I could get a reasonable priced CAD package for Linux.0
-
I wanted to buy a copy to run under 64 bit Ubuntu. But the trial was far too buggy. In fact, I never completed one single drawing. The toolbars wouldn't stay put. Tools that work on the Windows version did not work in the Linux version.
Hi Jim,
I am running BricsCAD on Linux and drawing is fluid. There are few things I wish would improve but they're "few" ... nothing like what you described. Is your experience recent? If so, have you filed a bug support ticket or report with Bricsys? I'm almost sure your experience can be sorted out. Which tools didn't work?
My little wish list:
---------------------
Command Window should always have focus -- it still looses it sometimes
Auto-complete can be obtrusive ... it freezes on the wrong commands sometimes
What about a visual LISP Editor? This is not an anomaly ... just a feature request
See? I can't think of more .... very few.0 -
I'm still using V11 on an old 32-bit laptop because I never had time to get the newer versions working on my 64-bit computers - until now. The latest version (14.2.19) finally seems to work on my system (Debian Jessie). I still have some testing to do but if the trial version is OK then I will not hesitate to pay for the upgrade. I do not think the cost is so high. But it is much more important that the system is stable than having all the bells and whistles. I have only Linux computers so the Windows version is not for me anyway. I do not use CAD very much but sometimes I really need it.
I would like to express my thanks to Briscsys for maintaining the Linux version of BricsCAD.0 -
We are targeting end of the year. Don't pin me on it, but we do our very best to get it done by then.
That's music to my ears
Could you grease our anticipation by divulging the estimated time of release? :-)Best regards, erik0 -
Hi - Hope I'm not too late to the discussion. - I only use the most basic 2D functionality of Bricscad, so a Classic version for Linux wouldn't upset me except, perhaps, as a symbolic abandonment of the Linux community. The discussion of supporting only 1 version of Linux makes a little bit of sense, but not total. Except for packaging (tar.gz yum deb etc.) does it really make a difference? I know I've used Bricscad with Ubuntu, Sabayon, Suse and Mint and with KDE, Gnome & Cinnamon environments and any problems I've had have not been due to the Linux distribution, except for missing libraries. Does it make sense to package Bricscad with all of it's dependent libraries or have them all available on Bricsys server for download and installation if necessary? -- If you are going to focus on one distribution, Mint seems to be pulling ahead of Ubuntu in user base and is my personal favorite, something I know is of great importance to you.
Maybe, if you must focus on one distribution, Debian would hit the most downstream Linux distributions. -- I second Mikael Nordvall's comment: "Maybe an interesting model would be if a few dist communities were invited (as payed consultants maybe) to help out compiling BricsCAD for their distribution (without releasing the source code). I think this would boost stability and give important feedback about issues before new versions are released."0
This discussion has been closed.