On Thu, Mar 21, 2024 at 8:45 PM Rob Landley <r...@landley.net> wrote: > > On 3/17/24 14:52, Oliver Webb wrote: > > On Thursday, March 14th, 2024 at 12:04, enh <e...@google.com> wrote: > >> at a high level, it does seem like many/most people interpret "pending" as > >> "almost done" (he says, being part of the problem himself, having several > >> pending things building and shipping on all Android devices) whereas in > >> actual fact it can mean anything from "yeah, actually pretty much done" to > >> "will be completely rewritten" via "still just trying random experiments > >> trying to work out _how_ this should be rewritten". > >> sadly i don't have a better suggestion... > > > > pending/experimental and pending/functional maybe, or something along that > > gist? > > That would be my "not adding more complexity to manage transient clutter that > should instead go away" objection, already made. > > > Then again it'd make it harder to track the history of pending commands, > > adding only new ones > > to those 2 directories would fix that, but would make the organizational > > problem for the old > > ones worse. > > https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering > > Stop. No. Halt. Wait. Hold it. Woah. Cease. Desist. Caution severe tire > damage. > Klatu barata nikto. Subcalifragilisticexpialidocious. > > >> a branch would be the usual git option, but that would probably mean "no > >> pending stuff in the main branch" > > > > Also a problem if you want to switch Version Control systems or distribute > > tarballs without a .git/ directory. > > I already DID switch version control systems (from mercurial to git), and I > already distribute release tarballs. Why do you think these are new issues? > > > It'd hide these commands too, > > I want to close tabs. I am not creating additional scaffolding for clutter > management: > > $ ls -d */toys > clean3/toys clean8/toys github/toys kl4/toys kl9/toys toybox/toys > clean5/toys clean.old/toys kl10/toys kl6/toys kleen/toys > clean6/toys clean/toys kl2/toys kl7/toys kl/toys > clean7/toys debian/toys kl3/toys kl8/toys release/toys > > I already try not to publish quite as much clutter as accumulates locally. > > There's some real fossils checked into the tree. I started work on gene2fs > back > under busybox, checked in what I had to the toybox repo in 055cfcbe5b05 in > 2007 > and haven't LOOKED at it this decade because I just haven't gotten back around > to it. Since then they INVENTED EXT4. (I still hope to get back to it, but at > the moment I'm answering email.) > > > For the first time I checked if there were any special branches in the repo > > because > > I didn't bother to think about that in the months I spent working on it. > > > >> i still struggle between "other" and "lsb" in particular. > > > > Same here, I can remember the posix commands. > > Can you? I still have to check some from time to time, and the definition of > whether "tar" is a posix command or not is outright eldrich bordering on > quantum. > > > But I don't care about LSB enough to > > memorize everything in wants. And keeping all completed commands that > > aren't in poisx, > > lsb, networking or android > > The "example" directory is important because it's the only other directory of > commands that should not "default y" in defconfig. It has a policy > distinction. > > Back in 2012, when the number of commands was growing fast and having one big > directory of them all was getting a bit busy, the alternative of sorting them > into directories was annotating them with tags, and THAT was a nightmare (of > the > "this command has three tags" variety). And also implied future pressure to > extend the existing kconfig implementation to USE the tags, which would be > worse. > > Moving them into subdirectories, with each command in ONE directory, and a > README explaining what the directory was for, with kconfig automatically > displaying them in menus and using the first line of the README as the menu's > title, seemed the least bad crowd control option at the time. > > > in a massive "other" folder sorta defeats > > the purpose of these directories which are supposed to reduce clutter. > > It wasn't really about reducing clutter. I mean yeas, back then some web > viewers > wouldn't display more than 250 files in a directory, the way github truncates > at > 1000 today: > > https://github.com/landley/linux/tree/master/arch/arm/boot/dts > > But the goal was annotating command categories. Posix and pending are obvious, > and I mentioned example. Back when I split them up, LSB was still a viable > standard (the Linux Foundation hadn't destroyed it yet), and it STILL kind of > means "this command existed back in Y2K and was considered part of the base > system back then, even if posix never caught up". Several commands in pending > get promoted into LSB (such as most of the password stuff, although oddly > mkpasswd is NOT in lsb 4.1). > > Hmmm, possibly instead of a dead standard the linux foundation killed, I > should > instead check the $PATH of my old red hat 9 install from the dawn of time...
the BSDs have already done that experiment for us (with bin, sbin, usr.bin, and usr.sbin [and contrib!] directories), and it's also a PITA. "if the new organization _still_ means i need to use find(1) for a command that's default 'y', we haven't made things any better" :-) > Hah, it's still on busybox's website: > https://busybox.net/downloads/qemu/rh-9-shrike.img.bz2 Login as user busybox > password busybox, I believe the root password is also busybox. But that's > post-1.0, I'm not changing horses midstream... > > Anyway, toys/android basically meant (to me), "commands that come from and are > maintained by Elliott which I can't even test because they don't apply to a > vanilla linux system that isn't running the full android environment". > Although > that's a personally idiosyncratic definition because I lumped selinux in with > that; (heh. you beat me to it :-) ) > the only other environment I've noticed having a big selinux rule stack is > Red Hat. I haven't noticed a lot of selinux in debian, arch, gentoo, alpine, > buildroot... Even SuSE used apparmor instead, although they switched to > selinux > recently because their business model is to be the Diet Red Hat so vendors > have > a second source to solicit enterprise bids from, so there's business logic to > minimizing the delta between them regardless of technical merit (and spending > less maintaining parallel infrastructure just to sign things in triplicate). > > I admit "toys/net" is a distinction that hasn't really worked out: I didn't > even > put nbd_client.c and nbd_server.c in there. I could move all that into other I > suppose, if one less directory was worth making git log history less > obvious... > > And then everything that ISN'T in one of those groups needed a place to go, > hence "other". It's not ideal, but it was motivated by the number commands > continuing to increase and One Big Directory getting a bit busy, and needing a > place for "pending". (tbh, just merging "lsb" into "other" would be a step forwards. wtf is/was "lsb" anyway? and while i can _usually_ guess "POSIX or not?" correctly, "lsb or other" is impossible by virtue of being meaningless.) > It's been the status quo for a dozen years now (commit 3a9241add947 in 2012) > and > moving everything AGAIN would have costs, so I'd want a reason and assurance > that we're not going to change our minds again. for me the holy grail is "tab complete works and i don't have to think about arbitrary partitions". i think "not yet default 'y'" is pretty defensible (though the reason we're having this discussion is because people _don't_ read "pending" as "danger, keep out!"), but the rest seem so arbitrary. > Collapsing the directories > together when the last command is promoted (or deleted) out of pending might > make sense, figuring out what to do about example/ (trusting to the demo_ > prefix > to annotate the example commands is nice, but hello.c hostid.c logpath.c and > skeleton.c would need... something). no, i think example/ is defensible too. (i'd argue you're only ever going to look in there if you have a _reason_ to. or you've done a `grep -r` for something you're changing/checking all references to. the reason i completely forgot about example/ is that it never causes me the "where the fuck is _mount_?!" annoyance :-) ) > I also note I think I've figured out how to replace kconfig: I can just make a > list that scrolls up and down with a highlighted entry you hit space on, > handle > help text, search, exit/save, resolve selects and depends and have "menus" be > a > label line with its contents nested two spaces further to the right. > > That's because I don't actually care about visibility the way they do (maybe > grey entries out but it just doesn't come up much), and my list doesn't nest > as > deep as theirs so spacing off the right edge is less of a bother, and I don't > support modules... > > But I need to close tabs to get there, and people keep sending me interrupts > to > focus on instead. > > >> `vi toys/foo.c` would save me a lot of thinking/calls to find. > > > > Eh, keeping all the commands in a massive toys/ directory makes it harder > > to tell what we have. > > > > A possible solution is to... > ... > > Then again... > > I need to stop checking email every time I sit down at my laptop, because > bikeshedding can eat an endless amount of time and I've got other stuff to do. > > For one thing, I promised to look at > https://github.com/landley/toybox/issues/486 tonight. (I did the code change > right after reading the commit, it's fluffing out the test suite to make sure > I > know what it should be doing and that it's getting it right that's the > headache; > "install -dm +x blah" applies the +x to 000 for some reason, and "umask 0; > install -d x" still does 755 so the behavior is NOT 777 minus umask...) > > > In any event, a complete reorganization of the commands would make the > > history of them a lot > > harder to keep track of. > > I believe I've said that every time this topic comes up. > > Right, enough meetings about the lack of progress... > > Rob > > P.S. I never mind people asking "what's the status of" or "why didn't you", > and > when people say they don't personally like stuff they can never actually be > WRONG about that. But suggesting what I "should" do is... tiring. _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
