On Fri, Mar 22, 2024 at 8:24 AM enh <e...@google.com> wrote: > > 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.)
(and to be clear, although "lsb" is particularly obscure, i think this is the same problem busybox's organization has: why do i have to care whether something is in coreutils or linux-utils or procps? how is that relevant to me? the best answer i can think of is "because i want to only use toybox/busybox to replace _that_ package", but i don't think the _directory structure_ helps there, right? that hypothetical person actually wants more metadata in the kconfig part of the comment inside each file?) > > 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
