Hi, sorry for late reply, On Sun, Aug 23, 2020 at 1:45 PM dmccunney <dennis.mccun...@gmail.com> wrote: > > Trying to get listed by the FSF is an exercise in futility.
I don't know if it's truly impossible, I never asked them. My silly floppy disk image (with minimal networking) is probably not worth much to them (nor others), but I did try. Maybe it's too generic? But I included various tests and lots of download links. Maybe it's too specific? Certainly it could be heavily expanded (as DOS often was). If it is truly impossible or considered not worth doing or using, then I still feel we should do our best with what we have. (Heck, even just emulating under QEMU is better than nothing!) But look at the hurdles Minix 3.x went through (not related to FSF), it seems impossible for alternative OSes to barely make a dent these days. But Android or ChromeOS might be larger (more practical and useful?) targets than DOS these days, especially with the impending death of BIOS/CSM. The big advantage of "anybody with a BIOS can run it!" has almost disappeared. (Same with the increasing popularity of ARM, thus IA-32 isn't as common as it used to be, and x64 is mostly hostile to 16-bit.) > The FSF has long ago ceased being about technology. It's a religion, > and Richard Stallman is its prophet. (I've met him, and know people > who've known him for decades. He's an odd person. In Stallman's world, > all software is FOSS, issued under the GPL. No surprise various Linux > distros don't pass his compatibility tests.) It's rather about ethics, he's against hoarding and limiting user freedom in any way. It's also very legalistic and pro-business use (as well as pro-hobbyist). Of course, this only truly matters to (would-be) developers. But most people don't seem interested in fiddling with makefiles and boring minutiae. (Most things should be MUCH easier to rebuild.) It's a very difficult struggle since there are so many "traps" (proprietary formats, DRM, trade secrets, patents, hardware variations). Admittedly, compatibility with familiar DOS APIs / interfaces may not be useful to them. > And open source has fragmented. My irony meter pegs off scale when > one open source product cannot incorporate code from another because > they are issued under incompatible licenses. (And Gnu is a Worst > Offender - my understanding is that GPLv3 is incompatible with GPLv2. > That's just hopelessly stupid.) GNU admits that license proliferation is bad: developers need to take a serious step back and be less controlling, but such is life. > FreeDOS began as an effort to produce an open source OS compatible with DOS. > It mostly succeeded. The kernel and shell are GPL, so it's impossible to say we're not sympathetic. But I think GNU has little patience for those who rest on their laurels. There's too much old legacy code still using proprietary tools (e.g. TASM) that should've been converted to something Free (e.g. NASM) long ago. Admittedly, it's VERY hard for a newcomer to do that, and often the original author / maintainer is long gone. So it never gets done. That's a truly tedious and thankless job, but it's still important for future improvements. (It's MUCH harder to fix bugs or add features if you can't easily rebuild.) > But people buy computers to do work or play, and the OS sits between > the user,. the program they run, and the hardware. A *lot* of > programs people want to run *aren't* open source, and won't be. Irrelevant! To Free Software users/developers, it's more about what you can do than what you can't. But the main problem is uniqueness. Is FreeDOS unique enough? 8086 is very limiting and unpopular these days. No one makes 8086 hardware anymore, and its memory model(s) are inconvenient to 386 "flat mode" users. But we also have DJGPP (for 386), which should greatly ease that struggle. Yet even that has been mostly ignored for many years (but was very popular "back in the day"). Is 8086 a worthy target? Is even 386 (or 686) obsolete? (Also bad that DJGPP is COFF and not ELF.) It's not that we don't have GPL'd 16-bit compilers (e.g. GCC IA-16 ELF or FPC cross-compiler for i8086-msdos), but who would use it? (Obviously I would, but I'm no genius.) GNU recommends the following utilities for Makefiles, at minimum (e.g. awk, sed, grep, diff): * https://www.gnu.org/software/make/manual/html_node/Utilities-in-Makefiles.html IIRC, they also recommend C (or even C++ nowadays) for building most things. Or Scheme (Guile?) or Emacs Lisp. (DJGPP has a recent-ish GNU Emacs build.) I don't think they directly care about cpu architecture, but they do care about the surrounding ecosystem. One of the biggest limitations with DOS is its FAT file system. Most developers just don't care enough to work around its limitations (even with optional, partial LFN support). For whatever reason, that often trips people up. (DJGPP relies way too much on VFAT under XP's NTVDM or similar to rebuild most things. Most stuff never bothered to bootstrap in raw native DOS. That is a serious flaw, even if I sympathize.) So, I think FSF would recommend more popular (ARM? RISC-V?) hardware these days. One third-party user did make a minimal GNU/Linux distro with Python and Git. See what I mean? Targeting 8086 with NASM or even 386 with DJGPP is probably less appealing to them than other options. They also still use Texinfo, which converts to a variety of documentation formats. (There's a lot of duplication and fragmentation in software, too many competing tools.) > Even if it were possible for FreeDOS to get listed by the FSF, what > would FreeDOS get out of it that would make the hoops worth trying to > jump through? Self-defeating prophecy: "I can't imagine it, so it's not worth doing." But perhaps "if you build it, they will come" isn't always true either. It's a thankless job bearing little fruit, yet without it, you get nothing. You're basically being a perfectionist "just because" or "just in case". Sadly, the zeal found in Linux circles isn't found around DOS. > Ignore the FSF. The rest of the world increasingly is. GCC and BinUtils are mostly maintained by Red Hat (owned by IBM) and a few other groups. Clang is very popular too, but I'm not sure if anyone can fully give up on BinUtils yet. GPL ideals are still very prevalent elsewhere. > Developments I'm following these days are generally under MIT or 2 clause BSD > licenses, precisely to make the license as open and unrestricted as > possible, and allow code sharing to happen. GPLv2 is probably still, by far, the most commonly-used, open-source license. We've had people take permissive software from FreeDOS and restrict it (for literally no practical benefit). That may be their legal right, but without any actual benefit, it comes across as either petty or short-sighted. I don't recommend such irrational behavior. I guess I take it for granted that software is meant to help people and not restrict them. Proprietary software may not always be evil, so I don't claim that. But it certainly helps less than openness. (But sometimes it's unavoidable. Who can be blamed for what they can't do? Hey, time is limited, people have other priorities, too.) I absolutely think GNU had the right idea. It's almost rebellion against a broken and flawed copyright system, almost reinventing the wheel just because no one would cooperate properly. It did greatly help the world, and we all did reap the rewards of their hard work. I totally think it's a good attitude, but life is more complex than that. But it just seems we can't truly "develop" these days without being architecture-specific, which limits the lifespan of software. If we're not too heavily tied to cpu, we're either too heavily tied to OS or distro or compiler or .... That's what frustrates me, there is no clear path. Nothing lasts very long (too much deprecation or replacing). We need solid platforms worth supporting. Well, at least there are tons of Linux laptops nowadays (e.g. System76 or StarLabs), often running Ubuntu LTS. Just use something "standard" like C++ (or close enough, e.g. FPC [GPL!]), and go from there. Perhaps we need a DOS-centric Linux distro (and/or recommended hardware OEM)! (Sorry for the ramble.) _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
