Hacker News Reader

I've actually wished for something that takes it the other direction: Technically, everything it does is allowed, but it's designed to stress-test your assumptions. So, a distro that replaces half of coreutils with busybox, the other half with toybox or BSD ports or something, the system libc is musl, build tools are patched to randomly switch between using gcc or clang (both of which have `-Werror` enabled by default), user home directories are created like `/home/First Last/` (and if it doesn't have a last name for you it'll just leave a trailing space in the name), mktemp likewise is patched to stick temporary files somewhere other than `/tmp` by default (and always somewhere with a space in the name), /bin/sh is provided by dash (this isn't super rare, but some stuff still assumes that BASH is /bin/sh), normal programs are all in PATH but /usr/bin is empty (or maybe chmodded 000 or something)...

The idea is, if your code builds and works on this system, it'll run anywhere, correctly, because the system leaves no room for "oh, everybody does it this way, so it's fine to rely on this non-standard behavior".

Strange Linux

I once got an hdd from a mac user. It had trailing spaces in filenames. Leading spaces. Asterisks. Question marks. Colon. Forward slash. :c

I needed 2 computers to fix that one.

detox(1) fixes that.

Nix with --pure does most of what you want here.

It does about half of what I want, which is to rip away implicit assumptions about where stuff lives, that's true. I don't think nix is inherently going to help with the other half, which is to leave gotchas for what is visible/accessible (i.e. lots of files with spaces in their names, maybe a few files named ex. `-h` or `-rf` sitting in common directories, or for that matter have something available by the same name, but a different version, ex. your PATH contains a grep, but it's from busybox, not GNU).

I could imagine this being very useful in the form of a tool like debootstrap(8), intended for conformance fuzz-testing. Feed it a set of switches/enum values, and it'll install these various different odd technically-conformant things into a chroot for you, in any combination you like. Feed it a random seed instead, and it'll select the setup flags based on seeded PRNG output.

Now, set up your CI system so that your "POSIX build" builds N times, each time in a new one of these randomly-generated "technically POSIX" chroots.

IBM's z/OS UNIX System Services is very nearly this. Many UNIX systems have tons of utilities that more resemble BusyBox than GNU coreutils, and AFAIK no C compiler is anywhere near as compatible with GCC as clang (including, notably, slightly older versions of GCC itself).

But AFAIK z/OS is the only UNIX[1] variant that offers a "POSIX" environment

Where no subset of the native character set even resembles ASCII.

Where "everything is a file", but where many of these "files" — including, notably, both shared libraries and executable programs — are mostly inaccessible using anything resembling traditional byte-oriented UNIX utilities, library functions, and system calls.

Where process creation is not only "not cheap", but where it can in fact be so cripplingly expensive vis-à-vis conventional UNIX systems that the z/OS designers have (wisely) not only resurrected something akin to the traditional meaning of the "sticky bit" on executables, but have also made extensive provisions to allow both "subshell" scripts and executable subprocesses to be created within one's own address space, both via system calls and from within the POSIX shell itself[2].

On a related note, I was thinking the other day that an "evil", yet at least minimally standards-compliant filesystem in the spirit of your system might actually useful to have around for testing. Or, if not, would at least be fun to design.

Think a filesystem that imposes random per-directory length limitations on filenames and or file sizes, and occasionally allocates space for files in terms of random, per-file allocation unit sizes just because it can.

Or imagine a filesystem that flushes the overwhelming majority of data to disk promptly, but which also maintains a large "evil cache" containing a few blocks out out of the middle of every few million write calls that is flushed as infrequently as is permissible by the relevant standards.

And why let previously-allocated free space go to waste when, given careful planning, its contents could be used to present stale, yet technically "valid" data to applications that use I/O operations whose ordering with respect to one another is not formally defined for IPC (e.g., POSIX only explicitly defines ordering between its own read() and write() calls, so I/O by any means not passing through particular versions of these functions explicitly designated as POSIX-compliant can, in terms of standards-compliance, be "safely" ignored).

And so on.

[1] https://www.opengroup.org/openbrand/register/ [2] Google "_BPX_SHAREAS" for details.

Bonus points for no procfs.

This sounds like if the designers of the web made a Linux distro.

This is already what happens.

Just like the web (W3C?) was a front for microsoft taking over from Netscape, and now Google taking over from everyone else, the linux foundation et al are just fronts for Google et al to have whatever they want on the kernel and to prevent any and all GPL3 "corruption" of their take-take-take business practices.

GNU/Linux is old news, everyone runs BIGCORP/Linux today. You probably have more code from Google/Amazon/etc than GNU in any modern distro.

Just look at all the effort devoted to systemd (which is a blatant copy of oracle/windows service management) or everyone eating up the hype of zsh on macs (which is nothing but a spin from apple: Look how this new shell is so much better, oh bash is going to be GPLv3, no this has nothing to do with it, look how shiny is zsh!)

GPLv3 will set you free!

My paranoid thoughts about the state of disorganization in organizations like Mozilla and Gnome is that large corporations like Google and Microsoft clandestinely pay agent provocateurs involved in these organizations to derail progress in the projects.

Systemd is really just the most blatant of these kinds of efforts.

See https://www.cia.gov/news-information/featured-story-archive/... , starting from page 28

zsh is older than you think.

Apple switching to it on the day Bash announce new version to be GPLv3 is very recent.

They have certainly made lots of money with that model. You could almost argue this stuff does not really matter because people are effectively forced to use it, as is.1 There is no alternative choice.

1. If you manage to "beat the system", and bend the web to your will, those invested in it will label you an outlier or accuse you of being like Richard Stallman.

The Suicide Linux idea, and in fact, all "rm -rf /" jokes, are still perplexing to me because I always made systems where one could accidentally rm -rf / (still have not done personally that after 20+ years) and would not lose anything of importance, because / is an overlay and any long-term user data is stored on external media, separate from executables, which I unmount after a periodic save completes. I guess I could describe it as a minimal system booted from USB and running in RAM, overlayed with a more complete system (downloaded from the network then extracted), also running in RAM, with a workspace consisting of 100% RAM. The only way to destroy the system is to mount the USB stick read-write, chattr -i on everything and then try to rm -rf /. Impossible to do that by mistake.

Had to chuckle, but the I realized that everything is going in this direction on desktop as well

Actually worked on something similar about 16 years ago. The idea was an attacker could be led astray and then drop various behavioral clues to disclose their identity past a legally arguable threshold based on challenges and confusions selectively presented.

The guy I was working on it with dropped out of academics for a career of spirituality. He went off to a monastery so I also abandoned the project as well. We never even got a publication out of it :-/. These days you could probably make a very expensive product out of it.*

Someone else may have picked it up, I don't follow the literature anymore

---

* - I just realized maybe he went off to become a spook - I don't know how I never thought of that - even to this day many of my colleagues from the era work for these nebulous companies with names like "The Adirondack Group" who just have a basic website with a single email address. I never understood why they even try, just say "we are spies" - everyone knows it. Maybe it allows them to live otherwise normal social lives where they don't have to lie about the superficialities of their job? I dunno. It can't be actually project based - that'd be super retarded - instead of knowing "he works for the CIA" everyone would also know what project they work on - super dumb - that can't be it. I'll probably hit up one of my old friends to see if that monastery was real. He can probably say "yes" or "no".

ok, just talked to my friend. He was evasive and politely changed the topic so yeah, I still have zero information. I guess that's the right approach.

If I has asked him if he knew the name of the monastery as opposed to whether the entire story was a canard, I probably could have gotten further. By foolishly asking if it was a story, I think he fell back on the "zero information" strategy - as in, even if it's real and he's living a solemn life of meditation, don't say anything. Me effectively going "Hey man, I gotta question about spies" was in retrospect, pretty dumb.

> the operating system does its best to pretend that nothing is wrong

Initially, I though you were talking about the lastest MacOS. You had me there for a second.

> Hell Linux

As someone who accidentally moved /etc recently, I have been into the valley of darkness and wish for no further OS pain.

Interestingly, this can be made to work; IIRC, nixos supposedly works fine like that. AFAIK, the idea being that you only need to put non-default settings in /etc.

Try accidentally moving /bin. A buddy at work did that not too long ago. There was panicking involved.

That's a bit extreme. You should at least allow some error messages. Though those ones should just say "Oops, something went wrong :)"

Or perhaps the famous ? from ed :)

I like the error messages in some early BASIC interpreters. They must be as short as possible, since the entire interpreter fits in 4 KiB of RAM. For example, in Li-Chen Wang's Palo Alto Tiny BASIC...

The only message for all syntax errors, is:

    WHAT?

The only message for all runtime errors, is:

    HOW?

And the only message for legal but unsupported operations (e.g. out of memory) is:

    SORRY

See the source code here: https://github.com/ancientcomputing/8080_8085/blob/master/Ti...

From the Z80ASM users manual (1984):

Syntax Error

This message appears when the assembler is too confused to know what went wrong.

Ohhh the horror...

:(

Seriously speaking, it took me many years to realize that nearly all Windows BSoD messages are non-specific and useless - looking them up is a total waste of time. The only correct way to identify the actual error is analyzing the crashdump in WinDbg.

I recently fixed a family computer that crashes randomly after a RAM upgrade. Removing the RAM didn't help, and it was totally a wild goose chase. The BSoD stop codes indicate some types of crucial system errors or memory corruption, sometimes in drivers, sometimes in kernel, but nonspecific. Finally I installed WinDbg and opened the crash dumps, and all dumps have the same error, and it became obvious immediately,

    KERNEL_DATA_INPAGE_ERROR - This bug check indicates that the requested page of kernel data from the paging file could not be read into memory.

RAM was fine, the kernel simply cannot swap from the bad hard drive, no wonder it crashes. But the SSD was known-good, so I checked voltages, and saw the +5 V had a huge voltage drop. Upon closer look, found a loose wire at the power supply.

That's quite the debugging! I can see how you acquired your username.

I can imagine that BSODs are useful-enough if you're writing a Windows kernel driver (or doing internal QA for someone writing a driver), and your new driver is what crashes.

(Which would be pretty likely, since when qualifying a new driver, you'd be stupid to use anything but the most bog-standard hardware and drivers for everything other than the particular device-under-test.)

In this particular example, I think the error is as specific as it gets, though.

Please reread the comment. The quoted error is from the debugger, not from the stop code in a BSoD screen. The BSoD screen would be something like...

    0x0000000A: IRQL_NOT_LESS_OR_EQUAL

or...

    0x0000007E: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED

It corresponds to whatever the last operation kernel was executing before it fails, but without information on how it fails, and only indicates that something is wrong in the kernel or in a driver in general. You can chase these stop codes and check for bad RAM or bad drivers forever without real progress. Don't spend too much time on these codes, it's a waste of time. Enable memdump and get WinDbg. In comparison, analyzing the crash dump in WinDbg gives real information.

    KERNEL_DATA_INPAGE_ERROR - This bug check indicates that the requested page of kernel data from the paging file could not be read into memory.

One of the "nice side effects" of your shell design is that one can do away with thinking about POSIX requirements / portability, among other "potential goodies". ;-)

    - - -

But yes, if Hell Linux exists, it'd make a great candidate for a future QEMU Advent Calendar[1] submission.

[1] https://www.qemu-advent-calendar.org/2018/#about

Some of these design decisions precisely emulate the thought process of some 'architects' (never understood why that word was used for software) that I've worked with. They'd call some of these 'being resilient'.

Is there a name for this design philosophy? A lesser version of it is already what both shell scripts and PHP pages do by default. No crashing—only limping forward (likely in ridiculous invalid states.)

> if one branch exits with a nonzero exit code, the other branch is taken

That's called the Amb operator. It's actually fairly useful! Presuming you tended to write side-effect-free shell scripts, I could see enjoying this one.

> If you try to read a .json file that doesn't exist, you get the bytes "{}"

I would actually appreciate some little intermediary utility that would inject "{}" to stdout iff stdin was empty. It'd make piping maybe-JSON documents through to jq(1) work a lot more smoothly.

> If you try to connect to a port that nothing is listening on, it does its best to behave like the service that should be listening there.

I love the idea of the xinetd(8) equivalent to Busybox. A multi-protocol stub server, that knows how to speak literally every protocol, and listens on every port it can, but does nothing much over any of those protocols. It could serve as a way to slow down a Metasploit scan, by offering it an endless variety of things to try to exploit!

Some variants of BASIC had the infamous 'on error resume next' statement.

> In shell scripts, if one branch exits with a nonzero exit code, the other branch is taken.

> 0 exit code is reported for all processes, no matter how they terminate.

These two things are mutually exclusive - shell script branching is usually based off of exit codes.

I read that, and I thought that.

But then I decided that the GP was probably throwing out suggestions, not developing an internally-consistent model for the final design. :)

Not quite mutually exclusive, I think. The combination just means we always try the "true" path first, in our depth-first search of paths out of the script.

> the operating system does its best to pretend that nothing is wrong

There is already a major OS with this characteristic.

That looks like a cmd.exe emulator. Just replace / with \ so it gets confused with escaping sequences.

I wonder what horrors you can subject the user to with only modifying the kernel. Nothing to kill the machine, but some sort of trickery involving messing with argv or randomly messing with process memory and silently prevent the resulting mess from being sent a SIGSEGV.

> the operating system does its best to pretend that nothing is wrong, so it takes you as long as possible to realize that you've made a mistake

Aka “the PHP design philosophy”?

I remember some of earliest Android phones returned shell errors as “__: not found” using LSM just to make ROM devs’ life harder

Gosh this gave me the chills. I am afraid some people are that creative to cause chaos!

> the operating system does its best to pretend that nothing is wrong

Call it "Trump Linux"! :)

If we're poking fun at political leaders, maybe the antithesis to this OS - one that pretends everything is going wrong all the time - should be Brussels OS