one thing that i really dislike about Unix is the zealous adherence to semi-accidental design elements that ends up interfering with the utility of the underlying useful principle
for example:
- early Unix could not run too complex a program due to hardware restrictions, so programs were composed using text streams
- useful underlying principle: designing your applications for composition
- zealous interpretation: your OS should have a toolkit of single-purpose programs communicating over text streams
- design we could have had, but never will: applications that communicate using structured data, simplifying life for both programmers and end users
Kristian 🌒 mag das.
teilten dies erneut
✧✦Catherine✦✧
Als Antwort auf ✧✦Catherine✦✧ • • •there is also much to be said about splitting your application into many different pieces, but keeping a unified approach to application design so that the pieces may be understood via a unified mental model
i think some Unices (that i haven't really used enough to comment) do approach userspace design like this, but the GNU-plus-random-tools userspace you're much more likely to encounter definitely doesn't
maswan
Als Antwort auf ✧✦Catherine✦✧ • • •The one commercial unix that had a unified design thought in tooling that I've experienced was AIX. The normal naming for tools was things like:
lsuser, mkuser, chuser, rmuser
lsfs, mkfs, chfs, rmfs
lsvg, mkvg, chvg, rmvg
But GNU, Solaris, and IRIX which were my other exposures had very little of this.
maswan
Als Antwort auf maswan • • •Addendum, I had forgotten that most of these (but not all) also had a -c or -C (not consistent, grr) for colon separated output instead of pretty printed tables.
ibm.com/docs/en/aix/7.2.0?topi…
lsuser Command
www.ibm.comwebhat
Als Antwort auf maswan • • •maswan
Als Antwort auf webhat • • •By that time, I was the AIX guy for legacy systems, and the new cool stuff was all linux.
@whitequark
snowyfox
Als Antwort auf maswan • • •Sensitiver Inhalt
✧✦Catherine✦✧
Als Antwort auf ✧✦Catherine✦✧ • • •why the actual fuck does Linux not have a syscall for /proc/self/maps
it is beyond ridiculous that the 2026 solution to "find out what my memory mappings are" is fucking fscanf
Yurii / Юра
Als Antwort auf ✧✦Catherine✦✧ • • •I can imagine only security-related stuff like anti-cheats.
✧✦Catherine✦✧
Als Antwort auf Yurii / Юра • • •Yurii / Юра
Als Antwort auf ✧✦Catherine✦✧ • • •Interesting. While working with JITs and allocators, I never looked beyond virtual memory, hence the question.
I'm not saying have the mapping is not useful, just pointing out that mileage may vary, so that may be the reason nobody has done it.
✧✦Catherine✦✧
Als Antwort auf Yurii / Юра • • •Yurii / Юра
Als Antwort auf ✧✦Catherine✦✧ • • •Basically my process' address space is what it is.
✧✦Catherine✦✧
Als Antwort auf Yurii / Юра • • •Yurii / Юра
Als Antwort auf ✧✦Catherine✦✧ • • •I see now. But again, never had to encounter those.
It’s fascinating to watch Linux evolve.
On one hand, one may expect /proc/self just for coherency. On the other, in corporate development, I’m a proponent of not writing code until it’s actually required. If someone implements a linked list with `insert_before`, I’ll ask them to delete `insert_after` if it’s unused.
Linux seems to handle this naturally, by the absence of certain patches.
✧✦Catherine✦✧
Als Antwort auf Yurii / Юра • • •@iurii you still fail to understand the core of my complaint. it is not about the specifics of /proc/self/maps. it is rather about how little care and thought was put into the design of the system as a whole.
moreover, the Linux development process actively filters out people with better taste who could improve the design, both by exhaustion of having to deal with assholes (gregkh isn't much better than linus) and by virtue of "if everything around you is a pile of crap, there is little point in building something great"
robryk
Als Antwort auf ✧✦Catherine✦✧ • • •✧✦Catherine✦✧
Als Antwort auf robryk • • •robryk
Als Antwort auf ✧✦Catherine✦✧ • • •uis
Als Antwort auf robryk • • •Yurii / Юра
Als Antwort auf ✧✦Catherine✦✧ • • •to me, it is a mystery why BSD is decaying, and Linux is thriving.
Judging by the readability of code only, it should be vise versa. Knowing a bit about maintaining OSS project makes me think sometimes that being an asshole is a hard requirement, I don't know.
Yurii / Юра
Als Antwort auf ✧✦Catherine✦✧ • • •I understand the complaint, I was just cautious to frame it that way.
if you view Linux not as a coherent system but as a set of related patches, it makes more sense, but yeah... When I was trying to understand how TCP/IP stack is implemented in Linux, I was reading BSD code, because "look we apply this flag just to make socket handler look like a file's one because unrelated code crashes"
I'm still fascinated by the lengths that Linux has made always being like this.
Yurii / Юра
Als Antwort auf ✧✦Catherine✦✧ • • •✧✦Catherine✦✧
Als Antwort auf ✧✦Catherine✦✧ • • •m_on_stair
Als Antwort auf ✧✦Catherine✦✧ • • •dont get me started on the different decisions, by those codebases, on what the actual file path of the mapped objfile should be
is it resolved? symlink only or also hardlink? is it relative? a special prefix to annotate remote targets? your guess is as good as mine!
Charlotte
Als Antwort auf ✧✦Catherine✦✧ • • •David Chisnall (*Now with 50% more sarcasm!*)
Als Antwort auf ✧✦Catherine✦✧ • • •This one of the things that keeps me on FreeBSD. Linux decided to put most of the things that the BSDs put in sysctls in filesystems and make them human readable. The equivalents on the BSDs are usually structured data from a sysctl.
About 20 years ago, I wrote some code for showing machine info in a desktop environment’s about box. On FreeBSD, NetBSD, OpenBSD, and Solaris, the information was exposed as sysctls. They had different names, but it was trivial to write a little wrapper where each platform told you the sysctls to use.
On Linux, the info was in /proc/cpuinfo. The structure of this changed between releases and also between architectures on the same kernel version. The code for Linux was more than all of the other three platforms, combined, and that code was just to interface with a 300 KiB library that included a parser that worked on all of the different versions.
It makes me sad that so many people’s first experience with a F/OSS kernel is with a design that bad.
mxk
Als Antwort auf ✧✦Catherine✦✧ • • •But yes, the whole fact that there is no generic interface to proc that avoids parsing strings is pretty embarrassing.
Alonely0 🦀 🇪🇺
Als Antwort auf ✧✦Catherine✦✧ • • •Myrrh Periwinkle
Als Antwort auf ✧✦Catherine✦✧ • • •"Starting with 6.11 kernel, /proc/PID/maps provides an alternative ioctl()-based API that gives ability to flexibly and efficiently query and filter individual VMAs. This interface is binary and is meant for more efficient and easy programmatic use. struct procmap_query, defined in linux/fs.h UAPI header, serves as an input/output argument to the PROCMAP_QUERY ioctl() command."
The /proc Filesystem — The Linux Kernel documentation
docs.kernel.orguis
Als Antwort auf ✧✦Catherine✦✧ • • •Also, Linux procfs is not one from Unix, it's one from Plan 9.
postweber
Als Antwort auf ✧✦Catherine✦✧ • • •Dragoon Aethis
Als Antwort auf ✧✦Catherine✦✧ • • •One of great things about Windows PowerShell is how much stuff in there is object-based, not text-based. So much stuff has normal introspection, normal names that make sense if you're not heavily experienced in that system already, functional autocomplete, and then if you need to do some cursed bullshit, you can just drop into a big boy programming language inline in the same script and let it handle that object directly.
Screw Windows, but they learned from *nix mistakes there T_T
Kristian 🌒 mag das.
✧✦Catherine✦✧
Als Antwort auf Dragoon Aethis • • •@dragoonaethis yeah I wanted to daily-drive PowerShell on Debian at one point
unfortunately... as you probably already know, PowerShell
Dragoon Aethis
Als Antwort auf ✧✦Catherine✦✧ • • •eh, PowerShell is fine, it's just not nearly as useful if you're on a system where you have to parse everything yourself anyways to make its good parts useful.
And then no *sh compat that breaks compat, different flags for basic stuff that break your muscle memory, eh
Kristian 🌒 mag das.
✧✦Catherine✦✧
Als Antwort auf Dragoon Aethis • • •Dragoon Aethis
Als Antwort auf ✧✦Catherine✦✧ • • •David Chisnall (*Now with 50% more sarcasm!*)
Als Antwort auf Dragoon Aethis • • •@dragoonaethis
It also leans heavily into verb-noun naming, which integrates poorly with autocomplete. And exposes objects more as structured data than objects, but doesn’t have the kind of polymorphism that functional languages have, which makes it very hard to write code that is generic over the data types.
It feels like a system designed by someone who saw a demo of Smalltalk and didn’t understand any of it but tried to copy it.
Richard Barrell
Als Antwort auf David Chisnall (*Now with 50% more sarcasm!*) • • •Dragoon Aethis
Als Antwort auf David Chisnall (*Now with 50% more sarcasm!*) • • •ティージェーグレェ
Als Antwort auf David Chisnall (*Now with 50% more sarcasm!*) • • •I remember, (maybe decades ago now) being excited by the prospect of PowerShell back when it was still known as Monad. Somehow I got the idea that maybe it supposedly derived inspiration from Lisp Machines (stuff such as Symbolics [Open]Genera was very object oriented too if the sorts who wrote the UNIX Hater Handbook could be believed).
Alas, when I finally got around to running Monad? And its later PowerShell renamed iterations?
Nothing but disappointment after disappointment.
It's inexcusably slow to interact with for a CLI.
Back when I used to get paid to administer Windows systems, PowerShell basically was a sideways if not backwards move from cmd.exe and RDP to me any time I actually needed to get something done. I was much more grateful for Cygwin and even uwin and to a lesser extent SFU (Services For UNIX). Though if it weren't for WSL (Windows Subsystem for Linux) becoming a thing so I could run something such as bash without cygwin.dll conflicts rearing their ugly head and Micro$oft overhauling cmd.exe heavily? I probably would have given up Windows even sooner.
These days, you can't pay me enough to touch such things and tbh, I am probably owed a lot of back pay from any organization which previously paid me to suffer through such stuff. It's awful. I may harbor slightly less resentment for the (Open)VMS systems in my past, because they were fewer in number mostly. (MPE in my past is still a wtfh, those things were so weird I am grateful I encountered them but I am way more grateful I have not encountered any since 2006).
But Monad/PowerShell did have "promise"!
Playing with old Smalltalk implementations is still far more joyous, and faster, and less resource demanding and to me at least, demonstrative of a more holistic design ethos. Though, I never did get around to revising this MacPort enough to submit a Pull Request: trac.macports.org/ticket/67457 Someday, maybe? Smalltalk has iterated into various other neat things and derivatives, but PowerShell? Ungh, it just seems to get worse with time.
CC: @dragoonaethis@mstdn.social @whitequark@treehouse.systems
#67457 (WIP: new Portfile submission: smalltalk) – MacPorts
trac.macports.orgJernej Simončič �
Als Antwort auf ✧✦Catherine✦✧ • • •Matteꙮ Italia
Als Antwort auf Jernej Simončič � • • •Cassandra is only carbon now
Als Antwort auf ✧✦Catherine✦✧ • • •Mark Dunne
Als Antwort auf Cassandra is only carbon now • • •I’ve had a pretty good time using nushell to do some otherwise gnarly data wrangling, but there is definitely a mental model transition that slows things down and I haven’t yet mastered. I’m not sure yet if it’s an inherent learning curve, or if there’s just an awkward mismatch between the shell pipeline and some operations. It’s enough like shell, and enough like some weird functional language and enough like sql that I’m not sure which mental model will lead to something working.
It has definitely allowed me to do things in a code snippet that would otherwise have been a *spreadsheet* and that is a huge step up in reproducibility and ability to share. Especially when I have to do that formation a year later.
@xgranade @whitequark @dragoonaethis
Kristian 🌒
Als Antwort auf Dragoon Aethis • •@✧✦Catherine✦✧
CartyBoston
Als Antwort auf ✧✦Catherine✦✧ • • •Per Vognsen
Als Antwort auf ✧✦Catherine✦✧ • • •Josh Simmons
Als Antwort auf Per Vognsen • • •✧✦Catherine✦✧
Als Antwort auf Per Vognsen • • •Per Vognsen
Als Antwort auf ✧✦Catherine✦✧ • • •Bartosz Taudul
Als Antwort auf Per Vognsen • • •@pervognsen "What do you mean pids no longer overflow on 16 bit and my parser now fails???"
tbh, trying to parse whatever undocumented binary blob the kernel internals will throw at you at times is even worse.
Oblomov
Als Antwort auf Per Vognsen • • •skrzyp
Als Antwort auf ✧✦Catherine✦✧ • • •LibXo - FreeBSD Wiki
wiki.freebsd.orgFelix
Als Antwort auf ✧✦Catherine✦✧ • • •✧✦Catherine✦✧
Als Antwort auf Felix • • •Alien software, human hardware
Als Antwort auf ✧✦Catherine✦✧ • • •Also, text doesnt make sense everywhere, and in those cases structured data is already used to pipe between tools.
And besides that: single function tools are much much easier to check for correct function, easier to debug, easier to read the source of if necessary.
And also easier to replace.
Sun Microdevil Pte Ltd
Als Antwort auf Alien software, human hardware • • •@mavu
> well defined
In my (admittedly very limited) experience with trying to understand Linux's /proc and /sys vomit, this probs leans towards not true in practice
You change kernel version the contents (and output and format) changes
You change computers it changes too
etc.
Sure the human mind can probably cope with it just fine but trying to programmatically parse it is another matter
I genuinely feel all those "human readable text streams" discussion is just distraction; you could probably encode all those data in something like JSON or XML with a formal schema to it and it'd be much better while still being a "human readable text stream"
Would a binary encoding be better? Maybe! But at the moment just putting a structure in to that madness would be a welcome improvement already...
✧✦Catherine✦✧
Als Antwort auf Alien software, human hardware • • •@mavu I disagree that human readable text output, as seen in real-world *nix utilities, is structured data: anything that cannot wrap arbitrary possibly-untrusted text without the danger of mistaking it for framing does not deserve being called "structured". (I do admit that if we scrapped all of the garbage tools we're using and started from scratch, it would be possible to implement userspace tools that treat external data in a principled way. this is not going to happen.)
I do not agree with the "easier to replace" either. if it was true, you wouldn't have thousands-of-lines ./configure monstrosities checking if gawk is really gawk or not. there is no lower limit for complexity beyond which tools are "easy to replace" (while ensuring correctness of the replacement) in practice, and having a structured and interdependent suite of tools means that they have to be considered as a whole, and may be depended on as such.
I do not think that it is desirable to prioritize "ease of replacement" over things like "ease of ensuring the tools you're using work the way you think they should". if everyone keeps replacing the tools, it creates a nightmare situation for people trying to use the tools because you can hardly know what exactly the behavior of them is; a problem similar in shape to how the stable Linux ABI is Win32.
Alien software, human hardware
Als Antwort auf ✧✦Catherine✦✧ • • •That is a good point, i didn't consider "hostile" data that might intentionally mess with output parsing.
1/? (i wish mastodon had at least some basic formatting for it's mesages.)
maswan
Als Antwort auf ✧✦Catherine✦✧ • • •Structure data would have been great, but look how long it's taken us to get to the point where we have a data serialization language that is kinda okay to parse by humans and computers.
Something json-like in existence and known to Bell Labs in the late 60s and maybe things had looked very different?
But to get there, we've gone though xdr, corba, xml, etc, which fail so hard in usability.
Cassandra is only carbon now
Als Antwort auf ✧✦Catherine✦✧ • • •Internet Hedgehog 🦔
Als Antwort auf Cassandra is only carbon now • • •@xgranade
bash-in-yaml + python
write once, run nowhere
Cassandra is only carbon now
Als Antwort auf Internet Hedgehog 🦔 • • •LisPi
Als Antwort auf Cassandra is only carbon now • • •There are various structured shells that wrap a number of programs to emulate this.
The lack of any standard interop makes them much as silo'd projects duplicating work.
The closest to standard is arguably dbus but that has considerable issues of its own (and a lot more overhead than either COM or the Lisp Machine/managed code equivalent of composed function/program calls).
Miss Rari 🏳️⚧️
Als Antwort auf ✧✦Catherine✦✧ • • •David Chisnall (*Now with 50% more sarcasm!*)
Als Antwort auf ✧✦Catherine✦✧ • • •This is why CHERIoT RTOS copied VMS and MULTICS, not UNIX. We run on microcontrollers orders of magnitude more powerful than the minicomputers UNIX was scaled down to support, we don’t need to make those sacrifices (and, by designing the ISA to support these abstractions, we can make programmer-friendly abstractions more efficient than the UNIX model).
Ken Milmore
Als Antwort auf David Chisnall (*Now with 50% more sarcasm!*) • • •Was it Dave Cutler?
Charlotte
Als Antwort auf David Chisnall (*Now with 50% more sarcasm!*) • • •Sensitiver Inhalt
@david_chisnall Clearly all we need is to formalise COM object sharing at the OS level
*stares into the Windows OLE abyss*
rakoo
Als Antwort auf ✧✦Catherine✦✧ • • •JP
Als Antwort auf ✧✦Catherine✦✧ • • •A while back I stumbled on an interesting project by some people who were making significant headway in building structured-comms user space tooling for a linux world…..and then I lost the name
I recall I found it while exploring around the edges of helix, but haven’t been able to refind it as yet
hex
Als Antwort auf ✧✦Catherine✦✧ • • •✧✦Catherine✦✧
Als Antwort auf hex • • •Usagi
Als Antwort auf ✧✦Catherine✦✧ • • •Paco Hope
Als Antwort auf ✧✦Catherine✦✧ • • •uis
Als Antwort auf ✧✦Catherine✦✧ • • •Jeff Forcier
Als Antwort auf ✧✦Catherine✦✧ • • •The Xonsh Shell — Python-powered shell.
The xonsh shell✧✦Catherine✦✧
Als Antwort auf Jeff Forcier • • •Tito
Als Antwort auf ✧✦Catherine✦✧ • • •The growth of command line options, 1979-Present
danluu.comcaptain notgull
Als Antwort auf ✧✦Catherine✦✧ • • •"applications that communicate using structured data, simplifying life for both programmers and end users"
Good news! This is implemented in most modern Unices, and it's called D-Bus, and- *gets dragged off*
ティージェーグレェ
Als Antwort auf ✧✦Catherine✦✧ • • •Re: "design we could have had, but never will: applications that communicate using structured data, simplifying life for both programmers and end users"
Did you ever encounter Tool Types on Amiga Workbench?
I sorta felt as if they offered that kind of functionality?
IIRC, I remember using some terminal program (Terminus I think?) and dropping in a telnet Tool Type, and voilà, it suddenly evolved the ability to also handle telnet!
Maybe someone created an SSH Tool Type in the ensuing years and that old Terminus program would be improved via a Tool Type as well? I dunno.
DM2 (DiskMaster2, I guess source code archived here: github.com/RudolphRiedel/DiskM…) felt similarly extensible, with very little muss or fuss.
Windows' File Explorer can be customized, sorta (e.g. use XYZ program to open .TLA), and macOS has the whole "Open with" option, but to me at least, neither felt as seamless nor as powerful as the Amiga Workbench Tool Type paradigm.
I think maybe MIME types were trying to be something similar? I remember in early web browsers, having to add MIME type handlers manually in browsers (and OFC, on HTTPD server configurations too) but it always felt way clunkier (like just about everything on the web) and it's been years since I remember doing anything with MIME types in a browser. Alas, post browser wars, browser specific Plugins/Extensions seem to become "the thing" and are just worse and worse in contrast IMHO. MIME stuff got shoved into (some) MUA (Mail User Agents, aka email clients) too, but never felt as unified; much more haphazard and slapdash. Sort of devolved into the VSTs of some network oriented protocols, but with less snazzy results.
Amiga's Tool Types felt as if something similar to UNIX pipes had leveled up to the GUI era, but too many missed the message I guess? Or never got it. ;(
GitHub - RudolphRiedel/DiskMaster2
GitHub✧✦Catherine✦✧
Als Antwort auf ティージェーグレェ • • •ティージェーグレェ
Als Antwort auf ✧✦Catherine✦✧ • • •Totally understandable, Commodore declared bankruptcy in 1994.
If you ever cross paths with someone who was an Amiga user, back before the Commodore bankruptcy occurred? Chances are you're in the presence of some sort of wizard. That is not a hard and fast rule, I can think of at least one example of an Amiga user back in those days who was well, more or less reviled in the local 408 BBS scene for a number of what at the time, seemed like justifiable reasons.
It's not really easy to explain from a retro lens. I think 2017's Viva Amiga tried as a documentary effort; but I was already part of the choir, so preaching to me isn't a great way for me to know if it lands with others who never experienced the magic.
Where I was at the time (in Monterey County) the local Amiga users group was called: SMAUG (Salinas Monterey Amiga Users Group), there was just something different (in a good way) about Amiga savvy sorts.
✧✦Catherine✦✧
Als Antwort auf ティージェーグレェ • • •✧✦Catherine✦✧
Als Antwort auf ✧✦Catherine✦✧ • • •ティージェーグレェ
Als Antwort auf ✧✦Catherine✦✧ • • •UAE does a pretty respectable job of Amiga emulation for sure!
I've still managed to bring it (and the host system) to its knees with some demos; but the demo scene really came into its own on the Amiga, and subsequently Amiga "compos" (competitions) remain a vibrant section in most demo scene related events, decades after Commodore's demise.
More recently, there seem to be various "NO CPU" classes of Amiga oriented demos? ^_^
But the cat and mouse game of demo sceners and emulator authors is an ongoing one and doesn't require an Amiga. Trixster's "8088MPH: We Break All Your Emulators" being an example for early IBM PC hardware: trixter.oldskool.org/2015/04/0… (and eventually, that did give rise to someone writing an emulator to handle it, I guess!)
8088 MPH: We Break All Your Emulators
Trixter (Oldskooler Ramblings)ティージェーグレェ
Als Antwort auf ✧✦Catherine✦✧ • • •"i made the conclusion that it was probably expensive and well-designed but never looked further"
Amigas were unequivocally: Well-designed!
"expensive"? Kind of relative. I think for their era, they offered probably the best "bang for the buck" and were considerably more affordable than Apple Macintosh systems while being substantially more versatile. SGI (Silicon Graphics) workstations were a lot more expensive, but maybe offered some advantages for those who could afford them and were well versed in UNIX already.
I was in the middle of writing a much longer reply, but life and dinner and Friday night (deejay grandma is takin over for Jessu at the moment: twitch.tv/jessu) have been distractin me.
So, I tossed that here rather than waste ActivityPub bandwidth and storage (particularly since I don't run this snac instance):
reviktra.neocities.org/toolong…
Jessu - Twitch
Twitch✧✦Catherine✦✧
Als Antwort auf ティージェーグレェ • • •ティージェーグレェ
Als Antwort auf ✧✦Catherine✦✧ • • •I hope the "interesting" was with regards to Jessu (or "grandma") deejayin?
Me nerdin out on old computer stuff, hopefully is more histrionic and definitely less fun for a Friday night. ^_^
sarah tonin
Als Antwort auf ✧✦Catherine✦✧ • • •well at least some tools have json / xml output but urgh
if we're going json based then jq will be a necessity