> On Feb 3, 2025, at 2:08 PM, Donald Whittemore via cctalk <cctalk(a)classiccmp.org> wrote: > > I am an old mainframe guy. I could give you my COBOL deck of cards or the compile listing. You could pour through the code looking for nefarious/malicious code. I then hand you the object deck. You have no idea if it matches the code you looked at. The only way you could be sure is to compile the code I gave you and use your own object deck.

Open source, properly defined, means not just that you can see the code but that you have the possibility of building it. If DeepSeek is advertised as open source but you can't create your own executable, that's clearly false advertising. The language doesn't matter so long as it's an available one. If you don't know it you can learn. For example, you could write open source code in COBOL, that's perfectly valid. Not a whole lot of people are left who can check your work, but anyone who wants to can learn the necessary basics. BTW, strictly speaking you should also suspect the compiler. See "Reflections on trusting trust". paul

I suspect for the several million cards you'd need you could easily get some local paper company to tool up and make them fairly reasonably :-)

You do not have that absolute ability to know. You can rely on a virus scanner to help but that’s not absolute either.

On Mon, Feb 3, 2025 at 12:51 PM Donald Whittemore via cctalk < cctalk(a)classiccmp.org&gt; wrote: How do you know a closed-source executable is safe? Hackers have installed vulnerabilities into closed source software. As previously said, even if you have the code expertise and ability to re-compile you're trusting your compiler. You seem to be looking for a guarantee that doesn't exist. Now whether 1,000,000 eye balls looking for bugs in open source code results in a "safer" end product given that there are an arbitrary number of bad actors who can also look for vulnerabilities is an issue of legitimate debate. Of course many of these are already looking through closed source binaries for vulnerabilities.

If safety is of paramount importance, a supplied object or executable should never be used. That’s just common sense. Sent from my iPhone

There is something there, though. If you use a binary supplied by a packager you have to worry not just about the bugs in the original open source project, but also about bugs added by patches created by the packager. There is a notorious example of one of the Linux distributions (Debian?) inserting a fatal security bug into openSSL. The original was right, but someone made a patch that clearly demonstrated an utter lack of clue.

On 2025-02-03 3:52 p.m., Chuck Guzis via cctalk wrote: I use a LAND LINE, I know the phone works.

I need it top secret I have shoe phone.

It is not malware, but good marketing to have to upgrade on every release. Ben. PS. is me or just the internet browsing getting so full of ads and questionable redirects that on can't use it any more.

Open source, properly defined, means not just that you can see the code but that you have the possibility of building it. If DeepSeek is advertised as open source but you can't create your own executable, that's clearly false advertising.

On Feb 3, 2025, at 3:40 PM, Alexander Schreiber via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: ... On top of that: A lot of those LLMs are build on theft at an epically large scale. They hovered up everything in sight (and then some) without even pretending to care about intellectual property rights - e.g. the NY Times has taken OpenAI to court because they managed to make the OpenAI LLMs spit out long verbatim fragments of NY Times content. The hilarious part is that DeepSeek essentially stole from OpenAI that which OpenAI previously stole from everyone else and OpenAI is very angry about the lack of honor among thieves or something ;-)

On Feb 3, 2025, at 13:15, Alexander Schreiber via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: On Mon, Feb 03, 2025 at 03:54:31PM -0500, Paul Koning via cctalk wrote: I just call them "bullshit generators", based on Harry Frankfurt's "On Bullshit". That's probably a lot less harmless than what already happened: More than one model had to be pulled back and deleted (as well as the corpus it was trained from) because its makers had unknowingly hovered up CSAM content, trained the model with it and it was cheerfully spitting that filth out again. If you blindly hover up the entire Internet, you're going find stuff that you probably don't want to have on your systems. Kind regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison

Alex, your posts come over with the “flag” set (i get a red “flag” on my iphone). Did you mean to flag all your responses for some reason ?

On Mon, Feb 03, 2025 at 07:08:32PM -0000, Donald Whittemore via cctalk wrote: On top of that: A lot of those LLMs are build on theft at an epically large scale. They hovered up everything in sight (and then some) without even pretending to care about intellectual property rights - e.g. the NY Times has taken OpenAI to court because they managed to make the OpenAI LLMs spit out long verbatim fragments of NY Times content. The hilarious part is that DeepSeek essentially stole from OpenAI that which OpenAI previously stole from everyone else and OpenAI is very angry about the lack of honor among thieves or something ;-)

On Feb 3, 2025, at 12:57, Ethan Dicks via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: On Mon, Feb 3, 2025 at 2:08 PM Donald Whittemore via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: That's basically true but "why Open Source" goes way beyond that. From the start, Open Source wasn't focused on "this is good for security" but "I should have the right to repair". In the face of 100% proprietary software, users have to beg the vendor to fix bugs, add features, then there's what happens to products that are abandoned and the OS moves on and updates are mandatory (system calls, adding SMP spinlocking (done that myself), and more). At the root of Open Source is you, the user, have the right to the source code. In the early days, that's as far as it went but especially after the Morris Worm, security became very important, Open Source afforded users the ability to inspect the code for vulnerabilities in ways that you could not if all you had was the binaries. . Because it allows those folks with skills (or money to hire out) the _ability_ to modify software, to build on the work of others. Now, it's not just one person or company writing code, anyone it touches can have a shot. Not all things are for all people. I don't know COBOL (I decided that back in 1978) so I would be the wrong person to evaluate or extend that, but there's plenty of stuff I can and do work on. I'm a contributor to several Open Source projects. I'm happy to help on them because I have the skills and I have the interest. Not everyone does. Some people just download and consume, and that's fine too. That's on you. -ethan

But open source should have fixed versions, if possible.

It was thus said that the Great ben via cctalk once stated: You will have to evaluate the C compiler in question. The C Standard covers not only the C language, but of a library as well, so your concerns about bugs applies to both the compiler and the library that comes with it. And it's not like there's just one C compiler everybody uses. While a C99 compiler will work with K&R style code, and may very well generate better code, there may still be issues because newer C compilers take advantage of undefined behavior to optimize the code, to the degree that once valid C code now exhibits bugs. For instance, this fragment of code: /* a and b are signed integers */ if (a + b < a) /* check for overflow */ handle_it(); may very well be removed because signed overflow in C is undefined, and by definition (per the compiler writers) a programmer will never intentionally invoke undefined bahavior, the code can be removed because it will never be true (and this is current behavior! Really!). So it could be that C99 will work for you, it might not. A C89-only compiler will work---it'll still accept K&R style code, and it will be old enough to avoid the "exploit undefined behavior for better benchmarks" compilers we have today. Or find an old K&R C compiler. They still exist, but generate very bad code. -spc

On 2/3/25 15:47, ben via cctalk wrote: Really? The x86 family does indeed have stack-based addressing. In particular, The BP register holds the base of the stack frame and the assumed segment is SS. Even the lowly 8085 has some (undocumented) nod toward stack addressing.

--Chuck

On 2025-02-03 5:06 p.m., Chuck Guzis via cctalk wrote: Was the X86 family meant for pascal type languages? Other than the small model, every thing is a hack.

Do you mean you want a compiler to generate 16-bit code? Or be compiled as a 16-bit program to run under Linux? If the later, it's not supported, or at least, not supported by default [1]. It took me only a few minutes to find it. There's the GIT repository at https://github.com/lkundrak/dev86 When I did the compile, there compiler did throw up some warning even though none were specified because the code is that old, but I did get an executable: [spc]matrix:~/repo/dev86/bcc>./bcc Usage: ./bcc [-ansi] [-options] [-o output] file [files].

The 8086/8088 was never meant to have stack based addressing? Um, the 8086/8088 has an entire register dedicated to that (BP by the way). The limitation with BP is that it's bound to the SS segment by default, and in some memory models that becomes an issue, but to say it doesn't have stack based addressing? Methinks you are misrembering here.

And self-hosting a C compiler on a small system isn't easy with 64K of RAM total. The PDP-11 had at least 64K code space and 64K data space to work with.

-spc [1] I have run a 16-bit MS-DOS exectuable under Linux, but it was on a 32b x86-based Linux system with a custom program I wrote to run it. I even had to emulate several MS-DOS system calls to get it to work (since I needed input from a Unix program to be piped in, I couldn't use DOSBox for this). [2] Dated July 27, 2002, which is before git existed, but this repository was converted to git at some point.

On Mon, Feb 3, 2025, 5:37 PM Sean Conner via cctalk &lt;cctalk(a)classiccmp.org wrote: > It was thus said that the Great ben via cctalk once stated: > > On 2025-02-03 3:32 p.m., Sean Conner via cctalk wrote: > > > > > So it could be that C99 will work for you, it might not. A C89-only > > >compiler will work---it'll still accept K&R style code, and it will be > old > > >enough to avoid the "exploit undefined behavior for better benchmarks" > > >compilers we have today. Or find an old K&R C compiler. They still > exist, > > >but generate very bad code. > > > > > -spc > > > So where does on find a older version, on a current Linux build. > > we don't support it!!! We only port the latest intel CPU. > > > You have 32 bit compilers, or bigger. I might want a 16 bit compiler > > under Linux. > Do you mean you want a compiler to generate 16-bit code? Or be compiled supported, > or at least, not supported by default [1]. I have Vexix86 emulator that does much the same thing. > I was hoping to use Embeddable Linux Kernel Subset (ELKS) BCC compiler > > and the 6809 code generator, but NO they had to rewrite it just for the > > 386. > It took me only a few minutes to find it. There's the GIT repository at > https://github.com/lkundrak/dev86 > Yes, it requires git to initially download it, but it's available. And it written > for Unix anyway, or at least it appears so from the initial importation > into > git [2]: Bcc was written by Bruce Evans to have a compiler for 386BSD for the boot loader (among other reasons). It dates back to the late 80s or so. It's one of the reasons we in FreeBSD held onto K&R constructs in certain areas of the tree for so long. Well after gcc / binutils could generate the small bits of 16bit code the loader eventually required.. Warner /* bcc.c - driver for Bruce's C compiler (bcc) and for CvW's C > compiler */ > /* Copyright (C) 1992 Bruce Evans */ > #define _POSIX_SOURCE 1 > #include <sys/types.h> > #include <sys/stat.h> > #include <sys/wait.h> > #include <unistd.h> > #include <signal.h> > #include <stdlib.h> > #include <string.h> > The latest version was ported to MS-DOS at some point. I was able to > compile the latest version (on a 32-bit Linux system---I no longer have a > MS-DOS C compiler so I couldn't test on that), but the code is C89, so in > theory, you could use any MS-DOS C compiler post 1989 to compile the code > if > you so wish. > When I did the compile, there compiler did throw up some warning even > though none were specified because the code is that old, but I did get an > executable: > [spc]matrix:~/repo/dev86/bcc>./bcc > Usage: ./bcc [-ansi] [-options] [-o output] file [files]. > > Open source is popular because it was free. > > > No compiler generates bad code,just some hardware was never meant to > > have stack based addressing, like the 6502 or the 8088/8086. > > Look at the mess that small C has for 8088/8086 code gen. > > Self hosting never seems to be important for C compiler on a small > machine. > The 8086/8088 was never meant to have stack based addressing? Um, the > 8086/8088 has an entire register dedicated to that (BP by the way). The > limitation with BP is that it's bound to the SS segment by default, and in stack > based addressing? Methinks you are misrembering here. > And self-hosting a C compiler on a small system isn't easy with 64K of > RAM > total. The PDP-11 had at least 64K code space and 64K data space to work > with. > -spc > [1] I have run a 16-bit MS-DOS exectuable under Linux, but it was on a work > (since I needed input from a Unix program to be piped in, I > couldn't > use DOSBox for this). > [2] Dated July 27, 2002, which is before git existed, but this > repository was converted to git at some point.

Nitpick: Not CRC checksums, as those are only good to detect gross data

Nitpick: Not CRC checksums, as those are only good to detect gross data

On Feb 3, 2025, at 5:32 PM, Sean Conner via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: It was thus said that the Great ben via cctalk once stated: You will have to evaluate the C compiler in question. The C Standard covers not only the C language, but of a library as well, so your concerns about bugs applies to both the compiler and the library that comes with it. And it's not like there's just one C compiler everybody uses. While a C99 compiler will work with K&R style code, and may very well generate better code, there may still be issues because newer C compilers take advantage of undefined behavior to optimize the code, to the degree that once valid C code now exhibits bugs. For instance, this fragment of code: /* a and b are signed integers */ if (a + b < a) /* check for overflow */ handle_it(); may very well be removed because signed overflow in C is undefined, and by definition (per the compiler writers) a programmer will never intentionally invoke undefined bahavior, the code can be removed because it will never be true (and this is current behavior! Really!).