Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

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.

  • edited October 28

    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).

  • 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)

  • 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...

  • 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.

  • 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.

  • @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...

  • 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.

  • 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.

  • 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.

  • 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.

  • 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}
    done

    returnCode=1
    while [ ${returnCode} -ne 0 ]; do
    apt -y upgrade
    returnCode=$?
    echo ${returnCode}
    done

    This 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.

  • That large bin bash line is missing the leading octothorpe. Apparently, the forum ate it to produce the large text.

  • 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.

  • I am good with 18.04 as we updated all our Linux boxes months ago....

Sign In or Register to comment.
Origami
Origami is the Japanese word for paper folding. ORI means to fold and KAMI means paper and involves the creation of paper forms usually entirely by folding.

Powered by VanillaForums, Designed by Steam