* Posts by elahav

5 publicly visible posts • joined 6 Jan 2021

QNX 8 goes freeware – for non-commercial use

elahav

Re: Intriguing.

Separation does not require a hypervisor. On Windows. Linux. *BSDs, QNX (and a few other systems) each process executes in its own virtual address space, spatially isolated from other processes. The kernel runs in a different privilege mode than user code, and is not accessible other than through a gated interface. That is not true for most of the RTOSs out there.

Additionally, on QNX, minix, helenOS and other micro-kernel OSs, the isolation extends to various system services, such as the file system, network stack, graphics drivers, etc., each of which runs as a user-mode process in its isolated virtual address space.

elahav

Re: Intriguing.

There is a lot of confusion that stems from the term RTOS being applied to very different systems. FreeRTOS, RT-Thread, NuttX etc. are not interchangeable with QNX. The former are light-weight thread execution environments with little or no separation between kernel and user, no process model, virtual memory, etc. On the other hand, they run on small MCUs where QNX doesn't.

The comparison with Linux boils down to whether or not you buy the argument that a micro-kernel OS provides safety and security advantages over a monolithic one, and that those advantages offset the micro-kernel overhead.

Nasty regreSSHion bug in OpenSSH puts roughly 700K Linux boxes at risk

elahav

Signal Handlers

So Linux is also insecure by design? ;-)

The real issue here is that, what is supposed to be the epitome of secure code, makes a rookie mistake in using signal handlers. Not only that, it ends up calling a non-async-signal-safe function buried under layers of indirection, making any future updates susceptible to repeating the same mistake.

Signal handlers should be avoided if possible. If not possible, the most the signal handler should do is set some global variable and then let the main context do the heavy lifting. Keeping track of which library functions are async-signal-safe on every C library implementation is doomed to failure.

Open-source contributors say they'll pull out of Qt as LTS release goes commercial-only

elahav

Re: Bait And Switch ?

> The Qt owners want a PERCENTAGE OF REVENUE and you must negotiate it with them.

That is a killer, I agree.

> MSFT is laughing all the way to the bank.

I'm not sure about that. MS has pretty much abandoned the market segments where I expect Qt is making most of its money (embedded, automotive). I can't think of any contender to Qt in these areas. HTML5, perhaps, but that means that you need a modern browser on your device, and that comes with its own set of problems.

elahav

Qt is not a community project

Long time reader, first time poster. I just couldn't resist given the negativity.

There seems to be a very basic misunderstanding expressed in many of the comments above. While Qt is open source (for some definition of open source) it has never been a community project. Almost all work on Qt over the years has been done by paid engineers working for whichever company happened to own Qt at the time. Many people have made contributions to it (myself included), but that does not make Qt the result of a joint effort of volunteers, who are now being cheated by a big, bad, greedy corporation.

If you don't believe me take a look at the commit log for any of the major source files in the Qt code base.

I regret this step by Qt (I have used it since 1998), but I understand it. It is not easy to survive as a software company these days (assuming you don't have an ad-revenue-generating model).