BricsCAD(Linux) V20, increase minimum requirement to Ubuntu 18.04?
Dear BricsCAD(Linux) users,
soon BricsCAD V20.1.04 will be published. This version will be published simultaneously on all platforms. On Windows it is a release, on Linux and Mac it is a beta.
BricsCAD (Linux) V20.1.04 is compiled on Ubuntu 16.04 with gcc 5.4.0. This dictates the minimum requirement.
I am considering to yet switch to Ubuntu 18.04 for V20 as our build system, which would increase the minimum requirements by two years.
This would be more practical on our side, for instance to allow using c++ 17, but also to avoid GUI bugs that no longer happen in newer versions of system libraries.
How many of you still use a distribution older than Ubuntu 18.04? (released before April 2018, or more precisely: a libstdc++ version lower than 5.4)
Greetings
Tijs
Comments
-
I'm on 18.04 and patch the O/S weekly.
Can you not statically link your executable so that it won't look for local libraries?
i.e. build on 18.04 and statically link in 18.04 libraries so when run on an older system it will use the 18.04 code that is embedded inside the executable instead of looking for a local library.
It would produce a large executable but would mean you KNOW what people are running when issues come up.
0 -
Not what you are asking, but I accidentally upgraded to Xubuntu 19.10 and so far everything works fine - with the older minor glitches, disabling the quad made it rock solid. With 18.04 being Long Term Support I think what you suggest serves everybody (my 2p's).
0 -
Hmmh,
Rolling Release here. And if it would be Ubuntu, I would use the latest
available.
AFAIK Ubuntu offers System Upgrading from older to newer versions (?)Would be pity to waste resources on too much backward compatibility
and not profit from newer technologies.Second,
do Bricscad users, that use LTS releases for 5-10 years, really use the latest
Bricscad version and maintanance ?So I think it would be very good to reliably know the statistics of which
Linux Versions AND Architectures/Distributions are used for, which
version of Bricscad.
Couldn't that be (optionally) done automated by installation/online licensing,
a user Poll or selection options in Account Settings ?(I hope V20 Beta will not only be Ubuntu or *.deb only)
0 -
Can you not statically link your executable so that it won't look for local libraries?
That may be worth a try.
Although personally I think something like Appimage/Flatpack/Snap may make more sense.you KNOW what people are running
That would be a major advantage indeed.
The huge variety of linux flavours is a serious complication, anything to bring that down is bound to help...0 -
I get rid of all snap default software and install the normal equivalents. Just trying to get the calculator up under snap takes Waayyy too long.
I don't have an SSD in my box. If I did, I might not object to snap as much because it would presumably load things in an eye blink. You may want to know about SSD's for performance reasons.
BTW - I'm considering getting an SSD just to load the O/S and put /home on a traditional spindle. So, intended hardware may also be a reasonable question to get answered.
0 -
Appimage has stolen the old JAVA canard of write once run everywhere. It was BS then and is BS now. Performance always takes a hit when you go through an abstraction layer.
Flatpak has security issues and was developed by Redhat now owned by IBM. I was on Fedora from FC2 through F26 and watched their support become nonexistent. I wouldn't trust IBM to improve the Redhat/Fedora environment as IBM's glory days are long over. It's a legacy company waiting to die off.
Adding a middle layer compounds your support issues and forces end users into an environment they may not want. A statically linked executable would probably load faster and mostly isolates your code from the host O/S. Only the most rudimentary O/S operations would be performed outside your linked executable by the O/S code and that is generally kernel level and very reliable over all Linux flavors.
0 -
@RoatanBill Thanks for your insights, I am learning!
The idea that I had in mind for the future was to
- keep the builds/installers we have now
- upgrade our build system sooner
- also publish an Appimage variant so older systems are covered too
But well, nothing is settled yet. A statically linked executable is worth considering too...
0 -
It's obvious that you started this discussion because you want more control over where and how your app is executed. Equally obvious is that the most control you're going to get is to eliminate as much middleware and random uncontrollable O/S interaction as possible.
By middleware, I'm referring to anything that purports to reduce your support headaches and improve performance all without too much intervention on your part. I believe diet pills and fuel additives are usually sold using those types of claims. My response is TANSTAAFL. Trying to support some antique operating system is, in my opinion, detrimental in the long run as it wastes too many resources trying to satisfy a sliver of a market, but that's your call.
Nothing is going to give you more control over an operating environment than a statically linked application. The less you need from the O/S because a known and tested version of a routine is already inside your app means that supporting older operating systems is inherently better with a statically linked app. Low level file control and memory management are about as bullet proof as one can expect in any O/S, not just Linux, and that's about all a static app will require from the O/S.
With a static app, you avoid the O/S thrashing looking for libraries. The O/S is going to look for the whole library, not just the tiny subroutine you need at the moment. If that subroutine is already statically linked, no thrashing and no O/S intervention.
Memory management becomes cleaner and is required less often because all the subs are loaded into their permanent addresses once.
Performance is usually enhanced at both load and run time, especially at run time.
Debugging an issue becomes easier because you can leave debug code in the production app and use a run time switch to activate it ON THE USERS MACHINE IN THE USERS ENVIRONMENT. That debug code sends you the results with whatever traces you care to implement. Over time, as you write more and more debug code that you bury inside the app, that code will make support much
more efficient.If you'd rather, you can supply two applications - the normal one with all debug code ignored at compile time and one where all the debug code is compiled in thereby avoiding the small performance hit debug switch checking naturally entails.
I would also suggest that all compiler and linker warning messages be eliminated as much as possible because that's typically where memory leaks and bad address pointers originate.
You may want to look into linkers as they aren't all made equal. Some linkers will optimize the module to module handshake and even point out additional warnings that a less intelligent linker will miss.
0 -
Michael Mayer wrote:
do Bricscad users, that use LTS releases for 5-10 years, really use the latest Bricscad version and maintanance ?
Good point. (Ubuntu 16.04 is less than 4 years old, still your point is valid.)
I tend to be reluctant to upgrade my OS for production purposes. I find upgrading every 4 years rather than every 2 years not a bad scheme - unless you need new stuff of course. But indeed, with that reasoning you don't need to upgrade BricsCAD every year either.
I definitely do think it is ok to 'jump' to Ubuntu 18.04 as minimum requirement. This post is meant as a sanity check of that intention. The forked-discussion about Appimage/Snap/Flatpack-like and static linking is interesting.
0 -
Normally you choose an operating system and then the applications. However, the software for CAD users is so important that it is reasonable to state that it is the other way around. A bit black and white but somewhat arguable.
Taking the development speed of BricsCAD into account, LTS seems a good compromise. After all, a new LTS version appears every two years. I also agree with Michael's statement about LTS users going on for 5 years. Do you want to use the new features? Then your operating system must also be up-to-date.
In addition, I agree with RoatanBill, layering may be tempting but makes it slow too and that is precisely one of the powerful purchasing arguments that you do not want to change: BricsCAD is pretty fast and should stay that way.
Appreciation for bringing this subject up.
0 -
Well there is Windows, a semi rolling release.
I can still run my 32bit? Microstation from 2004? on a
current Windows 10. Maybe a current Bricscad also
runs still on a Win7.And there is macOS.
Which,
a) with its deeper changes brakes most Software every year
b) OS Upgrades meanwhile are more or less forced.
So you either keep OS AND Software current or, in the worst case,
stay with a same Versions of OS+Hardware+Software.I thought Linux is something else or in between.
You can make oldest Software run on current Linux if you find and
install all needed sources or better by Flatpack/Snaps/... ?
Beside all Repository Software, proprietary Software runs on older
Linux just because such Software mostly uses pretty old
dependencies only ?Don't want to judge if it is useful or not to "never change a running system"
and use older OS. But if, I think the exactly same applies for the Software
running on it.
Software Upgrades means some effort to get used to it and some learning,
maybe OS and so Hardware upgrades and maybe adaption efforts to migrate
long running Projects.
So I think it is likely that someone who stays with an LTS also stays with his
Software release.
And in this case there would be no big problem to rise minimum requirements
to a current OS like on Mac.I just see that on Linux it is not that easy to keep current.
I realize that my Elementary is still based on 18.04 and uses an ancient 4.15
kernel and there are no hints that that will change that soon.Generally I personally think that newer is always better and I want the
most current Hardware, OS and Bricscad Release that I can afford.
I already get nervous when my Rolling Releases aren't rolling fast enough,
when my Manjaro gets Updates only every 2 weeks or why my Firefox doesn't
get updated for that security fix on Tumbleweed for 3 weeks.
When I watch Linux, Bricscad and especially Blender development, newer
is always so much better.
And I never experienced any significant Degradation vs so many benefits
by any upgrading so far. If there was, it was fixed a few days later.0 -
Michael:
Keeping Ubuntu 18.04 up to date with patches is as easy as executing this script as root:
!/bin/bash
returnCode=1
while [ ${returnCode} -ne 0 ]; do
apt update
returnCode=$?
echo ${returnCode}
donereturnCode=1
while [ ${returnCode} -ne 0 ]; do
apt -y upgrade
returnCode=$?
echo ${returnCode}
doneThis takes care of the nuisance
403 Forbidden [IP: 91.189.95.83 80]
failures.If one configures a system appropriately and takes daily backups to help mitigate hardware failures, then migrating to a newer Linux O/S is relatively painless and quick.
I can set a box up on 18.04 or its successor in about 15 minutes including standard applications, firewall, ssh, rsync, backup, etc because I've scripted MY standard install. Rudimentary BASH knowledge offers a huge payback.
0 -
That large bin bash line is missing the leading octothorpe. Apparently, the forum ate it to produce the large text.
0 -
Well I'm a standard user.
(Or deep in my heart even a typical Mac user)Of course all common Distribution offer Fixes and Updates regularly.
But those Ubuntu derivates will not upgrade the Kernel or Desktop.
Maybe there will come a newer Version that starts with a current kernel
at that point. With the need of a full System Upgrade, which some people
may want to avoid.I also tried MX Linux which was called a semi rolling release.
Latest "stable" Debian Kernels. Looks like that is still 4.19 for Debian.
Tried to use their semi official 5.1 kernel option one time.
Wouldn't boot and I reverted. Also no new XCFE 14 desktop.
They say it needs a complete new installation from scratch(!?) for their
new current version.
I mean for someone like me it is quite risky to try to make changes of
things I don't understand.For me my rolling releases with KDE are less of a hassle.
These continuous updates are tested and stable. Not worse than current
macOS Updates or Upgrades.
Maybe less risky than any Windows Updates.0 -
I am good with 18.04 as we updated all our Linux boxes months ago....
0 -
Fedora 31 is here.
And I can build ObjectBRX extention on it for v19.
0 -
I am very excited to be joining the linux user category. I'm doing a hardware upgrade and my new machine will be linux only. It has been a long trajectory and I'm so grateful to Bricsys for being a brave BIM on all major platforms. I am primarily a business user, so I mostly want stability and to be able to get my work done on a less corporate OS. Switching from Mac, my first love, is not so hard after all their intrusive marketing has interrupted my workflow, but switching to linux will be tricky too I'm sure.
My question is: How do I get a v20 beta for linux? I have some schematic models drawn up on the mac version, and the stair tool has been super helpful already. I don't want to go back to v19.
0 -
I created a support ticket asking when v20 would be available and they sent a beta link download.0
-
I also asked successfully for beta access by a Service Request.
And as far as I have seen Heidi Hewett in a video,
Bricscad is happy for anyone interested in participating
the Beta Testing.0 -
I'm looking forward to the release of Ubuntu 20.04. Please do move up to Ubuntu 18.04 for BricsCad.
Sure it takes effort to upgrade but if you upgrade BricsCad you might as well go with a clean install of a current OS too.
For those who dread upgrading - Get a hard drive switch in your desktop and install a second hard drive. Then you can "ease" into the upgrade rather than immediately kill your old, productive setup.
0 -
From my point of view, increasing minimal requirements to 18.04 is perfectly fine. More, I' am eagerly looking forward to it. Not sure, how much is BricsCAD desktop environment agnostic, but there was also switch from Unity desktop to Gnome. Unity desktop was fine, but now is gone and there is no need to maintain compatibility in new BricsCAD versions.
0 -
Unity was gone quite some time ago.
AFAIK Bricscad supports Gnome and KDE, on Ubuntu or Open SUSE.(While all 3D Apps like Cinema4D or Modo seem to support only
RHEL/CentOS, which seems to be only used in large Studios ?)I see no big issues on Ubuntu based ElementaryOS either,
(beside a doubled top bar )
which DE is based on Gnome but their own Development called
Pantheon desktop environment. Although they do large modifications
to GUI.
Similar to Gnome derivate Cinnamon DE, from Linux Mint.So basically Bricscad should also run fine on any Ubuntu + Gnome based
Distribution like e.g. PopOS, ZorinOS, .... too.For me who prefers KDE, I would go Kubuntu instead.
(Currently I go Manjaro, Open Suse Tumbleweed, and ElementaryOS)0 -
I like Gnome, so I stick to regular Ubuntu. There are some glitches regarding BricsCAD behavior when switching between virtual desktops. They persisted to V20, so I have filled a bugreport about them. Also in V19 there is a problem with notifications (xref changed, print publish finished) and dual monitors with different resolutions (in office I have 1920x1200 + very old 1280x800). Haven't checked it in V20 yet however.
0 -
If you are experienced with Gnome and using Virtual Desktops ....
Is it possible in Gnome too, to assign Apps individually to a special
virtual desktop. So that when you open an App, it will open directly
in its own virtual desktop ?(Or what about Gnome derivates, latest XFCE and such ?)
I always made heavy use of VDs in macOS.
And I found with Windows Settings in KDE I can do the same.
Although much more tedious to setup than in macOS, but once
set up it works well.I realized I can't work without such "auto-desktops" when I tried Windows.
Having VDs but needing to move my Apps manually is tedious enough.
But that all your setup gets lost after a reboot really annoys me.I mean each Windows Start I reorder my 2 Explorer Windows side by side
to half screen size, hurry up to switch to the second VD, so that when
Firefox starts up it will do on the right VD.
I found a macOS "Preview-like" Addon App for Windows already,
but so far no Tool to bring macOS or KDE comfort to virtual desktops.0 -
I have found some extension which should do what you want, but I didn't tested it:
https://extensions.gnome.org/extension/16/auto-move-windows/
Gnome has dynamic desktops and I usually simply switch to a new one with Ctrl+Alt+Down (or Up) when I need and open app there. If I need it on another one, I simply move it with Ctrl+Shift+Alt+Up/Down.
0 -
Thanks Vaclav.
Sounds pretty much like what I want.
Some other Gnome Shell Extensions look useful too.So if I get it right,
by default Gnome DE's virtual desktops work the same way
(as limited) as on Windows.Does by any chance someone know a similar extension
for Windows ?0
