What about C?
Without the C programming language, we wouldn't have the computer operating systems we've become co-dependant with,
like: Microsoft Windows, Apple Mac OS X and yes, even Linux servers and desktops.
The creator of AT&T UNIX; Ken Thompson and the creator of the C programming language; Dennis M. Ritchie, both ushered the world into a new era of computing.
What they actually did was to offer a programming language with source-code that was cross-system compilable(!), and an accompanying operating system (UNIX) that, unike it's predecessors, was a portable operating system (POSIX-standard). Meaning: it was entirely written in the C programming language (whereas earlier OSes were written entirely in assembly),
making it compilable on several computer-platforms (apart from the 16-bit PDP-11 for which it was originally written).
Many clones of Unix have arisen over the years, most notably the various flavors of BSD' in the 80s, but none of them enjoyed the wide user-adoption like Linux, having overtaken the popularity of
"true" Unix on server platforms since it's inception in the early 1990s.
AT&T UNIX debuted as a modular PDP11/20 mini-computer operating system in 1970, mostly for so-called super- / power-users, programmers, academia and industrial communities. UNIX was also very instrumental for the creation and further development of ARPANET (otherwise known today as the Internet).
Some sample-programs in C
I don't use 32-bit processors, so I won't be supplying 32-bit binaries.
If you want 32-bit binaries, I suggest you compile them yourself ;)
Like this: "
gcc programname.c -o programname".
Listed tarballs contain C source-code and a x86_64 LSB-compliant ELF-binary (Linux-executable).
These sample-programs are offered "as-is", they are freeware
(i.e. not governed by software-licenses). You can do with them as you please.
*** links are coming... ***
Norwegian C-programs:
These programs were made as part of my programming / system development course (2013-2014).
And therefore, all output made by the programs are in Norwegian (no_NO.UTF-8).
These tarballs contain C sauce and a x86_64 LSB-compliant ELF-binary.
Year 2038 Problem / s2G
*** what is the YEAR 2038 PROBLEM / s2G ? ***
Excerpt from
wikipedia.org:
The year 2038 problem may cause some computer software to fail at some point
near the year 2038. The problem affects all software and systems that both
store system time as a signed 32-bit integer, and interpret this number as
the number of seconds since 00:00:00 UTC on Thursday, 1 January 1970.
The furthest time that can be represented this way is 03:14:07 UTC on Tuesday,
19 January 2038. Times beyond this moment will "wrap around" and be stored
internally as a negative number, which these systems will interpret as a date
in 1901 rather than 2038. This is caused by integer overflow. The counter
"runs out" of usable digits, "increments" the sign bit instead, and reports
a maximally negative number (continuing to count up, toward zero).
This is likely to cause problems for users of these systems due to erroneous
calculations.
Further, while most programs will only be affected in or very
close to 2038, programs that work with future dates will begin to run into
problems much sooner. For example, a program that works with dates 24 years
in the future will have to be fixed no later than 2014.
Because most 32-bit Unix-like systems store and
manipulate time in this format, it is usually called Unix time, and so the year
2038 problem is often referred to as the Unix Millennium Bug, or s2G.
The tarball listed below is provided as an example of "The Year 2038 problem / Unix Millennium Bug".
It contains C source-code and a x86_64 LSB-compliant ELF-binary.
The "2038-linux-bug" program is offered as-is, it is public domain.
To counteract this issue, modifications have been made to certain parts of the
Linux operating system to defer it for another 204 years.
"Ext4"-excerpt from wikipedia.org:
As computers become faster in general and as Linux becomes used more for
mission-critical applications, the granularity of second-based timestamps
becomes insufficient.
To solve this, ext4 (Linux file-system) provides
timestamps measured in nanoseconds. In addition, 2 bits of the expanded
timestamp field are added to the most significant bits of the seconds
field of the timestamps to defer the year 2038 problem for an additional
204 years.