What I'm looking for is conceptually similar to cygwin - where the "kernel", or better worded - the POSIX API - is provided as a library, not as a separate process that communicates via IPC with the minC "app"'s process. However, unlike cygwin, there should be a static libminc.a (or .lib) that can be used to make standalone binaries that don't need an external DLL like cygwin1.dll. MingW is not an option here as it lacks too many POSIX apis, but it could serve as the base toolchain to compile minc itself, and the programs linking against it, by switching out (or overriding) the default library and include paths. Basically making it use MinC's libc and OS syscall layer, but keeping its WinAPI interface. That would allow cross-compiling minc applications from linux, without having to use a win32 binary toolchain. Alas, the short project description on the website and on the github repo don't address any of these (imo crucial) details.
would like to read, but the site uses some clownflare alternative, that just like clownflare tries to verify my browser (palemoon), and then comes to the conclusion that my browser isn't a browser.
It's a comfortable, feature-rich interactive shell like bash, but with a relatively clean and small codebase, and the binary is only a third of bash's size. It's also much easier to build from source. Sort of a suckless bash replacement. Not compatible to most bash features though, focus is on POSIX compatibility.
if the purpose of cloudflare is to block bots and allow humans in, then they fail miserably at their job. what they're doing instead can be summarized in one word: DISCRIMINATION. welcome to the age of internet apartheid.
the micro-dependency scheme used by go, rust, js and others is to blame.
makes it far too easy for people to pull in libraries for just about any task, even if it can be coded in just 5 lines. this often results in simple apps having hundreds of recursive dependencies.
a C programmer thinks twice whether to use a 3rd party library, because users will have to install it using their distro package manager. so they generally stick to what's commonly available there or write their own 20 lines for micro-tasks. one of the benefits that come along with that is that these distro packages are usually well vetted.
> When a new member discovers your community, joining should be easy.
But it ain't, because they will be greeted with this text:
"Unfortunately, your browser is unsupported. Please switch to a supported browser to view rich content, log in and reply."
That's active exclusion (as opposed to being inclusive) based on a User agent string that's been declared non-kosher by some developer.
FTR, this is what palemoon users get to see when they try to read a discourse forum and they will have to read the forum using HTML plaintext because scrolling is disabled for those non-kosher browser.
using palemoon, i don't even get a captcha that i could solve. just a spinning wheel, and the site reloads over and over. this makes it impossible to use e.g. anything hosted on sourceforge.net, as they're behind the clownflare "Great Firewall of the West" too.
the approach of meson to hardcode the properties (including the name of the main executable!) of each and every compiler in the universe seems pretty short-sighted if not outright dumb and isn't quite how the designers of UNIX, the C language and compiler toolchains envisioned a build system to work.
if meson was properly designed, a user could just run `CC=whatevercc meson ...` and it would work with basically each and every single compiler available on *NIX and every POSIX compatible environment, including gcc, clang, tcc, cproc and even within cygwin.
the only compiler i know that works differently is MSVC and it would be easier to just provide a wrapper that transforms POSIX-compatible compile command lines into ones that MSVC understands.
(this reminds me of the head-desk approach CMake takes to adding library dependencies: each library has a hardcoded configuration file, which can go as far as scanning your /usr/lib for libfoo.so rather than just assuming "-lfoo works, and if it doesn't, use $PKG_CONFIG --libs foo"...)
