What you need to know about the real-time capable edition of Ubuntu 22.04

Canonical has made a Real-time edition of Ubuntu 22.04 available on x86 and Arm… but only to Ubuntu Pro customers, and there are some potential issues you should know about. The new real-time edition was announced on Valentine's Day [insert joke about loving a more responsive computer here]. The beta version appeared last year …

[Plest]

"What you need to know about the real-time capable edition of Ubuntu 22.04"

I know I don't need Canonical any more! Not after the "let's put ads in the command line tools" debacle right now. It's their O/S and they're welcome to whatever the heck makes them happy, just don't be surprised if people decide to migrate off to someone else's distro.

[Mike 137]

The key question maybe?

How real is "real time"? We need some objective criterion (or more probably a set of objective criteria for defined use caes).

[petef]

Re: The key question maybe?

Real time does not mean that it responds quickly but that the time is deterministic. The OS provides guarantees that an event will be processed before a time limit is reached.

It is not something that you would want in a general purpose desktop.

[FatGerman]

Re: The key question maybe?

It is something you want if you're doing serious audio work, especially with virtual instruments. Linux 2.6 with the RT patches + JACK is still the best system I've ever used for that purpose. The "lowlatency" kernel was no better than the standard one. Agree about having to carefully tune it though, I used to build my own. Not sure I could be bothered with all that any more.

[bazza]

Re: The key question maybe?

I've had good success with 2.6 + PREEMPT_RT for embedded signal processing applications. It's not hard real time like VxWorks or INTEGRITY is, but it's pretty tractable for the applications I had.

Kernelshark is pretty useful; before that came into being, someone wrote a tool to convert FTRACE logs to the file format used by some FPGA debugger (a software logic analyser).

[Mike 137]

Re: The key question maybe?

"The OS provides guarantees that an event will be processed before a time limit is reached"

Exactly. But what we need is some objective OS-independent standards against which to compare the real time offerings. However that could be hard to achieve. I've done quite a bit of experimentation in getting Java to operate real time, albeit within quite loose criteria (c. 50 milliseconds), and the biggest problem has been consistency when transferring between different hardware rather than variability on any given platform.

[John H Woods]

Re: The key question maybe?

It's the guarantee that's key, not the limit.

The fast system you developed is not "real time" because it's not deterministic (hmm, is any Garbage Collecting system deterministic?)

We don't need "OS-independent standards" because Operating Systems are either Real Time or not, and no matter how fast things go in the latter case it never qualifies as the former.

[Yet Another Anonymous coward]

Re: The key question maybe?

>We don't need "OS-independent standards" because Operating Systems are either Real Time or not, and no matter how fast things go

So a system which guarantees that the garbage collection will complete by the end of the quarter is by defn. Hard Real Time

[that one in the corner]

Re: The key question maybe?

> So a system which guarantees that the garbage collection will complete by the end of the quarter is by defn. Hard Real Time

Yes.

The only question then is whether that time guarantee is workable in your specific use-case.

RT in a Nutshell.

Ok, "by next quarter" is out at the far end of what most people consider is RT, but as we've had RT systems since the early days of computer-control and clock speeds have increased quite a bit (Hard RT - whatever that means, it is really only RT or not-RT - on a CPU clocked at 200kHz is quite reasonable) the range of response times is pretty wide. Again, so long as it meets your needs.

Another daft one: How about a long-orbit probe that needs a precise boost re-calculated by its onboard systems every time it reaches apogee - so, once every few Earth years (one of its own years). No need to rush and do it all in the last few seconds if it can done slowly as the months go by, just so long as you can guarantee that it will be ready in time or the poor thing will go flying off who knows where: that is a pretty hard-as-rock RT requirement.

[bazza]

Re: The key question maybe?

We do have an objective, OS-independent standard against with to compare real time offerings.

It's called the S.I. second.

If we measure OS latency as fractions of an agreed unit of time, we can compare different OSes!

[Altrux]

LTS

Just a note to add that 5.15 LTS has now been extended to Oct 2026, with 5.10 and 6.1 also running to late 2026.

[Neil 44]

Nothing new in "Real Time" Unix...

... Massachusetts Computer Corporation (Masscomp) (later merged with Concurrent Computer Corp) had it in the early 1980s on 68k hardware.... ("RTU" - which was a System V derivative)

[martinusher]

Re: Nothing new in "Real Time" Unix...

Its been a kernel build option for some time. Its been a few years since I had to build/port a Linux for some hardware that included the RT option but it was just one of several scheduling algorithms you could choose from.

For a lightly loaded system --- which *should* be the typical user (If it wasn't for all the damn popups and other crap that materializes in a typical web browser these days) -- you won't notice the difference between it and the regular scheduling algorithm. The goal for this particular build was supporting CAN, a type of networking that sits awkwardly on Linux at the best of times.

[An_Old_Dog]

"But it's one louder."

There are gonna be people who install this on their desktop systems because they think it's cool.

They also have amplifiers whose volume controls go to "11."

[Ideasource]

I can see appeal for desktop users.

Better intuition into systems behavior lending to easier troubleshooting.

I've lost count how many issues I've discovered and fixed due to response timing seeming off.

It stands to reason that more reliable timing would lend to more reliable intuition.

[Filippo]

Desktop is a poor use case for RT. The timing guarantee generally comes with a performance trade-off; the system would probably feel slower in practice. And getting RT to work properly with multiple concurrent applications is very difficult; chances are some process would starve the others, making the whole thing even slower. And there's no clear benefit for a RT GUI anyway.

RT's use cases are industrial automation, signal processing, and other things where you have exactly one job that must be done within the next millisecond, getting priority over cache flushes, GC, other processes, and so on. GUIs really don't need that; a well-designed GUI plays nice with the rest of the environment and degrades as gracefully as possible when the system is overloaded; it doesn't block everything else.

[bazza]

I have previously run Linux as a desktop, with an RT kernel. It was interesting to see the effect.

You're right, in that in some ways the "performance" did feel slower, but of course the reason why is that user facing tasks (e.g. scroll that window) would get less of a look-in on CPU time than something else running at a higher priority but has no obvious visible consequences.

Car Infotainment

What's interesting is to see the impact of a real time OS on single-purpose GUI systems, specifically car infotainment systems. I'm not sure about now, but certainly only a very few years ago the systems that were praised for being smooth, glitch free graphics were the ones based on QNX. If the GUI is the most important task in the process list, it's never going to glitch. I suspect that Linux / Android based systems are catching up, mostly likely through a preponderance of CPU / GPU performance...

BlackBerry did / still do an excellent job with QNX and its graphics libraries for slick, touch-enabled applications. All of this was in BB10 OS for their smartphones, which were slick to use but sadly bereft of application support. Not the first time history is littered with the dead corpse of something technologically superior, but unwanted...

I have done GUIs using X servers running on VxWorks (perhaps the hardest of bastard-hard-real-time OSes). Real time X is, well, entertaining! Actually, this was rather good. The pipe connection between application core and graphics meant that the core wasn't left hanging around for some graphics engine to get on with it; the pipe acts as a buffer. Not quite so easy with other ways of doing graphics.

Japan Rail

I have seen other examples of real time GUIs. The terminals used in Japan Rail ticket offices are a custom design; a combination of buttons and a nice touch screen, keyboard for in-case.

You have to go into one of these offices and set them a challenge (like, sell you a ticket for the train that's arriving at that very moment and will depart in the next 30 seconds). I'm pretty sure that the staff are trained specifically in the use of these terminals and have to sit speed test. What I've noticed is that, to process your booking request, it involves a combination of button presses, and presses on soft-buttons that are shown on the touch screen. The soft buttons on the touch screen will vary depending on the nature of your booking. And, if harried for time, these people are really, really fast.

What's interesting is that, to support such rapid use of the terminal to make a booking, the software generating the display for the soft buttons that are appearing on the screen has to do it fast enough, because when their thumb is heading downwards towards a soft button they know is going to be there, the button has got to be "ready" to press otherwise it's going to all go wrong. By my reckoning, watching an expert book a complex 3-train journey with reserved seating in a matter of seconds, there are astonishingly few 10s of milliseconds for the database query to be generated, submitted, processed, results returned, display geneated, soft button "created" ready to be pressed, and doing this a lot during the entire booking procedure. And, this is happening nationwide, all day, seemingly without fail.

The whole combination of staff training, terminal design, network infrastructure, database back end being fast enough to work that quickly disguises a very, very deep truth about selling train tickets. If you can sell them quicker, you can sell more of them. And, so far as I can see, betrayed by the reality of the technology they must have in place to make happen what you can see happen with your own eyes, JR has taken that very great extremes; they really get it, and have invested heavily in it.

So, whenever I have the souless experience of buying a train ticket here in the UK; well, it's enough to make one weep, even before they announce the cancellation of your service just after you've paid for it.

[FIA]

To any UI designers out there, heed this story.

The first company I worked for had a text based system in their branches, which I was very sneery about as a young upstart; until you see someone who knows how the system works actually use it. It's exactly as described as above, muscle memory takes over, popups are answered as they're being drawn, forms are submitted almost as soon as they appear. Because if you can get (the very complex) 'paperwork' done quicker you can sell more.

This later extended to our web system, we mandated the use of Firefox in our call center as you can type whole words to select items in dropdowns, vs IE at the time which would just jump to the first item starting with the letter you last pressed. This speedup had a measurable impact on the number of customers a given agent could process in an hour.

If you watch someone trained in a system using a system and there's a hovering finger then you're too slow. ;) (Supermarket self service tills... I'm looking at you...)

[nintendoeats]

I work on a 3D graphics system in my day job, but not something like a game which has to work as fast as possible. What I tend to say is that we need to meet "interative" timing requirements. So if there is a hitch every now and again it's ok, but it can't be too long or a regular thing.

Then this goes out the window when somebody complains that it's slow because they are trying to show a correctly dept-sorted semi-transparent object with 500k vertices on an iGPU.

[waldo kitty]

nintendoeats wrote: [...] they are trying to show a correctly dept-sorted semi-transparent object with 500k vertices on an iGPU.

O.U.C.H.!

i'm guessing someone finally/eventually takes them and their project to a properly GPU-equipped system... maybe even explaining or at least attempting to explain the difference between their iGPU and something that actually does the job they want/need done...

[nintendoeats]

I try, they just get angry.

"But I can play games on an iGPU!"

The brain withers.

[DrXym]

Real time processes can hog the CPU so they're almost orthogonal to a desktop where you want all of it to be reasonably responsive. I suppose there might be situations where you have a visual application, e.g. an oscilloscope, where real time might make sense. But you probably want the application owning the whole display rather than being a client of a desktop with many other clients in contention for the same resources.

[Filippo]

You could do that on a RT system, having an oscilloscope in a window that works well; you wouldn't even need for it to own the display. It would, however, come at the expense of everything else. Which, if what you want is specifically for the oscilloscope to work, can be exactly what you want.

I was probably too generic when I said that GUIs shouldn't be RT, and the other poster above provided a couple more excellent examples, but what I meant was when I said that "desktop" is a poor use case for RT. You really don't want your word processor, web browser and email client, not to mention the window manager itself, to aggressively fight each other for the CPU as they each declare to the OS that they absolutely need to respond to clicks within 10 msec. It just won't work.

[ske1fr]

No thanks

I already turned off that nagging Ubuntu Pro shilling (thanks for the heads-up Liam), I'll stick with Ubuntu Studio. It works. Ok, the Nouveau drivers that last about twenty minutes before crashing the box should be taken round the back of the bitbarn and inhumed, but once you find the right Nvidia drivers (in my case) it's fun, I'm learning a lot with it. I think I tried the low-latency kernel option, it went clang and died, so not so low-latency...

[Tomato42]

Re: No thanks

that sounds like a PEBKAC issue, if you planned running real OS on the system you shouldn't have picked an nVidia GPU...

[Ace2]

Re: No thanks

+1 for “inhumed”

[DaemonProcess]

capacity and scheduling

A lot of my problems with this in the past have been around either bad software, interrupts, poor configuration or general capacity.

I used to use processor affinity to bind cores to network or serial cards interrupt servicing, making sure I left free cores for other tasks. I outsmarted myself a couple of times with that but it did work with heavy NFS.

Thankfully eventually the kernel got better than me and the speed and number of the cores meant I really didn't need task sets any more.

My USB music recording has never been perfect even with Ubuntu studio low latency. At least Ubuntu got Jack working which is more than I ever managed from source.

Thanks for the heads-up about Nvidia chips.

[StrangerHereMyself]

Mainline

I personally believe it's important to merge PREEMPT_RT into the Mainline kernel since it will force more software to use the new scheduling algorithm.

The Real Time scheduling will shine on a highly loaded machine where critical software (like video encoding or decoding) will keep pace even though the processor is maxing out. Imagine a small IoT device with only very limited processor capacity still being able to respond in a timely fashion when the load strains its resources.

The next thing I'm looking forward to is the CHERI Capability Based Extensions for bullet-proof security. This will make hacking a computer all but impossible and will certainly worry LEA.

[Ken Hagan]

Re: Mainline

Except that your RT kernel won't make your hardware faster and won't re-write the software that does the video en/de-coding. OTOH, your existing kernel is already designed to do the best it can when faced with more work than it can do and no telepathy device to know which you want the most.

(Actually, it sounds like you want the system you had 10 years ago running on the hardware you have today. I bet that would run like shit off a shovel.)

[bazza]

Re: Mainline

It's not quite that bad. There are CLI tools to set the priority of processes, even if the process itself doesn't bother doing so. So, one can run an existing piece of software at a real time priority even if it was never intended to be that. The software might not benefit from that, except that it'll be a higher-up dog when it comes to priority calls on resources.

Resolving priority inversions (something PREEMPT_RT does) has interesting consequences too, if one starts setting process priorities higher than, say, that of the kernel thread running a network interface. It usefully helps minimise the latency in accessing serialising shared resources (such as a network connection), without blocking other use of it.

PREEMPT_RT on the desktop felt slower, last time I tried it (a long time ago). I'm sure this is because there's a lot more context switching going on. That's kinda the point, to context switch ASAP when conditions permit, rather than delaying context switching in the interests of getting more work done. It also doesn't help that, out of the box, the desktop session is just another ordinary priority process, so it's going to come off second best. Of course, if one fiddled with the priority of the desktop session, it'd feel very nice and very spritely indeed!

[StrangerHereMyself]

Re: Mainline

WinTel PC's are grossly overdimensioned in terms of CPU to keep audio and video working smoothly when the load increases. This isn't needed with a Real Time schedulling OS and programs that make use of the Real Time capabilities.

[89724102172714182892114I7551670349743096734346773478647892349863592355648544996312855148587659264921]

@Liam Proven

Ubuntu? Sadly not for my VAIO P. BTW Haiku wouldn't install! antiX is a lot faster than 32-bit Mint on my newly upgraded with SSD Sony VAIO P - the SSD (240gb Integral mSATA) upgrade went painfully: One screw was almost completely stuck - galvanic corrosion probably, and the plastics are old and very delicate, therefore I broke a tiny tab (inconsquential, near the battery, which I could repair by filing, cutting and sanding an impossibly small shape to fit using superglue + very fine baking soda, but who has the time?), then discovered that the ZIF cable was completely stuck in the drive's ZIF connector clasp (after removing umpteen tiny screws to get at the tiny 1.8 inch hard drive [kept dropping the screws on the busy floor... best to keep a neodymium magnet handy, to seek out those screws which are actually magnetic, or better still don't drop them on the floor in the first place. I'm deffo not cut out to be a surgeon - it's worrying that there are two screws left over after reassembly. I don't think they're fatal omissions, will try again to determine their exact original function]), and because the design of the unit is fanless, over the years heat had baked the ZIF hard drive connector clasp very brittle, and that broke too - I may still attempt to save Sony's original cut-down Vista build via drive cloning, after pressing a ZIF cable against the connector using two plectrums either side of the hard drive and tiny cable, using a small G-clamp... One thing to be aware of, is that the old version ZIF cables are thinner, therefore you must apply a layer of heat-resistant Kapton tape on the non-conducting side of the Sony ZIF cable connector, to make Sony's old and proprietary ZIF cable thick enough for the new ZIF to mSATA converter's ZIF cable's clamp to operate, otherwise no drive will be detected. Connector secured... after trying and failing installing every Windows 7 version old and new (I have licenses for both 7 Home Premium and Pro - all versions could partition, but screen-freeze crashed on or before the commencement of formatting. I have no idea why this was. Aside from boot order, there are no hard drive options in Sony's tiny BIOS), and failing miserably to install TinyXP... Easy2USB saved my bacon! The full version of Windows XP Professional booted within 10 seconds! But no WiFi (drivers) and no sound - you (sometimes, depending on model) only retain sound if you downgrade from the original version of Vista from Sony, the recovery partition of which is on the now damaged ZIF drive. So I thought I'd try the full fat version of the OS it originally shipped with: Windows Vista Business, and that also works! I have no idea if it'll activate yet, used the serial provided in the battery compartment. Vista takes three times as long as XP Pro's sub-10 seconds to load. I have no idea how long Vista originally took to boot up when the Sony had a hard drive, because I bought it post Windows 7 upgrade. Instant-on boots within 10 seconds, for all the good that does - it's far less useful than XP Pro, and I'm in the process of installing all the Vista drivers, so that I can upgrade it to Windows 7... but if I can't and Vista is slow (so far so good on that front: snappy in operation), a dual boot of antiX and XP Pro could do for some of my on-the-go tiny computing needs, plus a Win10 on a USB stick for newer/alternative browser functionality? There must exist a lighter Linux than antiX, which has WiFi, Firefox, LibreOffice and sound for my VAIO P! If Windows 7 Home Premium (after upgrading) is no slower than Vista (which looks speedy in use thanks to the SSD, considering the puny Atom CPU, on a big monitor via the Sony port replicator, which also has ethernet. But as before, Youtube will barely play audio [stutters sound and video]), that may be a keeper, or antiX + Win 7, dual boot... or XP Pro + Win 7 dual boot with antiX USB permanently optioned by one of it's two USB ports, via a tiny Verbatim USB thumb drive. I may attempt a tri-boot. Now I'm waiting for double sided heat-resitant sticky foam tape to arrive, so that I can secure the mSATA converter, to enable use of my Sony VAIO P on the road again. I'd used some other sort of sticky pad, which is making for a messy removal - careful application of isopropyl alcohol will dissolve the adhesive, ready for the proper stuff. The error messages were too tiny to read on the 8 inch 1600 X 768 screen, and this entire process was a blur. It it hadn't worked, I would have sourced another slim-profile ZIF drive, or used one of it's two USB ports for a Live OS and the other for storage, in addition to it's integral SD card and Sony memory card readers... but that would gave been slow. I do wish Sony would make new netbooks in a similar size or smaller, they clearly know a thing or two about attractive and functional design, hampered in this case by the puny Atom CPU. Pity about Haiku - if you get it running on your VAIO P, please do detail your solution somewhere.

[Liam Proven]

Wow... that is quite a saga.

I think I will leave mine's hard disk in place for now, then!

There is a higher-end Vaio P with a trackpad next to the screen. I think it came with an SSD. Maybe I'll try to find one of them if I find a modernish OS that's usable on it.

I had no problems booting Win7 on mine, but I did need to update its BIOS. That is worth checking. I put Windows Thin PC on it, but it's sluggish.

For XP, I suggest TinyXP from the Internet Archive.

[89724102172714182892114I7551670349743096734346773478647892349863592355648544996312855148587659264921]

@liam Provem

> Wow... that is quite a saga.

>> And it isn't over yet! Bashing one's own head against a brick wall: it's nice when it stops.

__

> For XP, I suggest TinyXP from the Internet Archive.

>> Tried: I should have used Easy2Boot to insall that, but it failed because of a driver/first post-install-boot CD seek issue, which Easy2Boot has a two stage XP installation mitigation for - I cannot believe how fast Windows XP Pro boots and flies! It now only takes 28 seconds to get from the BIOS password screen to Windows 7 Professional's (see install method below) chirp upon full successful boot, and it's snappy in use. Quite honestly I'm delighted. XP Pro will be my go to quick access OS, because it supports my ancient but good software for getting on with writing my memoirs about my oh so very interesting life, and making horrible noises.

__

> There is a higher-end Vaio P with a trackpad next to the screen. I think it came with an SSD. Maybe I'll try to find one of them if I find a modernish OS that's usable on it.

I had no problems booting Win7 on mine, but I did need to update its BIOS. That is worth checking. I put Windows Thin PC on it, but it's sluggish.

>> A small update... circumvented the mysterious Windows 7 Professional driver issue which prevented installation, by starting the install on a desktop PC, then putting the mSATA back into the Sony VAIO P to finish the installation (The same install method should shoehorn in Windows 10, but judgingby what I've seen on Youtube, it isn't worth it). Now that I have Gparted resized (tried some windows based tool call Partition Wizard minitool - it corrupted the disk) and installed a dual booting XP + Win7Pro, I'm auditioning for a decent but light 32 bit Linux (already had a tri boot XP + Vista + Mint working), for the latest Firefox releases going forward, which will come in handy for those occasional websites (and routers) I encounter on the road, which are not usable because the developers haven't programmed a decent desktop mode for Android. AntiX seems a tad time consuming to harden... trying 32-Bit Zorin Lite right now. Most Linuxii seem easy to remove from dual or multi-boots.

Also my previous post should read Easy2Boot, not Easy2USB - it's XML file for Window Vista Business should be bypassed.

__

> I think I will leave mine's hard disk in place for now, then!

You too should experience the seemingly unending hell of SSD upgrade of VAIO P via mSATA to ZIF converter! It's almost over now, thank fsck! And it seems well worth the effort. I've just finished scrubbing off the cheap and nasty Poundland sticky pad I used to secure the ZIF converter, ready for the heat resistant version which arrived today, to secure it properly. Just need to be certain of a perfect setup with a usable and useful 32-bit Linux first. I hope the isopropyl hasn't dissolved/weakened the rubber covering one of the hard drive shock sensors (small bubble, looks like alcohol may have deflated it, as it does most things lol), which one of the cheap and nasty pads had stuck to (!). Full fat Linux Mint did run, sluggshly - best to install Linux after singular or dual Windows, otherwise Windows 7 replaces the boot loader (but there's EasyBCD to correct that).

There's a video on YT which goes through the whole SSD upgrade (hardware) process, but leaves out the necessity of having heat-resistant Kapton tape at hand.

Zorin was glacial too, it has to be AntiX - it even plays the video on YT detailing how a badger broke my wrist cycling (the badger wasn't cycling, and my wrist wasn't cycling alone), which is the main benchmark I'm judging Linuxii by. Stuttery playback, but sound is continuous in Firefox ESR - it all goes t*tsup with the latest version: zero sonicry, barely 1 or 2 fps. AntiX takes about 49 seconds to fully boot, and it's comparatively snappy in operation, much more responsive than Mint and Zorin - in fact if I didn't need certain Windows apps, it'd do. I'll have to read up on hardening AntiX... but currently it's dual booting with Windows 7 Pro, and I'm about to wipe the disk and start again for the final time, for the tri-boot with XP. Then I can still work on holiday, after I tape the SSD secure and screw it all back together again, if I can find homes for all of them. I knew upgrading that cr*p hard drive would be a freaking nightmare...

Well worth upgrading IMHO. The SSD might even make a VAIO P Hackintosh viable? I'm going to buy another Sony VAIO P, plus the VAIO UX.

[89724102172714182892114I7551670349743096734346773478647892349863592355648544996312855148587659264921]

@Lian Proven

> There is a higher-end Vaio P with a trackpad next to the screen. I think it came with an SSD. Maybe I'll try to find one of them if I find a modernish OS that's usable on it.

Mine is a vgn-p19wn with 2GB RAM. Those early SSDs were relatively slow - check out YT videos displaying tests. I've tested the Integral 240gb mSATA I've installed using Crystaldiskmark on Win 7 Pro:

SEQ1M Q8T1 READ 99.82mb/s

SEQ1M Q8T1 WRITE 48.55mb/s

SEQ1M Q1T1 READ 96.06mb/s

SEQ1M Q1T1 WRITE 46.77mb/s

RND4K Q32T1 READ 23.08mb/s

RND4K Q32T1 WRITE 32.87mb/s

RND4K Q1T1 READ 14.04mb/s

RND4K Q1T1 WRITE 16.99mb/s

[89724102172714182892114I7551670349743096734346773478647892349863592355648544996312855148587659264921]

@Liam Proven

I can't upload photos here, and it's hard to keep track of replies because I can't check often, and because there is no reply alert system on The Reg (unless they're in my spam folde?)... so for reference I've uploaded some photos on the UK's top ebike forum, where I can try to help if you encounter difficulties while upgrading your Sony VAIO:

https://www.pedelecs.co.uk/forum/threads/dan-walker-warns-cyclists-after-bike-crash-the-helmet-i-was-wearing-saved-my-life.44849/page-2#post-673627

[89724102172714182892114I7551670349743096734346773478647892349863592355648544996312855148587659264921]

@Liam Proven

I was unhappy about AntiX's inability to play the video in Firefox 109, of a badger breaking my wrist, which required a big titanium implant and bunch of screws repair, which the hospital now refuse to remove. Tried Puppy ssl :( , Linux Mint, AntiX, PsychOS - but MX actually managed this feat, just about! So now I've got to Gparted the mSATA again, to shorhorn it in. Magnus screen magnifier comes in handy, otherwise it's all too tiny for my eyes to see these days (Windows has it's own - unsure if the magnify function key on the VAIO P did just that, or activated something else? I haven't found a Vista or Win 7 program for that Sony function key [as yet]... BTW if you want the Alps tap nipplemouse to click function: install that from the Vista driver and software installation set). MX, like antiX and Mint, found the second display via the VIA port replicator. It's quite alarming how my eyesight has gone so wonky over the past decade (maybe my left wrist breaking will slow it's decline lol). In addition to the 240gb mSATA, I can add 2 X 64gb USB thumb drives, plus 64gb via the VIA's integrated SD card reader, plus another 32gb via the VIA's Sony DUO via a dual SD to DUO converter, for my documents and other files.