While XML was imperfect from overcomplication, JSON is imperfect by falling short of even basic database use, and somehow despite its alleged simplicity it manages to be unstandardized almost as badly as Markdown. JSON and YAML both fail to have comments that survive processing, something it's easy to regret since XML does have comments that appeared in the parsed objects.
A saner subset of XML, possibly run through some over-caffeinated developers to lighten its redundant syntactic feeling, would have given us something FAR better than JSON's failure and YAML's gratuitously hypercomplicated syntax.
XDG doesn't handle complex environments, especially not heterogeneous computing environments. Something long the core strength of Unix is acknowledged by XDG and then left utterly unaddressed. Without this, the "standard" is as much an impediment as an aid.
It's amusing that modetc goes through all this effort to twist dotfiles into the XDG half-solution, and here I am using symlinks through /dev/shm/xdg/* to warp XDG into sort-of working in an actual heterogeneous environment.
Because XDG by itself is a failure beyond trivial cases.
A while ago, I just wrote a filter to be able to paste markdown into a <name>.smd file, and an Apache filter to autoprocess them much like any other filter (and a <named>.smd.meta for title info and some other metadata).
This makes it super easy to write something cool on Reddit or whatever, then just paste the markdown into an index.smd file in a new directory (named meaningfully) and poof it's in a webpage.
The core of all of it is a /var/www/cgi-bin/markdown-to-html program centered on:
# This works, with setup in /etc/apache2/conf-enabled/mod-ext_filter-adds.conf
AddType text/markdown .md
AddType text/markdown .smd
AddOutputFilter markdown-to-html md
AddOutputFilter markdown-to-shtml;INCLUDES smd
Much easier to just edit markdown (index.smd usually) and reload than reconvert, and that filter above lets you include arbitrary HTML too, critical to deal with markdown numerous weaknesses.
I just hate that (1) you can't nest anything into a table (2) it's different everywhere.
Restructured Text is much more capable, and yet here we are, still using Markdown.
My markdown pages often also have HTML in them, I mainly use Markdown so if I decide some overlong thing I wrote on Reddit actually doesn't suck, I can copy-paste it into a webpage, and my web-server's .smd handler does the convertion. Lowest common denominator. :(
Don't put suffixes on command names. Don't. It's a DOS thing that has no meaning in Unix. It confuses users. It breaks hiding implementation details. It encourages users to do the wrong thing. It makes changing what language a script's in have a ripple effect of breakage across everything else that uses it.
The general movement of UI paradigm has been from one tech to the next with a focus on backwards compat. Almost amusingly so at times, but this is how all the earlier users and use cases can most easily progress. E.g.
* hollerith cards and sundry + printer
* printing teletype
* dumb (video) terminal
* smart (cursor addressable) terminal
* images of smart terminals
* images of smart terminals with color (businesses resisted color for years)
* ... ?
And in the meantime we have an evolution of support for modelling things visually and working with more descriptive protocols - or even function-defining protocols to raise the abstraction chatting with the display server in realtime. In this, "abstracted" means something that can be sent over the network instead of using a local buffer. These are in a less strict order than foregoing...
* text, color plotters, VDST, and all that other old slow stuff
* [skipping a bit up through bitmapped greyscale graphics]
* bitmapped color graphics
* abstracted 2D graphics (-> W and X)
* abstracted 3D graphics (OpenGL + GLX)
* dynamically client-extendable remote graphics servers (NeWS, mostly 2D)
* ... ?
So here I am, waiting for the next stage in these. Hypothesizing that finally we'll get something with 3D abstracted, network graphics (display lists in GLX but accelerated with something like XCB?), where the primary display coördinate space is (x, y, x) instead of (x, y), where the client can push some code to the remote server and raise the abstraction on the fly, finally. Where maybe we'd be able to permission the objects in that space and share it among users live. Where the 2D apps would be inside the 3D space instead of the other way around. Something for the 2000s instead of familiar abilities provided in 1990.
But instead, Wayland. Wayland, which is not backwards compatible with X. Wayland, which is 2D at its heart. Wayland, another 1990 era graphics system with a super thin offering of features for actual end users (not devs) which come at substantial cost in lost X features. Wayland, which resists the one user doing things we've long thought of as normal - in the name of "security".
I can't really enjoy an article on CSS where the third thing he does is to override the USER'S PREFERRED FONT SIZE.
Arrogant.
But not as bad as those jerks that use smaller and smaller, progressively lower contrast text as the actual content gets more important. Huge readable repetitive headings, microfiche gray-on-gray for the stuff that mattered.
Their docs don't even mention homes mounted over NFS, or LDAP managed users. This is the same sort of pathetically marginal garbage that damns Snaps, which somehow think that large environments put all user directories in /home - even that that is NOT a standard and doesn't scale worth a damn.
Systemd is a curse, the TRON MCP that doesn't even seem have a system for alternate solutions to compete. Before systemd we saw a more lively environment of alternatives for each service area, but systemd strangles this with a collection of mediocrities, and lack of foresight.
Looking through the doc at https://systemd.io/HOME_DIRECTORY/ shows a entire webpage built of ideas many would rightfully reject, some defy standards, some defy common sense, and best practices, fail to scale, add arbitrary constraints, or have other problems.
I've been a sysadmin at large sites before. systemd-homed looks a lot like unusable trash.
This whole issue just seems so pathetic. PostScript and DPS, notably NeWS, have device-independent scaling from the outset - you can completely omit even mentioning pixels, even though they're 2D. Wayland braying on about scalability here just highlights how they don't even understand the game.
Going to OpenGL is a nice tactic, since OpenGL doesn't give a flip about screen coördinates anyway.
I miss NeWS - it actually brought a number of great capabilities to a window system - none of which, AFAIK, are offered by Wayland.
Using abort() every time malloc and kin fail isn't really satisfying anything except the idea that the program should crash before showing incorrect results.
While the document itself is pretty good otherwise, this philosophical failing is a problem. It should give examples of COPING with memory exhaustion, instead of just imploding every time. It should also mention using "ulimit -Sd 6000" or something to lower the limit to force the problems to happen (that one happens to work well with vi).
Memory management is mature when programs that should stay running - notably user programs, system daemons, things where simply restarting will lose precious user data or other important internal data - HANDLE exhaustion, clean up any partially allocated objects, then either inform the user or keep writing data out to files (or something) and freeing memory until allocation starts working again. E.g. Vi informs the user without crashing, like it should.
This general philosophy is one that I've seen degrade enormously over recent years, and a trend we should actively fight against. And this trend has been greatly exacerbated by memory overcommit.
It's a beginners article about memory management. I think it's weird that so many comments here are judging the code snippets as if they're commits to production systems. When writing articles like these there are pedagogical decisions to be made, such as simplifying the examples to make them easier to understand.
A saner subset of XML, possibly run through some over-caffeinated developers to lighten its redundant syntactic feeling, would have given us something FAR better than JSON's failure and YAML's gratuitously hypercomplicated syntax.
Developers Are Stupid - developer.
reply