Maintaining a separate arch build

[AnarchistHoneybun]

Hello, since additional system support is listed as a long term todo, I was wondering if I could maintain a separate version of this specifically for arch systems myself?
I haven't worked out the specifics but I'll make the proper attributions and stuff. Let me know @neilpanchal

[neilpanchal]

We're still cooking up a good direction for this project.

The ideas:

1. Build up current implementation. Bash/exposed source code (as opposed to compiled binary or other unapproacheable lang) is a huge plus. Most people know bash and as much as it pains to write in bash, it is universally present, ubiquitous, and has wide adoption + backwards compatibility. It's stable. So, from a pragmatic perspective—this project has a compelling framework.

   A. Expand the scope, go full out and support many systems. This will get complex very quickly. It'll get to a point where users who download the script will be intimidated and the whole thing become unmanageable in terms of maintanability (from the user's perspective). Imagine if v1.1 releases, how does one upgrade the script that they've heavily modified? So that's the problem.

   B. Limit the scope to very few critical things. Perhaps, keep what we have and stop adding new features. Only expand the compatibility layer. Meaning—maximally compatible with any system / configuration we throw at it. It'll still get complex but we can try be clever about it.

   C. Modular approach: base | os_customization | renderer as @weebney is advocating. More discussion here and there is already a PR: Feature: variable width output #2

   D. Extreme modular approach: header | eth0 | eth1 | lan | wan | gpu1 | gpu2 | cpu | ram | last_login | uptime | footer | renderer.

2. Use existing base such as fastfetch and build a theme for it.

3. Keep as is, develop a base.sh and that's all. No expansion of the scope or os support. Keep a collection of various systems, os's, etc and link them out from this repo. Kind of a rag tag alliance of bash scripts scattered all over. And it becomes kind of a low-key scrappy DIY project for every user involved :)

1D would be really cool if we can pull it off.

Open for thoughts!

[AnarchistHoneybun]

What I think:

• 1D obviously provides the best use experience, but also definitely has potential to get worse real quick for people trying to modify things and play around with it for themselves. If the project goes that way it'll be great to have something like a config system that touches all these files allowing users to make low to mid tier modifications themselves at one place
• 2 is a bit eh since a lot of systems are doing that. Would definitely be faster/easier to dev but loses a bit of the novelty I think?
• not much to say for 3, if enough people add on to it it's easily the best since there wouldn't be much code that a user on a particular platform would have to edit to modify for their needs.
  (ESL so apologies if some sentences feel awkward in structure)

[k-lar]

I don't think it's necessary to maintain any forks for specific distros, at least not one like arch. My fork for example should be able to run on basically any distro right now with the reduced dependencies and with my use of strictly POSIX tools for the most part.

For the direction:
I think any modular approach would turn off most users, it would add steps to the install process and it would ruin the simplicity of just being able to curl the script to a system and begin tinkering with it.

The best approach in my opinion would be 1B -> 1A. First we should limit the scope to what we have currently, expand the compatibility to at least MacOS. Given enough time I could probably convert the entire thing to POSIX shell but maybe that would turn some people off as it's harder to write than bash. Although it would guarantee maximum compatibility with all Linux, *BSD and Mac systems.

After we are compatible with all above systems, we can start adding more substantial features. Don't think we should worry about tinkerers downloading the newer versions of the scripts, since they probably know how to copy-paste their modifications to the newer version since the script is not really that big or complicated. Even if the script is larger, I believe it will still be pretty hackable since all we're really doing is 3 things throughout the whole script:

1. Checking if we can fetch data
2. Fetching/Formatting data
3. Printing data

When we add variable width, the most unappealing thing will definitely be the printing function but in general the users/tinkerers don't have to touch the print function. All they would have to know is that it takes a variable and prints it no mater what the width of the data is (to a certain max probably). E.g. print_data "$cpu_model"

For the fastfetch, I agree with @AnarchistHoneybun that it would lose it's charm if it was just a template. But I am not apposed to it if someone were to make it, we could even point to it in the README or bundle it with the project, as it would be a pretty small file.

[cowtoolz]

I'm inclined to agree with pretty much everything here.

Targeting POSIX shell should be pretty easy, and I'd be more than happy to get that done if that's a box we're interested in checking (though I'm not sure if that's really too important; targeting POSIX shell has been pointless for a while now as most shells aren't even POSIX compliant). Targeting POSIX utils would be good though as there's a lot more give between GNU/BSD/BusyBox/POSIX/etc implementations of core utilities, though that seems like something we're unlikely to encounter with something this simple.

On variable width, #13 implements this. You can check out the solution I came up with by poking around in my fork.

[neilpanchal]

I am down with fixing the width to something sensible. Users can change it ofc, but then we don't guarantee issues.

Any further thoughts here, @weebney

[AnarchistHoneybun]

fwiw, I think @weebney could decouple their pr to separate the variable width and script splitting parts, since one of them(width) is clearly a smaller scale change than the other and I don't think it's really decided on how much modularity the project wants/if it even does

[cowtoolz]

The scope of changeset #3 grew pretty quickly; I would be more than happy to roll #3 back to its earlier incarnation that just introduces automatic variable width and hashing out the other architectural stuff later (I planned to split the PRs anyway for sanity's sake).

We can work out the details of how the project should grow at a later date, but I see dynamic sizing is as basic missing functionality that should be merged ASAP. It adds very little complexity at a major benefit to the end-user.

[cowtoolz]

I'm on vacation right now ('til July), but I do have quite a few ideas of how we could approach this; I'm not sure I would say I'm even "advocating" for the changes in my fork, but just thought it would be an interesting thing to explore and mocked it up for myself.

What I will say is that, like any endeavor in engineering, the stewards of this project need to really determine the function of the project. It's pretty much pointless to pick a solution without setting some realistic goals (and asking the questions that lead us there) for the project. Is this a beautiful fetch script? Is this a learning tool for those interested in learning how to write and modify shell scripts—and what level of programming skill are we assuming these people possess? Does this project target a single system internally or does it target a greater universe like POSIX? There are a million more questions, but the most important ones—including a few asked here—must be answered to the best of our ability and prioritized accordingly for us to find the ideal solution. After all, how can any solution accomplish its goals if its goals are poorly defined?

Just something to snack on; I understand this project is exceptionally simple in nature but the nature of engineering demands that simple things be considered in detail. I'll be back and ready to build come the end of the month. In the meantime don't hesitate to reach out to me about this—an open offer to all y'all. [email protected]

[neilpanchal]

Fair critique, I did lay down some rough outlines of the philosophy here: https://github.com/usgraphics/TR-100/blob/master/README.md

[neilpanchal]

I outlined some more thoughts here:

#16 (comment)

[AnarchistHoneybun]

On #16

• we can close the related issue [ Feature: variable width output #2 ] if you think this implementation of variable width works well. I was thinking the display is abstracted a bit too much (enough to pull that part out to a seperate module, so people who aren't concerned with data retrieval can customise how it appears on their screen) but I don't have very strong feelings on that one so yeah
• "Even just a loop for DNS IPs has made the renderer slightly rigid on current master. It assumes that DNS IPs are new rows" could you explain this; is there a scenario where we display multiple ip's in a row(wrap them around or just ... on overflow) or is it about the numbers displayed for the addresses

[neilpanchal]

Ah, what I meant is something very theoretical. Perhaps a comma separted list of DNS IPs? 1.1.1.1, 1.0.0.1 instead of two rows. Your comment made me write a short essay on this topic of 'abstractions' haha. It is posted here.

[AnarchistHoneybun]

I see. I was thinking that since the DNS ip's are almost always long(er), having more than one would require us to extend the width of the table. Both scenarios, stacking multiple addresses side by side or wrapping them(possibly splitting an address during display), don't sound very visually appealing. Burn that bridge when we get to it though ig.

I'll check out the blog!

[neilpanchal]

Yeah, totally agree with you. So, we'll just go with our opinionated design. I like automation done by @k-lar, it is merged.