On 02/03/2025 2:36 PM EST Fred Cisin via cctalk <cctalk(a)classiccmp.org> wrote:

That deck would be difficult to even source enough blank cards for. :-)

cctalk(a)classiccmp.org> wrote: 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. be open source but I have no way to create my own executable. Besides, I don’t know what language it is written in but I bet I have no expertise in it. No way to for me to identify nasty code. I am running is the result of that code. 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.

If I am not proficient in the source language or have the ability to create my own executable I don’t see how open source is ‘safer’ for the average Joe or app.

On Feb 3, 2025, at 12:51, Donald Whittemore via cctalk <cctalk(a)classiccmp.org> wrote: If I don’t have the code expertise or compiling capability how do I know the executable is safe?

If I don’t have the code expertise or compiling capability how do I know the executable is safe?

On Feb 3, 2025, at 12:42, Donald Whittemore via cctalk <cctalk(a)classiccmp.org> wrote: I was not being specific on language or the app. I was questioning the general impression that open source is safe(r). If I am not proficient in the source language or have the ability to create my own executable I don’t see how open source is ‘safer’ for the average Joe or app.

On Feb 3, 2025, at 4:08 PM, Chuck Guzis via cctalk <cctalk(a)classiccmp.org> wrote: On 2/3/25 12:51, Wayne S via cctalk wrote: Seems to be a cognitive disconnect, here.

You miss my tongue-in-cheek observation. iPhone software isn't, to bhe best of my knowledge, open-source. How does one know or determine that there's not malware in vendor-supplied software?

--Chuck

PS. is me or just the internet browsing getting so full of ads and questionable redirects that on can't use it any more.

On Tue, 4 Feb 2025 at 00:55, ben via cctalk <cctalk(a)classiccmp.org> wrote: FWIW, I find the combination of Firefox and the uBlock Origin extension stops me seeing most of them. I also have Privoxy installed and configured, but I think nobody tests it any more in Ubuntu. It doesn't seem to work in 22.04 or 24.04.

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 <cctalk(a)classiccmp.org> 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 <cctalk(a)classiccmp.org> 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 <cctalk(a)classiccmp.org> wrote: On Mon, Feb 3, 2025 at 2:08 PM Donald Whittemore via cctalk <cctalk(a)classiccmp.org> 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!).