Word of the day: shimulate

shimulate, vt.: To insert a shim into code so it simulates a desired standardized ANSI/POSIX facility under a deficient operating system. First used of implementing clock_gettime(2) under Mac OS X, in the commit log of ntpsec.

I checked first use by Googling.

56 thoughts on “Word of the day: shimulate

  1. Just today got bit by systemd for the first time, officially. I’ve successfully avoided it til now. Firewalld doesn’t always die when systemd promises it isn’t running anymore, you see, and you have to pkill it. The only symptom is that the start times out, with no usefull log messages *anywhere*.

    Why did so many distribution release configuration managers drink Lennart’s Flavor-Aid on these components? It’s no longer even practical to switch back, since *distro repos no longer require sysVinit compatibility*.

  2. Just today got bit by systemd for the first time, officially. I’ve successfully avoided it til now. Firewalld doesn’t always die when systemd promises it isn’t running anymore, you see, and you have to pkill it. The only symptom is that the start times out, with no usefull log messages *anywhere*.

    You need to report a bug on systemd, preferably to your distribution’s bug tracker. (Sometimes they make goofs in their own patches, or ship old versions with the bug already fixed upstream… and if neither of those, it’s normally the package maintainer’s responsibility to forward the bug upstream.) systemd’s entire job is to track processes, even in cases of double-forking and other tricks that would leave things zombified on sysvinit. What you’ve described is systemd failing to do that job :-)

    this might sound like an apologist’s post… maybe it is. It just bugs me a bit (pun intended) when people describe such obvious bugs and resort to using them as a platform to complain instead of getting it fixed.

  3. On the subject of the jargon file, I started reading it some again, and have noticed a couple things so far. On the special character test page, “schwa” is rendered as an ASCII @ sign rather than the proper unicode version ə – which I’m sure was reasonable in 2003, makes it look a bit dated now. While the special character test page itself works, many of the actual lexicon pages have invalid unicode (the file itself appears to be in ISO-8859-1 encoding). Also, it would be nice to have a “one big HTML” version to download.

    Also, the source tarball extracts to the current directory rather than a subdirectory.

  4. @random832 –

    > Also, the source tarball extracts to the current directory rather than a subdirectory.

    Matter of taste. I almost always create a sub-dir for a new project/item/, and am often annoyed when it then unpacks into an additional dir (which I then have to hoist it out of). The documentation should tell you which way it does it. (@esr – HINT, HINT)

    > On the subject of the jargon file, I started reading it some again, and have noticed a couple things so far….

    Hello! Submit a fscking patch in “diff -c” (or better!) format! Don’t make ESR do all the work!

  5. At this point I’m wondering if it would be fun to set up a source repository of the File and restart work from there.

    Maybe even a historical repository of All The Versions, as appears to be the fashion these days.

  6. Why’d you think I downloaded the source? Now I just have to figure out how to get the danged thing to actually build. And I don’t even know if I could reproduce the Unicode problem without his web host; the issue is the content-type header being sent by the server. It thinks it’s UTF-8 but it’s not (though honestly it’d be nice if it was.)

    Anyway, other things I’ve not even mentioned yet are the kind of things that are going to take an army to go through all entries fix, and isn’t worth doing without a design decision from the editor on whether these things are as worthwhile as I personally think they are – like chasing down citations, adding hyperlinks to things that should have more hyperlinks, etc.

  7. And of course, finding any changes worth keeping in the “5.0.1” fork. Which appears to be mastered in Tex. If this is worth doing, it’s worth doing right.

  8. > resort to using them as a platform to complain instead of getting it fixed

    I don’t want it fixed. I want it nuked from orbit, and replaced with something that doesn’t violate Unix principles — and indeed, basic good software engineering principles — nearly so badly.

    And I’ve tried hanging bugs on big monolithic packages in the past. Not a single one of them has ever been touched. KDE, Firefox, you name it. I don’t have time to marry their entire codebase.

  9. Further example of the practice:
    fbida – use strsignal
    (use strsignal if possible, else emulate with sys_siglist)
    And a conceptually analogous trick, for a port from GIFLIB 4 to giflib 5 (while retaining compatability with the old version, because it hasn’t disappeared yet):
    fbida – port gif reader to giflib 5
    (Actually, up until then it had been expecting libungif, but that’s roughly the same as GIFLIB 4.)

  10. @Baylink – hear, hear! I’m trying to think of a single principle of the Unix philosophy that systemd doesn’t violate and I’m coming up short.

  11. Baylink,

    There are plenty of Linux distros that still do not use systemd: Slackware and Gentoo are major ones, plus there’s Crux and VoidLinux actually used systemd at one point and switched away. If you want an easy installer and nice Windows-like UX — well, remember that those things are the K-Y Jelly of computing: it may go in easy, but you’re still getting fucked.

    Note that at some point, presumably within the next few years, X11 support will likely be dropped from the major toolkits, so systemd will probably be a requirement to get graphics going since that’s how Wayland acquires permissions to use the framebuffer. (And GNOME hard-depends on systemd, so that’s out.) But until then — at least as long as the Wayland experience remains terribad compared to what’s here now and works — you have options.

  12. @esr

    I would broaden the definition, by removing its dependency upon *nix shimulation.

    shimulate, vt.: To insert a shim into code so it simulates a desired standardized facility under a deficient operating system. First used of implementing clock_gettime(2) under Mac OS X, in the commit log of ntpsec.

  13. (Bleep it; Eric, if you would approve only this version/delete the previous two?)

    It’s no longer even practical to switch back, since *distro repos no longer require sysVinit compatibility*.

    I’m responding by shifting to a base Xen supporting distro which won’t ever use systemd (Alpine), and I’m hoping to run as the standard DomU VM the current Ubuntu LTS that’ll be supported until early 2019, which uses systemd a bit, but not in PotteringOS fashion. That gives me time to help with the process of developing better alternatives.

    And I’ve tried hanging bugs on big monolithic packages in the past. Not a single one of them has ever been touched. KDE, Firefox, you name it. I don’t have time to marry their entire codebase.

    Jamie Zawinski expressed this well in his Cascade of Attention-Deficit Teenagers (CADT) paradigm essay, where a couple of years worth of his GNOME 1.x bug reports were closed as irrelevant with the release of Gnome 2.0/2.2, with an invitation to resubmit if that was not true. Observations of the general truth of CADT as you note, of how so much FOSS is going from maybe OK to really bad (e.g. GNOME 3), and otherwise seldom improving, and wondering about the future of PotteringOS, excuse me, Linux, especially when Linus no longer can play the role he does now, has me looking at joining efforts at properly rebuilding a lot of this stuff from the ground up, e.g. starting with seL4.

    The biggest difficultly I see with any style of attempting to improve things is the gross complexity required by modern web browsers, and the inherent dangers of doing stuff on the web. The amount of work required would seem to defeat the FONC (VRPI/Alan Kay), Lisp Machine, and formally verified approaches. Leaving … Rust/Servo? Which given it and Mozilla in general’s SJW infestation, I’m not about to bet on any time soon.

  14. Yup, Jeff, and that’s when the people in the middle — the ones big enough to care, but too small to have the labor available to build their own distr *and repos* from scratch — will be completely screwed.

    I wonder how that’s going to work out.

  15. Under the broadened definition, Microsoft uses shimulation all the time, in the form of its “compatibility shims” that can be selectively included to allow older programs to work on newer versions of its OS. (I know, I spoke the name of the dreaded Beast of Redmond, but hear me out…)

    They have to do this, because every business (and many consumers, too) has at least one “deal breaker” application that has to be able to run under newer versions of Windows, or they just won’t upgrade. See Raymond Chen’s post on this subject for more details.

  16. @Erbo – the difference there is they are implementing a worse API in terms of a better one, rather than the other way around.

  17. > I don’t want it fixed. I want it nuked from orbit, and replaced with something that doesn’t
    > violate Unix principles — and indeed, basic good software engineering principles — nearly
    > so badly.

    Sing it brother.

    > And I’ve tried hanging bugs on big monolithic packages in the past. Not a single
    > one of them has ever been touched. KDE, Firefox, you name it. I don’t have time
    > to marry their entire codebase.

    https://www.jwz.org/doc/cadt.html

  18. @Jeff Read:
    > There are plenty of Linux distros that still do not use systemd: Slackware and Gentoo

    There are only 3, maybe 4 distributions that matter. Red Hat[1], Ubuntu, SuSE and *MAYBE* Debian.

    That covers somewhere between 95 and 99% of the business/corporate/education base.

    Just like FreeBSD is slowing losing ground, and Net and OpenBSD are basically hobbies for people on the spectrum, so are the other Linux Distros.

    I’m not saying they don’t have technical merit, or that they’re bad–but things like this exist on market share, and for what ever reason, they don’t have it.

    Oh, and that kind of sucks because now the Internet Of Things is going to wind up based on one of those four (probably Centos or Debian), and as a consequence will be bloated and full of security holes.

    But yeah, something will come along in a decade or so to replace systemd. We’ll whine about it then too.

    [1] I include Fedora, Centos and Scientific Linux under the umbrella “RHEL”.

  19. >Matter of taste. I almost always create a sub-dir for a new project/item/…, and am
    > often annoyed when it then unpacks into an additional dir (which I then have to
    > hoist it out of).

    mv ..
    cd ..
    rm -rf

    F’k me that’s a tough hack.

    IMO it’s MUCH better to tar up the directory than just the contents because that way you have a minimal chance of stepping on someone’s files by accident. Yeah, it might cause people like you and I to have to type an extra line, but it’s just safer.

  20. @William O. B’Livion –

    > F’k me that’s a tough hack.

    Oh, I wasn’t trying to imply that it was tough. And yes, I can take the TOC of the tarball first and see if it’s rooted in $DIR or .

    Your remarks about not clobbering the files in the current directory are spot on.

  21. Bell:
    > I can take the TOC of the tarball first and see if it’s rooted in $DIR or .

    Then in theory you could wrap tar with a shell script that checked the TOC itself and created a directory or not based on the output of that.

  22. Sure, but I think the controlling theory here is the Principle of Least Astonishment. If I go to unpack a tarball, the odds the files in it will conflict with other things in a directory or clutter that directory up and be hard to clean up after — if it wasn’t what I wanted — are much lower if the contents unpack *into a directory*; that’s the way I’ve always heard it should be…

  23. Then in theory you could wrap tar with a shell script that checked the TOC itself and created a directory or not based on the output of that.

    Such a script already exists. It’s called aunpack.

  24. Tar doesn’t have a TOC — not without extensions. It’s just a sequence of header chunks followed by file data, in 512-byte blocks. You have to walk the whole tarfile (uncompressing it if compressed) to find out what’s in there, which aunpack presumably does.

  25. @Jeff Read –

    > Tar doesn’t have a TOC ….

    I don’t care about the implementation details – I meant the output of “tar t{decompress_opts_if_needed}”. Functionally, that’s a Table Of Contents.

    • >did the community ever come to any consensus on a word for exploratory codebase modification?

      No, and I wasn’t super happy with my original proposal either. No sightings in the wild yet.

  26. My instinct would be to have the script create a directory, unpack into it, and then remove the extra level of indirection iff the tar file contained exactly one directory. This does require some extra maneuvering in the (likely) case that the directory it creates (from the basename of the file) has the same name as the directory extracted from the file, and I’m not quite sure yet how to solve it.

  27. I had not read CADT yet, though I’d seen it go by, and I didn’t realize that it addressed this point; I’m off to read it now.

    For those anti-systemd people who didn’t realize it was a movement, with four-part harmony and feeling, check out:

    http://suckless.org/sucks/systemd

    https://news.ycombinator.com/item?id=7207655

    http://ewontfix.com/14/

    And a couple related pieces about Lennart himself, whose rhetorical style is as little liked as his design:

    http://www.zdnet.com/article/lennart-poetterings-linus-torvalds-rant/

    http://www.linkedin.com/pulse/20140924071300-170035-why-you-cannot-trust-lennart-poettering-systemd

    and finally, a relatively pragmatic appraisal of why, in fact, Flavor-Aid seemed to tasty to the aforementioned RCMs:

    https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdWhyItWon?showcomments

    (Happens I disagree with that last piece’s thesis, on at least one critical point: older init’s didn’t have lots of doco *because they didn’t need it* — they did one thing, and did it well.)

    Oh, and you can get a t-shirt:

    http://teespring.com/systemd-sucks

    And finally, here’s a nice long reddit thread about whether the “systemd is bad *because* it violates the Unix Design Philosophy” argument holds water, that our Fearless Leader will probably have an opinion on, if not the time and energy to relitigate it. :-)

    https://www.reddit.com/r/linux/comments/2k5b7e/the_concern_isnt_that_systemd_itself_isnt/

    [ Sorry for hijacking your thread, Eric; I’ll shut up now. ]

  28. >the difference there is they are implementing a worse API in terms of a better one, rather than the other way around.

    The overriding principle here is that the best API in the world isn’t going to matter, if the fact that your OS doesn’t properly support a “worse” API that somebody’s key line-of-business application relies on means that you lose an upgrade sale. In that respect, the “desired standardized facility” could be the older, “worse” API, and the “deficient” OS could be the newer one that doesn’t properly support it.

  29. > (Happens I disagree with that last piece’s thesis, on at least one critical point: older init’s didn’t have lots of doco *because they didn’t need it* — they did one thing, and did it well.)

    Right, which means there’s no formal documentation on how to accomplish some bit of functionality that, since it doesn’t do it (it not being part of the one thing it does well), you have to implement from scratch and shoehorn into the existing init script model.

  30. Honestly, I think the use of “unstructured”* text files was and is one of the big mistakes of the “Unix Philosophy”, so, whatever my overall opinion on systemd’s architecture, it’s hard to really agree with people who think the use of XML or JSON is a major fault.

    *unstructured, adj. [syn. human-readable] – of a text file: having a unique** format only truly understood by a single tool. – maybe the jargon file needs a devil’s dictionary equivalent.

    **except, of course, for the ones that are technically shell scripts which accomplish configuration by being sourced and providing variables into a surrounding shell script context

  31. @Random832:

    You say the first part like it’s a bad thing. Everyone has different needs; the vast majority have *no* special needs; those who do often want to do them their own way anyway — the proper solution is “provide a good framework and a sample solution implemented in terms of that framework” not “do it the way you think best locked up in a binary box”.

    As for config file format choices, while I understand the attraction of XML for machine parseability (and generability), the framing to data ratio — and hence the odds of gratuitous errors causing problems, is too high for me, for files commonly maintained by humans.

    JSON I like a lot more.

    But — and here’s the part everyone misses: “installed base”. There are lots and lots *and lots* (easily billions) of machines out there with already working configs, and, more to the point, lots of SAs (easily millions) who have spent lots of time developing the reflexes for the current system and — absent a *real need* for the replacement — ought not to have their time unilaterally deflected to “learning the new and unreasonably complex method” from whatever they were going to use it for, especially without compensation.

    I, personally, resent Poettering deciding that my time was better spent learning his exceptionally poorly architected new system *and refitting stuff I’ve done in the past that’s deep enough inside it won’t work anymore*, instead of, say, going to the beach.

    And sure, that drives some of my distaste. But not all of it, by any means; I have good objective reasons for it as well.

  32. Baylink,

    I’m reminded of the observation by Douglas Adams: “The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at and repair.”

    It applies to systemd, and it applies to Red Hat systems as a whole. Granted, I have no love for Ubuntu, but the *brittleness* of getting a Fedora system up and going is appalling. And oftentimes, it’s because systemd is too damn clever for its own good.

    Meanwhile my Slackware system Just Works, and if it breaks I can fix it in situ with “simple hand tools” (common Unix utilities).

    • >I think the new term used in the blog would be good candidate for a new one that should be added.

      Under my rules at least two observations of usage in the wild, not obviously connected to the originating post, would be required.

      I’ve coined a lot of jargon. Only a handful of it passed that test and got in.

  33. @Jeff Read,
    “and oftentimes, it’s because systemd is too damn clever for its own good.”

    I recently had cause to install Ubuntu Server LTS on a laptop, which I’d temporarily re-purposed as a ‘server’.

    Everything went well, until I shut the lid, and the system SUSPENDED. This was a HEADLESS installation of a SERVER operating system!

    The particularly tragic part of all of this is that I’ve put off migrating all my non-toy machines to FreeBSD because of that OS’s fairly poor laptop support. Even Ubuntu Server does better ;)

  34. And that’s why Slackware is still important. All the hardware support of Linux in an easy to deploy distro like BSD. Slackware releases are more stable than Ubuntu or any other distro besides perhaps Debian, and supported for a long time. Heck, Slackware 13.0 is still supported with security patches and that was released six freakin’ years ago!

  35. esr, off topic but might be important: are you aware of the FCC’s proposed rulemaking that could affect users’ ability to install their own OS on any device with a wifi radio? The proposed rulemaking notice is here:

    https://www.federalregister.gov/articles/2015/08/06/2015-18402/equipment-authorization-and-electronic-labeling-for-wireless-devices

    A recent article discussing it is here:

    http://prpl.works/2015/09/21/yes-the-fcc-might-ban-your-operating-system/

    I have only skimmed the proposed rulemaking, but it looks to me like the above article’s claims about how extreme this is might be justified. If so, this could be sufficient cause for another Internet Blackout Day-type effort.

    • >If so, this could be sufficient cause for another Internet Blackout Day-type effort.

      It could be, but I’m not among the people who usually organizes those. Likely the EFF will lead on this.

  36. The FCC is authorized in this country to regulate the electromagnetic spectrum in order to prevent radio interference. And no, no magic mesh technology is ever going to come along and make interference not a thing.

    It has ever been the case that for radios with programmable frequency and power output, the FCC considers hardware and software as a single unit when it comes to certifying these devices for unlicensed consumer use. The goal is to ensure that the user has no way of setting the frequency or power out of spec during normal operation. If it’s possible to set the radio device to transmit at unauthorized frequencies and power levels via software, and any but the approved software is being run, then technically you are running illegal equipment. What this also implies is that releasing open source radio control software is difficult from a regulatory standpoint because in principle anyone can modify the source code, recompile, and set the radio to transmit illegally. This bit Atheros in the ass when they tried to offer Linux driver support; what they ended up doing was shipping a binary blob with all the radio control that got linked into the kernel module.

    So as far as Uncle Sam is concerned, the router — hardware, software, and all — is a single unit, and in order to be legal it must prevent the user from transmitting illegally. If you can just download and flash a new firmware image and set the radio to unapproved settings — it doesn’t matter if you intend to, only that you can — the FCC will come knocking on the manufacturer’s door.

    As it turns out the FCC isn’t particularly interested in banning open source. So it should be possible to build a compliant router by isolating the radio bits from the main CPU and having the radio governed by baseband firmware that enforces the regulatory policies, allowing the main CPU to run whatever OS its user wants without ever permitting the radio to be set to transmit illegally. But this adds to costs in a thin-margin industry, both in terms of hardware and configuration management, so router companies are more likely to let the OS itself enforce transmission regulations and then lock down the OS from ever being changed.

    Besides which, the baseband in such a router would have to be closed source out of necessity, and that would invalidate some of the security advantages of having an open source router OS.

    So it’s a sticky, complicated situation, and one that open source may not have a viable solution for. We may have to live with proprietary firmware or else buy more expensive gear that is designed to be open source friendly. Or, you know, stick a USB wifi dongle in a Raspberry Pi and call THAT your router.

Leave a Reply

Your email address will not be published. Required fields are marked *