You could start out removing the autocrap checks for <sys/stat.h> and <stdlib.h>.
Then you could eliminate all the other autocrap checks which come out one and the same way on every single OS in existence.
And in all likelyhood, you would find out that you don't actually need autocrap at all, because the remaining two checks can be done with an #ifdef instead.
Makefile.template
Makefile.SunOS
Makefile.Linux
Makefile.FreeBSD
cp Makefile.template Makefile.'uname' && vi Makefile.'uname'
People who'd "kept it simple" like you suggest were the bane of my life. I spent more time debugging each of those builds than all of the builds that used actual tools combined.
(Ironically enough "all projects must use autotools" seems like a quite cathedrally attitude though)
There are of course occasional glitches, but not like those ones.
People don't want a clunky computer any more; except for computer people, I don't know anybody from general population who has one. I'm offended that we're even wasting time discussing desktop anything!
Also I don't see anything here on these APIs,
https://developer.android.com/guide/index.html
https://developer.apple.com/reference/
https://developer.mozilla.org/en/docs/Web/HTML/Element
That relate to these ones:
You mean they carry their portable UNIX servers in their pockets with them. Since they all come with a web browser, there's your application's or your server's front end.
and use this thing called apps on them.
I have a few of those on my mobile UNIX server as well. Stupidest thing I've ever seen or used, "apps". What for, when they could have used a web browser to display their front ends, or could have ran on a backend server and just sent the display to the web browser? Most of those "apps" I use won't function without an InterNet uplink anyway... idiocy pur.
Which means the OS running on the server is equally irrelevant as long as it can serve pages, CSS and JavaScript.
Which ad absurdum makes UNIX APIs irrelevant for cloud computing.
https://www.usenix.org/legacy/events/osdi10/tech/full_papers...
Hell, I built one for a guy's gaming rig a little while back. That replaced his hand-me-down from a company designing & installing sprinkler systems. Why he have that? They just bought new desktops for all there CAD users. Lot of CAD users out there probably have one too. ;)
Plenty of RAM? Yes, but on supercomputers. My machines were sgi Origin 2000's and 3800's running a single compute intensive application doing finite element analysis and using 16 GB of RAM, across all the CPU's in the system. A single calculation would usually take a month.
On the desktop, you couldn't be more wrong: I was part of the cracking / demo scene, and we literally counted clock cycles in order to squeeze every last bit of performance in our assembler code, me included.
One can also look at the numbers. Last year, over 17 million PC's were sold in US. Think the buyers were really all computer people? Even with 3 year refresh cycle, low end, that be estimate of around 50 million computer people in this country that's been buying desktops over 3 years. Think they're really that big a demographic?
But if you look at the number of PC's sold year over year, the number is dwindling at the rate of roughly 15% - 18% per year. Look, for example, under the "Global Computer Sales" column, here:
http://www.statisticbrain.com/computer-sales-statistics/
the average laypeople don't want computers any more, and the sales reflect that. For their needs a tablet or a mobile telephone with a web browser is pretty much all they need, and the web can and does now deliver pretty much any kind of application they could ever need or want. And that's precisely where most of the sales of desktops were. Professionals using computer aided design and people like you and me are few and far in between, in comparison.
On an sgi related note, I myself owned several Octanes and even an sgi Challenge R10000 (with a corresponding electricity bill). I must have torn and rebuilt that Challenge four or five times, just for fun. My primary workstation for years (which I fixed and put together myself) was an sgi Indigo2 R10000, with an hp ScanJet II SCSI scanner, a 21" SONY Trinitron, and a Plextor CD-RW SCSI drive, back in the day when CD-RW was "the thing". With 256 MB of RAM when most PC's had something like 16 or 32 MB, it was a sweet setup. Ah, IRIX 6.5, how much I miss thee...
Anyway, the answer to your question is iPad Pro by Apple Computer. It runs an operating system called "iOS" which is a heavily customized FreeBSD on top of a custom CMU Mach kernel. And it's UNIX03 compliant. UNIX! It's everywhere!
I'm aware of it, it's not good enough. Its UI is terrible when you need to work with multiple applications, it's a pain to customize anything and even more of a pain to run your own programs.
How does you .profile on iOS look like?
There isn't a standard UNIX way to do GUIs, bluetooth, NPC, GPGPU, touch screens, cryptography, printers, medical devices, ...
All that UNIX has is POSIX, http://pubs.opengroup.org/onlinepubs/9699919799/ , which only focus on CLI and daemons as applications.
Anything else are not portable APIs that don't have necessarily to do with UNIX.
It doesn't matter that the kernel is UNIX like, if what is on top of it isn't.
And anyone that only knows GNU/Linux as UNIX, should read "Advanced Programming in the UNIX Environment" from W. Richard Stevens/Stephen A. Rago, to see what actually means to write portable UNIX code across POSIX implementations.
GUI is dead; if your application doesn't run on the server and display the results either on the command line or in a web browser, you're doing it wrong.
So you use VI and Emacs on Android, generate postscript and troff files, configure /etc/passwd and /etc/init.d
How does your Android .profile look like?
Yes z/OS has a POSIX subsystem, it also doesn't support anything besides CLI, daemos and batch processing.
Mac OS X is a certified UNIX, however none of the APIs that matter. You known, those written in Objective-C and Swift are UNIX.
> GUI is dead; if your application doesn't run on the server and display the results either on the command line or in a web browser, you're doing it wrong.
Better let all of those that earn money targeting infotainment systems, medical devices, factory control units, GPS units, iOS, Android, game consoles, smart watches, VR units, POS, ... that they are doing it wrong.
I don't use Android, because it's a ridiculously hacked-up version of GNU/Linux (as if being based on GNU/Linux isn't bad enough).
Have you spawned a shell on it? The filesystem is a royal mess, the likes of which I've never seen before. Could I run vi and groff and even SVR4 nroff on it? Yes, if I wanted to waste my time with it, I could.
How does your Android .profile look like?
I didn't touch .profile because I don't care for bash one bit, but it was there.
However, in this context, it's still UNIX. A hacked-up, ugly UNIX severely mutilated to run on mobile telephones and tables, but conceptually UNIX nevertheless (honestly, I have never seen anything to hacked-up and mutilated like Android, and you can bet that in 30+ years of working with computers, one sees all kinds of things).
1. That just pushes the issue back to the language implementors. Ever discover that your favorite language is unavailable on your new platform?
2. You get restricted to the least common denominator. Thay one OS feature that would make your app 10x faster? Sorry.
Do you think C had any major meaning outside UNIX, before it got largely adopted in the industry?
It was just yet another language with dialects that had some kind of compatibility, with Small-C being the most used one.
For the second point, also not an issue unless the language doesn't support FFI.
The beauty of runtimes, instead of bare bones C, is that they can be tuned to make the best of each OS APIs, while keeping the code portable.
This is nothing new, it was quite common outside AT&T.