Linux and the 'clssic' computing world
To my knowledge the Linux kernel was released to the public 30 years ago around this time. My dear friend swears by it and will never go back to Windows even though WIN 11 is much more secure than previous Windows versions. Prior to Linux there were other much-earlier operating systems for 8-bit and 16-bit machines we classic computer users could use. For emulators now we have a choice but do they work better in Linux or Windows? Happy computing. Murray 🙂
Re: Linux and the 'clssic' computing world
Claiming one OS is better than another is always a contentious issue, and i'd rather prefer that this mailing list didn't fall for the same petty bickering that can be found across the internet. The fact of the matter is, when it comes to emulation on x86 IBM PC compatibles, both Windows and Linux are on a pretty level playing field, with most emulators available on both platforms. Obviously, there's more hardware platforms that support Linux (like the RPi and other ARM boards), and many retro collectors use such ARM based systems for emulation. However, much of the "Linux" software is in fact POSIX software, and can quite easily be ported between Linux and other *NIX-likes, such as Solaris, macOS and the *BSD family. As such, with a bit of time and effort, most of the emulators are fairly hardware-agnostic and can be ported to anything with a POSIX interface, opening them up to be ported to whatever hardware and software platform your heart desires. Josh Rice
Re: Linux and the 'clssic' computing world
The is also the Windows Subsystem for Linux, which basically runs Linux under Windows. https://docs.microsoft.com/en-us/windows/wsl/ On 9/27/2021 9:07 AM, Joshua Rice via cctalk wrote: Claiming one OS is better than another is always a contentious issue, and i'd rather prefer that this mailing list didn't fall for the same petty bickering that can be found across the internet. The fact of the matter is, when it comes to emulation on x86 IBM PC compatibles, both Windows and Linux are on a pretty level playing field, with most emulators available on both platforms. Obviously, there's more hardware platforms that support Linux (like the RPi and other ARM boards), and many retro collectors use such ARM based systems for emulation. However, much of the "Linux" software is in fact POSIX software, and can quite easily be ported between Linux and other *NIX-likes, such as Solaris, macOS and the *BSD family. As such, with a bit of time and effort, most of the emulators are fairly hardware-agnostic and can be ported to anything with a POSIX interface, opening them up to be ported to whatever hardware and software platform your heart desires. Josh Rice
RE: Linux and the 'clssic' computing world
As I think others already mentioned, there's no difference between emulators run under windows or linux... they are both limited by the cpu and amount of ram used to run them, not by the host os -Original Message- From: cctalk On Behalf Of Murray McCullough via cctalk Sent: Monday, September 27, 2021 3:55 PM To: cctalk Subject: Linux and the 'clssic' computing world To my knowledge the Linux kernel was released to the public 30 years ago around this time. My dear friend swears by it and will never go back to Windows even though WIN 11 is much more secure than previous Windows versions. Prior to Linux there were other much-earlier operating systems for 8-bit and 16-bit machines we classic computer users could use. For emulators now we have a choice but do they work better in Linux or Windows? Happy computing. Murray 🙂
Re: Linux and the 'clssic' computing world
Doesn’t this have the relationship between the OS and the hardware platform backwards? > On Sep 27, 2021, at 07:07, Joshua Rice via cctalk > wrote: > > Obviously, there's more hardware platforms that support Linux (like the RPi > and other ARM boards)
Re: Linux and the 'clssic' computing world
On Mon, Sep 27, 2021 at 11:18 AM Alan Perry via cctalk < cctalk@classiccmp.org> wrote: > > On Sep 27, 2021, at 07:07, Joshua Rice via cctalk > wrote: > > > > Obviously, there's more hardware platforms that support Linux (like the > RPi and other ARM boards) > > Doesn’t this have the relationship between the OS and the hardware > platform backwards? > When there is no relationship between the hardware and OS teams (i.e. the OS team chooses to adopt the hardware on their own) you can say the OS is adding support for that hardware platform. But more often than not, OS support is a big part of selling hardware. You seriously reduce your potential sales if your hardware doesn't run a popular operating system, and to ensure that your operating system(s) of choice will run on your hardware, you pay your own developers to do the port(s). At that point, it is very much a case of the hardware platforms supporting an OS. This is especially true when other operating system developers find themselves unable to support your hardware because the needed documentation isn't available. The situation is similar with add-on hardware that requires device drivers. If the documentation needed to write a device driver is unavailable, and the only available drivers came from the hardware maker, then it is definitely a case of the hardware maker supporting the OS. -ken
Re: Linux and the 'clssic' computing world
> On Sep 27, 2021, at 12:06 PM, Kenneth Gober via cctalk > wrote: > > On Mon, Sep 27, 2021 at 11:18 AM Alan Perry via cctalk < > cctalk@classiccmp.org> wrote: > >>> On Sep 27, 2021, at 07:07, Joshua Rice via cctalk >> wrote: >>> >>> Obviously, there's more hardware platforms that support Linux (like the >> RPi and other ARM boards) >> > >> Doesn’t this have the relationship between the OS and the hardware >> platform backwards? >> > > ... > But more often than not, OS support is a big part of selling hardware. You > seriously reduce your > potential sales if your hardware doesn't run a popular operating system, > and to ensure that your > operating system(s) of choice will run on your hardware, you pay your own > developers to do the > port(s). > ... > The situation is similar with add-on hardware that requires device > drivers. If the documentation > needed to write a device driver is unavailable, and the only available > drivers came from the > hardware maker, then it is definitely a case of the hardware maker > supporting the OS. True, and that's also a reason to avoid that hardware. I remember when the SoC used on the Raspberry Pi was secret. That prompted me to go BeagleBone instead, since TI published a full manual, over 5000 pages. It seems Broadcom has cleaned up their act a bit since that time, from what I've heard. paul
Re: Linux and the 'clssic' computing world
On Mon, 27 Sept 2021 at 15:55, Murray McCullough via cctalk wrote: > > even though WIN 11 is much more secure than previous Windows > versions [[Citation needed]] ;-) There still are more choices than people realise. I sometimes play around with Haiku. It's getting there and is quite usable for some stuff. I have friends who are OpenBSD enthusiasts, although for me it's too Spartan to be much use. I intend to have a proper look at the Hello System, a new FreeBSD distro aimed at people migrating off Mac OS X put together by a very smart chap I know online. https://hellosystem.github.io/docs/ I have a Raspberry Pi running RISC OS, which for many tasks is a surprisingly usable OS these days. It's not great on the Web but it's entirely usable for email, productivity, graphics, sound/music, programming and more -- and it has a rich assortment of emulators for classic 1980s home computers. https://www.riscosopen.org/content/ RISC OS has new owners now who are pursuing a relatively aggressive programme of updating the OS. https://www.riscosdev.com/projects Soon it will have a modern Webkit-based browser, a new IP stack ported from OpenBSD that includes IPv6 and Wifi, and some people are working on SMP support. By the same token I know people still using Amigas, and a new wave of activity is happening in the Amiga world. The attempted move to PowerPC chips hasn't really taken off, so the company that owns the OS now is doing new releases for 68000 hardware. There are also new processor accelerators for classic Amigas so that you can bring them say 20 years up to date -- at least into the realms of hundreds of MHz CPUs, hundreds of megs of RAM, and modern storage. Given the efficiency of the Amiga OS this makes a 1980s Amiga a very powerful and usable machine today. https://www.hyperion-entertainment.com/index.php/news/1-latest-news/290-amigaos-42-for-all-classic-amigas-released-and-available (Note, there's a typo in the URL -- they're talking about AmigaOS 3.2, released 24 years after v3.1. :-) https://www.apollo-accelerators.com/ ← FPGA replacement CPUs/graphics cards https://www.hackster.io/news/hands-on-with-the-pistorm-the-ultimate-raspberry-pi-powered-accelerator-for-your-commodore-amiga-449ef0634f3e It's easy to look at modern desktop computing and conclude it's all either Windows, macOS or Linux, but there is more to life! -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: Linux and the 'clssic' computing world
On Mon, 27 Sept 2021 at 16:07, Joshua Rice via cctalk wrote: > > and i'd rather prefer that this mailing list didn't fall for the same > petty bickering that can be found across the internet. +1 to that! -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: Linux and the 'clssic' computing world
> > > > > To my knowledge the Linux kernel was released to the public 30 years ago > around this time. My dear friend swears by it and will never go back to > Windows even though WIN 11 is much more secure than previous Windows > versions. Prior to Linux there were other much-earlier operating systems > for 8-bit and 16-bit machines we classic computer users could use. For > emulators now we have a choice but do they work better in Linux or > Windows? Murray 🙂 > Assembly version August 25th 1991. - comp.os.minix newsgroup. C version October 5th 1991 - Linux Bible 8th edition. I started using Red Hat with version 6.2. For a while the server I put it on just sat there until I got around to making it a mail server. I still have the server but it was upgraded to BSD at some point. I doubt I have a backup anymore Bill
Re: Linux and the 'clssic' computing world
On Sep 27, 2021, at 8:03 AM, mazzinia--- via cctalk wrote: > > As I think others already mentioned, there's no difference between emulators > run under windows or linux... they are both limited by the cpu and amount of > ram used to run them, not by the host os The real difference is in the emulators available under one or the other platform. Realistically, for many/most people, that’s the first thing to look at, are the Applications I need to run available for Linux, MacOS, or Windows. End result, many of us have all three, and others. Zane
Re: Linux and the 'clssic' computing world
On 2021-09-27 10:07, Joshua Rice via cctalk wrote (in part): However, much of the "Linux" software is in fact POSIX software, and can quite easily be ported between Linux and other *NIX-likes, such as Solaris, macOS and the *BSD family. I cannot agree. Many developers ensure that their software runs under their particular distribution and then call it POSIX. Porting to UNIX systems, such as Solaris or macOS, can be difficult and tedious. (Of course, this is not a Linux issue.) N.
Re: Linux and the 'clssic' computing world
On Sep 27, 2021, at 2:15 PM, Nemo Nusquam via cctalk wrote: > > On 2021-09-27 10:07, Joshua Rice via cctalk wrote (in part): >> >> However, much of the "Linux" software is in fact POSIX software, and can >> quite easily be ported between Linux and other *NIX-likes, such as Solaris, >> macOS and the *BSD family. > > I cannot agree. Many developers ensure that their software runs under their > particular distribution and then call it POSIX. Porting to UNIX systems, such > as Solaris or macOS, can be difficult and tedious. (Of course, this is not a > Linux issue.) > > N. This also sums up nicely what is Linux’s greatest failing. Software vendors need “Linux”, and what they get is “Red Hat”, “SLES”, “Ubuntu”, etc. and as a result, the users suffer. This is why most commercial apps target MacOS and Windows, or more often than not, just Windows. One vendor I work with is looking at supporting something in Linux, the problem being, they have to re-implement it for each distro. That’s just one of the issues they face it supporting Linux. Zane
Re: Linux and the 'clssic' computing world
On Mon, Sep 27, 2021 at 2:39 PM Bill Degnan via cctalk wrote: > > To my knowledge the Linux kernel was released to the public 30 years ago > > around this time. My dear friend swears by it and will never go back to > > Windows even though WIN 11 is much more secure than previous Windows > > versions. Prior to Linux there were other much-earlier operating systems > > for 8-bit and 16-bit machines we classic computer users could use. For > > emulators now we have a choice but do they work better in Linux or > > Windows? Murray 🙂 > > > > Assembly version August 25th 1991. - comp.os.minix newsgroup. > C version October 5th 1991 - Linux Bible 8th edition. First release September 17th 1991 - Linus Torvalds a few days ago http://lkml.iu.edu/hypermail/linux/kernel/2109.2/03485.html I've been using it since 9/17/1992 +/- a few days. Jim
Re: Linux and the 'clssic' computing world
On 9/27/21 3:30 PM, Zane Healy via cctalk wrote: This also sums up nicely what is Linux’s greatest failing. Software vendors need “Linux”, and what they get is “Red Hat”, “SLES”, “Ubuntu”, etc. and as a result, the users suffer. The same can be, and was, said about Unix. IRIX, Solaris, SunOS, AIX, HP-UX, OpenServer, UnixWare, what have you. They were all Unix operating systems, if not actually licensed to use the Unix name. Yet they were as different from each other as different Linux distributions can be. Microsoft has even had this problem with Windows 3.x, Windows 9x, and NT / 2k. -- Grant. . . . unix || die
Re: Linux and the 'clssic' computing world
More like you sell the hardware, then write the software. Look at APPLE was 68000 now the Apple/386 style cpu. Hardware has no meaning. Never a fan of RISC or modern designs because you got speed by being able pipeline DRAM access, not because of RISC or what ever CPU of the day was. Ben.
Re: Linux and the 'clssic' computing world
On 2021-09-27 3:15 p.m., Nemo Nusquam via cctalk wrote: On 2021-09-27 10:07, Joshua Rice via cctalk wrote (in part): However, much of the "Linux" software is in fact POSIX software, and can quite easily be ported between Linux and other *NIX-likes, such as Solaris, macOS and the *BSD family. I cannot agree. Many developers ensure that their software runs under their particular distribution and then call it POSIX. Porting to UNIX systems, such as Solaris or macOS, can be difficult and tedious. (Of course, this is not a Linux issue.) N. POSIX requires a byte to be exactly 8 bits I read somewhere. C99 C standard? Great for ARM and INTEL, not so great for the 36 bit computers. Ben.
Re: Linux and the 'clssic' computing world
On Mon, 27 Sept 2021 at 23:31, Zane Healy via cctalk wrote: > > On Sep 27, 2021, at 2:15 PM, Nemo Nusquam via cctalk > wrote: > > > > On 2021-09-27 10:07, Joshua Rice via cctalk wrote (in part): > >> > >> However, much of the "Linux" software is in fact POSIX software, and can > >> quite easily be ported between Linux and other *NIX-likes, such as > >> Solaris, macOS and the *BSD family. > > > > I cannot agree. Many developers ensure that their software runs under > > their particular distribution and then call it POSIX. Porting to UNIX > > systems, such as Solaris or macOS, can be difficult and tedious. (Of > > course, this is not a Linux issue.) > > > > N. > > This also sums up nicely what is Linux’s greatest failing. Software vendors > need “Linux”, and what they get is “Red Hat”, “SLES”, “Ubuntu”, etc. and as a > result, the users suffer. This is why most commercial apps target MacOS and > Windows, or more often than not, just Windows. Everything I personally develop for Linux will build on all Linux distros, and also IRIX, Solaris, AIX, and, until recently, Tru64 (because I have access to those systems, except for Tru64 now). And to some extent BSD variants. It's not hard at all. And the company I work for used to have build systems for all of the above until not that far ago, but, as customers more and more move to Linux systems the build support and tests have been removed for most of the rest (AIX still hangs on by a thread). As for the various Linux distros, the issue isn't really that they are that different, it's that they don't have the same version of core software - in particular moving targets like the C++ compiler (and this goes for various releases of the same distro too). I started testing Linux just for fun in early 1992 (because unlike 386BSD, Linux supported disk partitions, and that meant I could test it on a 486 where the primary OS was OS/2). When my X terminal then broke down in April 1991 I replaced it with a 486 system running Linux, kernel 0.95c. And I was an early tester for the ext file system and X11. Even that early that Linux box was good enough to replace an X terminal, even though most of the development I did was by accessing a remote Sun box. And I never looked back - it's *always* been "ready for the desktop" for me.
Re: Linux and the 'clssic' computing world
On 2021-09-27 11:46 p.m., ben via cctalk wrote: > On 2021-09-27 3:15 p.m., Nemo Nusquam via cctalk wrote: >> On 2021-09-27 10:07, Joshua Rice via cctalk wrote (in part): >>> >>> However, much of the "Linux" software is in fact POSIX software, and >>> can quite easily be ported between Linux and other *NIX-likes, such >>> as Solaris, macOS and the *BSD family. >> >> I cannot agree. Many developers ensure that their software runs under >> their particular distribution and then call it POSIX. Porting to UNIX >> systems, such as Solaris or macOS, can be difficult and tedious. (Of >> course, this is not a Linux issue.) >> >> N. > > POSIX requires a byte to be exactly 8 bits I read somewhere. > C99 C standard? > Great for ARM and INTEL, not so great for the 36 bit computers. We've been through this before. No. > Ben.
Re: Linux and the 'clssic' computing world
On Mon, Sep 27, 2021 at 09:55:08AM -0400, Murray McCullough via cctalk wrote: > [...] WIN 11 is much more secure than previous Windows versions. [...] Windows 11 hasn't even been released yet, so this cannot be known. Any claims of "much more secure" comes from press releases and other marketing materials. Microsoft don't exactly have a good reputation for accuracy and honesty here. However, it would have to try quite hard to be *less* secure than previous versions of Windows. Unless one actually needs to run Windows, the comparison should be against other platforms which can also do the job, and not just whatever garbage Microsoft churned out last time.
Re: Linux and the 'clssic' computing world
On 2021-09-27 23:46, ben via cctalk wrote: > POSIX requires a byte to be exactly 8 bits I read somewhere. > C99 C standard? > Great for ARM and INTEL, not so great for the 36 bit computers. > Ben. And probably don't work on your 20-bit CPU, when it is done ;-)
Re: Linux and the 'clssic' computing world
On 9/28/21 12:26 AM, Tor Arntsen via cctalk wrote: Everything I personally develop for Linux will build on all Linux distros, and also IRIX, Solaris, AIX, and, until recently, Tru64 (because I have access to those systems, except for Tru64 now). And to some extent BSD variants. Kudos to you. I mean that sincerely and with respect. It's not hard at all. I'm not a developer by any stretch of the imagination. But I know from a Unix systems administrator standpoint, creating shell scripts / command structures (think HereDocs run through SSH redirection) that doing so in a cross platform way is non-trivial. I found the biggest hurtle was knowing what commands ~> syntax / utilities my target platforms (AIX 5~7, Solaris 8~10, OpenServer 5, UnixWare 7, Red Hat / CentOS 4~6, SuSE 7~9, Gentoo (~2008), FreeBSD (?), and others I don't remember) had in common. File paths and what command were one thing. Command flags ~> syntax was another. Elevating privilege to root via su or sudo or doas was ... tedious. Unfortunately I think that it's unreasonable reasonable to expect someone that has a myopic view of their singular platform to have any idea how to do things on other platforms as well as they can on their platform of choice. -- Is it reasonable to expect a mechanic that works on lawn mowers to be as proficient on tractor trailers or motorcycles? I don't think so. I would expect that someone that has a working understanding of any platform to be able to muddle their way through most other platforms. But muddling your way through something is definitely not the same level of support. So, I sincerely mean kudos to anyone that even attempts to do things on multiple platforms. I believe it's a laudable goal. I believe that each supported platform adds an order of magnitude of complexity to the overall task at hand. As for the various Linux distros, the issue isn't really that they are that different, it's that they don't have the same version of core software - in particular moving targets like the C++ compiler (and this goes for various releases of the same distro too). I had not considered what you are describing. But it sounds like a more development centric version of what I described above. I started testing Linux just for fun in early 1992 (because unlike 386BSD, Linux supported disk partitions, and that meant I could test it on a 486 where the primary OS was OS/2). When my X terminal then broke down in April 1991 I replaced it with a 486 system running Linux, kernel 0.95c. And I was an early tester for the ext file system and X11. I'd be interested in sharing a beverage and hearing (horror) stories. Hopefully I'd learn a thing or three. Even that early that Linux box was good enough to replace an X terminal, even though most of the development I did was by accessing a remote Sun box. And I never looked back - it's *always* been "ready for the desktop" for me. My year of the Linux desktop was '99. I switched from a release candidate of Windows 98 to Slackware '96 (an old book that someone lent me). I've almost completely used Linux as my chosen platform ever sense. I've moved around between Linux distros, but have always either directly used or SSHed to a Linux box for my core work. -- Grant. . . . unix || die
Re: Linux and the 'clssic' computing world
My .02 on this is that the computing world has changed a lot since the 1990s. Back when I was using RH 5, it was useful for server-side stuff but as a general replacement for Windows desktops, it left a lot to be desired. On the other hand, it was pretty stable. Eventually I moved to an OpenBSD release--there was no need for a graphical desktop. It was pretty much a "get it running and leave it alone" affair. When Win10 debuted and I was about to lose support for XP, I decided that my direction and Microsoft's were going to be different. I still maintain a couple of systems with Win7 just in case, but by and large, I've found that Debian or Ubuntu with XFCE desktop doesn't pose any "you can't get there from here" situations, as was the case 20 years ago. There may be a few old applications where I have to resort to a version of Windows running in a Virtualbox session, but that situation is pretty infrequent. My development and EDA tools run just fine on Linux. In summary, the situation isn't as black and white as it once was. My lovely wife even uses Linux on her desktop--and she's still using a couple of old DOS applications for some things. It's all good. --Chuck
Re: Linux and the 'clssic' computing world
On 9/28/2021 5:14 AM, Toby Thain via cctalk wrote: On 2021-09-27 11:46 p.m., ben via cctalk wrote: POSIX requires a byte to be exactly 8 bits I read somewhere. C99 C standard? Great for ARM and INTEL, not so great for the 36 bit computers. We've been through this before. No. As I understand things, POSIX does require the existence of 8 bit bytes, (int8_t and uint8_t) and requires them to be exactly 8 bits. It does not AFAIK explicitly prohibit the existence of bytes with other sizes, but who would bother? The C standards are more liberal, and continue to require char types to be 8 or more bits. In principle then, char could still be 9 or more bits, but if int8_t is required for a *NIX, who would do it? They'd just be making a compatibility mess for themselves. It's also unclear to me whether one's complement representation would be allowed. (Various other representations would probably be prohibited by other restrictions.) Vince
Re: Linux and the 'clssic' computing world
On 2021-09-28 02:26, Tor Arntsen via cctalk wrote (in part): On Mon, 27 Sept 2021 at 23:31, Zane Healy via cctalk wrote: On Sep 27, 2021, at 2:15 PM, Nemo Nusquam via cctalk wrote: On 2021-09-27 10:07, Joshua Rice via cctalk wrote (in part): However, much of the "Linux" software is in fact POSIX software, and can quite easily be ported between Linux and other *NIX-likes, such as Solaris, macOS and the *BSD family. I cannot agree. Many developers ensure that their software runs under their particular distribution and then call it POSIX. Porting to UNIX systems, such as Solaris or macOS, can be difficult and tedious. (Of course, this is not a Linux issue.) N. This also sums up nicely what is Linux’s greatest failing. Software vendors need “Linux”, and what they get is “Red Hat”, “SLES”, “Ubuntu”, etc. and as a result, the users suffer. This is why most commercial apps target MacOS and Windows, or more often than not, just Windows. Everything I personally develop for Linux will build on all Linux distros, and also IRIX, Solaris, AIX, and, until recently, Tru64 (because I have access to those systems, except for Tru64 now). And to some extent BSD variants. It's not hard at all. Writing portable s/w may not be difficult but it takes some discipline on the part of the programmers. Many programmers only have Linux distros so they (perhaps understandably) only develop in their environment. And the company I work for used to have build systems for all of the above until not that far ago, but, as customers more and more move to Linux systems the build support and tests have been removed for most of the rest (AIX still hangs on by a thread). As for the various Linux distros, the issue isn't really that they are that different, it's that they don't have the same version of core software - in particular moving targets like the C++ compiler (and this goes for various releases of the same distro too). I have the same experience. We produced s/w that ran on dozens of different UNIX and non-UNIX systems including embedded systems. The main point was to write POSIX C-code (and stay away from the preprocessor). Our main issue was that native compilers were not always as compliant as claimed. We were fortunate in that our s/w was either back-end or embedded without the need -- read headache -- of GUI interfaces. N.
Re: Linux and the 'clssic' computing world
> On Sep 28, 2021, at 1:43 PM, Vincent Slyngstad via cctalk > wrote: > > On 9/28/2021 5:14 AM, Toby Thain via cctalk wrote: >> On 2021-09-27 11:46 p.m., ben via cctalk wrote: >>> POSIX requires a byte to be exactly 8 bits I read somewhere. >>> C99 C standard? >>> Great for ARM and INTEL, not so great for the 36 bit computers. >> We've been through this before. No. > > As I understand things, POSIX does require the existence of 8 bit bytes, > (int8_t and uint8_t) and requires them to be exactly 8 bits. It does not > AFAIK explicitly prohibit the existence of bytes with other sizes, but who > would bother? > > The C standards are more liberal, and continue to require char types to be 8 > or more bits. You're mixing up two unrelated things. int8_t is an integer type of 8 bits width. char is the type used for characters. While in many machines they are the same size, that isn't required. C compilers have been built for machines with non-8 bit characters, from the CDC 6600 to the PDP-10 and Cray-1 and various DSPs. GCC at one time (some of them still, I think) handled all these except the 6600. paul
Re: Linux and the 'clssic' computing world
On 2021-09-28 11:43 a.m., Vincent Long standing via cctalk wrote: The C standards are more liberal, and continue to require char types to be 8 or more bits. Was PL/I the only language that would let you select data size for variables? Of course the fine print would not let you have more than 16 decimal digits, or 32 bit binary. You would think by now that a language could handle any length data. In principle then, char could still be 9 or more bits, but if int8_t is required for a *NIX, who would do it? They'd just be making a compatibility mess for themselves. Is it not a mess already as hardware keeps changing standards. Look at USB or all the kinds of network protocols. It's also unclear to me whether one's complement representation would be allowed. (Various other representations would probably be prohibited by other restrictions.) My next computer will be 44 bits, if I ever get the routing timing bugs out the FPGA prototype card. I can't change the FPGA vender because I can use TTL macros like 74181, for TTL bread boarding. With the 74181 I can have any width I want, thus I can play with odd sizes. More I play with my designs, I come to the conclusion that 32 bits is not ample for a general purpose computer. Vince Ben.
Re: Linux and the 'clssic' computing world
> On Sep 28, 2021, at 3:15 PM, ben via cctalk wrote: > > On 2021-09-28 11:43 a.m., Vincent Long standing via cctalk wrote: > >> The C standards are more liberal, and continue to require char types to be 8 >> or more bits. > Was PL/I the only language that would let you select data size for variables? > Of course the fine print would not let you have more than 16 > decimal digits, or 32 bit binary. You would think by now that a language > could handle any length data. Python does, its "int" type handles numbers of any size, so long as it fits in memory. If you create sufficiently large numbers it may take a while to do arithmetic operations, of course. >> In principle then, char could still be 9 or more bits, but if int8_t is >> required for a *NIX, who would do it? They'd just be making a compatibility >> mess for themselves. > > Is it not a mess already as hardware keeps changing standards. > Look at USB or all the kinds of network protocols. "The nice thing about standards is that there are so many to choose from" -- Prof. David Clark, MIT. >> It's also unclear to me whether one's complement representation would be >> allowed. (Various other representations would probably be prohibited by >> other restrictions.) C certainly has been run on one's complement machines (CDC 6000 series) but I've heard it stated by some who would know that the current standard expects two's complement. Interestingly enough, floating point data is, in IEEE and a number of other formats, sign/magnitude encoded, not two's complement. Some old machines used one's complement for float, though. > My next computer will be 44 bits, if I ever get the routing timing bugs out > the FPGA > prototype card. I can't change the FPGA vender because I can use TTL macros > like 74181, for TTL bread boarding. > With the 74181 I can have any width I want, thus I can play with odd sizes. For extra credit, create a GCC back end for that design. :-) > More I play with my designs, I come to the conclusion that > 32 bits is not ample for a general purpose computer. I think Von Neumann would agree; he picked 40 bits as I recall. There are all sorts of interesting word lengths out there; the strangest I've worked with is 27 bits one's complement. paul
Re: Linux and the 'clssic' computing world
On 9/28/21 12:15 PM, ben via cctalk wrote: > My next computer will be 44 bits, if I ever get the routing timing bugs > out the FPGA > prototype card. I can't change the FPGA vender because I can use TTL > macros like 74181, for TTL bread boarding. > With the 74181 I can have any width I want, thus I can play with odd sizes. > > More I play with my designs, I come to the conclusion that > 32 bits is not ample for a general purpose computer. 64 bits is so, 1960s. How about 128 or 512 bits? Memory and silicon are a lot cheaper than they were back in the day. Why not a variable word length architecture? They were all the rage in the 1950s and 60s. --Chuck
Re: Linux and the 'clssic' computing world
On 9/28/2021 2:15 PM, ben via cctalk wrote: On 2021-09-28 11:43 a.m., Vincent Long standing via cctalk wrote: The C standards are more liberal, and continue to require char types to be 8 or more bits. Was PL/I the only language that would let you select data size for variables? Of course the fine print would not let you have more than 16 decimal digits, or 32 bit binary. You would think by now that a language could handle any length data. Hardly. FORTRAN: INTEGER*4 INTEGER*8 (and sometimes INTEGER*2 - e.g. Sun FORTRAN-77) was common, though never adopted as a standard. Also REAL vs. DOUBLE. COBOL: COMP-1 and COMP-2 for floating point: single and double precision. Pascal, Ada: specified range of values. How that actually got implemented would be implementation dependent. And more, I'm sure. As for any length of data, that becomes a cost/return question. Adding that capability would create no end of headaches for language implementation, so it isn't done. Instead, if one actually needed that, one would define a type (with methods) or a set of functions to accomplish that - and no doubt many exist out on the 'net. Vince Ben. JRJ
Re: Linux and the 'clssic' computing world
On Tue, 2021-09-28 at 17:03 -0500, Jay Jaeger via cctalk wrote: > > On 2021-09-28 11:43 a.m., Vincent Long standing via cctalk wrote: > > > > > The C standards are more liberal, and continue to require char > > > types > > > to be 8 or more bits. > > Was PL/I the only language that would let you select data size for > > variables? Of course the fine print would not let you have more > > than 16 > > decimal digits, or 32 bit binary. You would think by now that a > > language > > could handle any length data. > > > > Hardly. > > FORTRAN: INTEGER*4 INTEGER*8 (and sometimes INTEGER*2 - e.g. Sun > FORTRAN-77) was common, though never adopted as a standard. Also > REAL > vs. DOUBLE. Fortran 90 introduced "kind type parameters" for all types. For REAL, one can use SELECTED_REAL_KIND to ask for a specific number of decimal digits. The standard does not require any minimum number be required. Both "default real" and double precision are required. Many processors provide quad precision. For INTEGER, one can use SELECTED_INT_KIND. Processors are required to provide at least one kind with at least 18 decimal digits. There is no specification which other sizes are required.
Re: Linux and the 'clssic' computing world
On 2021-09-28 2:24 p.m., Paul Koning wrote: My next computer will be 44 bits, if I ever get the routing timing bugs out the FPGA prototype card. I can't change the FPGA vender because I can use TTL macros like 74181, for TTL bread boarding. With the 74181 I can have any width I want, thus I can play with odd sizes. For extra credit, create a GCC back end for that design. :-) Self-compile Small and Bootstrap seem to be forgotten words. So is ASCII 69. I wish they had <- or -> arrow symbols to replace the = 's for assignment. More I play with my designs, I come to the conclusion that 32 bits is not ample for a general purpose computer. I think Von Neumann would agree; he picked 40 bits as I recall. There are all sorts of interesting word lengths out there; the strangest I've worked with is 27 bits one's complement. Was that a drum machime? paul Ben.
RE: Linux and the 'clssic' computing world
> -Original Message- > From: cctalk On Behalf Of Van Snyder via > cctalk > Sent: 28 September 2021 23:34 > To: cctalk@classiccmp.org > Subject: Re: Linux and the 'clssic' computing world > > On Tue, 2021-09-28 at 17:03 -0500, Jay Jaeger via cctalk wrote: > > > On 2021-09-28 11:43 a.m., Vincent Long standing via cctalk wrote: > > > > > > > The C standards are more liberal, and continue to require char > > > > types to be 8 or more bits. > > > Was PL/I the only language that would let you select data size for > > > variables? Of course the fine print would not let you have more than > > > 16 decimal digits, or 32 bit binary. You would think by now that a > > > language could handle any length data. > > > > > > > Hardly. > > > > FORTRAN: INTEGER*4 INTEGER*8 (and sometimes INTEGER*2 - e.g. Sun > > FORTRAN-77) was common, though never adopted as a standard. Also > > REAL vs. DOUBLE. > > Fortran 90 introduced "kind type parameters" for all types. For REAL, one can > use SELECTED_REAL_KIND to ask for a specific number of decimal digits. The > standard does not require any minimum number be required. > Both "default real" and double precision are required. Many processors > provide quad precision. For INTEGER, one can use SELECTED_INT_KIND. > Processors are required to provide at least one kind with at least 18 decimal > digits. There is no specification which other sizes are required. REXX has had this ability from the start. It only does decimal arithmetic, but you can set the number of numeric digits used to whatever you want Dave
Re: Linux and the 'clssic' computing world
> On Sep 28, 2021, at 8:32 PM, ben wrote: > > On 2021-09-28 2:24 p.m., Paul Koning wrote: > >>> ... >>> More I play with my designs, I come to the conclusion that >>> 32 bits is not ample for a general purpose computer. >> I think Von Neumann would agree; he picked 40 bits as I recall. There are >> all sorts of interesting word lengths out there; the strangest I've worked >> with is 27 bits one's complement. > Was that a drum machime? Not a drum machine. Core memory, all solid state -- one of the first, and as far as I know the first commercial product with interrupts standard. Electrologica X1, from 1958. Also its successor the X8, around 1964. The X8 had a drum as a peripheral device, used in the THE operating system for paging virtual memory (512 k words). paul
Re: Linux and the 'clssic' computing world
Nemo Nusquam via cctalk : > I cannot agree. Many developers ensure that their software runs under > their particular distribution and then call it POSIX. Porting to UNIX > systems, such as Solaris or macOS, can be difficult and tedious. (Of > course, this is not a Linux issue.) It's especially frustrating when, after having put in the work, projects refuse even trivial patches for Solaris and derrivatives or sometimes even BSDs because 'who uses that anyway'. (I include the patches in pkgsrc instead.) Sijmen
Re: Linux and the 'clssic' computing world
On Mon, Oct 25, 2021 at 10:18:51AM +0200, Sijmen J. Mulder via cctalk wrote:
[...]
> It's especially frustrating when, after having put in the work, projects
> refuse even trivial patches for Solaris and derrivatives or sometimes even
> BSDs because 'who uses that anyway'. (I include the patches in pkgsrc
> instead.)
Solaris is owned by Oracle, a bunch of litigious bastards who readily
freeload off Linux and other Open Source projects but are rather reluctant
to give back much beyond gateway drugs to their closed-source offerings. I
note the existence of CDDL which appears deliberately designed to clash with
the GPL. That sort of thing can leave a nasty taste in the mouth.
The specific details differ, but this basically also applies to Microsoft
and Windows.
Anyway, this hypothetical patch submitter has apparently put in minimal
effort ("trivial patches") and now implicitly expects the project maintainer
to integrate it immediately, and then do the thankless task of maintaining
and testing it indefinitely on (multiple releases of) a closed-source
platform which is actively hostile to their work. For free, presumably.
To a rough approximation, nobody uses Solaris. It's not a good use of any
developer's time to support it unless they're being paid to do so.
Re: Linux and the 'clssic' computing world
On Mon, 25 Oct 2021 at 11:39, Peter Corlett via cctalk
wrote:
>
> On Mon, Oct 25, 2021 at 10:18:51AM +0200, Sijmen J. Mulder via cctalk wrote:
> [...]
> > It's especially frustrating when, after having put in the work, projects
> > refuse even trivial patches for Solaris and derrivatives or sometimes even
> > BSDs because 'who uses that anyway'. (I include the patches in pkgsrc
> > instead.)
>
> Solaris is owned by Oracle, a bunch of litigious bastards who readily
> freeload off Linux and other Open Source projects but are rather reluctant
> to give back much beyond gateway drugs to their closed-source offerings. I
> note the existence of CDDL which appears deliberately designed to clash with
> the GPL. That sort of thing can leave a nasty taste in the mouth.
>
> The specific details differ, but this basically also applies to Microsoft
> and Windows.
I think "Solaris and derivatives" was a easier way than saying
SmartOS, Illumos and OpenIndiana as well as any poor souls running
Solaris (some of which may be running older versions on Sparc kit)
> Anyway, this hypothetical patch submitter has apparently put in minimal
> effort ("trivial patches") and now implicitly expects the project maintainer
> to integrate it immediately, and then do the thankless task of maintaining
> and testing it indefinitely on (multiple releases of) a closed-source
> platform which is actively hostile to their work. For free, presumably.
I'm... pretty sure SmartOS/Illumos are actively friendly to open
source work - last I checked Joyent provided pkgsrc config to build
around 20,000 packages and had a policy of trying to feed back changes
upstream https://pkgsrc.joyent.com/install-on-illumos/
> To a rough approximation, nobody uses Solaris. It's not a good use of any
> developer's time to support it unless they're being paid to do so.
You could easily s/Solaris/Solaris,BSD,non(x86,arm,riscv),etc/
Its obviously entirely up to the members of a project to decide on
what to spend their time, and specifically what they are interested in
supporting, though if there is an active policy to not want to support
certain platforms it would help to have a specific statement in the
README to avoid other people wasting their time and annoying project
members by sending in unwanted patches and then complaining that the
patches are being ignored.
If its a matter of the patches needing more work, then that's always a
perennial problem, for just about all platforms and projects. Maybe
submitters of patches orm some platforms need to do more work, so they
should be told that
tl;dr if there are hoops to jump through for some platform patches,
indicate the hoops. If the path is closed, make it clear up front..
David
Re: Linux and the 'clssic' computing world
Peter Corlett via cctalk :
> On Mon, Oct 25, 2021 at 10:18:51AM +0200, Sijmen J. Mulder via cctalk wrote:
> [...]
> > It's especially frustrating when, after having put in the work, projects
> > refuse even trivial patches for Solaris and derrivatives or sometimes even
> > BSDs because 'who uses that anyway'. (I include the patches in pkgsrc
> > instead.)
>
> [...]
>
> Anyway, this hypothetical patch submitter has apparently put in minimal
> effort ("trivial patches")
'Even' trivial patches, not only trivial patches. I can understand
rejecting something that will take real effort to review and merge.
> and now implicitly expects the project maintainer
> to integrate it immediately, and then do the thankless task of maintaining
> and testing it indefinitely on (multiple releases of) a closed-source
> platform which is actively hostile to their work. For free, presumably.
This is a rather harsh take on someone submitting a shell compatibility
fix, or a linker flag, or an autoconf check, etc. No one is asking for
'immediate' or 'indefinite' anything. It's perfectly fine to accept
compatibility patches and not commit to officially support that
platform.
Re: Linux and the 'clssic' computing world
One major issue with any patch or code change is regression testing.
Any given change may fix a particular issue but what are the
ramifications for the entire system across all circumstances.
Though a change or fix may seem simple to integrate, the time is takes
to fully vet that fix could take weeks depending on the system.
On 10/27/2021 8:02 AM, Sijmen J. Mulder via cctalk wrote:
Peter Corlett via cctalk :
On Mon, Oct 25, 2021 at 10:18:51AM +0200, Sijmen J. Mulder via cctalk wrote:
[...]
It's especially frustrating when, after having put in the work, projects
refuse even trivial patches for Solaris and derrivatives or sometimes even
BSDs because 'who uses that anyway'. (I include the patches in pkgsrc
instead.)
[...]
Anyway, this hypothetical patch submitter has apparently put in minimal
effort ("trivial patches")
'Even' trivial patches, not only trivial patches. I can understand
rejecting something that will take real effort to review and merge.
and now implicitly expects the project maintainer
to integrate it immediately, and then do the thankless task of maintaining
and testing it indefinitely on (multiple releases of) a closed-source
platform which is actively hostile to their work. For free, presumably.
This is a rather harsh take on someone submitting a shell compatibility
fix, or a linker flag, or an autoconf check, etc. No one is asking for
'immediate' or 'indefinite' anything. It's perfectly fine to accept
compatibility patches and not commit to officially support that
platform.
