Notices by divVerent (divverent@misskey.de)

@don_atoms@hostux.social @aral@mastodon.ar.al Maybe I do not get it, but why?

"People" is the status quo. Other "people" control what I can do with e.g. my phone.

But it should be me, the user.

"The people" as a whole may however exert democratic control over which things should be possible to some extent.

@theorytoe@ak.kyaruc.moe stop badgering me

@lanodan@queer.hacktivis.me @ska@social.treehouse.systems @mirabilos@toot.mirbsd.org "rm -i", already mentioned, uses stderr both for prompts and error messages.

Which means things look funny (missing line feeds) if you were to e.g. "2>&1 | tee" it.

That is what IMHO should be avoided. Can a compliant rm use /dev/tty for the prompt instead? What if the OS is not Linux - is there always a reliable /dev/tty?

@lanodan@queer.hacktivis.me @mirabilos@toot.mirbsd.org @ska@social.treehouse.systems Which actually demonstrates kinda an issue in "POSIX as it is used today": Logging and interactivity go to the same file descriptor, usually stderr (2).

That's actually a bad thing.

Of course, by the original intent, logging should go to syslog and only interactivity or error messages that are actual output of the tool for the user should go to stderr (and then that's a quite evil mix TBH, and probably should use two separate FDs - as an example, on Linux one can open /dev/tty for interactivity, and then use fd 2 for error output only). Logging to stderr is kinda an antipattern.

And yet people would complain a lot if I were to make my desktop game AAAAXY write its debug logs to syslog instead of stderr... as syslog is only really intended for system services, and the application logs which I write to stderr ending up in ~/.xsession-errors is actually the right place where people would look. OTOH on Windows, applications writing to the Event Log (and not stderr) is very much right.

I think this is actually an example of something that historically grew into a semi bad shape.

@lanodan@queer.hacktivis.me @mirabilos@toot.mirbsd.org @ska@social.treehouse.systems Worse, a completely separated daemon that's now just some weird legacy support in systemd.

But directly talking to journald is bad too, as then the program becomes Linux speciifc for no real reason at all.

@lanodan@queer.hacktivis.me @ska@social.treehouse.systems As for why I suggested remapping stdout: I too often had issues of dependencies writing random stuff to stdout breaking tools that want to use stdout as a redirectable output for a pipeline.

Most common in shell scripts, not C programs, though... it became very common for me to write

exec 3>&1 1>&2

so that I regain control over what goes to stdout.

@ska@social.treehouse.systems @lanodan@queer.hacktivis.me I almost wonder if it wouldn't be better to dup2 stdout to 3 and then stderr to 1, so regular printf defaults to stderr.

Or just move to a proper logging library. Maybe just syslog with LOG_PERROR for a start.

@lanodan@queer.hacktivis.me @Willow@social.translunar.academy @navi@social.vlhl.dev @mirabilos@toot.mirbsd.org Sadly also a problem for Go, especially the second part of this.

And yet both Rust and Go have a good reason for static linking everything that's in their own language - both languages perform cross package inlining and thus one cannot reliably change an upstream library without recompiling any and all downstream code depending on it.

In C we get away with being less strict on ABI stability guarantees by putting some work on the caller. E.g. even if a module returns pointers to structs (like AVFormatContext), it's kinda common knowledge a caller can't just allocate a new one of the same type and, say, copy the previous context into the new one. As such, correct C code using this type never needs to know its size, and as such, the FFmpeg team kinda stands a chance at maintaining "good enough" ABI compatibility. However, if a caller were to violate this contract, this will very likely end up in undefined behavior - something both Go and Rust don't want to allow by design (even though both languages have their "holes" - e.g. a Go object containing a sync.Mutex better not be copied).

All this could in theory be fixed - but neither Rust nor Go really put any thought into ABI compatibility, and as such, common modules or crates aren't designed to provide it at all, as there isn't even a common coding style in use that ensures it. Ideally, a language should be designed with ABI compatibility in mind. The typical way would be to ensure that no features of the language create implicit requirements for ABI compatibility.

E.g. if all access to struct fields is via setter/getter methods, then these methods can be managed by the linker, and as such, the exact offsets of the fields or the size of the struct no longer matter to the ABI - provided these methods never get inlined of course. But... if we do that, we have massive performance losses. How does Java get away with it then? By its JIT approach, of course, which inlines the accessor methods at runtime.

Outside JITs, we seem to only have the choice of languages like C where the burden is put on the developer of both the caller and the callee, or languages like Rust and Go where this issue hasn't been addressed at all and everything's linked statically instead.

But... there just must be a way... the way how Go resolves interfaces at both runtime and compile time may be a hint: e.g. those offsets to struct fields could be computed at runtime when first needed (or even just at startup), and then stored for code to use (or even just replaced in the compiled code itself - dynamic linkers can do such stuff). We still definitely won't get cross package inlining back though.

That, or ditch the idea of an ABI altogether and just ship source. Or "obfuscated source" i.e. files with intermediate code, like Java does.

@prettygood@socially.drinkingatmy.computer @scathach@stereophonic.space Python 3 is impossible to use correctly anyway.

Exercise: write up a simple clone of the unix "cat" program. Just copy sys.stdin to sys.stdout. Anyone can do that.

Test it manually, all is good.

Then run it on /dev/urandom.

In Python 2 this exercise is trivial.

And yes, it is fixable by two ways (there is an env variable solution, and a code solution to use the underlying buffers, not the handles themselves).

Once you understand that, try writing a program that accepts file names as option args. Those file names may not always be valid in your encoding, as file systems tend to not guarantee that. Another oops...

@prettygood@socially.drinkingatmy.computer @scathach@stereophonic.space Meanwhile in Perl land:

print while <>

@Loki@whinge.town From what I have seen it is not blacks that get offended by this, but whites who misunderstood MLK.

Having said that, never bring someone food without talking about it first. Dietary restrictions, both religious, medical, generally health related and ethical ones, vary wildly, and so does taste - to the point there exists no single "safe" food that works for everyone.

@Loki@whinge.town At least two major religions ban alcohol. Call them gay if you want to, but I sure won't take any.

@Loki@whinge.town If they are, who is Mitt Romney's boyfriend?

@Loki@whinge.town Good point So Muhammad's Aisha was a boy?