From tytso at mit.edu Sun Nov 10 14:27:37 2024 From: tytso at mit.edu (Theodore Ts'o) Date: Sat, 9 Nov 2024 23:27:37 -0500 Subject: [COFF] [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: <20241109222334.gy27tvoh5fpbovts@illithid> References: <20241105010937.GC18296@mcvoy.com> <20241105015400.GD18296@mcvoy.com> <20241109182955.m2uoditi3muvg2vg@illithid> <20241109203001.GA1828993@mit.edu> <20241109222334.gy27tvoh5fpbovts@illithid> Message-ID: <20241110042737.GB21941@mit.edu> (Moving this thread over to COF, since we've gotten pretty far afield from the TUHS list's charter.) On Sat, Nov 09, 2024 at 04:23:34PM -0600, G. Branden Robinson wrote: > > The Linux Foundation does not exclusively own the copyright on the > > Linux kernel. The copyright is jointly owned by all of the > > contributors of the Linux kernel. This makes it quite unlike the FSF > > projects, where contributions to FSF project require a copyright > > assignment[1]. > > That's a myth. It is the FSF's stated _preference_, but it is a > negotiable point. For example, Thomas Dickey negotiated reversion of > copyright to himself when becoming ncurses maintainer 26 years ago.[A] In the web site I quoted, the fact that there is an option not to do the copyright assignment was apparently conveniently ommitted. And in the early 1990's, I *personally* tried negotiating to not do the copyright assignment directy with the FSF, and I was told to go to heck. Given that I *had* taken a legal class from the MIT Sloan School (Legal issues for the I/T Manager), I knew what the word "indemnify" meant, and there was no way in the world I was going to sign the damned FSF copyrioght legal paperwork, and I told the FSF so. The only other alternative was my not contributing to the GNU Project. The FSF may have since relaxed their poition in the past 30 years, but it's not something that they've really admitted (again, see the FSF web page I referenced). My theory is that the only reason *why* they relaxed their position was that it would have made GNU even more irrelevant if they hadn't (e.g., people don't have to contribute to GCC; if it's more friendly and easier to contribute to Clang.) > But is it true for less prestigious projects or individual contributors > with no clout to speak of? Well, apparently in the early 1990's I didn't have any clout in the eyes of the FSF. :-) Probably for the best, all things considered. > With respect to the Linux kernel in particular, it seems the GPL _in > practice_ imposes no obligations. That was my point. Little > enforcement is visible. As far as "public shaming" goes, I've seen it > from the FSF and the Software Freedom Conservancy, not from the LF. > > Give me examples of the LF leaning on infringers and getting results! > I want them! OK, I see where you are coming from here. And I think the main isue is that the goals of the Linux community are quite different from that of the FSF. (And note that I say the Linux community, since these atttudes predate the founding of the Linux Foundation by **years** and existed across many developers, some of whom, like me, weren't yet hired by a Linux corporation; I was at MIT, and my day job was TL for MIT Kerberos and IPSEC working group chair for the IETF as well as serving on MIT Network Operations.) The Linux attitude was a focus on the social contract between *developers*. If you improve the Linux kernel, we expect that you contribute those changes back. So what we care about is the company that has 9,000 out of tree patches, representing hundreds of engineer years of SWE investment. And here, this is where in practce, GPL social contract becomes self-enforcing. It is in the interest of the company who is interested in keeping up with upstream to get the changes back upstream. The FSF and Richard Stallman has a much bigger focus on the ability of users to be able to get the sources for GPL'ed code, make changes, and then install that changed sources on their hardware. That's a fine goal, and I respect that some people might have that as a very strong policy preference and something that they care about. It's just that it's a very different goal than what most Linux kernel developers care about. (And again, this wasn't shaped by my employers; I and many of the people I know had these preferences long before the Linux companies formed and started hiring us.) So take for example, the hypothetical someone who makes a tiny change to the Linux kernel to create a crappy AI gadge in a square orange box. Call it, for the sake of argument, the "Squirrel S1". :-) As far as the Linux kernel community is concerned, the Squirrel S1 is irrelevant. It has no interesting technology that we would care about, and while it might be sad that a user might not be able to change the software in the S1, either because the manufacturer didn't meet their GPL oligations, or the hardware was locked down and the GPL2 does't have an anti-Tivo clause it it, in my opinion, the enforcement is self-executing. If you're a user, and can't make changes, and you want to, then don't fork over $199 for the Squirrel S1! >From the FSF's Free Softare perspective, they obviously have a very different goal. They believe all users should have the ability to access the source code and modify software on a Squirrel S1, whether they want to doit or not, and regardless of whether that might cause the device to become more expensive. They believe this is a core user freedom, that should never be abograted. I respect those people who have those feelings. But obviously people in the BSD camp don't share those priorities --- and in the Linux kernel community, while we believe the GPL2 is a great way of expressing the social expectations between developers, we don't necessarily share the same attitudes as Mr. Stallman. Could someone who has some copyright ownership try do some vexatious lawsuits in order to (legally) extort money out of companies who are infringing the GPL? Sure; although I'll note that for the targets of those lawsuits, I'm not so sure that they would see that much difference between a Patrck McHardy and the SFC. And at least personally, the amount of help that I would give a Patric McHardy and an SFC lawsuit is pretty much the same; zero, and my personal opinion is that they are not really helpful, since my goal is to have more companies being *happy* to contribute to Linux; not to feel coerced and forced to contribute by sullenly dropping a bunch of code to comply with the GPL and then walking away. > > So why do companies join the Linux Foundation? Well, there are a > > number of benefits, but one very important one is that it provides a > > way for companies to directly collaborate with funded programs to make > > improvements to Linux without worrying about anti-trust conerns. > > Are these concerns anything more than notional? Well, I was at the IBM Linux Technology Center when we were first working on standardizing ISO/IEC 23360-2:2006. This was well after the FTC consent decree was dissolved in 1996, and while a Republican (George W. Bush) was president --- and I can tell you that it *was* something that my employer at the time very much cared about. We got very clear instructions about what we could and could't do when we participated with OSDL and Linux Foundation work groups, and we had madatory training regarding how to not get in trouble with anti-trust enforcers. > But I do sympathize with WG14 and the Austin Group; following recent > developments with C23 and POSIX 2014, it seems that ISO is bent > on giving them a hard time. Maybe ISO/IEC, or certain players within, > are trying to shed some mass, and/or don't see C and Unix as worth > standardizing anymore. Old and busted. What's the new hotness? ISO/IEC participation has always been heavyweight, and companies are quite strategic about the understanding the cost benefit tradeoffs of participating in ISO. This has been true for years; and once various European government customers stopped requiring ISO standardization, IBM and HP pretty quickly stopped funding the standards tech writer and those of us who were on the US National Body represenatives to ISO/IEC for 23360. (And not just the US; the various companies working on the ISO/IEC 23360 effort had carefully made sure that to have their employees in other country's national bodies, to make sure the fix was in. This was not too different from what Microsoft was accused of doing while standardizing ISO/IEC 29500, although not to the same scale; there were many more countries' national bodies involved with ISO/IEC 29500. So when you say "ISO" is giving the Austin Group a hard time, I'd ask the question, "who on ISO"? And what company do they work for; or if they are an independent contractor, which company might be paying them at the time; and what the agenda of those company(s) might be?) Am I super cynical about ISO/IEC standards? Perhaps. :-) - Ted P.S. Obviously, not *everyone* in the Linux ecosystem feels this way. For example, there are many people in Debian who are much more aligned with the FSF. After all, they are one of the few distros that will use the GNU/Linux terminology demanded by Stallman. But I have talked to many Linux kernel developers over the past 30+ years, and I think have a pretty good sense of what the bulk of the "old-timers" priorities have been. After all, if we had been much more aligned with the FSF's philosophies, perhaps we would have worked on GNU/HURD isntead. :-) From crossd at gmail.com Mon Nov 18 07:33:36 2024 From: crossd at gmail.com (Dan Cross) Date: Sun, 17 Nov 2024 16:33:36 -0500 Subject: [COFF] Fwd: [ih] NYT: Thomas E. Kurtz, a Creator of BASIC Computer Language, Dies at 96 In-Reply-To: <01f401db3932$4b17f190$e147d4b0$@glassblower.info> References: <01f401db3932$4b17f190$e147d4b0$@glassblower.info> Message-ID: I don't believe this was sent here yet. BASIC is much maligned, but was important nonetheless. - Dan C. ---------- Forwarded message --------- From: Tony Patti via Internet-history Date: Sun, Nov 17, 2024, 3:50 PM Subject: [ih] NYT: Thomas E. Kurtz, a Creator of BASIC Computer Language, Dies at 96 To: https://www.nytimes.com/2024/11/16/technology/thomas-kurtz-dead.html (published yesterday November 16, 2024) "At Dartmouth, long before the days of laptops and smartphones, he worked to give more students access to computers. That work helped propel generations into a new world." Me too, I owe it all to BASIC. Because 5 decades earlier, via an ASR 33 Teletype and acoustic coupler at 110 baud to a remote HP 2100, BASIC was my introduction to computers and programming. Tony Patti (ARPAnet NIC IDENT "TP4") -- Internet-history mailing list Internet-history at elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Nov 18 08:17:35 2024 From: clemc at ccc.com (Clem Cole) Date: Sun, 17 Nov 2024 17:17:35 -0500 Subject: [COFF] Fwd: [ih] NYT: Thomas E. Kurtz, a Creator of BASIC Computer Language, Dies at 96 In-Reply-To: References: <01f401db3932$4b17f190$e147d4b0$@glassblower.info> Message-ID: Indeed. The problem is it took a life of its own beyond what really should have been used. When it was the original Dartmouth K&K language I learned in 1967 on DTSS it was much simpler. HP added to it a small amount with the 2100 implementation and the DEC10 even more so, and by the later RSTS implementations DEC expanded it and added way more to it than K&K described in the goals, first papers and book. Although, with care, the original examples I think with run on RSTS. But, in all of those cases there was much more computer behind it and there was some argument the added complexity was worth it to expose “system’s features.” The problem came in that because the core language K&K described was so simple it was easy to implement on 8-bit systems. But by then the RSTS extension had started to become more popular however the 8-bit micros lacked the systems-ness of even something like RSTS. The result of the micro versions of BASIC was Frankenstein’s creature - which was really hard to love unless you knew no better. And here in was the issue, because the micros were inexpensive and they all included a simple BASIC you sort of warped a generation or two without real guidance. And because there was little standardization in the system interface anyway, what you saw was more and more ugliness. By the time the micros grew up enough to support more system features, MS was full bore into trying to own everything so there private extensions became ‘standardize in there world but no where else.” And MS eventually gave away the primary idea behind K&K in the first place - really simple, so any one could use it. Thus make it a good first language. But try running any of the K&K examples from there book (I still have a copy btw) with VBASIC. By then teacher has given up and switched to better teaching languages, al biet, ones that did require a bit more computer system to expose. Clem Sent from a handheld expect more typos than usual On Sun, Nov 17, 2024 at 4:33 PM Dan Cross wrote: > I don't believe this was sent here yet. BASIC is much maligned, but was > important nonetheless. > > - Dan C. > > ---------- Forwarded message --------- > From: Tony Patti via Internet-history > Date: Sun, Nov 17, 2024, 3:50 PM > Subject: [ih] NYT: Thomas E. Kurtz, a Creator of BASIC Computer Language, > Dies at 96 > To: > > > https://www.nytimes.com/2024/11/16/technology/thomas-kurtz-dead.html > > (published yesterday November 16, 2024) > > > > "At Dartmouth, long before the days of laptops and smartphones, > > he worked to give more students access to computers. > > That work helped propel generations into a new world." > > > > Me too, I owe it all to BASIC. > > Because 5 decades earlier, via an ASR 33 Teletype and acoustic coupler at > 110 baud > > to a remote HP 2100, BASIC was my introduction to computers and > programming. > > > > Tony Patti > > (ARPAnet NIC IDENT "TP4") > > > > -- > Internet-history mailing list > Internet-history at elists.isoc.org > https://elists.isoc.org/mailman/listinfo/internet-history > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Mon Nov 18 09:43:18 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 17 Nov 2024 17:43:18 -0600 Subject: [COFF] Fwd: [ih] NYT: Thomas E. Kurtz, a Creator of BASIC Computer Language, Dies at 96 In-Reply-To: References: <01f401db3932$4b17f190$e147d4b0$@glassblower.info> Message-ID: <20241117234318.vx5ygtduutcsmiav@illithid> I have a testimonial to offer as a member of the generation who really did grow up using 8-bit micros and Microsoft BASIC... > On Sun, Nov 17, 2024 at 4:33 PM Dan Cross wrote: >> BASIC is much maligned, but was important nonetheless. At 2024-11-17T17:17:35-0500, Clem Cole wrote: [...] > But, in all of those cases there was much more computer behind it and > there was some argument the added complexity was worth it to expose > “system’s features.” Yes. I think Wozniak's Apple I made an excellent choice by booting into a monitor, not a specific language interpreter. Microsoft of course did not make that decision. They had a BASIC, and "the only thing that matters in this business is volume", as Gates has been quoted saying, so it was to their advantage to funnel all micro users down a cattle run if they could. And they did. And so did Apple, later. > The problem came in that because the core language K&K described was > so simple it was easy to implement on 8-bit systems. This was true of Forth, too. I knew of its existence (and Pascal, and COBOL) when I was a kid, thanks to magazines like _80 Microcomputing_, but didn't get to experiment with it in person until GNU Forth (also I had a chance to play with a Canon Cat for a time--that was pretty neat). > But by then the RSTS extension had started to become more popular > however the 8-bit micros lacked the systems-ness of even something > like RSTS. The result of the micro versions of BASIC was > Frankenstein’s creature - which was really hard to love unless you > knew no better. When I learned that micro BASICs all threw out Dartmouth's MAT operators, I was pretty annoyed. Even with a rudimentary exposure to matrix algebra in high school I could tell that they were the sort of computational application that screamed for automation by computer. Unless the machine sat in the corner of the room as a toy and was operated only by people who didn't write (or even modify) programs in the first place, and had zero curiosity about programming, I think the prevalence of the "forever corrupted by BASIC" specimen is overstated by several orders of magnitude. It was impossible to operate a TRS-80, an Apple, or a Commodore without being aware of alternatives to BASIC as a programming language-- foremost, the availability of machine language. The hobbyist magazines, like the aforementioned 80 Micro, the _Rainbow_ for a Moto 6809-based machine (nothing to do with the DEC product), and even Radio Shack's own "Microcomputer News" monthly, which absolutely was dedicated to flogging only products they sold from their own stores, ran features or columns on machine/assembly language programming in practically every issue. (The last went so far as to run a series presenting the architecture and some of the organization of the Sharp PC-1500/TRS-80 PC-2 "pocket computer". I would attach it for the list's amusement, but the PDF is too big. The author was Bruce Elliott.) ML was inescapable. It was blindingly faster than BASIC and necessary to program certain features of the hardware that Microsoft or its licensees didn't get around to abstracting in the language. Considering games, collections like David Ahl's were largely portable to help protect sales, and limited to Teletype-like interaction because that's often the environment whence they originated. But there were hardly any commercial game programs for the micros that _didn't_ poke into RAM for device configuration, contrive to poke ML subroutines for speed or obfuscation, or were just outright written in ML. To be unaware of alternatives to BASIC on an 8-bit macro was to achieve a miraculous feat of ignorance. Granted, I'm sure we've all met at least one programmer in our lives who fit that description. But a familiarity with BASIC likely wasn't their problem. An even halfway serious 8-bit micro user was never unaware of the underlying ISA. William Barden, Jr. wrote multiple bestselling books on assembly language programming, and he had competition. To not even be tempted to go to the "bare metal" on these machines would be a feat of self-restraint that would tax even the sternest ascetic. > And here in was the issue, because the micros were inexpensive and > they all included a simple BASIC you sort of warped a generation or > two without real guidance. And because there was little > standardization in the system interface anyway, what you saw was more > and more ugliness. By the time the micros grew up enough to support > more system features, MS was full bore into trying to own everything > so there private extensions became ‘standardize in there world but no > where else.” Alternatives to Microsoft's dialect of BASIC were known and sold, sometimes bundled with alternatives to the vendor's OS. Frequently these had better feature sets and/or higher performance than MS BASIC. They had to, to survive at all in the market. Microware's BASIC-09, a really disciplined dialect for the time that I feel pushed BASIC in the direction of Pascal as far as it could, was an eye-opener to me and prepared me well to encounter Pascal and C for real. And again, thanks to hobbyist magazines and culture I knew of the existence of those alternatives long before I got to experiment with them. One of the nice features about the M6809-based Color Computer 2, was that it shipped enough RAM chips for the entire address space along with its ROM. That meant that while part of the reset sequence copied the ROM into RAM, you could then get rid of it, replacing it with something else (usually an OS). You could then enjoy a BASIC-free, or even Microsoft-free, runtime environment. Again, the "(MS) BASIC is the only way" cohort must comprise (a) mythical beings, (b) mindless Microsoft boosters, and (c) the supremely incurious. I think the trope of maligning BASIC is more about maligning people, hence the emphasis on programmers supposedly being irreversibly brain damaged by having acquired competence in the language. Some people love to construct hierarchies and pecking orders, and often the person with the most prescriptions for who shall get pecked, and why, has a startlingly unimpressive beak for programming. > By then teacher has given up and switched to better teaching > languages, al biet, ones that did require a bit more computer system > to expose. Relatively few of us would go back to a Unix that would fit into a PDP-11/45 as a daily driver, either. ;-) At the risk of getting back on topic, I reviewed Kemeny & Kurtz's _Back to BASIC_ 15 years ago. https://www.goodreads.com/book/show/2140350.Back_to_BASIC?from_search=true&from_srp=true&qid=l7wRgphXzf&rank=9 Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From crossd at gmail.com Fri Nov 22 11:53:03 2024 From: crossd at gmail.com (Dan Cross) Date: Thu, 21 Nov 2024 20:53:03 -0500 Subject: [COFF] [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: [TUHS to Bcc:, Cc: COFF] On Mon, Nov 18, 2024 at 11:47 AM Anton Shepelev wrote: > Dan Cross wrote: > >Programmer ability is certainly an issue, but I would suggest that > >another goes back to what Rob was alluding to: compiler writers have > >taken too much advantage of UB, making it difficult to write > >well-formed programs that last. > > Following the letter, rather than the spirit, of the standard? Pretty much! > [snip] > >My sense is that tossing in bad programmers is just throwing gasoline > >onto a dumpster fire. Particularly when they look to charlatans like > >Robert Martin or Allen Holub as sources of education and inspiration > >instead of seeking out proper sources of education. > > I am a bad one as well, to have liked some things in Martin's books > /Clean Code/ and /Clean Architecture/ . True, heis no Wirth, nor > Dijxtra, nor Knuth, but why a charlatan? Briefly, because he writes with unwarranted confidence, and just isn't a very good programmer himself. He writes with an authoritative voice about things that he doesn't know very much, if anything, about. For example, the things he's written about static typing in programming languages are complete nonsense. Sriram Krishnamurthi called him out on that (https://x.com/ShriramKMurthi/status/1136411753590472707) and he did not respond well, doubling down on his unfounded opinions (https://blog.cleancoder.com/uncle-bob/2019/06/08/TestsAndTypes.html). Later, he justified his opinion by making allusions to the amount of time he's been programming (https://blog.cleancoder.com/uncle-bob/2021/06/25/OnTypes.html). Hey, when it comes to logical fallacies centered on appeals to length of experience, well...I swooshed a basketball for the first time more than 40 years ago, but I've given up any dream I may have ever had of being a point guard in the NBA. Just doing something for a long time doesn't mean you're good at it. Robert Martin doesn't write production-quality code, period. He claims to "ship" lots of code, but acknowledges that most of that is example code for his books and personal side-projects. But the code examples he has publicly available are not particularly well-structured, readable, or maintainable. For a particular egregious example, see https://github.com/unclebob/PDP8EmulatorIpad/blob/1eba53c08fb530effb9d29aca8134f7acadfdd5f/src/topt.c (not the current commit; he modified it somewhat after I sent him https://github.com/unclebob/PDP8EmulatorIpad/commit/dbfa03e90a084a25992dff79e5064897bce5ef42, which he did not acknowledge; see https://github.com/unclebob/PDP8EmulatorIpad/pull/2/commits/84483cd4d60320cd6ca5637f2c062d9d0540cc4a for the timeline). And while that small program is a particularly bad example, other bits of his code are also bad. Ousterhout was asked to comment on his "extract till you drop" approach and presented with a "refactoring" Martin did of a program due to Knuth (https://sites.google.com/site/unclebobconsultingllc/one-thing-extract-till-you-drop). Ousterhout responded that he was "bewildered and horrified" by the approach. As Ousterhout put it, "He has taken 25 lines of code that are pretty straightforward and easy to understand, and turned them into 38 lines with 9 methods, none of which has a stitch of documentation. What was the point of this?" (https://groups.google.com/g/software-design-book/c/Kb5K3YcjIXw/m/qN8txMeOCAAJ) These are all typical of Martin's approach. Hence why I say the man is a charlatan. Others have written at length about why, and how, his advice is generally bad. - Dan C. From athornton at gmail.com Sun Nov 24 09:07:15 2024 From: athornton at gmail.com (Adam Thornton) Date: Sat, 23 Nov 2024 16:07:15 -0700 Subject: [COFF] A couple thoughts about BASIC Message-ID: I was one of those 80s kids who grew up with 6502s with BASIC in ROM. Yeah, I learned some bad habits from that, but they weren't that hard to unlearn, and they, at the very least, got me screwing around with computers and figuring out how to make them do what I wanted. It's been my career for three and a half decades now, so I'm not gonna complain. A couple decades later we had PHP for the web, which did almost exactly the same thing: made the barrier to entry, for getting stuff you wanted to see on the screen actually show up there, really low. And yeah, a bunch of people wrote a bunch of terrible web pages, but at least some of them, I'll wager, got inspired by that to learn more and do better. Sneering at BASIC is exactly the same sort of irritating privileged-ivory-tower BS that The Unix-Hater's Handbook and the cult of ITS represent. Sure, in some perfect world, people would learn better habits and have access to more capable (and therefore grossly more expensive) machines, but in the world in which we actually live, a really-low-barrier-to-entry for smart kids without tons of money is a lovely democratizing force. Here endeth the rant. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Sun Nov 24 10:27:39 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 23 Nov 2024 18:27:39 -0600 Subject: [COFF] A couple thoughts about BASIC In-Reply-To: References: Message-ID: <20241124002739.62hlm5cocdynimbg@illithid> At 2024-11-23T16:07:15-0700, Adam Thornton wrote: > I was one of those 80s kids who grew up with 6502s with BASIC in ROM. I was Z80 and M6809. The rivalries back then were serious business. ;-) > Yeah, I learned some bad habits from that, but they weren't that hard > to unlearn, and they, at the very least, got me screwing around with > computers and figuring out how to make them do what I wanted. The ease with which you could lock up the machine for force a reset by causing a processor fault--no hardware traps on these guys--made a pretty severe instructor. > A couple decades later we had PHP for the web, which did almost > exactly the same thing: made the barrier to entry, for getting stuff > you wanted to see on the screen actually show up there, really low. PHP was what I had to deal with for my first paying gig during the golden age of "e-commerce". Even as naïve as I was back then (some say I am still), I recognized a language that was dangerously sloppy. I recall that PHP had a stretch that resembled the legendary Sendmail Root Hole of the Week. > And yeah, a bunch of people wrote a bunch of terrible web pages, but > at least some of them, I'll wager, got inspired by that to learn more > and do better. > > Sneering at BASIC is exactly the same sort of irritating > privileged-ivory-tower BS that The Unix-Hater's Handbook and the cult > of ITS represent. Acknowledged, but there _is_ some funny stuff in TUHH. Will programming culture ever manage to simultaneously avoid both the greener-grass _and_ the drinking-one's-own-Kool-Aid fallacies? If RMS's is an example of ITS cult humor, it's pretty weak sauce. > Sure, in some perfect world, people would learn better habits and have > access to more capable (and therefore grossly more expensive) > machines, but in the world in which we actually live, a > really-low-barrier-to-entry for smart kids without tons of money is a > lovely democratizing force. Everybody has a smart phone. That could be a democratizing force (and has been, in some contexts). Unfortunately smart phone platforms are locked-down, walled-garden environments for the "delivery" of "services" and exfiltration of enormous tranches of personal information for the convenience of advertisers, law enforcement, and intelligence agencies of every country. But it seems like the price threshold is no longer a problem. Maybe what we need is a completely hackable convergence device that you can plug into any commodity TV, keyboard, and thumb drive and go. No need to build a radio into it. Let that be an optional external peripheral. Maybe this already exists and I'm just not aware of it, or maybe all the VCs of the world have decided that there's "no market" for them. I haven't priced out FPGAs recently, but hackability all the way down to the gate level seems like a terrific thing to unleash the next generation of kids on. We could have a self-taught Nisan and Schocken on every block. Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From athornton at gmail.com Sun Nov 24 11:00:49 2024 From: athornton at gmail.com (Adam Thornton) Date: Sat, 23 Nov 2024 18:00:49 -0700 Subject: [COFF] A couple thoughts about BASIC In-Reply-To: <20241124002739.62hlm5cocdynimbg@illithid> References: <20241124002739.62hlm5cocdynimbg@illithid> Message-ID: On Sat, Nov 23, 2024 at 5:27 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > At 2024-11-23T16:07:15-0700, Adam Thornton wrote: > > I was one of those 80s kids who grew up with 6502s with BASIC in ROM. > > I was Z80 and M6809. The rivalries back then were serious business. ;-) > Ah, a Radio Shack aficionado, I presume. > > But it seems like the price threshold is no longer a problem. Maybe > what we need is a completely hackable convergence device that you can > plug into any commodity TV, keyboard, and thumb drive and go. No need > to build a radio into it. Let that be an optional external peripheral. > > That would be a Raspberry Pi. SD card rather than thumb drive, but...$75 (I mean, I have a $9-many-years-ago thing that ran Linux, so it could be cheaper, certainly, but a fairly fast ARM with several GB of memory is $75) gets you...plug in the sd card, keyboard, mouse, and HDMI (newer Pis require a Micro-HDMI to HDMI adapter, which is like another $5 or $10), and you've got a fully functional Linux machine. One would think that it wouldn't be too hard to build an OLPC-like environment for it (it probably already exists). I'm amazed at how ubiquitous Pis are in the control system for the telescope I work on, but maybe I shouldn't be. After all: it's $75 for a general-purpose Linux box with a bunch of GPIO pins to play with. That's a lot cheaper than designing a custom hardware anything. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Sun Nov 24 11:27:21 2024 From: coff at tuhs.org (segaloco via COFF) Date: Sun, 24 Nov 2024 01:27:21 +0000 Subject: [COFF] A couple thoughts about BASIC In-Reply-To: <20241124002739.62hlm5cocdynimbg@illithid> References: <20241124002739.62hlm5cocdynimbg@illithid> Message-ID: On Saturday, November 23rd, 2024 at 4:27 PM, G. Branden Robinson wrote: > At 2024-11-23T16:07:15-0700, Adam Thornton wrote: > > > A couple decades later we had PHP for the web, which did almost > > exactly the same thing: made the barrier to entry, for getting stuff > > you wanted to see on the screen actually show up there, really low. > > > PHP was what I had to deal with for my first paying gig during the > golden age of "e-commerce". Even as naïve as I was back then (some > say I am still), I recognized a language that was dangerously sloppy. > > Regards, > Branden I did some volunteer PHP work for a local non-profit for a while, was my first and really only significant exposure to it. The recurring phenomenon I found was that it seems that nobody agrees on best practices or canonical ways to do literally anything. The educational resources and library components out there are such a hodge podge it's a wonder that there are any functionally adequate PHP-driven sites out there at all. I gave up on trying to get a feel for what best practices cropped up in the community and instead just religiously studied the documentation instead. That may have started my trend of foregoing secondary sources on programming and referring almost exclusively to reference manuals and my own intuition. It's a shame because the idea behind PHP is obviously one that has stuck around, what with other languages also featuring weird mishmash HTML and structured procedural code, although nowadays with the popularity of doing almost everything in client-side scripting, I wonder how PHP is going to adapt in the coming decade or two. Plus given the growing popularity of JS server-side engines, the playing field PHP enjoyed a wide berth in is becoming more crowded. Just speaking as someone who did some PHP, didn't really have any major qualms with the language, but finds there is a lot to be desired in the quality of educational materials out there... However, the same could probably be said about a lot of languages, especially those meant for "pick up and go" because that doesn't always translate to "pick up and go /correctly/". I'm just glad I had so much programming experience under my belt before I touched PHP, it would be far too easy to pick up bad patterns and then carry those into other realms... - Matt G. From crossd at gmail.com Wed Nov 27 05:51:38 2024 From: crossd at gmail.com (Dan Cross) Date: Tue, 26 Nov 2024 14:51:38 -0500 Subject: [COFF] [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: On Tue, Nov 26, 2024 at 8:48 AM Kevin Bowling wrote: > On Thu, Nov 21, 2024 at 6:53 PM Dan Cross wrote: >> [TUHS to Bcc:, Cc: COFF] >> >> On Mon, Nov 18, 2024 at 11:47 AM Anton Shepelev wrote: >> > Dan Cross wrote: >> > >Programmer ability is certainly an issue, but I would suggest that >> > >another goes back to what Rob was alluding to: compiler writers have >> > >taken too much advantage of UB, making it difficult to write >> > >well-formed programs that last. >> > >> > Following the letter, rather than the spirit, of the standard? >> >> Pretty much! >> >> > [snip] >> > >My sense is that tossing in bad programmers is just throwing gasoline >> > >onto a dumpster fire. Particularly when they look to charlatans like >> > >Robert Martin or Allen Holub as sources of education and inspiration >> > >instead of seeking out proper sources of education. >> > >> > I am a bad one as well, to have liked some things in Martin's books >> > /Clean Code/ and /Clean Architecture/ . True, heis no Wirth, nor >> > Dijxtra, nor Knuth, but why a charlatan? > > And what about Hollub? Pretty much the same thing. > A long time ago I came across and seemed to think some of his earlier books (on C) were ok. Yeah. He wrote a book about compilers, but as near as I can tell, it's mostly material regurgitated from the Dragon Book, just a different presentation, and a less academic focus. Curiously, he's in the acknowledgements for K&R (I forget which edition). I guess he read an early draft? > Looking lately, I don’t tend to care for the metaphysical and ceremonial stuff whence one starts talking about design patterns and scrum instead of doing the work so I haven’t paid attention. > > It’s a strong accusation to levy publicly and maybe should be explained. Many of Hollub's claims are ridiculous on the face of them ("you don't need a bug tracker! You don't need schedules! Code should be written by 'mobbing'!" Here's a representative example: https://twitter.com/allenholub/status/1734661813638459843 In that tweet he writes, "What we do involves essentially no mathematical analysis of anything. We are not doing math.If you're building a system that requires math, then the math is part of the _domain_, not the development process." I suppose he's never heard of time or space complexity analysis of algorithms? Or how about this one: https://twitter.com/allenholub/status/1827790079617892675 "A PR [Pull Request] is necessary only when someone you don't trust writes code in isolation. It's essential for OS work, for example, or if you're working using scatter/gather [https://bit.ly/3XYLhb3]. It's also a complete waste of time if you're working in a mob#/ensemble (or even a pair) because the code is reviewed as it's written." I suppose he's never worked someplace with a real, rigorous review culture. Also, https://x.com/allenholub/status/1634050850434826240 A few others: https://x.com/allenholub/status/1594859115557232640 https://x.com/allenholub/status/1613609655519019008 https://x.com/allenholub/status/1656811047783899138 https://x.com/allenholub/status/1610708432331632641 He has some code on Github that's relatively recent. It's not very good. - Dan C. >> Briefly, because he writes with unwarranted confidence, and just isn't >> a very good programmer himself. >> >> He writes with an authoritative voice about things that he doesn't >> know very much, if anything, about. For example, the things he's >> written about static typing in programming languages are complete >> nonsense. Sriram Krishnamurthi called him out on that >> (https://x.com/ShriramKMurthi/status/1136411753590472707) and he did >> not respond well, doubling down on his unfounded opinions >> (https://blog.cleancoder.com/uncle-bob/2019/06/08/TestsAndTypes.html). >> Later, he justified his opinion by making allusions to the amount of >> time he's been programming >> (https://blog.cleancoder.com/uncle-bob/2021/06/25/OnTypes.html). Hey, >> when it comes to logical fallacies centered on appeals to length of >> experience, well...I swooshed a basketball for the first time more >> than 40 years ago, but I've given up any dream I may have ever had of >> being a point guard in the NBA. Just doing something for a long time >> doesn't mean you're good at it. >> >> Robert Martin doesn't write production-quality code, period. He claims >> to "ship" lots of code, but acknowledges that most of that is example >> code for his books and personal side-projects. But the code examples >> he has publicly available are not particularly well-structured, >> readable, or maintainable. For a particular egregious example, see >> https://github.com/unclebob/PDP8EmulatorIpad/blob/1eba53c08fb530effb9d29aca8134f7acadfdd5f/src/topt.c >> (not the current commit; he modified it somewhat after I sent him >> https://github.com/unclebob/PDP8EmulatorIpad/commit/dbfa03e90a084a25992dff79e5064897bce5ef42, >> which he did not acknowledge; see >> https://github.com/unclebob/PDP8EmulatorIpad/pull/2/commits/84483cd4d60320cd6ca5637f2c062d9d0540cc4a >> for the timeline). >> >> And while that small program is a particularly bad example, other bits >> of his code are also bad. Ousterhout was asked to comment on his >> "extract till you drop" approach and presented with a "refactoring" >> Martin did of a program due to Knuth >> (https://sites.google.com/site/unclebobconsultingllc/one-thing-extract-till-you-drop). >> Ousterhout responded that he was "bewildered and horrified" by the >> approach. As Ousterhout put it, "He has taken 25 lines of code that >> are pretty straightforward and easy to understand, and turned them >> into 38 lines with 9 methods, none of which has a stitch of >> documentation. What was the point of this?" >> (https://groups.google.com/g/software-design-book/c/Kb5K3YcjIXw/m/qN8txMeOCAAJ) >> >> These are all typical of Martin's approach. Hence why I say the man is >> a charlatan. Others have written at length about why, and how, his >> advice is generally bad. >> >> - Dan C. From lm at mcvoy.com Wed Nov 27 06:15:03 2024 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 26 Nov 2024 12:15:03 -0800 Subject: [COFF] [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: <20241126201503.GJ30570@mcvoy.com> On Tue, Nov 26, 2024 at 02:51:38PM -0500, Dan Cross wrote: > Many of Hollub's claims are ridiculous on the face of them ("you don't > need a bug tracker! You don't need schedules! Code should be written > by 'mobbing'!" Why would anyone listen to this guy? I ran engineering at BitMover for 18 years, yeah, you need a bug tracker. If for no other reason than to track the churn rate. HP-UX used that metric to decide when to land the plane. You need to realize that schedules are a rough idea, but you absolutely need them, people work better towards a goal. This guy sounds like he hasn't worked on anything other than small user space programs. From douglas.mcilroy at dartmouth.edu Wed Nov 27 07:37:35 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 26 Nov 2024 16:37:35 -0500 Subject: [COFF] [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) Message-ID: > Curiously, Robert Martin's in the acknowledgements for K&R > (I forget which edition). I guess he read an early draft? I didn't find Robert Martin in the long list of acknowledgements in the preface to the second edition. But any such acknowledgement would certainly be to Bob Martin, a savvy Bell Labs executive whose advice was always welcome. He is acknowledged in Aho and Ullman's "Theory of Parsing, Translation, and Compiling", but not in the Dragon Book. I have never seen a Robert Martin book on programming; I probably would have were it written by Bob. Doug From johnl at taugh.com Wed Nov 27 07:38:01 2024 From: johnl at taugh.com (John Levine) Date: 26 Nov 2024 21:38:01 -0000 Subject: [COFF] [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240930191216.tIpea9lo@steffen%sdaoden.eu> References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: According to Dan Cross : >> And what about Hollub? > >Pretty much the same thing. > >> A long time ago I came across and seemed to think some of his earlier books (on C) were ok. > >Yeah. He wrote a book about compilers, but as near as I can tell, >it's mostly material regurgitated from the Dragon Book, just a >different presentation, and a less academic focus. It was terrible because none of the code worked. There was a fat list of errata that fixed some of them but it was more trouble than it was worh. R's, John -- Regards, John Levine, johnl at taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From steffen at sdaoden.eu Wed Nov 27 11:03:50 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 27 Nov 2024 02:03:50 +0100 Subject: [COFF] [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20241126201503.GJ30570@mcvoy.com> References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> <20241126201503.GJ30570@mcvoy.com> Message-ID: <20241127010350.mToAkuOx@steffen%sdaoden.eu> Larry McVoy wrote in <20241126201503.GJ30570 at mcvoy.com>: |On Tue, Nov 26, 2024 at 02:51:38PM -0500, Dan Cross wrote: |> Many of Hollub's claims are ridiculous on the face of them ("you don't |> need a bug tracker! You don't need schedules! Code should be written |> by 'mobbing'!" | |Why would anyone listen to this guy? I ran engineering at BitMover for |18 years, yeah, you need a bug tracker. If for no other reason than to |track the churn rate. HP-UX used that metric to decide when to land the |plane. Only to mention it, the Linux bugzilla is famous for living "in the twilight zone": https://lore.kernel.org/lkml/6808cd17-b48c-657d-de60-ef9d8bfa151e at leemhuis.info/ From: Thorsten Leemhuis To: Linus Torvalds , Greg KH , Konstantin Ryabitsev Date: 2022-04-06 Subject: A lot of regression reports submitted to bugzilla.kernel.org are apparently ignored, even bisected ones |You need to realize that schedules are a rough idea, but you absolutely |need them, people work better towards a goal. | |This guy sounds like he hasn't worked on anything other than small |user space programs. I have not seen or read anything but what was posted here, but .. honestly i find it overly funny. In that it sounds to reflect actual reality of many, if not most, big engineering efforts i have ever heard of. Ie, if budget and time limits go down the engineer reality toilet, why not just leave them alone. For example, in Germany/Europe we had the Jäger90 (fighter plane), to which the polish did not want to .. but that aside .., which then turned to Jäger91, 92, 93, 95, 2000 (i have forgotten the real details mind you, 35+ years since that was mess of the week -- and it really was exactly that). Yes, eventually this turned to the Eurofighter, but it was *at leas* a decade late, and it took even longer thereafter, until 2006 says wikipedia, until it really entered service. --End of <20241126201503.GJ30570 at mcvoy.com> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |And in Fall, feel "The Dropbear Bard"s ball(s). | |The banded bear |without a care, |Banged on himself for e'er and e'er | |Farewell, dear collar bear From crossd at gmail.com Wed Nov 27 18:50:41 2024 From: crossd at gmail.com (Dan Cross) Date: Wed, 27 Nov 2024 03:50:41 -0500 Subject: [COFF] [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: Message-ID: On Tue, Nov 26, 2024, 4:37 PM Douglas McIlroy wrote: > > Curiously, Robert Martin's in the acknowledgements for K&R > > (I forget which edition). I guess he read an early draft? > > I didn't find Robert Martin in the long list of acknowledgements > in the preface to the second edition. But any such acknowledgement > would certainly be to Bob Martin, a savvy Bell Labs executive whose > advice was always welcome. He is acknowledged in Aho and > Ullman's "Theory of Parsing, Translation, and Compiling", but not > in the Dragon Book. I have never seen a Robert Martin book on > programming; I probably would have were it written by Bob. > Sorry, I mis-wrote. I meant to say Allen Holub was in the K&R acknowledgements; not Martin. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Thu Nov 28 10:40:59 2024 From: coff at tuhs.org (Warren Toomey via COFF) Date: Thu, 28 Nov 2024 10:40:59 +1000 Subject: [COFF] AI and spin locks Message-ID: I was just trying to find out if there was a way of uploading the TUHS mailing list as a corpus of text into a LLM so that I could ask questions based on the knowledge contained therein. I'm not having much luck yet. Anyway, while messing around with things I asked a simple question and got this answer: What is a spin lock? A spin lock, also known as a spinning lock or spinning lock mechanism, is a type of mechanical locking device used to secure and protect sensitive electronic components, such as microprocessors, memory chips, and other high-value devices. Here's how it worked: when a CPU instruction was executed and the necessary data was stored in registers, the CPU would "lock" the registers by spinning them around to prevent other instructions from accessing them. Those poor registers must get dizzy with all the spinning that they have to endure :-) Cheers, Warren P.S. If anybody has ideas on how to usefully import the TUHS mailing list into a LLM, let me/us know. From barto at kdbarto.org Thu Nov 28 11:56:59 2024 From: barto at kdbarto.org (David Barto) Date: Wed, 27 Nov 2024 17:56:59 -0800 Subject: [COFF] AI and spin locks In-Reply-To: References: Message-ID: <1724E522-648E-4583-8C03-6662342934DD@kdbarto.org> That is some of the funniest stuff I’ve read in a long time David Sent from iPhone Hotblack Desiato > On Nov 27, 2024, at 4:41 PM, Warren Toomey via COFF wrote: > > I was just trying to find out if there was a way of uploading the TUHS > mailing list as a corpus of text into a LLM so that I could ask questions > based on the knowledge contained therein. I'm not having much luck yet. > > Anyway, while messing around with things I asked a simple question and got > this answer: > > What is a spin lock? > > A spin lock, also known as a spinning lock or spinning lock mechanism, is > a type of mechanical locking device used to secure and protect sensitive > electronic components, such as microprocessors, memory chips, and other > high-value devices. > > Here's how it worked: when a CPU instruction was executed and the > necessary data was stored in registers, the CPU would "lock" the registers > by spinning them around to prevent other instructions from accessing them. > > Those poor registers must get dizzy with all the spinning that they > have to endure :-) > > Cheers, Warren > > P.S. If anybody has ideas on how to usefully import the TUHS mailing list > into a LLM, let me/us know. From stuff at riddermarkfarm.ca Fri Nov 29 00:44:10 2024 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Thu, 28 Nov 2024 09:44:10 -0500 Subject: [COFF] AI and spin locks In-Reply-To: References: Message-ID: <76284032-0c95-4642-5c70-35bfcc4780fa@riddermarkfarm.ca> On 2024-11-27 19:40, Warren Toomey via COFF wrote: > I was just trying to find out if there was a way of uploading the TUHS > mailing list as a corpus of text into a LLM so that I could ask questions > based on the knowledge contained therein. I'm not having much luck yet. > > Anyway, while messing around with things I asked a simple question and got > this answer: > > What is a spin lock? > > A spin lock, also known as a spinning lock or spinning lock mechanism, is > a type of mechanical locking device used to secure and protect sensitive > electronic components, such as microprocessors, memory chips, and other > high-value devices. > > Here's how it worked: when a CPU instruction was executed and the > necessary data was stored in registers, the CPU would "lock" the registers > by spinning them around to prevent other instructions from accessing them. > > Those poor registers must get dizzy with all the spinning that they > have to endure :-) ld gravol S. > > Cheers, Warren > > P.S. If anybody has ideas on how to usefully import the TUHS mailing list > into a LLM, let me/us know. From edouardklein at gmail.com Fri Nov 29 04:11:22 2024 From: edouardklein at gmail.com (Edouard Klein) Date: Thu, 28 Nov 2024 19:11:22 +0100 Subject: [COFF] AI and spin locks In-Reply-To: (Warren Toomey via COFF's message of "Thu, 28 Nov 2024 10:40:59 +1000") References: Message-ID: <87bjxz8bzp.fsf@gmail.com> So, I ran the following experiment: I downloaded the last month of email from the archive, and split them into one email per file using a quick and dirty state machine script in python looking an empty line followed by two lines starting with "From" in order to know where to split. I then uploaded the files into https://openwebui.com/ built-in RAG system. The vectorization model is nvidia/NV-Embed-v2, and the LLM is https://huggingface.co/bartowski/gemma-2-27b-it-GGUF/blob/main/gemma-2-27b-it-Q8_0.gguf I then put the following very vague query, but which I knew was relevent to last month's discussion: What has changed in the C language in the last few decades ? I copied the response at the end of the email. It seems quite good to me, but it may get worse when the whole archive is uploaded. I think this proof of concept shows that there could be value in doing the whole list, with a cleaner email extraction a few tweaks to the system prompt. I can't do it now because I have a few deadlines coming soon (not the least of which is the International Workshop on Plan 9 https://iwp9.org/ SEND YOUR PAPERS, PEOPLE !), but I would like to tackle that in the near future. Hosting this require significant but not overly expansive hardware (from 1 to few k€), if a university lab or a generous patron wants to see it done and make it available to the public, please contact me :) Otherwise llamafile (https://github.com/Mozilla-Ocho/llamafile justine single-handedly restored my faith in Mozilla) could be used to distribute a file that would contain the model+the emails+the vector database in a single huge file that can run anywhere. Exciting times ! Here is the LLM answer: Based on the provided context, it appears that the C language has undergone significant changes over the last few decades. Here are some key changes mentioned: Standardization and Formalization : The C language has become more formalized and standardized, with the introduction of new standards (e.g., C89, C99, C23). This has led to a more rigid and legalistic approach to the language, which some users find less useful. Changes to realloc function : The behavior of the realloc function has changed over time. In the first ANSI C standard, realloc(0, ptr) was well-defined when ptr was not nil. However, this behavior was changed in C99, and now, in C23, realloc(0, ptr) is undefined behavior (UB) regardless of the value of ptr. Strict Aliasing : The introduction of strict aliasing rules has led to compilers assuming that pointers to incompatible types always point to different non-overlapping locations. This has caused issues for some programmers. Additional Features and Functions : The C language has gained new features and functions over the years, such as stdint.h (introduced in C89), which provides integer types with specific widths. Evolution of Language Principles : The language has evolved with no appreciation or understanding of the aesthetic and practical principles of the original language effort, leading to a more verbose and less concise language. These changes reflect the C language's growth and adaptation to new requirements and use cases over the decades. However, some users, like the ones in the provided context, feel that these changes have made the language less useful and more complicated. Warren Toomey via COFF writes: > I was just trying to find out if there was a way of uploading the TUHS > mailing list as a corpus of text into a LLM so that I could ask questions > based on the knowledge contained therein. I'm not having much luck yet. > > Anyway, while messing around with things I asked a simple question and got > this answer: > > What is a spin lock? > > A spin lock, also known as a spinning lock or spinning lock mechanism, is > a type of mechanical locking device used to secure and protect sensitive > electronic components, such as microprocessors, memory chips, and other > high-value devices. > > Here's how it worked: when a CPU instruction was executed and the > necessary data was stored in registers, the CPU would "lock" the registers > by spinning them around to prevent other instructions from accessing them. > > Those poor registers must get dizzy with all the spinning that they > have to endure :-) > > Cheers, Warren > > P.S. If anybody has ideas on how to usefully import the TUHS mailing list > into a LLM, let me/us know. From imp at bsdimp.com Fri Nov 29 04:17:11 2024 From: imp at bsdimp.com (Warner Losh) Date: Thu, 28 Nov 2024 11:17:11 -0700 Subject: [COFF] AI and spin locks In-Reply-To: <87bjxz8bzp.fsf@gmail.com> References: <87bjxz8bzp.fsf@gmail.com> Message-ID: On Thu, Nov 28, 2024, 11:11 AM Edouard Klein wrote: > So, I ran the following experiment: > > I downloaded the last month of email from the archive, and split them > into one email per file using a quick and dirty state machine script in > python looking an empty line followed by two lines starting with "From" > in order to know where to split. > > I then uploaded the files into https://openwebui.com/ built-in RAG > system. > The vectorization model is nvidia/NV-Embed-v2, and the LLM is > > https://huggingface.co/bartowski/gemma-2-27b-it-GGUF/blob/main/gemma-2-27b-it-Q8_0.gguf > > I then put the following very vague query, but which I knew was relevent > to last month's discussion: > > What has changed in the C language in the last few decades ? > > I copied the response at the end of the email. It seems quite good to > me, but it may get worse when the whole archive is uploaded. > > I think this proof of concept shows that there could be value in doing > the whole list, with a cleaner email extraction a few tweaks to the > system prompt. > > I can't do it now because I have a few deadlines coming soon (not the > least of which is the International Workshop on Plan 9 > https://iwp9.org/ SEND YOUR PAPERS, PEOPLE !), but I would like to > tackle that in the near future. > > Hosting this require significant but not overly expansive hardware (from > 1 to few k€), if a university lab or a generous patron wants to see it > done and make it available to the public, please contact me :) > > Otherwise llamafile (https://github.com/Mozilla-Ocho/llamafile justine > single-handedly restored my faith in Mozilla) could be used to > distribute a file that would contain the model+the emails+the vector > database in a single huge file that can run anywhere. > > Exciting times ! > > > Here is the LLM answer: > > Based on the provided context, it appears that the C language has > undergone significant changes over the last few decades. Here are some > key changes mentioned: > > Standardization and Formalization : The C language has become more > formalized and standardized, with the introduction of new standards > (e.g., C89, C99, C23). This has led to a more rigid and legalistic > approach to the language, which some users find less useful. > > Changes to realloc function : The behavior of the realloc function > has changed over time. In the first ANSI C standard, realloc(0, ptr) > was well-defined when ptr was not nil. However, this behavior was > changed in C99, and now, in C23, realloc(0, ptr) is undefined > behavior (UB) regardless of the value of ptr. > > Strict Aliasing : The introduction of strict aliasing rules has led > to compilers assuming that pointers to incompatible types always > point to different non-overlapping locations. This has caused issues > for some programmers. > > Additional Features and Functions : The C language has gained new > features and functions over the years, such as stdint.h (introduced > in C89), which provides integer types with specific widths. > > Evolution of Language Principles : The language has evolved with no > appreciation or understanding of the aesthetic and practical > principles of the original language effort, leading to a more > verbose and less concise language. > > > These changes reflect the C language's growth and adaptation to new > requirements and use cases over the decades. However, some users, like > the ones in the provided context, feel that these changes have made the > language less useful and more complicated. > Now you kids get off my damn lawn! But it is a fairly accurate summary. Warner Warner Warren Toomey via COFF writes: > > > I was just trying to find out if there was a way of uploading the TUHS > > mailing list as a corpus of text into a LLM so that I could ask questions > > based on the knowledge contained therein. I'm not having much luck yet. > > > > Anyway, while messing around with things I asked a simple question and > got > > this answer: > > > > What is a spin lock? > > > > A spin lock, also known as a spinning lock or spinning lock mechanism, > is > > a type of mechanical locking device used to secure and protect > sensitive > > electronic components, such as microprocessors, memory chips, and other > > high-value devices. > > > > Here's how it worked: when a CPU instruction was executed and the > > necessary data was stored in registers, the CPU would "lock" the > registers > > by spinning them around to prevent other instructions from accessing > them. > > > > Those poor registers must get dizzy with all the spinning that they > > have to endure :-) > > > > Cheers, Warren > > > > P.S. If anybody has ideas on how to usefully import the TUHS mailing list > > into a LLM, let me/us know. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Nov 29 04:19:53 2024 From: clemc at ccc.com (Clem Cole) Date: Thu, 28 Nov 2024 13:19:53 -0500 Subject: [COFF] AI and spin locks In-Reply-To: References: <87bjxz8bzp.fsf@gmail.com> Message-ID: Amen Sent from a handheld expect more typos than usual On Thu, Nov 28, 2024 at 1:17 PM Warner Losh wrote: > > > On Thu, Nov 28, 2024, 11:11 AM Edouard Klein > wrote: > >> So, I ran the following experiment: >> >> I downloaded the last month of email from the archive, and split them >> into one email per file using a quick and dirty state machine script in >> python looking an empty line followed by two lines starting with "From" >> in order to know where to split. >> >> I then uploaded the files into https://openwebui.com/ built-in RAG >> system. >> The vectorization model is nvidia/NV-Embed-v2, and the LLM is >> >> https://huggingface.co/bartowski/gemma-2-27b-it-GGUF/blob/main/gemma-2-27b-it-Q8_0.gguf >> >> I then put the following very vague query, but which I knew was relevent >> to last month's discussion: >> >> What has changed in the C language in the last few decades ? >> >> I copied the response at the end of the email. It seems quite good to >> me, but it may get worse when the whole archive is uploaded. >> >> I think this proof of concept shows that there could be value in doing >> the whole list, with a cleaner email extraction a few tweaks to the >> system prompt. >> >> I can't do it now because I have a few deadlines coming soon (not the >> least of which is the International Workshop on Plan 9 >> https://iwp9.org/ SEND YOUR PAPERS, PEOPLE !), but I would like to >> tackle that in the near future. >> >> Hosting this require significant but not overly expansive hardware (from >> 1 to few k€), if a university lab or a generous patron wants to see it >> done and make it available to the public, please contact me :) >> >> Otherwise llamafile (https://github.com/Mozilla-Ocho/llamafile justine >> single-handedly restored my faith in Mozilla) could be used to >> distribute a file that would contain the model+the emails+the vector >> database in a single huge file that can run anywhere. >> >> Exciting times ! >> >> >> Here is the LLM answer: >> >> Based on the provided context, it appears that the C language has >> undergone significant changes over the last few decades. Here are some >> key changes mentioned: >> >> Standardization and Formalization : The C language has become more >> formalized and standardized, with the introduction of new standards >> (e.g., C89, C99, C23). This has led to a more rigid and legalistic >> approach to the language, which some users find less useful. >> >> Changes to realloc function : The behavior of the realloc function >> has changed over time. In the first ANSI C standard, realloc(0, ptr) >> was well-defined when ptr was not nil. However, this behavior was >> changed in C99, and now, in C23, realloc(0, ptr) is undefined >> behavior (UB) regardless of the value of ptr. >> >> Strict Aliasing : The introduction of strict aliasing rules has led >> to compilers assuming that pointers to incompatible types always >> point to different non-overlapping locations. This has caused issues >> for some programmers. >> >> Additional Features and Functions : The C language has gained new >> features and functions over the years, such as stdint.h (introduced >> in C89), which provides integer types with specific widths. >> >> Evolution of Language Principles : The language has evolved with no >> appreciation or understanding of the aesthetic and practical >> principles of the original language effort, leading to a more >> verbose and less concise language. >> >> >> These changes reflect the C language's growth and adaptation to new >> requirements and use cases over the decades. However, some users, like >> the ones in the provided context, feel that these changes have made the >> language less useful and more complicated. >> > > Now you kids get off my damn lawn! > > But it is a fairly accurate summary. > > Warner > > Warner > > Warren Toomey via COFF writes: >> >> > I was just trying to find out if there was a way of uploading the TUHS >> > mailing list as a corpus of text into a LLM so that I could ask >> questions >> > based on the knowledge contained therein. I'm not having much luck yet. >> > >> > Anyway, while messing around with things I asked a simple question and >> got >> > this answer: >> > >> > What is a spin lock? >> > >> > A spin lock, also known as a spinning lock or spinning lock >> mechanism, is >> > a type of mechanical locking device used to secure and protect >> sensitive >> > electronic components, such as microprocessors, memory chips, and >> other >> > high-value devices. >> > >> > Here's how it worked: when a CPU instruction was executed and the >> > necessary data was stored in registers, the CPU would "lock" the >> registers >> > by spinning them around to prevent other instructions from accessing >> them. >> > >> > Those poor registers must get dizzy with all the spinning that they >> > have to endure :-) >> > >> > Cheers, Warren >> > >> > P.S. If anybody has ideas on how to usefully import the TUHS mailing >> list >> > into a LLM, let me/us know. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davida at pobox.com Fri Nov 29 05:25:47 2024 From: davida at pobox.com (David Arnold) Date: Fri, 29 Nov 2024 06:25:47 +1100 Subject: [COFF] AI and spin locks In-Reply-To: <87bjxz8bzp.fsf@gmail.com> References: <87bjxz8bzp.fsf@gmail.com> Message-ID: > On 29 Nov 2024, at 05:11, Edouard Klein wrote: <…> > Additional Features and Functions : The C language has gained new features and functions over the years, such as stdint.h (introduced in C89), which provides integer types with specific widths. Wasn’t stdint.h a C99 thing? d From imp at bsdimp.com Fri Nov 29 05:36:00 2024 From: imp at bsdimp.com (Warner Losh) Date: Thu, 28 Nov 2024 12:36:00 -0700 Subject: [COFF] AI and spin locks In-Reply-To: References: <87bjxz8bzp.fsf@gmail.com> Message-ID: On Thu, Nov 28, 2024, 12:26 PM David Arnold wrote: > > > On 29 Nov 2024, at 05:11, Edouard Klein wrote: > > <…> > > > Additional Features and Functions : The C language has gained new > features and functions over the years, such as stdint.h (introduced in > C89), which provides integer types with specific widths. > > Wasn’t stdint.h a C99 thing? > Yes. It's why FreeBSD has lots of u_int16_t instances in its tree still. Warner > > -------------- next part -------------- An HTML attachment was scrubbed... URL: