From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21336 invoked from network); 9 Feb 2021 05:10:48 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 9 Feb 2021 05:10:48 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id A361F9C79F; Tue, 9 Feb 2021 15:10:45 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id CD0BD9BA43; Tue, 9 Feb 2021 15:10:10 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="gCDbMvhm"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 68DC79BA43; Tue, 9 Feb 2021 15:10:08 +1000 (AEST) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) by minnie.tuhs.org (Postfix) with ESMTPS id 821699BA42 for ; Tue, 9 Feb 2021 15:10:07 +1000 (AEST) Received: by mail-io1-f52.google.com with SMTP id m17so6983288ioy.4 for ; Mon, 08 Feb 2021 21:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=NhP9UM/gg/9cFNT0FdLkY4BGNlA4Di8F76hE1cltmBI=; b=gCDbMvhmBTR7zyU/W/IWbeP/uRTHSwoSL/ewCt15M+wW1yOrXSUj77YfS2OzGXksBY oTym2XvrpcBHhTDUfsYNiaLxLNXWkfFlODL02mJwH8jvpSDp/SrW54AELxocIIlQt6nz sCb3TgfBn3vtWwvuAIoFOpHifW9/LnY5iAXUdZq5aciQWD0h+dNRx7CIdbIiBMPgcDjW CLuaWKbG1OcQlKdZLH9ueAL7vcyYNfpmorzn1GG7nlA+Fb8WzkEPmCscChMGo0Eg4737 h5vrbdj34eZwlBkuiV6STkjFWLp5blwLy3k+8Hv0Y5cgf8FF/q8ULiK73MwS/Nypf8FJ rZHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=NhP9UM/gg/9cFNT0FdLkY4BGNlA4Di8F76hE1cltmBI=; b=jd6i+lxoF8JhVAO9qVEKFfvOvI2mRH43EX2KT/O1HOw0oH6Iiypv9h8TWT8wovsPXQ seDWSi3wA52vFxXsswRd5syQYgQf/23xqofm5DWDYBvqxkHfLov1E36zpv7KSVXhRzmG wRQy6ZhOCyu+/h5MZLKYcAZ1R3z8HfsNHYiMimKgGvtxJbnYI5hkB72HU0wifxcMaG2H 49K555GlsdUpykKRMHMTz/i9xcBO8njniqiIHgVcNAt0zYUcXqac/U8F6WtzzP4Rh7eC uCgWDqKAlFmDfY1wbE13UdDALhP1aQ6u0NMAGHVifHVKLY7J8sHXGrSN66lOR4W6bWDI 4ssQ== X-Gm-Message-State: AOAM533AwQ97UxSZbTtzofUiK7yYpzKg3z9d3BFAdHHzlkiPTUesRGw/ /X/mMQILamV4CMIsd53pHgbIolUTU1uZ5xuF9Va3hxWF X-Google-Smtp-Source: ABdhPJyVu+XOtBlJwrE5hr8Hr2IhGnzDPeNLoiWTEZY48Ni6hUKo1lUj0xIJx+BMVxzgAaU0gQz/ItC7zafGXP7lxck= X-Received: by 2002:a6b:8b81:: with SMTP id n123mr17084145iod.3.1612847406340; Mon, 08 Feb 2021 21:10:06 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ad5:48a1:0:0:0:0:0 with HTTP; Mon, 8 Feb 2021 21:10:05 -0800 (PST) In-Reply-To: References: From: Andrew Warkentin Date: Mon, 8 Feb 2021 22:10:05 -0700 Message-ID: To: TUHS main list Content-Type: text/plain; charset="UTF-8" Subject: Re: [TUHS] Macs and future unix derivatives X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 2/8/21, Will Senn wrote: > > My thought for the day and question for the group is... It seems that > the options for a free operating system (free as in freedom) are > becoming ever more limited - Microsoft, this week, announced that their > Edge update will remove Edge Legacy and IE while doing the update - > nuts; Mac's desktop is turning into IOS - ew, ick; and Linux is wild > west meets dictatorship and major corporations are moving in to set > their direction (Microsoft, Oracle, IBM, etc.). FreeBSD we've beat to > death over the last couple of weeks, so I'll leave it out of the mix for > now. What in our unix past speaks to the current circumstance and what > do those of you who lived those events see as possibilities for the next > revolution - and, will unix be part of it? > Yes, those are almost exactly my thoughts on the current state of OSes. I'm hoping that I can change it by writing my own OS , because I don't see anyone else making anything that I consider to be a particularly good effort to solve those issues. However, it's still anyone's guess as to whether I will succeed. I'm trying to give it every chance of success that I can though by using existing code wherever possible and focusing on compatibility with Linux (or at least I will be once I get to that point). BTW, I welcome any contributions to UX/RT. I currently am still only working on the allocation subsystem (it's a bit trickier under seL4 than it would be on bare metal due to having to manage capabilities as well as memory), but I think I am pretty close to being able to move on. > > And a bonus question, why, oh why, can't we have a contained kernel that > provides minimal functionality (dare I say microkernel), that is > securable, and layers above it that other stuff (everything else) can > run on with auditing and suchlike for traceability? > A lot of people still seem to believe that microkernels are inherently slow, even though fast microkernels (specifically QNX) predate the slow ones by several years. Also, it seems as if much of the academic microkernel community thinks that there's a need to abandon Unix-like architecture entirely and relegate Unix programs to some kind of "penalty box" compatibility layer, but I don't see any reason why that is the case. Certainly there are a lot of old Unix features that could be either reimplemented in terms of something more modern or just dropped entirely where doing so wouldn't break compatibility, but I still think it's possible to write a modern microkernel-native Unix-like OS that does most of what the various proposed or existing incompatible OSes do. > > I can answer the microkernel question I think. It's discipline. > The only microkernel I ever liked was QNX and I liked it because it was > a MICROkernel. The entire kernel easily fit in a 4K instruction cache. > > The only way that worked was discipline. There were 3 guys who could > touch the kernel, one of them, Dan Hildebrandt, was sort of a friend > of mine, we could, and did, have conversations about the benefits of a > monokernel vs a microkernel. He agreed with me that QNX only worked > because those 3 guys were really careful about what went into the > kernel. There was none of this "Oh, I measured performance and it is > only 1.5% slower now" nonsense, that's death by a hundred paper cuts. > Instead, every change came with before and after cache miss counts > under a benchmark. Stuff that increased the cache misses was heavily > frowned upon. > > Most teams don't have that sort of discipline. They say they do, > they think they do, but when marketing says we have to do $WHATEVER, > it goes in. > I still don't get why QNX hasn't had more influence on anything else even though it's been fairly successful commercially. If i am successful, UX/RT will only be the second usable non-QNX OS with significant QNX influence that I am aware of (after VSTa; there have been a couple other attempts at free QNX-like systems that I am aware of but they haven't really produced anything that could be considered complete). seL4 is fairly similar to QNX's kernel both in terms of architecture and design philosophy. That's why I'm using it in UX/RT. I may end up having to fork it at some point, but I am still going to keep to a strict policy of not adding something to the kernel unless there is no other way to reasonably implement it. For the sake of extensibility and security I'm also going to have a strict policy against adding non-file-based primitives of any kind, which is something that QNX hasn't done (no other OS has AFAICT, not even Plan 9, since it has anonymous memory, whereas UX/RT will use memory-mapped files in a tmpfs instead). On 2/8/21, Dan Stromberg wrote: > > But I also have high hopes for Redox OS, and may switch someday: > https://en.wikipedia.org/wiki/Redox_(operating_system) > https://www.theregister.com/2019/11/29/after_four_years_rusty_os_nearly_selfhosting/ > The biggest problem I see with Redox is that they insist on writing everything from scratch, whereas with UX/RT I am going to use existing code wherever it is reasonable (this includes using the LKL project to get access to basically the full range of Linux device drivers, filesystems, and network protocols). Also, their VFS architecture is a bit questionable IMO. Otherwise I might have been inclined to just contribute to Redox (UX/RT will use quite a bit of Rust, but it won't try to be a "Rust OS" like Redox is). I may end up incorporating more code from Redox though (I'm already going to use their heap allocator but will enhance it with dynamic resizing of the heap). In addition they claim it to be a microkernel when it is actually a Plan 9-style hybrid, since the kernel includes a bunch of Unix system calls as primitives, disqualifying it from being a microkernel. This is unlike QNX where the process server that implements the core of the Unix API is built into the kernel but accessed entirely through IPC and not through its own system calls (the UX/RT process server will be similar in scope to that of QNX and will similarly lack any kind of multi-personality infrastructure and be built alongside the kernel, but will be a separate binary).