Lawrence D?Oliveiro wrote:
So why does Apple?s OS still call its kernel ?XNU??
?XNU? = ?XNU?s Not UNIX?.
Because there's no reason to change it?
Taken as a logical statement, it is true that XNU is not UNIX. That's
because XNU is just a kernel, but a UNIX system requires a C library and compiler, plus a shell and a bunch of utilities.
I.e. XNU is a proper subset of a UNIX system; it is not itself a UNIX
system.
Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
So, which way does RISC OS do it?
You call the SWI (syscall) OS_GetEnv and get back a single string
buffer of the command (as well as your RAM size and timestamp).
You can call OS_ReadArgs to parse the string if you like (and many
do), but that's just a helper function. That provides quote handling
- you can optionally apply more advanced 'GS translations'.
There's no shell because RISC OS doesn't have shells.
On Fri, 07 Aug 2026 13:17:50 +0100, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
So why does Apple?s OS still call its kernel ?XNU??
?XNU? = ?XNU?s Not UNIX?.
Because there's no reason to change it?
Taken as a logical statement, it is true that XNU is not UNIX. That's because XNU is just a kernel, but a UNIX system requires a C library and compiler, plus a shell and a bunch of utilities.
I.e. XNU is a proper subset of a UNIX system; it is not itself a UNIX system.
I'm afraid Lawrence is getting confused in his dotage.
He is conflating it with XINU (XINU Is Not UNIX), a real embdedded
operating system.
Bob Eager <throwaway0008@eager.cx> wrote:
He is conflating it with XINU (XINU Is Not UNIX), a real embdedded operating >> system.
Both are 'X not UNIX':
https://en.wikipedia.org/wiki/XNU
https://en.wikipedia.org/wiki/Xinu
Apple use XNU, not Xinu. Lawrence is correct in saying that XNU is just a kernel - Apple use parts of the FreeBSD userland.
'XNU' wasn't UNIX back when it was part of the NeXTSTEP OS in the 80s. But it has since become part of the UNIX certified macOS. It's also used in the the not-certified iOS, watchOS, tvOS, etc.
Xinu seems mostly used for teaching, although also by a few companies (mostly in the 90s).
ass command linesThere's no shell because RISC OS doesn't have shells.
You don?t have a ?shell?, but you still have to p
around as though a shell were involved.
Does the phrase ?worst of both worlds? come to mind ... ?
On Fri, 7 Aug 2026 21:46:34 -0000 (UTC)
Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
There's no shell because RISC OS doesn't have shells.
You don?t have a ?shell?, but you still have to pass command lines
around as though a shell were involved.
Does the phrase ?worst of both worlds? come to mind ... ?
I'm not sure where the idea that RISC OS doesn't have a CLI comes from,
it most certainly does. As regards the original question, per the docs
for OS_GetEnv the command line is passed in as a whole null-terminated string.
Taken as a logical statement, it is true that XNU is not UNIX.
That's because XNU is just a kernel, but a UNIX system requires a C
library and compiler, plus a shell and a bunch of utilities. I.e.
XNU is a proper subset of a UNIX system; it is not itself a UNIX
system.
XNU is a proper subset of a UNIX system; it is not itself a UNIX
system.
So Apple?s ?UNIX? is implemented as an emulation layer on top of a
non-UNIX kernel?
Contrast that with Linux, where the UNIX support is native to the
To: Lawrence =?iso-8859-13?q?D=FFOliveiro?=
Re: Re: UNIX certification (was: Whatever Happened To
Document-CentricComp By: Lawrence =?iso-8859-13?q?D=FFOliveiro?= to
alt.folklore.computers on Thu Aug 13 2026 23:23:21
XNU is a proper subset of a UNIX system; it is not itself a UNIX
system.
So Apple’s “UNIX” is implemented as an emulation layer on top
of a non-UNIX kernel?
Contrast that with Linux, where the UNIX support is native to the
You all keep capitalizing it like it's an acronym. What does UNIX stand
for?
So Apple?s ?UNIX? is implemented as an emulation layer on top of a
non-UNIX kernel?
You all keep capitalizing it like it's an acronym. What does UNIX stand for?
To: Lawrence =?iso-8859-13?q?D=FFOliveiro?=
Re: Re: UNIX certification (was: Whatever Happened To Document-CentricComp
By: Lawrence =?iso-8859-13?q?D=FFOliveiro?= to alt.folklore.computers on Thu Aug 13 2026 23:23:21
> > XNU is a proper subset of a UNIX system; it is not itself a UNIX
> > system.
>
> So Apple?s ?UNIX? is implemented as an emulation layer on top of a
> non-UNIX kernel?
>
> Contrast that with Linux, where the UNIX support is native to the
You all keep capitalizing it like it's an acronym. What does UNIX stand for?
On Fri, 14 Aug 2026 01:38:07 -0400, Phigan wrote:
You all keep capitalizing it like it's an acronym. What does UNIX stand
for?
The all-caps is what appears in the original documents from Bell Labs, so
I guess it's correct.
It's a play on words - the original word being MULTICS.
On 2026-08-14, Bob Eager <throwaway0008@eager.cx> wrote:
On Fri, 14 Aug 2026 01:38:07 -0400, Phigan wrote:
You all keep capitalizing it like it's an acronym. What does UNIX stand
for?
The all-caps is what appears in the original documents from Bell Labs, so >> I guess it's correct.
It's a play on words - the original word being MULTICS.
Interestingly, though, I couldn't find a single reference where
"Multics" (Multiplexed Information and Computing Service) is
spelled in all caps.
Unix, on the other hand, I see both ways, with the all-caps
version being used when referring to the registered trademark.
On 2026-08-14, Bob Eager <throwaway0008@eager.cx> wrote:
On Fri, 14 Aug 2026 01:38:07 -0400, Phigan wrote:
You all keep capitalizing it like it's an acronym. What does UNIX stand
for?
The all-caps is what appears in the original documents from Bell Labs, so
I guess it's correct.
It's a play on words - the original word being MULTICS.
Interestingly, though, I couldn't find a single reference where
"Multics" (Multiplexed Information and Computing Service) is
spelled in all caps.
Unix, on the other hand, I see both ways, with the all-caps
version being used when referring to the registered trademark.
Speaking of Multics, people here are probably aware that it has been
running on an emulator for some time now.
Phigan wrote:
You all keep capitalizing it like it's an acronym. What does UNIX
stand for?
It's not an acronym. We are capitalizing it because we are discussing
the trademark, which is UNIX?.
See https://www.opengroup.org/trademarks which says (point 3 under
"Rules for Proper Trademark Usage"):
Trademarks are not acronyms; they should not be spelled out,
abbreviated, or used by themselves within parentheses or
brackets. Always spell and capitalize the Trademarks exactly as
they are shown in our Trademarks list above.
To: Lawrence =?iso-8859-13?q?D=FFOliveiro?=
Re: Re: UNIX certification (was: Whatever Happened To Document-CentricComp
By: Lawrence =?iso-8859-13?q?D=FFOliveiro?= to alt.folklore.computers on Thu Aug 13 2026 23:23:21
> > XNU is a proper subset of a UNIX system; it is not itself a UNIX
> > system.
>
> So Apple?s ?UNIX? is implemented as an emulation layer on top of a
> non-UNIX kernel?
>
> Contrast that with Linux, where the UNIX support is native to the
You all keep capitalizing it like it's an acronym. What does UNIX stand for? --- Synchronet 3.16c-Win32 NewsLink 1.103
MutinyBBS - telnet : mutinybbs.com:2332 - ssh : mutinybbs.com:2232
On 8/14/26 14:18, Charlie Gibbs wrote:
On 2026-08-14, Bob Eager <throwaway0008@eager.cx> wrote:
On Fri, 14 Aug 2026 01:38:07 -0400, Phigan wrote:
You all keep capitalizing it like it's an acronym. What does UNIX stand >>>> for?
The all-caps is what appears in the original documents from Bell
Labs, so
I guess it's correct.
It's a play on words - the original word being MULTICS.
Interestingly, though, I couldn't find a single reference where
"Multics" (Multiplexed Information and Computing Service) is
spelled in all caps.
Unix, on the other hand, I see both ways, with the all-caps
version being used when referring to the registered trademark.
Speaking of Multics, people here are probably aware that it has been
running on an emulator for some time now. Shortly, thanks to the hard
work of some genuises - not me (and some help from Claude) the new
version will shortly be available with TCP/IP support - mostly the
original Honeywell code, scrounged up from pieces, with the missing
routing piece newly written
On Fri, 7 Aug 2026 13:17:50 +0100, Geoff Clare wrote:
Taken as a logical statement, it is true that XNU is not UNIX.
That's because XNU is just a kernel, but a UNIX system requires a C
library and compiler, plus a shell and a bunch of utilities. I.e.
XNU is a proper subset of a UNIX system; it is not itself a UNIX
system.
So Apple?s ?UNIX? is implemented as an emulation layer on top of a
non-UNIX kernel?
Contrast that with Linux, where the UNIX support is native to the
kernel itself.
Jeffrey Bagely <6cf6e82302@darkc0de.one> wrote:
On 04 Aug 2026 15:33:38 +0100 (BST), Theo wrote:
Jeffrey Bagely <6cf6e82302@darkc0de.one> wrote:
I think the definition of "document" is getting muddied up here. From
what the OP seems to have stated, the delineation between a "document" >>>> and what I will call a "Composite Doc" is that a "document" is a single >>>> file for each type of data handled for that file type's application.
A "Composite Doc" being a single file that has multiple data "types"
being contained (i.e. Spreadsheet data mixed in with regular rich
text).
How the data is stored on disc is orthogonal to how the editing works.
They're just bags of bits; how you organise the bags of bits is a design >>> decision.
Ahh, I thought you were specifically talking about the structure of
documents. I find that if everything is in it's separate file and a
document preparation system is designed to work that way, it is much more
enjoyable to work with. Say templating with LaTex for reporting based off
of CSV files and making graphs. Just nicer to work with and can also apply >> version control. No proprietary all encompassing binary formats like docx
The way Computer Concepts did it used a few tricks:
1. On the Archimedes, applications were a directory whose name started
with the ! symbol. Roughly the same as how MacOS has Something.app
application bundles which are just directories. (! was chosen as it's
first in ASCII sorting)
So you are talking about not only applications that could be global to the >> system for use by the application (not saying this is how the archimedes
worked) but also a set of utils built for a specific software product in
its own isolated bundle/package that all worked cohesively to serve as a
document preparation toolkit which happened to be really well integrated.
No, merely that documents were stored each in their own file bundle that happened to reuse the way application file bundles worked. In RISC OS application bundles are just a fancy directory, they can (and do) live anywhere on any filesystem. What makes an application? Most it has its own icon (a Sprites file inside the directory) and it has an action that runs when you double click it. In this case that was a script that started the editor and told it to open this document. That made its behaviour to the user that what they'd expect from a single file (except the ! prefix).
This is mostly tangential, but it meant a 'document' could be a cohesive bundle of files that appeared to the user to be one object, rather than having to be packed into a single file. It's relevant because inside the document bundle were the individual document elements (text, images, tables, equations, etc) which retained their native filetyping. You could just open the document bundle (shift-double-click the application) and find the document elements inside.
Of course, such ideas were later popularised with standards like docx (OOXML), where the document 'file' is actually represented by a zipfile containing a bundle of component files.
2. Their 'documents' were stored as applications, where double clicking >>> them (opening the app) would open them in the overarching editor (eg
word processor). Inside the application directory were various files
making up the inclusions (tables, equations, drawings, bitmap images,
etc).
Are you saying that the document that you may be preparing is shared in
the same directory as the software used to write it? That seems a bit odd
to me. Nice an encapsulated but wouldn't that mean every user generated
docuemnt carries the whole set of binary utils with it as well?
No, they were separate. In general there was no on-disc organisation imposed, so the pieces could live wherever you wanted them. (Including on removable discs which may or may not be present)
(there's a mechanism by which the first time you open a folder containing
an application, it can register itself with the system and make it
available to open file types it knows about. This can also be pre-loaded at boot time)
3. RISC OS gives each file 12-bit 'filetype' metadata, so you can know
whether a regular file is a drawing or a JPEG from the filetype rather
than the extension.
I wish this was the case still, rather than extensions as you mention or
memorizing and hoping to find magic numbers. Would make sorting through
filesystem data a bit easier and reassuring when restoring from backups.
Some filesystems can have extended metadata for this, although I can't think of anything that widely uses it. It gets a bit hairy when
you consider the mappings of extensions to MIME types, which are typically what people mean by filetypes today - this mapping is not a bijection.
This is starting to make WAY more sense now that you putting more plainly
here. It was the case where you could utilize specialized small programs
that generated a vector drawing, just following lets say a 'table' ruleset >> (how you are allowed to draw) which then could be interpreted by the word
processor as any general vector to display within the document.
I now also see why you specifically say that the organization of data
doesn't matter in the context of an isolated system like this because all
would be operating on and stroing data in the 'universal way'
With something like OOXML or ODF you can still do the same thing, eg if I make a wordprocessor doc with a JPEG in it I can unzip the .docx or .odt and find the JPEG inside the bundle.
In Libreoffice, if I open the file and right click on the JPEG I can 'open
in external tool'. For me that opens it in Gwenview. Suppose I rotate the JPEG, save and close it - the image in the document is now updated. LO is using a temporary JPEG file for that (I can't access the file in the original .odt without first unpacking it) but otherwise it's the same process.
The idea of having 'hidden' metadata is also not uncommon today - eg in HTML where the browser ignores tags it doesn't understand and can nevertheless render the page. If you open the HTML in something that does understand the extra tags then it can do something different with the document.
I would also like to say that creating features for a piece of software
that overlap is somewhat bad practice. What I mean is that for a
functional (maths variety) kind of thinker there should really be one
right (developer blessed) way to do a particular function. Now that
doesn't mean that there is a limit to any particular feature but that the
cross cutting (interfering is probably a better term here, not sure)
aspects of a program's design should be kept to a minimum.
An example is in MS Excel today, there are multiple ways to provide
alternative colors for a table, conditional coloring, or converting the
range into a proper structured table selected with a particular color
scheme/pattern. In fact the fact that in a spreadsheet program you can
define a 'stronger' table within a tabular environment is something that
most users don't even grasp because it seems like they already arrived to
the correct (best?) solution to their tabular problems by opening MS
Excel!
Its this set of features stumbling over each other within single
applications that do the most damage in regards to this werid machines
problem they seem to all have.
I'd say this is a result of application featureitis. Because you can't easily share functionality, every app ends up with its own table editor,
even if one app (Excel) does it better than others (Word, OneNote).
Sometimes there is a reason for that (aesthetics, simplicity, interconnection), but often not (eg it would be very handy to be able to put a spreadsheet-powered table in my OneNote files instead of the dumb tables they implement). This is also why these monolthic apps get bloated, because they need to include the code for every feature everyone could possibly
want.
With the Unix philosophy, it may be more complicated to learn but you build up an ecosystem of swappable parts - if you don't like the app that does one job, swap it out for another app that does the same job better. You don't end up with the monoculture where you get locked into Word for everything, even if some sub-feature is better done by an independent app.
Perhaps software shouldn't necessarily expect to work like how humans
think but that humans should realize that they are using a computer and
should first learn how to use one if it is necessary (think like how a
computer works). Much like I wouldn't feel comfortable with a person
driving a car who didn't know what the accelerator or breaks are or what
they did in reference to the vehicle.
But its a lot to ask from people I know, especially since most still can't >> figure out how to drive even now.
Much of this is still learned behaviour. I always say that 'intuitive' is just (deliberate) technobabble for 'works like something you've used
before'. You still had to learn that first thing - no-one was born knowing how to use dialog boxes.
On 15/08/2026 11:52 AM, Peter Flass wrote:
On 8/14/26 14:18, Charlie Gibbs wrote:
On 2026-08-14, Bob Eager <throwaway0008@eager.cx> wrote:
On Fri, 14 Aug 2026 01:38:07 -0400, Phigan wrote:
You all keep capitalizing it like it's an acronym. What does UNIX
stand
for?
The all-caps is what appears in the original documents from Bell
Labs, so
I guess it's correct.
It's a play on words - the original word being MULTICS.
Interestingly, though, I couldn't find a single reference where
"Multics" (Multiplexed Information and Computing Service) is
spelled in all caps.
Unix, on the other hand, I see both ways, with the all-caps
version being used when referring to the registered trademark.
Speaking of Multics, people here are probably aware that it has been
running on an emulator for some time now. Shortly, thanks to the hard
work of some genuises - not me (and some help from Claude) the new
version will shortly be available with TCP/IP support - mostly the
original Honeywell code, scrounged up from pieces, with the missing
routing piece newly written
That's indeed good news. Never mind the Lawrence Language Generator,
he's always spouting nonsense.
I definitely should try out some of the public access Multics systems,
one of these days.
Unified Netwetworked Interface eXecutive
Looking at all of my printed collateral from the 80s, all
references to UNIX were in upper case (e.g. the DWB
Looking at all of my printed collateral from the 80s, all
references to UNIX were in upper case (e.g. the DWB
printed documentation) and noted as a trademark.
And later, when AT&T spun the UNIX folks into UNIX
Systems Laboratories (USL), UNIX was always in upper-case.
Lawrence D?Oliveiro wrote:
So Apple?s ?UNIX? is implemented as an emulation layer on top of a
non-UNIX kernel?
What matters is the behaviour of those things that applications and
users experience, not the technical details of how they are
implemented at lower levels.
Looking at all of my printed collateral from the 80s, all
references to UNIX were in upper case (e.g. the DWB printed
documentation) and noted as a trademark.
And later, when AT&T spun the UNIX folks into UNIX Systems
Laboratories (USL), UNIX was always in upper-case.
Goes back to at least V7, and the official rendering seems to have been
small caps, not upper case. See tmac.s.
Looking at all of my printed collateral from the 80s, all
references to UNIX were in upper case (e.g. the DWB
printed documentation) and noted as a trademark.
And later, when AT&T spun the UNIX folks into UNIX
Systems Laboratories (USL), UNIX was always in upper-case.
Goes back to at least V7, and the official rendering seems to have
been small caps, not upper case. See tmac.s.
drb@ihatespam.msu.edu (Dennis Boone) writes:
Looking at all of my printed collateral from the 80s, all references
to UNIX were in upper case (e.g. the DWB printed documentation) and
noted as a trademark.
And later, when AT&T spun the UNIX folks into UNIX Systems
Laboratories (USL), UNIX was always in upper-case.
Goes back to at least V7, and the official rendering seems to have been >>small caps, not upper case. See tmac.s.
I think, in this context, 'small caps' and 'upper case' can be
considered equivalent.
I like to use BeOS as an example of this. People have been trained,
quite extensively, since 1995 to use an X to close an application win-
dow. It took me help from I.R.C. to figure out the [] in the tab thing
on top of the window is an /active/ button. Admittedly, that was some-
thing like twenty-or-more years ago, and now I don't have to learn it
again, but I did have to learn it once; that not every operating system follows the /Microsoft/ tradition.
Which still has the double-click-the-small-icon-in-the-upper-left-corner
as /close/, despite the X being touted as the /close/ button.
I've also noticed, that to a lot of people /intuitive/ means what they
know, and nothing can convince them otherwise. There is no talking to
these people, in my experience, about how all of this needs to be learn-
ed in the first place, and /intuitive/ is just "what I know" in terms of human-computer user interfaces.
And next time I boot up my RISC OS machine, I'm probably going to have
to read the user manual all over again, because I never spent much time
on it. Hopefully that changes in the near future.
Nobody said RISC OS doesn't have a CLI. Lawrence was talking about a
Unix shell in the context of 'shell escaping', ie passing command
lines through one program which launches another.
RISC OS doesn't have the model where one process is used to launch
other processes; for one thing it doesn't have a process model.
Programs are launched directly by the kernel, and if one program runs
another then the first is replaced.
[...]
Because there's no process mechanism according to the Unix model, the
idea of a shell process for launching other programs (and passing
command arguments) doesn't exist. The native CLI does happen to be
called ShellCLI but it's not a shell in the Unix model, it's merely a
way to run one program at a time. So Lawrence's concerns about
escaping parameters aren't really relevant.
Theo
On Fri, 14 Aug 2026 13:20:38 +0100, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
So Apple?s ?UNIX? is implemented as an emulation layer on top of a
non-UNIX kernel?
What matters is the behaviour of those things that applications and
users experience, not the technical details of how they are
implemented at lower levels.
So Apple?s ?UNIX? should be sufficient to run software supposedly
designed for ?UNIX?, should it not?
Yet most of that software seems targeted at Linux, not macOS. To the
point where Apple (like Microsoft) needs to include the option to run
a Linux kernel in a bag on the side of macOS now, to get access to it.
Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
On Fri, 14 Aug 2026 13:20:38 +0100, Geoff Clare wrote:
Lawrence D?Oliveiro wrote:
So Apple?s ?UNIX? is implemented as an emulation layer on top of
a non-UNIX kernel?
What matters is the behaviour of those things that applications
and users experience, not the technical details of how they are
implemented at lower levels.
So Apple?s ?UNIX? should be sufficient to run software supposedly
designed for ?UNIX?, should it not?
Yet most of that software seems targeted at Linux, not macOS. To
the point where Apple (like Microsoft) needs to include the option
to run a Linux kernel in a bag on the side of macOS now, to get
access to it.
Porting between various Unices was always tricky.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 5 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 232:43:56 |
| Calls: | 221 |
| Files: | 21,513 |
| Messages: | 84,424 |