As I retire, my goal now is to release 40+ years of source code
dunfield.themindfactory.com
dunfield.themindfactory.com
Older C compilers will let you get away with a lot of sins which a modern C compiler will (correctly) call you out for.
Under some very old C standards, maybe. But C99 requires that you at least declare a function before calling it.
There is no such requirement of a declaration before first call in Java for example?
Kind of like how the JavaScript dudes all use this ".ts" stuff now for convenience that processes into ".js"
let x: number = 6;
You should instead allow the compiler to infer where it can and do
let x = 6;
Inference doesn't work across function calls like it does (did?) in Flow, which is a good thing, so those always need to be typed.
If you wanted the type of x to be 6 instead of number, you would use
let x = 6 as const;
extern int id();
This implicit declaration meant that if it was later defined in the same file as returning a type other than int, the compiler wasn't permitted to go back up in the file and treat the function call as though it returned a type other than int.
This requirement was removed in C99, but in practice, compilers kept doing it for backwards compatibility, even when not invoked in C90 mode.
You do have analyses like ctags. In theory the compiler could use ctags to find definitions in source code. My experience is ctags can get confused. It's possible in a set of files to have multiple implementations of a function and ctags can't tell which one is used. And I see cases where it can't find definitions.
Personally I'd be happy if the compiler tried to find a missing definition using ctags and issued a warning.
I have wondered if adding funct, public, private keywords to the language might allow the compiler to reliably find function and stuct definitions in source files.
That's not necessarily true. It's possible that the symbol is a function pointer; calling a function pointer requires slightly different code generation. Compare the generated code between:
void fn(void);
void call_fn(void) { fn(); }
void (*fn_ptr)(void);
void call_fn_ptr(void) { fn_ptr(); }
you mean the linker will throw an error. The linker is trying to link together the "references" be they forward or backward, that the compiler has created, and the compiler needs to have generated the right references, round peg round hole, square peg square hole.
You don't want your linker throwing errors, it doesn't have the context the compiler does; and you don't want to turn the linker into ChatGPT that can converse with you about your source code, just use the C version of forward references which are not particularly forward, they just say "I don't know where this is defined, it's just not defined here, but we know it's a square peg"
For example, there are architectures where space is tight (embedded for example) and nearby things can be called more efficiently than far away things, so the compiler needs to generate as many near calls as it can, falling back to far away when it has to. It doesn't know in advance how far away things are going to be, but it might uncover plenty of near things as it goes. Square pegs, round pegs.
when you recompile your project code, the library code, is not necessarily around. When other people recompile their library code, your project code isn't around. What's the size of what's being put on the stack? Still gotta get the square/round pegs right.
Win32 C code from way back.
Heh.
Where is that written? Please quote the standard. My reading of ISO/IEC 9899:TC3 is that Foreword says (paraphrasing) "hey, we removed implicit int and implicit prototypes from the standard". So they simply stopped specifying it, but as far as I can tell, the standard says nothing about forbidding them. From my point of view, that means compilers are free to still implement implicit types as a compiler extension to the language, and everyone does, because that extension is needed in order to support the older c89 standard. It would only impact people who want to be able to claim their codebase is c99 standard compliant, because you can't do that if you depend on compiler extensions.
ISO/IEC 9899:TC3 [1] §6.5.1 ¶2: "An identifier is a primary expression, provided it has been declared as designating an object (in which case it is an lvalue) or a function (in which case it is a function designator)."
There's even a footnote to underscore this point: "79) Thus, an undeclared identifier is a violation of the syntax."
[1]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
https://en.m.wikipedia.org/wiki/Forward_declaration
https://en.m.wikipedia.org/wiki/Pascal_(programming_language...
https://en.m.wikipedia.org/wiki/Object_Pascal
https://www.thedelphigeek.com/2017/03/forward-record-declara...
if(*(Ptr = argv[i]) == '-') {
It's not even a good idea to do that on modern computers, because implicitly declared functions do type promotions from float to double and char/short to int, and on the System V ABI, it has to pass in the number of floating point arguments there are in register eax.
A low bar, really :-P
In older C compilers (maybe pre-ANSI, or later, can't remember), you could literally write i[a] instead of a[i], where a was an array and i was an int, and it would work equivalently, i.e. no compiler error, and give the same result as a[i]. This was because a was the address of the start of the array, and i was an offset, so a[i] actually meant *(a + i), which, by the commutative property of arithmetic, was equivalent to *(i + a), which was equivalent to i[a].
I had read this in some C book, maybe K&R or the Waite Group C Microsoft Bible.
Never forgot it, because it was counter-intuitive, unless you knew the above reason.
And tried it out in one or more C compilers at that approximate period, and it worked as stated.
https://godbolt.org/z/37Kv44o1b
> I had read this in some C book, maybe K&R or the Waite Group C Microsoft Bible.
I haven't read the Microsoft C Bible, but it does say this in K&R while explaining pointers.
Wow, good to know.
>but it does say this in K&R
Then that must be where I had read it.
For the uniformed
> In the above one-liner, we've basically reconfigured the stock compiler on Linux so it outputs binaries that'll run on MacOS, Windows, FreeBSD, OpenBSD, and NetBSD too. They also boot from the BIOS. Please note this is intended for people who don't care about desktop GUIs, and just want stdio and sockets without devops toil
they also boot from the BIOS.... does this mean that I can achieve my dream of booting straight into a BBC BASIC emulator on bare metal(ish)?
Justine is a genius.
Justine’s APE [0] project is one of the few things to induce in me true, nostalgic, nerdful glee in the last few years.
At the same time, companies seem so quick to layoff that I question how I even grow to the point where I'd be trusted with such problems. Do I really just need to do a 2nd full time duty in the open source community to get that growth?
- working on a medium-large repo size exercises more skills than just jumping into anything alone. Growth is my biggest factor for the next few years.
- OS introduces me to a community of passionate devs. Who can be anything from mentors to expand my horizons, to friends to future contacts.
- I'd choose to contribute to tools I would probably use for my own projects. So I can dig into repos early and know it intimately for the time I'd need to branch for my own project
- potential clout in certain communities can open other doors.
- Resume material is never bad if everything else falls through
It's not my end game but I think it'll help in many ways. And Personally I always had a certain respect for the OS community and want to give back, and hopefully pay if forward. .
I contribute to repos I use in my projects, but I’d never start with them before actually finding a use for them
And it would be a soul crushing world if I simply submitted to the fact that we're more connected than ever, but simultaneously I can't find literally anyone else to connect with without money being involved. I have at least a good decade in my heart left to fight that mentality.
Obviously spending 20+ hours a week on interesting OSS is going to get you more interesting roles over time, and generally OSS stuff is way more fun because you can pick what interests you. But you have to decide if it's worth the cost - do you really want to spend 60 hours+ a week just doing coding / engineering? Maybe you do, but in that case you'd probably be doing it already.
What a rude and profoundly dumb statement. Are all the ones who bust their arses out of necessity failures or do they simply want to endure pain? Caring for a handicapped child, parent, being trapped in a poor country, etc.
I'd be curious to know where most of you around here who put desires above all else are coming from.
A parent that cares for a disabled child is only a failure as long as he does not want to do it but has to. In this case he is not only a failure but a horrible person.
I volunteer to care for old people 1h per month and I do not consider this a burden or entrapping or nothing like that. In fact I've met my first wife like this.
Your definition of what constitutes a "failure" doesn't have to be the same as someone else, and that's OK.
> I volunteer to care for old people 1h per month
I'm sorry, it does not render what you're doing irrelevant, but the comparison is laughable.
Caring for a disabled children is a full time job. I can't imagine that most were hoping to be in that situation when they conceived. It doesn't prevent them from being good carers for the child they love. If you meet some of these parents, ask them. Then you can tell them they are horrible people because as opposed to them you voluntarily go to chat with an oldie for 1h a month.
Have some empathy.
I’ve seen the parents of severely disabled children. The daily work, financial cost, and social cost is immense. They don’t give up their children often out of duty and sympathy not because they ever wanted to live a life like that. They are burdened and entrapped and it’s not simply a matter of mindset.
Not even the disabled children would be keen to agree with you that their self-sacrificing parents are failures and horrible people if they feel they’ve been burdened and entrapped. THEY feel burdened and entrapped themselves. People in a bad situation can sympathize with people’s circumstances for what they are. They might resent the parent being open about their feelings, but not for having them at all.
As for why the 3rd world cab driver does not feel this way, a cab driver in the third world is often doing relatively well compared to their peers, they may have grown up in worse circumstances, and cab driving is something relatively easy to give up for a few years and then pick back up no worries. That’s not nessecarily true of the investment banker or the parent of the disabled child.
"For what it’s worth... it’s never too late, or in my case too early, to be whoever you want to be. There’s no time limit. Start whenever you want.... I hope you live a life you’re proud of, and if you’re not, I hope you have the courage to start over again."
My courage definitely wavers, but the stuff I'm "supposed" to do will hold me back if I try to what I want first. If I can't do that first, I'll at least set the breadcrumbs as I climb out of that pit.
It's a condition of certain kinds of life, to tolerate unbearable dissatisfaction. Many things have come from this drive, many astonishing people have shared it, and they'll never settle. They'll die still not 'done', their dreams unreached… because those dreams were able to scale, those stars remained beyond their reach.
Nah, not how it works.
> truly solving problems
By picking a problem you have a vested interest in, you'll get further than solving someone else's problems in which you don't
It's ok to not be building some new thing in your off hours. That's a choice they made for their own reasons. Doing what you do is also a choice and both are valid.
[1] https://raw.githubusercontent.com/jart/cosmopolitan/1.0/ape/...
Cargo pulled in something like 105 dependencies to build it.
Although, as an apples to apples comparison, it does only have 2 use statements.
Here is a http health check in 19 lines using only the rust standard library.
There’s a happy medium to be had.
I’d also disagree this is not at all a language problem - I think it’s both, in that the language has moved an awful lot of core functionality into the crate ecosystem, where there are a bewildering array of options for almost any need. The resulting explosion in the dependency graph is an entirely foreseeable consequence — partially of that language design decision and partially due to the “npm culture” (for lack of a better description.)
The list goes on. While I'm not a Rust developer, there's probably hundreds of libraries because the problem is structured into a lot of small parts, and frameworks are expected to be able to satisfy the functionality you expect without needing to bypass it.
(The signal_hook crate even contains documentation on those pitfalls. https://docs.rs/signal-hook-registry/1.4.1/signal_hook_regis...)
I mean sure, reinvent the wheel. But it might do good to at least have an inkling what those 105 dependencies for your http listener did.
I ended up going with sigwaitinfo since the attempts you likely saw on matrix which is perfect for my application that will only ever run on modern linux kernels.
Combining that with the stdlib health check above and we end up with a dead simple health checking signal handling service pattern that works well and easy to confirm is free of supply chain attacks.
:)
https://en.m.wikipedia.org/wiki/No_true_Scotsman
Not sure if that's a good analogy, but put it out there, to see what people say.
- True=7 -
Having lots of very low-level code and hardware experience, I developed a bit
of tendancy to "minimize what can go wrong at low levels" - C treats 0==FALSE
and !0==TRUE - most people use 0/1 ... but thats only 1 bit "difference". I
sometimes use 7=TRUE as thats 3 bits with no more chars to type (and of course
foolish as such a 1 bit hardware error would "trash" pretty much any system -
but I do tend to be a creature of habit :)
https://learn.microsoft.com/en-us/dotnet/visual-basic/langua...
Edit: "Gained" no "Earned"
Haven't seen A5 in the wild but I suppose it could be useful as a initial "Let's setup a connection" where endianness is unknown. Assuming the next thing that is exchanged is an endian negotiation.
i was sending pixel data out from an Arduino (ESP32 really but using Arduino IDE) to a bunch of shift registers that seemed to be 74x595 (but couldnt know for sure) to resurrect an LED display for a local art project, and reading the data coming back out from the last register let me know I was at least getting back what I was putting in, which helped me troubleshoot a few wire length and speed/stability issues
to get started with electronics and hardware in general, I wrote a short tutorial: https://news.ycombinator.com/item?id=35116705
Learning hardware just for the sake of it is tough to keep motivated and perhaps you would never use the skills you learn? Hardware adds a tougher level to debugging - but software experience gives you a fantastic start - a logical mind and rational drilling down.
If you can fix your car you have the skills to start on electronics!
A lot of skilled people grew up through the hardware generations e.g. I began learning basic electronics because on an Apple ][ everything was simpler and we were all at the same stage. My first job was writing low level serial driver code and regularly dealing with serial devices (e.g. on PC). Our modern context is just not the same. The internet is hard to learn from. It is difficult to write good articles to help - the experienced like me just know a huge variety of implicitly learned knowledge.
I suggest you concentrate on a useful or fun outcome - I believe it's good life practice (and good engineering) to stay focused on the outcome and not get too side-tracked by explicitly trying to learn. We implicitly learn just by doing!
I'd like to think that this is a comment on the ease of fixing cars, rather than a comment about how fixing cars is basically embedded hardware/software dev....
Of course, trying to work around it in software is utterly futile.
This implies that old hardware always worked, which I strongly doubt (what year did hardware go from always working to not?).
I thought they (from cosmic rays, etc.) were always a thing, but so rare that you needed a very large system (in scope or time or both) to have a substantial chance of encountering one (outside of noisy comm channels, which use error correction protocols for exactly that reason.)
https://en.wikipedia.org/wiki/Qantas_Flight_72#Conclusion
Cosmic rays were suspected but unconfirmed (kind of hard to confirm after the fact).
"All the aircaft in the world" for sixty years is kind of a large system given that currently there are on the order of one million people in the air at any moment.
Bits flipping due to hardware that didn’t work well was what caused Xerox PARC to implement an error correcting memory for MAXC, fifty years ago.
> Bit flips due to buggy software was a thing though.
No kidding.
Unless you can stop cosmic rays.
Luckily it doesn't happen THAT often. I forget the exact metric but I recall various Google Engineers saying that something like one out of a million test run failures is a random bitflip?
Also, you can definitely stop cosmic rays, that was part of how they eliminated them as the source.
As I understand it, bit flipping in RAM is mitigated by error correction, via auxilliary and redundant bits.
https://en.wikipedia.org/wiki/Dynamic_random-access_memory#R...
Due to RAM/CPU failures? I don't think so (though I have seen it, fwiw). With weird serial protocols that don't have proper checksums/digests, running over sketchy wiring? Yeah, and that might be part of "very low-level code and hardware experience".
It meant that you didn't need the distinction of "logical operators" (like && in C) and "bitwise operators" (like & in C). You could just use bitwise operators, e.g. the bitwise NOT operator would convert 0 (all bits clear) was -1 (all bits set) so there was no need for "logical operators".
I always felt that was more elegant than C (but of course required a two's compliment machine, which BBC/Archimedes was, but C didn't require).
if (var == TRUE)
; // It was 7
else if (var == FALSE)
; // it was zero
else
??? what do I do here?
But, you know, what if it was a variable that you used in a switch statement instead? Or just "if (i > 17)"? Bit flips can affect your logic all over the place, not just when it's a boolean variable.
And then, if a bit flip can affect a boolean, it can also affect a pointer. Or the return address on the stack (or the link to the previous stack frame).
Or it can flip a bit in the code.
So this is, at best, a very very partial solution, and it's non-trivial to implement. So this was very much not standard practice or a "convention".
#define FALSE 0
#define TRUE (!FALSE)
ASSERT( TRUE != FALSE );
and let the compiler worry about which bits to use for TRUE
Any team that realizes that the compiler may choose to optimize out a shit-ton of such code gets an extra gold star.
Until you added the 2nd test and the 2nd else case, there is no scenario under which both paths of an if/else would fail to execute due to a bit flip of the test variable, because with ‘if (boolean_condition) {} else {}’ there is only 1 conditional test. A bit flip could have caused the wrong branch to execute, but it could not have skipped both branches. A bit flip could change the jump instruction to something else, but in that case your imagined else case still wouldn’t help.
> this is, at best, a very very partial solution
FWIW, the author said this, and fairly succinctly, saying this TRUE=7 thing is “of course foolish as such a 1 bit hardware error would "trash" pretty much any system”. He was only having a bit of fun that cost nothing, and nowhere suggested this is a solution to cosmic rays or other data errors.
If 7 == true and anything other than 7 == false, then one bitflip will still change the meaning. If 7 == true and 0 == false, then you could have code that does `if (mybool == 7) { ... }` and later `if (mybool == 0) { ... }` and end up with a situation where code path invariants are broken (i.e. mybool is neither true nor false.
If you use `>= 7` to mean true and `< 7` to mean false, while a 0 false value won't randomly become true if one of 3 bits randomly flips, a `7` true value will become false if any of those bits flip. And if any of the other bits flip, 0 will become > 7.
Or will you assume that one of the branches is safe to execute during failure?
Or will you count the number of bits in each conditional and assume more ones than zeroes is a true, with no error correction? Will you log that a bit has flipped or otherwise alert the operator? Will you consider that as evidence that an int has changed value too?
Will you store ints with three bits per bits also?
Error detecting codes have their place, but it takes more than just saying that true is 7.
Logical nots would then work.
And youre still an inc/Dec away from the opposite.
a) Two's complement representation
and
b) Wraparound on arithmetic, which is still UB in low-level languages.
Not doesn't rely on wrap around arithmetic.
Wrap around arithmetic is only undefined for signed values.
What platform doesn't wrap around signed integers?
Just because c has some undefined behaviour, doesn't make it some natural law of the universe.
Take good care of your code kids!
Got really depressed by it at the time, as it included most of the projects I worked on at the time. After that I got super paranoid about having backups.
I do enjoy going back and looking at the code I still have though. Being self-taught it's mostly not terribly great, but I do have fond memories of finally cracking a certain nut or figuring out some neat trick.
Many a person has had to learn it the hard way.
In this story the remote storage facility was my mom's house shortly before the GFC. The hardware were varying PS/2 computers from 286 to 486s with hard drives of zip files of my QBASIC, TurboPascal, Delphi, and VisualBasic code. The only hardware saved was our first computer, an 8088. All because she didn't want the clutter in the house anymore. No contact, no chance to retrieve said wares.. just poof gone. Gone were the Z80 ASM files of my rendition of PunchOut for the Ti-83+. Can't reference my old writings that I saved in various TXT files on the gazillion 3.5" floppy disks I kept in an old laundry basket. 5.25" floppies of DOS installs, random games, and an ancient version of SCO Unix. Gone.
Everyone learns the hard way.
A recurrent theme in retrocomputing forums. Never trust family with old computers; they consider them worthless.
I somehow managed to save mine. Hardware is with me, and data is well replicated, with warm, cold, remote, as well as cloud copies.
It is also all encrypted, thus it has a good chance to remain private unless I decide otherwise.
He is still alive today, he has a normal life and he even manages to go for a run in the beach every saturday. His exams haven't improved, he is always out of breath, but he just refuses to die. It's like what the physician said in the link above: "You look a lot better than what's in the paper".
Anyone know why doctors do this? They did the same thing with my father when he wasn't getting better (leukemia with pneumonia) and they couldn't get him off the breathing tube. They were very adamant he'd be disabled for life.
Still, if something happens to me or loved ones I hope I get doctors who can distinguish between zero and one in a thousand.
We hear a lot about all the times they're wrong, because they're tragic or frustrating or confusing, and because biology is super non-deterministic they're probably wrong more often than say physicists, but they're also right a lot of the time too, enough of the time that we consider it worth having them. We just don't get as many articles and anecdotes about a doctor correctly predicting someone's disability, because it's not as interesting.
This is a bit like receiving an inheritance from your grandparents. There will be true gems and novelties mixed in with a lot of knick knacks and rubbish. But the totality of that tells a story of real people living rich and interesting lives that only a handful of highlights would not do justice to.
But if you move on to another project and let time pass, the clay dries out and becomes brittle. When you open the project up again, it takes time to “wet the clay” - and remember all that context that you’ve forgotten. It’s easy to add bugs, or reimplement methods that already exist somewhere else under a different name. But over time, you work water into the clay and it becomes malleable again.
I agree with your comment. Refactoring software to split out libraries that you can opensource is a lot of work. More work than people realise. But if you think refactoring is a lot of work when the clay is wet, it’ll be many times harder if you let the clay dry first. Refactoring as you work is always the best way, because it’s often the only way to get it done.
There's a vibrant retrocomputing community.
Today’s trendy development practices are shockingly ephemeral and fragile. Very little of today’s projects would survive one decade left fallow, let alone four.
It takes a lot more effort to package stuff, since you can't just download your dependencies from the internet. But you also create something that isn't as ephemeral.
A few years ago we tried to rebuild some safety critical code from sometime back and were unable to because the certificates had expired and so the machine that can build the source code refused to connect to our version control system.
go makes this extremely easy to do
https://go.dev/ref/mod#go-mod-vendor
rust tool chain also includes a vendor dependency process
But maybe it’s worth going through and actively and explicitly downloading all those dependencies too. Who knows when npm will get hacked again, or old package versions will get yanked. Disk space is cheap. I’ve written a lot of code over the years. It would be nice to know it all still runs.
My fellow human, you have just nailed what is wrong with today's software.
> Very little of today’s projects would survive one decade left fallow, let alone four.
Thinking about the "dependency tree" for any modern convenience is truly staggering. I can't even start to think about how you can make a factory without first having a factory.
They already are, if something has been hijacked and is now malicious.
They already are, if you need to install something offline somewhere.
They already are.
But languages like go and rust have had the ability to “vendor dependencies” for awhile now.
Don’t need an active internet connection. Just need to have the toolchain.
Much of the old software found on bitsavers.org (and archive.org) was recovered using this utility.
You've made a contribution to the hoard that someone will benefit from, whether tomorrow or in 5,000 years.
----
One last bugfix before retirement (this is a joke):
I wanted to look at micro-cad it generates a 404.
URL: https://dunfield.themindfactory.com/dnld/sc/MICROCAD.ZIP Expected: I can download the .zip file.
Looking through some of these though, I think I'm inspired. Super cool idea, I would donate to the retirement project financially to say thanks if possible.
And what are the organizing processes you learned; I’m always eager to learn productivity tips/software from others
[1] https://archive.org/details/Programmers_Heaven_InfoMagic_Mar...
# we require more vespene gas; unix consensus; kNtErrorOutofmemory;
And slyly tells you the “password” to get past his spam filter
[It might be more a ShowHN if you are?]
I'm interested if all of the code is self-written? If you wrote any of it under contract and so had special terms to allow you to eventually release it? Which piece of code there that you are most proud of and/or gonna most useful?
If you're the author, please please release into the public domain (CC0) if your purpose is educational. That makes it so anyone can learn from it and build on it without any fear of infringement.
Am I missing something? Where did you get 23 years from?
Downside of self-hosting is time, money and effort. You've to spend for energy and hardware and your time and effort to keep them shipshape. Chances of it surviving beyond you are slim.
Both has downsides; just pick one depending on what kind of person you're. If you only want to write code vs that and also know how to maintain it. The latter is necessary skill if you ask me, instead of being just a code monkey.
Man how far people are brainwashed.
Not saying it needed to be on github only, but unzipping into a set of repos there in addition to posting the zips would be helpful.
I suppose anyone could do that, but then the provenance is not preserved.
Of course there would be a lot of reasons to use github, which I'll refrain from attempting to list since I'm not really an expert of that particular subject, but those benefits has to be weighed against handing over the control of such vast amounts of data to a huge corporation which I'd think its safe to say, primarily would be interested in profit and survival, rather than the wellbeing of the open source community. One might for instance consider the possibly of the data being used to train an AI, which in itself isn't necessary a bad thing, but that still raises some questions. Apart from that relying on github's, might lead to vendor lock in, and it might also mean that the processes that gets used to develop projects falls under control of a in a best case scenario selfish actor and in a worst case scenario a hostile one.
Perhaps you are familiar with the "embrace, extend and extinguish" strategy that Microsoft has been accused of employing? Things like these doesn't really inspire trust in the company's intention towards free software. Due to the size of the company, they are also capable of influencing the industry at large through various means, for instance via expensive advertisement campaigns, and to selling their solution to existing clients. So for instance they could create software such as VS Code and Teams, which would argubly be more or less copies of existing software, using their sizable pool of developers and then use it's huge marketing machinery to take over the market.
Even tough the open source community seems to be flourishing at the moment, there would be threats looming on the horizon. For instance the question of how to relate to service providers who can profit off of open source code, without really having to share back since the code is running solely on their own servers, another one being that open source code gets used to build closed solutions with the help of AI.
Personally I appreciate projects, that distribute code in the old-fashioned ways, which has proven to be successful in countless cases, and I would like to ask open source creators to consider the alternatives, and how they would fit in with the goals of the project. A lot of times I bet github still would be a good fit, but at the same time I'm sure that there are good ideas that could be implemented outside of those parameters.
Curious as to why you consider that a bad thing.
Its UI for presenting large number of software projects sucks, too.
The presence of use restrictions does also disqualify it from being Open Source (OSI trademark) or Free Software (GNU/FSF).
If a standard license was adopted instead, such as MIT (permissive and I believe well-aligned with the intent of the author), then any concern would go away.
> This file is NOT included in the demo version of this product.
> For more information, please contact Dunfield Development Systems
I admire the effort, but if you're not going to make the source freely available, what's the point? What is somebody going to do 100 years from now when they get your .zip off archive.org and you're long gone?
The author seems quite aware of this. He calls it out specifically: it's for learning and curiosity purposes.
> my goal now is to release 40+ years of source code
And there was no code in the .zip. Shrug.
Confusion on your part regarding what the other commenter's complaint is. The complaint is that the source code archive they downloaded did not contain the source code. It contained an old copy of a shareware notice instructing the reader to write to Dunfield for access to the source.
Confusion on Dunfield's part: specifically, the belief that he had included the correct version of RINGSW.C when republishing this stuff to celebrate his retirement.
Finally, confusion on the part of the other commenter here, involving an assumption that Dunfield's oversight was a deliberate decision.
(I do regret giving too much of my time to free projects, yet have found a satisfying balance by including source with purchases of software I sell.)
Otherwise AI will be the end of anything open - which we can already see in stackoverflow now.
I share what I do freely. If someone integrates that trivia and shares it with someone else, so much the better. I offer a fractional shoulder to stand on. Getting hovered up into an AI that then goes on to help someone else isn’t much different than having something random posted on the internet that solves someone else’s stumbling block.
But that’s just me.
Is there no such thing as "done" anymore?
It does not.
> Is there no such thing as "done" anymore?
Is there no such thing as "building upon it" anymore?
I wonder if the code manages be so clean because it's only aimed at a single compiler and a single platform. Multi-platform C code tends to be messy with preprocessor goo.
if it was on GitHub, and it made it to the HN front page, "tomorrow everyone forgets about it" would still apply.