Linux Mint

[Harry WilkesParticipant @harrywilkes58467]

I know there are many LM user on the forum so who's upgraded tp LM 21,0 and what are your thoughts is it worth upgrading ?

H

[Harry WilkesParticipant @harrywilkes58467]

[SandgrounderParticipant @sandgrounder]

I upgraded to LM 21.0 this morning from LM 17.3 and it looks good to me so far but I've not had chance to go into all it has to offer, and the 17.3 was a bit out of date.

John

[AdrianRParticipant @adrianr18614]

I have recently upgraded two laptops, one from 19 and the other from 20.3, both upgraded just fine and I am happy with the way it works.

I upgraded because I needed a newer version of the Canvas libraries to run an application. There is an issue with some applications in 20.3. There is a problem that some of the desktop icon themes use a newer version of Canvas than is supplied in 20.3. For me, this meant that Gsender for my CNC would crash on trying to open files.

Changing from the icon themes from the Y series to X series fixed it in 20.3 but in 21 it all works fine.

LM 20.3 will be supported until Aprl 2025 so unless you are having issues there is no hurry to upgrade. If you do decide to upgrade then do the recommended backup, but then again if you have anything important you should be backing up anyway.

Adrian

[SillyOldDufferModerator @sillyoldduffer]

For what it's worth, Vanessa Mint is based on Ubuntu 22.04 which I've been using since April with no problems.

Although Mint and Ubuntu present different desktops, they're much the same under the bonnet. So unless the Mint team mess up the desktop bit, the underlying operating system has been thoroughly tested by Ubuntu users already.

Many prefer Mint's look and feel, but trailing 5 or 6 months behind Ubuntu also makes it less likely to be buggy. As Ubuntu is usually solid, this makes Mint delightfully low risk.

However, I always wait a few weeks before upgrading anything! It's to allow others to find any serious problems that might have slipped through: rare, but it does happen, and I prefer not to be a pioneer on the bleeding edge!

Dave

[Peter G. ShawParticipant @peterg-shaw75338]

Hi,

I am in the somewhat unusual, or perhaps difficult might be more apt, position in that I use a DOS database program and a Win32 bit CAD program. In amongst other programs of course. The CAD program works more or less satisfactory via Wine. (More or less because with Mint 17 & earlier and Wine 5 and earlier, there were a tiny number of oddities which didn't really affect me. I haven't yet tried it out under Mint 21.) The DOS program has caused me problems in getting it working satisfactorily with earlier programs; ultimately, I found I could get a satisfactory setup using the original version of DOSEmu. Unfortunately, this progam would not work under Mint 20 or 21.

Mint 17.x becomes End of Life (EoL) in April of next year, so I set about trying to get the DOS program working under Mint 21 as this will give me five years before it becomes EoL again. I looked into the original DOSEmu – but no dice. I then looked into DOSEmu v.2. Now last time I tried this, I could not get it to work – there was a problem loading the DOS program. Since then DOSEmu v.2 has been considerably updated, and I'm pleased to say that my DOS program now seems to be working satisfactorily, I haven't yet had a full workout, but the signs are good.

A lot of people will ask me why I don't use this program, or that program, and why don't I just scrap the DOS program, and I suppose the CAD program, in favour of more modern equivalents. Fair enough if I could be assured of a satisfactory life in which to use them. As it is, aged 79, and with BigC, I really can't be bothered learning new programs. Plus, of course, they work, and work satisfactorily for me. End of story!

Other problems. I've only been changing over this week, so I haven't had that much experience yet. The only problem I have so far found is that using Mate desktop with a black screen, Mint X symbols & something else – can't remember what, I do have a problem that if I open a file from the desktop, the icon changes colour, whilst the title displayed under the icon changes to a very pale, almost white colour which makes the text almost unreadable. I have compared with a separate machine running Mint 17.3, and whilst under the exact same circumstances the colours do change, the text background does NOT obliterate the text. Of course, this may just be a setting somewhere but I've yet to find it. Any ideas anyone?

So, there we are. Is it worth it? Well, in my case yes since Mint 19 becomes EoL in 6 months time whilst Mint 21 becomes EoL in 2027 which may see me out – hopefully not, but there we are, I must face realities.

Cheers,

Peter G. Shaw

[Harry WilkesParticipant @harrywilkes58467]

Many thanks for your replies

H

[AdrianRParticipant @adrianr18614]

Peter, I just sent you a PM about your DOS problem.

[Nick Clarke 3Participant @nickclarke3]

Peter –

Rather than trying to get your DOS program to work under an emulator under Linux have you considered making your computer dual boot with one of the free MsDOS equivalents 'cutting out the middleman' so to speak?

Another way might be to use the free version of VMWare and again running a free DOS operating system so your database is running natively rather than under emulation.

[Kiwi BlokeParticipant @kiwibloke62605]

Bit off topic, perhaps. I used various Mint versions (Cinnamon desktop) for many years. It was mostly entirely satisfactory, and pleasant to use. However, something went wrong with an installation on a laptop with a touch-screen, so I explored other distros which were said to be more likely to be compatible with odd hardware. I settled on MX Linux, which has worked even more reliably than Mint, and even comes with a built-in manual. When upgrades are due, I'll be moving to MX Linux on the other machines. Worth a look…

[SillyOldDufferModerator @sillyoldduffer]

Why DOS programs might not work on a modern computer may be mildly interesting. The engineering problem isn't with DOS itself, it's that modern hardware has moved on considerably, which, depending on how the DOS program was written, can cause compatibility problems.

First issue is word length: the limitations of early microprocessors restricted MS-DOS to 8/16bit operations able to address only 64kB of RAM. The next generation of Intel microprocessors extended addressable RAM up to 640kB by allowing addresses to be paged, ie in two parts, rather than flat, ie in one part. Paging extends the address range at the cost of speed and extra complexity in the code. So programs written for these chips have a choice of 6 different memory models, which the programmer selected depending on how fast the code need to run and how much memory it needed. 64kB addressing was quick, but the program and data were small, while 640kB addressing allowed big code and/or data, but was slow. Other combinations in the middle: it's rather complicated!

Time marched on: later 32bit microprocessors have a simple flat addressing system up to about 4Gb, and 64bit computers can address up to 4 petabytes (usually less, but at least a Terabyte), without paging. As later systems can do fast and big at the same time, they have no need to prat about with complicated memory addressing schemes. However, problems can occur when a 64bit computer emulates 16bit paged DOS because the 64 bit system has to translate the six 16 bit address models into something sensible. It usually works, but…

Second more serious issue is the way the DOS program was written back in the day. Code that only uses the official MS-DOS API should run in an emulator or free-standing DOS O/S with no problems. Unfortunately, some DOS programs were written to bypass DOS and access the computer BIOS (Basic Input Output System) directly. Usually to improve performance. Bad news! The BIOS is firmware providing the simplest possible interface to discs, RAM, keyboard, mouse, and screen for the purpose of booting a real operating system at power up, and not normally available to user applications.

Cutting out sluggish MS-DOS isn't dangerous on a single-user single-tasking computer, but it's a major no-no on multi-tasking, multi-user operating systems like Windows, Mac and Linux which have to fully manage processes and what they are accessing. Direct BIOS access is also a serious security risk, so almost the first thing a modern OS does is lock the BIOS down strictly.

Although they try, DOS emulators may not be able to catch and process direct BIOS calls, in which case the guilty DOS program will fail.

In the longer run, BIOS is slowly being replaced by UEFI (Universal Extensible Firmware Interface), which is even less likely to allow a DOS user program special access to firmware functions. The long-term outlook for DOS programs that call the BIOS is grim.

The best fix is to go back to the original DOS program and recode it to work with standard DOS system calls. Modern computers are so fast compared with older kit that the performance impact is imperceptible: there's almost no need for a user program to call the BIOS. Unfortunately, although the changes are relatively easy, it's unlikely to happen because not many DOS programs are maintained and the source code of many others is lost. Otherwise, one has to wait for emulator upgrades in hope a programmer has been able to code it cleverly to cope with wayward DOS programs.

In general programmers are trained to avoid fancy-pants tricks especially when they bypass the operating system. Although clever-stuff improves performance and utility, it's often at the cost of reduced portability and future-proofing. This was widely ignored in the last century because it was so difficult to get decent results out of puny hardware, and of course, no-one expected DOS to still be popular. What was smart in 1985 can be a downright menace in 2022! The sins of the fathers…

Dave

[Peter G. ShawParticipant @peterg-shaw75338]

Nick,

I've just sent a long reply to Adrian explaining all about my DOS program. I'm not about to repeat it – it's too long & life's too short!

The bottom line is that I have tried Oracle's VM and although it worked, there were problems, more to do with all the excess computing required than anything else. That was a few years ago – it may have improved since then.

Dual Booting is ok, but it takes time and causes the shutdown of everything else. As of now, I can use all these non-Linux programs as if they were original Linux progs, even to the extent of having shortcuts on the Panel. Thus taking full advantage of multi-tasking & task swopping. Actually, I don't know if multi-tasking does indeed work, not that it matters – task swopping is the important bit.

Cheers,

Peter G. Shaw

p.s. I've just realised that in various places aBOVE I've talked about using Mint 17. That should, of course, been Mint 19. Mint 17 has been EoL for a few years, whilst Mint 19 only becomes EoL next April. Sorry about that.

[Bob Unitt 1Participant @bobunitt1]

I've been using Mint 21 for quite a while now. The only problem I've found is that it won't recognise my camera when I attach it via USB. I have to dual-boot to Mint 17, attach the camera, copy the photo's from the camera to a shared drive, reboot to Mint 21, and copy the photo's from the shared drive back to main storage. A nuisance but I don't take that many photo's so it's livable-with. It's quite an old camera, a Panasonic Finepix HS10, so I don't know if it's any better on a more recent model.

The other thing to remember is that it doesn't work on 32-bit machines. I have an ancient 32-bit laptop in my shed for music & the odd google search, but that won't accept an upgrade to Mint 21.

[Frances IoMParticipant @francesiom58905]

the non-working camera is probably due to lack of support for the old camera chips in a library (dropped apparently as the single maintainer no longer maintains it – there are some self contained camera/video programs that don’t use this library and thus can still handle the old chips – bit of a nuisance as the small cameras using these old chips are perfectly acceptable for simple ‘look-see’ tasks and were very cheap.

[Bob Unitt 1Participant @bobunitt1]

I doubt it's the chip, as the camera wasn't small and cheap. I got a vague suggestion that it was a timing problem of some kind, in that the camera wasn't responding quickly enough to a poll from the PC – it was suggested that someone had reduced the relevant timer in Mint for some reason, and my problem is just collateral damage. I never did find out how to report the problem to whoever produces Mint, support there seems almost as obscure as MS…

[SillyOldDufferModerator @sillyoldduffer]

Posted by Bob Unitt 1 on 17/09/2022 10:27:18:

I doubt it's the chip, as the camera wasn't small and cheap…

Might be the cable. Not done much these days but there was a time when some manufacturers used a special USB cable where one of the data pins was held high by a resistor. It tied the device to particular software. Caused a lot of trouble because it's deliberately non-standard, and the special cables are indistinguishable from proper ones.

There's a hint in the camera manual that the cable might be special. It says:

Turn the camera off and connect the supplied

USB cable as shown, making sure the connec-

tors are fully inserted. Connect the camera di-

rectly to the computer; do not use a USB hub

or keyboard.

Standard cables don't care about hubs; the specials do. Otherwise the camera says it's USB2.0 which is compatible with Mint.

Have to go out now, but on my return I can explain some Linux commands that might pin down where the interface is failing.

Dave

[Bob Unitt 1Participant @bobunitt1]

Thanks for the help, I don't think it's the cable, as it works OK on Mint 17 on more than one PC (I never got around to trying Mint 19).

[Peter G. ShawParticipant @peterg-shaw75338]

Well now, I am having to backtrack on what I have previously said. Mint 21 seemingly does have a few problems which, to me, appear unsurmountable. But then, in all fairness, I am using a somewhat hybrid setup, but I have not had these problems before. Anyway, I'm having to remove Mint 21 and use Mint 20.3 instead, the major difference being that End of Life for Mint 20.3 is 2025, rather than the 2027 of Mint 21. Oh well, c'est la vie, n'est ce pas?

The problems I have:

Unreadable desktop at times. I like a black desktop with no fancy graphics and use Mint-X or Mate as appropriate. I have done this for a few years now and have found it totally satisfactory. When selected, the icon & the undertext are both highlighted. Using Mint 21, this highlighting is extreme, such that both the icon and the text are obscured.

Loss of data. One of the advantages of modern computers is that of multi-tasking. I use this when copying data either from one hard drive to another, or inbetween computers. Normally, I can then do something else whilst the copying is going on. Under Mint 21, I was doing this when I attempted to delete some files. The system then completely obliterated on both the donor hard drive and the receiving hard drive all those files yet to be copied resulting in a complete loss of some data. Not good at all.

Problems with Wine. In addition to the DOS program mentioned above, which by the way works ok now with DOSEmu2, I also use DesignCad 3D Max v. 17.2 which is a Win 32 bit program. Now ok, this is another ancient program, dating back to 2005 or thereabouts but it works and does what I want, and whilst there is a modern version of the program, it is expensive. But, with Wine it works at about 98%, and the bits that don't work don't matter anyway. So, install Wine, and then DC17. The first time I set this up using Mint 21, it loaded Wine v.6.x.x. The next time, on a separate computer, it loaded Wine 7.x.x. I think I clashed with WineHQ's changeover, but I could not get it to run properly. Dropping back to Mint 20.3, and Wine installs using v. 7.x.x. and all seems ok, within reason!

Now, for historic reasons I also have a number of data files saved in the proprietary formats for both Paint Shop Pro v.7 (PSP) and for Lotus SmartSuite. Last time I tried, I was unable to read any of these files using either The Gimp or Libre Office as appropriate, so I loaded the original programs into Mint 19.3 (yes, not a mistake, 19.3) with the intention of using Wine and thus being able to open these old files. Attempting to do this, under Mint 20.3 or Mint 21 was not good which does rather suggest the problem may lie with Wine 7.x.x. Fortunately, I have now discovered that Libre Office can open the Smartsuite files and as PSP appears to be usable under Wine, then I will be able to convert those data files if necessary.

Apparently, it is possible to use earlier versions of Wine, according to something I came across on the WineHQ site, but it was too late to bother with. And anyway, it does seem that I may not need to bother.

Overall then, although my initial attempts to update to Mint 21 seemed possibly ok, all in all, it's not ok, and therefore I have had to revert to using Mint 20.3. Still, it isn't all bad – I've now got at least a further 2 1/2 years before reaching End of Life. So maybe Silly Old Duffer/Dave has a good point in not automatically upgrading to the newest and latest version of anything.

Cheers

Peter G. Shaw

[Author]

Posts