351–360 of 380 posts
Earlier quoted context omitted.
Basically I'm trying to write a better Linux than Linux and a better QNX than QNX, at least for certain use cases that is. At least initially, my primary focus is on workstation/enthusiast desktops and higher-end embedded systems (some types of servers, especially ones where high security is important, are also a focus as well but maybe not quite as much for now). Pure consumer desktops aren't really much of a priori…
Interesting, but sounds like much more than a lifetime achievement. As far as I understand, it is written in Rust; this raises the question of whether there are significant differences to Redox OS, which seems to share most of the goals. But sel4 on the other hand is written in C; are you going to migrate sel4 to Rust?
Redox has several of what I consider to be questionable design/implementation decisions. I explained a couple of them in a previous comment (the limited filesystem namespace and IPC models and the lack of real-time support). Some other things include the weak implementation of locking (it uses pure spinlocks instead of something like the adaptive queue-based locking that I'm using in the process server), a rather limited heap allocator that doesn't support growing/shrinking the heap or custom object sizes for slabs (the heap allocator I'm using is a derivative of the same one that Redox uses but it's been heavily enhanced with support for shrinking/growing the heap and custom slab sizes), and the rather boilerplatey implementation of some of the libraries (for example fork() is implemented as a library function that copies process context through a filesystem-based API, but rather than having object-oriented wrappers on top of the filesystem for the various state objects that it's manipulating, the fork() implementation directly invokes open(), read(), and write() a lot).
Earlier quoted context omitted.
> and a crucial part of NVIDIA's DriveOS stack fwiw they have been working hard to support linux as a second option, and have been major contributors to Real Time Linux sooooooo
Are there any automakers out there that use real-time Linux for anything at or above ASIL-B?
Earlier quoted context omitted.
Interesting, but sounds like much more than a lifetime achievement. As far as I understand, it is written in Rust; this raises the question of whether there are significant differences to Redox OS, which seems to share most of the goals. But sel4 on the other hand is written in C; are you going to migrate sel4 to Rust?
Like I said, it's not meant to be a "Rust OS" and will incorporate a lot of C code still (and various other languages as well). I doubt that the kernel will ever get completely rewritten in Rust, although eventually some Rust code might get added (once I break up the giant kernel lock I am thinking I'll use the same locking library I'm using in the process server, so that would add some Rust code to the kernel). I do…
Earlier quoted context omitted.
Real time is about worst case time, not average. The classic test for a real time OS is simple. You write a program that waits from an interrupt from an input pin. When the input is raised, there's an interrupt. That activates a user process. The user process turns on an output pin. You hook this up to a signal generator and a scope. Feed in a square wave. See the delay between input and output. If there are outliers…
> If there are outliers, delays much larger than the normal delay, the system is doing real time properly at all. Just to clarify for anyone reading, I think you meant: > If there are outliers, delays much larger than the normal delay, the system is not doing real time properly at all.
Earlier quoted context omitted.
The stock is almost dead. Please just opensource it instead of taking all that to the grave with you. Just do it.
I just looked. BB peaked around US$140 and is now around US$2. Financials are so bad it's amazing the doors are still open.[1] QNX is a great technology, but nobody who acquired it knew what to do with it. [1] https://www.bing.com/entitydetails?q=BB+stock&wt=FinanceGene...
QNX and BeOS were the only operating systems I tried in the early '00s that could make old single-core mid-90s Pentiums feel excellent and snappy to use. Far, far better than any Windows version, or Linux. I assume it's mostly scheduler stuff and much better multimedia stacks, in both cases. I always hoped the operating systems of the future would feel more like that. Closest we've got is probably iOS and it cheats b…
Another data point:
SGI IRIX has an unusually good scheduler. I ran a 30Mhz machine for a while and it's desktop was pretty snappy.
One day, I compiled AMP and fed it a list of .mp3 files, most being 192kbps. The program could decode 256kbps without skipping, just FYI.
Those files were on an NFS share.
When I ran the gr_osview program, CPU was 95 percent utilized, and still the file manager was responsive and that music did not skip.
Frankly, just decoding higher bitrate > 192kbps mp3 files at 30Mhz was impressive.
Doing it with a full X Window system desktop, while playing he files off an NFS share, while remaining responsive speaks to a lean and mean network stack and scheduler that performed even on low spec hardware.
Was IRIX 5.3 FYI. Indigo Elan
A friend and I enjoyed operating systems and ran Be on an old Pentium 90, and like the parent comment says, it was snappy!
Linux also has a part in this:
After a water event, that Pentium 90 was no longer reliable. Used non parity RAM and Windows NT would go slowly senile eventually blue screening over and over.
For funzies, we put Red Hat 5.2 on that box and it ran fine! The syllog had a bunch of entries every second too. Open X console, and just watch them go by...
That box served up the company web page for a coupla weeks just for fun too.
Good times.
If only you could believe them. QNX has been "opened" twice before. Each time, there was a rug pull, and it went closed again. Before the first rug pull, open source groups routinely added QNX to their target list. There was a Firefox for QNX. Eclipse had QNX as a target. GCC and most of the Gnu command line tools could be built for QNX. There was a desktop environment, Photon. I used that as a primary desktop for th…
> Now, if QNX is serious about this, the way to go is to use the licensing model Epic uses for Unreal Engine. Unreal Engine is behind most AAA game titles. The basic terms are that you can download the source and use it for anything you want, and there's no charge until you get the first $1 million in revenue from your product. Then Epic takes a 5% royalty.[2] This has been extremely successful for Epic. There's not…
Earlier quoted context omitted.
>QNX went open source. Not open source. Those words have a specific definition[0], which QNX never met. 0. https://opensource.org/osd
Things don't become true just from being written down on the Internet. Open source means that the source code is open for the public to see, and that's it.
> Things don't become true just from being written down on the Internet
That's not what they were saying.
People who care about open source software use the OSI's definition. You can't reason about the open source movement if you use a fundamentally nonstandard understanding of the term, such as the one you are proposing. You wouldn't be able to make sense of a blog post like this, for instance. [1][2]
> Open source means that the source code is open for the public to see, and that's it.
The open source movement disagrees. Are we expected to accept your definition just because it's written down on the Internet?
[0] https://news.ycombinator.com/item?id=31203209
[1] https://drewdevault.com/2024/07/16/2024-07-16-So-you-want-to...
Earlier quoted context omitted.
You would use it if you wanted to get a job doing RTOS dev and wanted to show you had some skin in the game.
I don't think that "skin in the game" means what you think it means.