<illiliti>
btw dilyn, isn't generic kernel a bad idea?
<dilynm>
Why?
<illiliti>
because generic kernel requires modules, no?
<illiliti>
people prefer monolithic kernel cuz it is simpler
<dilynm>
Well then they can make their own kernel
<dilynm>
:)
<illiliti>
then what's the point of generic kernel if everyone would use its own kernel
<dilynm>
Ah
<dilynm>
Mostly, convenience
<illiliti>
modules also require initramfs
<dilynm>
Certainly true, but a kernel doesn't necessarily
<dilynm>
For instance they could use a config that enables all of the things they need to be built-in
<illiliti>
then it is not generic kernel anymore
<illiliti>
generic kernel is a kernel that just work, right? if i need to make some changes to config, it is not generic
<illiliti>
also where the kernel will be installed? /boot?
<dilynm>
You just have a variable that allows adding a generic config that overrides default values
<dilynm>
And another variable for location
<dilynm>
Though by default, /boot. Because that's the sane place
rohan has quit [Ping timeout: 256 seconds]
<illiliti>
ok, /boot. but it won't be bootable by default, right?
<dilynm>
Wdym?
<dilynm>
They'd have to make their own boot entry for it
<dilynm>
Because of distro dumbness there is no good generic location, and some people are allergic to unlearning stupidness. For instance, I'd wager at least one person using KISS has a /boot AND a /esp
<midfavila>
impossible
<illiliti>
then again what's the point of it if user needs to do a lot of extra work to make it usable
<midfavila>
all KISS users are at least jimmy neutron level
<midfavila>
they would never do something like that dilyn
<dilynm>
I mean it would really be as easy as putting something like CONFIG_NVME=1\nCONFIG_EXT4=1 into some file, setting a variable to point at that file, running the build, and then them running whatever they would otherwise have to run
<dilynm>
Then they basically don't need initramfs
<dilynm>
Then they can add some post-install hook to generate that boot entry
<dilynm>
It's pretty easy, just nondeterministic. So the install guide just has to say "either use initrd OR do x,y,z for generic"
<illiliti>
i don't see much value in having abstraction(kiss package) here
<illiliti>
i can do the exact same thing without it and it will be a lot simpler
<illiliti>
because i control the entire process
<dilynm>
The same is true for llvm, mesa, GCC, chromium, ...
<dilynm>
It's not an abstraction so much as it is a generic package
<illiliti>
no it isn't
<illiliti>
it is not generic
<illiliti>
because it requires extra steps
<illiliti>
without these extra steps it will be useless
<illiliti>
the abstraction only complicates process
<illiliti>
with chromium, i can do kiss b && kiss i and get a working browser
<illiliti>
no extra steps, no complication
<illiliti>
with kernel, it is not that simple
<illiliti>
look at binary distros and see how they achieve this "genericness"
<dilynm>
What do you mean?
<dilynm>
Almost every distro has a sufficiently generic kernel to accommodate almost every system
<illiliti>
i mean they hardcode grub dependency, modules, firmware, initramfs to make kernel usable
<dilynm>
I mean hell I could devise a generic config that could work for 80% of systems
<illiliti>
generic config != generic package
<dilynm>
Literally not of that would be required. Install tinyramfs, run a command, run required command for your bootloader, done
<illiliti>
again
<illiliti>
if i need to do these extra steps, generic package is useless
<dilynm>
I... Disagree...
<illiliti>
ok
<dilynm>
The package is useless if you still have to do the work of building a kernel, which you don't. The package is doing its job
<dilynm>
I mean shit the install guide gives you the required bootloader command
<asdfhjkl>
support broad amounts of hardware for broad amounts of users
<asdfhjkl>
not everyone wants to jack off on the kernel
<asdfhjkl>
Have a nice day
<dilynm>
Lol
<dilynm>
Illiliti just doesn't think it's valuable if it requires manual intervention because packages shouldn't require manual intervention
<dilynm>
Which I think is true in general, but this is a special case I would argue
<midfavila>
asdfhjkl i can't see a generic kernel serving to increase kiss' userbase
<asdfhjkl>
I can see it, give me a minute to type it out
<asdfhjkl>
So I have developer friends, talented individuals for example, working real jobs... Typically they end up something like Arch or Debian, the install process is reasonably straight forward, no need to figure out all the hardware they're using and twiddle with an ncurses menu to install a kernel and all that bullshit, when they just need a terminal,
<asdfhjkl>
their editor of choice, a web browser, and whatever else.
<asdfhjkl>
One friend of mine in particular...
<asdfhjkl>
He's very interested in hacking on distros, or at least, being able to easily have the source code just readily available already on the system, to hack on it or just read it if he wants, and doing things like mesh nets, sneaker nets, not requiring internet all the time and massive gigabytes of upgrades
<asdfhjkl>
I think there's a lot of people out there like that, who could appreciate it, having the option of tweaking on things, but having some also easy way to just get in and get started in a short amount of time
<dilynm>
I mean either way this is getting packaged. It's going to be a dependency for snapd :v
<asdfhjkl>
portability, too, being able to just zap your files across systems is great
<midfavila>
i mean, if someone wants to put it together that's obviously their choice, but a) putting together a Linux is honestly trivial even for a first-timer, and b) if the prospective user in question just wants to "do real work" so to speak, they should just use debian or arch.
<dilynm>
I just want to use KISS again, which means I need lxd for work. And the easiest way to get it is snapd
<asdfhjkl>
Right on dilynm
<illiliti>
so you want to make kiss more casual and friendly
<asdfhjkl>
yeah, i'll call it kush or something
<asdfhjkl>
I want to make kiss, not be a pain in the ass by default
<asdfhjkl>
But at the same time, not make it too smart or assuming, or abstracted away, just, sane install by default, have a blank OS that is easily hackable if that's your thing, but if it's not your thing, you can still get work done right away
<illiliti>
not possible
<illiliti>
kiss is a gatekeeper. if you wanna be a part of it, you must pass the gate
Torr has joined #kisslinux
<phoebos>
I get the appeal of a generic kernel package, but I don't think it's suitable for repo
<phoebos>
perhaps that defeats your objective though
<phoebos>
but I can imagine the install guide saying "either configure your own kernel, or use a generic package such as x..."
<phoebos>
or even "look at this package for inspiration"
<asdfhjkl>
i imagine something like a arch and a manjaro. a kiss and a ? something that fills the gap there
<phoebos>
for me, the appeal of kiss is the ease of personalisation. more users for the sake of users isn't necessarily desirable
<asdfhjkl>
One big problem here is documentation, kiss documentation is sad right now, hard to contribute to it too since it's just dylans old website
<phoebos>
*achieving more users by reducing the need to do stuff yourself
<asdfhjkl>
Wild goose chase to find what you need, too. You almost have to know kiss already to use kiss now.
<midfavila>
i mean, do you?
<dilynm>
Feel free to debate the addition of a Linux package on the issue linked by the PR :)
<midfavila>
it's really not hard to use kiss
<dilynm>
^
<midfavila>
like
<midfavila>
i'm gonna spit a nuclear take here real quick right
<midfavila>
if the user can't figure out how to use kiss from the prompt it provides without options or with an invalid option, they shouldn't be using kiss
<midfavila>
because they clearly can't read
<phoebos>
centralisation of some info is definitely required, but i like the decentralised part of individual repos and ideas stemmed from the kiss base
<midfavila>
(sorry it actually doesn't provide a prompt with an invalid option)
<midfavila>
(at least my version doesn't)
<midfavila>
(maybe that could be improved)
<phoebos>
just run kiss with no args
<midfavila>
yeah ofc
<midfavila>
but running a command with -h isn't an unreasonable expectation
<midfavila>
assuming the user wants help
<phoebos>
maybe a manpage would be useful?
<midfavila>
either a manpage or -h/display of the menu on invalid param (or both) could be nice
<midfavila>
yeah
<phoebos>
lol
<phoebos>
thing is, a manpage would just be dumping that `kiss` output
<phoebos>
we _could_ write a void-style suite of manpages - kiss(1), kiss(5), kiss(7) etc
<phoebos>
but that would just be duplicating parts of dylan's wiki
<midfavila>
i was just thinking replacing the included kiss wiki with manpages
<midfavila>
the fact that kiss installs documentation in a weird way has always bugged me
<phoebos>
manpages can't replace the docs which aren't just about how kiss works
<midfavila>
uh, why not
<midfavila>
there's no reason you couldn't include a description of, say, the kiss package format under 7
<midfavila>
or whatever the administration section of the manual is
<phoebos>
yes
<phoebos>
but
<midfavila>
are you talking about "kiss" the distro or "kiss" the program?
<phoebos>
stuff like service-management.txt
<midfavila>
i'm only concerned with kiss the program
<phoebos>
4 messages ago, kiss the program
<midfavila>
when it comes to that stuff my take is that it shouldn't be part of the distro
<illiliti>
^
<phoebos>
why not? you need to know how to run services with the default service manager
<phoebos>
and busybox docs are
<midfavila>
the service manager the user installs will install relevant docs for service management, because that's its job. kiss manages packages, nothing else, and so extraneous documentation should be cut because it's irrelevant
<phoebos>
non-existent
<midfavila>
phoebos: assume the user is competent. busybox is just sysvinit
<midfavila>
anyway, you don't need services
<midfavila>
if the user knows enough about unix to want services, they probably also know enough to look at different service managers and to find their docs
<phoebos>
but how does a new user know that busybox implements something else, which is documented
<phoebos>
there needs to be documentation for the default setup
<phoebos>
or at least a pointer to documentation
<midfavila>
my response is to again assume the user is competent or that they know how to use a search engine
<phoebos>
kiss-defaults(7) maybe
<midfavila>
like
<midfavila>
if you know what busybox is it's not hard to logic out that it probably has a service manager, and that the default install of it probably installs services
<midfavila>
from there you look at those services and you just... figure shit out?
<phoebos>
"busybox service manager" doesn't bring up anything useful
<phoebos>
well sure, you can just "figure shit out" but that's relatively unfriendly
<midfavila>
KISS is by design unfriendly
<phoebos>
i disagree
<midfavila>
in the sense of not holding the user's hand, it's honestly somewhat user hostile
<midfavila>
there's nothing stopping you from replacing your libc and bricking your setup for example
<phoebos>
maybe we're talking about friendliness in different ways
<midfavila>
then again i suppose that's not terribly related to the issue of docs
<midfavila>
and yes, that's likely
<midfavila>
when i consider the friendliness of a program i consider it from the point of view of how much hand-holding it does
<phoebos>
without the service management docs, i wouldn't have known (or would have taken a lot longer to find out) how to use them, and probably would have given up
<midfavila>
there's a point where it's helpful, and there's a point where it's detrimental. most stuff falls in the detrimental category because it either asks you if you're sure about every little tiny operation, or it swamps you with docs, or some combination of the two
<phoebos>
kiss, today, is friendly in the sense of being encouraging and providing enough for it's weird configuration that you can go on and use it
<midfavila>
anyway does busybox even manage services in a traditional sense of the word?
<phoebos>
it's also friendly in being small and uncomplicated
<midfavila>
sysvinit doesn't strictly mean it manages services
<midfavila>
(i don't use busybox)
<phoebos>
what is your definition of traditional service management
<midfavila>
a "traditional" service manager in my mind is something like sysmgr
<midfavila>
it's a discrete binary that exists solely to spawn and monitor processes, and handle them failing in an intelligent way. ideally it would also provide a relatively convenient interface to starting, stopping, and checking them
<midfavila>
sysvinit "service management" is really just slang for "here's a pile of shell scripts"
<phoebos>
cem's sysmgr?
<midfavila>
nothing wrong with that, but sysvinit does not itself manage services
<midfavila>
yeah
<midfavila>
i use an old version of it on my desktop
<phoebos>
pretty sure it was inspired by runit etc
* midfavila
shrugs
<midfavila>
ultimately my point is that service management isn't part of the scope of sysvinit
<midfavila>
assuming busybox uses sysvinit, which i'm fairly certain it does, it follows that service management isn't part of busybox's scope, assuming my prior conjecture is correct
<midfavila>
which i'm *fairly* certain it is
<midfavila>
sysvinit just starts up and runs a set of scripts defined in inittab or w/e
<midfavila>
or maybe i'm totally talking out of my ass here. wouldn't be the first time. if so ignore me... or ignore me if i'm not, not like it matters
<phoebos>
whether or not busybox stays within its own scope is irrelevant to kiss
<midfavila>
the point isn't whether it stays within its scope
<midfavila>
anyway, ultimately, upstream can do whatever. i don't use it. i'll say that if docs are written they should be included as a package ala man-pages
<midfavila>
so that they can at least be removed trivially
<midfavila>
then everyone wins
<phoebos>
busybox provides a service manager without docs, which is used by default. the default installation should have docs, imo
<phoebos>
docs should be a separate package for kiss (the program) specifically or for everything?
<midfavila>
these kiss docs that aren't related to kiss the program
<midfavila>
the package "kiss" should install kiss the program and its manpages, but not man-pages-defaults or whatever you want to call these other docs
<phoebos>
but another package with KISS (distro defaults) docs is ok?
<midfavila>
i would say so
<midfavila>
it would also free it from the constraints of man
<phoebos>
anyway, docs can be removed with hooks. i don't think more docs is a problem, but the only reason kiss-distro docs come with the kiss-program package is to avoid an extra package, since one implies the other anyway
<phoebos>
man?
<midfavila>
the program and set of roff macros
<midfavila>
and no, using the package manager certainly does not imply using the broader distro
<phoebos>
yes :V there aren't kiss docs written in man
<midfavila>
yes i'm aware that there aren't any right now
<phoebos>
oh ok
<midfavila>
what i'm *saying* is that kiss the program should install the program and a set of manpages, and behave more in line with traditional unix tools
<phoebos>
using the kiss package in the kiss distro repo does imply using the broader distro
<midfavila>
no, it doesn't
<phoebos>
the distro essentially is the main repo
<midfavila>
upstream's docs would be worse than useless on my system because everything that isn't the package manager is different, and it's still technically "kiss"
<phoebos>
which contains the kiss package with extra docs
<phoebos>
but presumably you don't use the community repo package for kiss?
<phoebos>
kiss-community/repo, not repo-community
<midfavila>
no, i use an old version of the official one. but i still sometimes pull packages from community and etc
<midfavila>
at the end of the day it's possible to use kiss the program without using upstream's repos, whilst still "using kiss". including documentation with the package manager that assumes details about the rest of the OS is a bad idea because kiss-the-manager isn't kiss-the-os
<phoebos>
the package itself is distro-specific, even though the kiss script isn't
<phoebos>
> including documentation with the package manager
<phoebos>
no
<phoebos>
including documentation with the package of the package manager
<midfavila>
but that doesn't change my point whatsoever.
<phoebos>
i mean that you have your own distro in a sense, and you're complaining about a different distro including specific docs in one of their packages
<midfavila>
anyway, i don't have much sway with the community repos and this is really a matter of taste. plus, if it's a package thing, i guess it's trivial to change or add hooks, but that just seems inelegant to me.
<midfavila>
yes, packages that i use, and that other kiss forks use
<midfavila>
forks that have in some cases very little to do with upstream. and again, sure, it's a trivial change, but it's one that would be unnecessary if KISS distro docs were documented in a separate package
jslick has quit [Ping timeout: 260 seconds]
<phoebos>
a separate doc package is a good idea. i just don't think it's a valid complaint, since the default repos are *for* the default distro
<midfavila>
the default distro can be strayed from with a single command
<midfavila>
without actually straying from the default distro because that action is to be expected
<midfavila>
and now i have to maintain my own fork of kiss or my own hooks or w/e to eliminate superfluous and incorrect docs
<midfavila>
fork of the kiss package*
<phoebos>
well yeah, if you have a different distro
<phoebos>
anyway
<phoebos>
are you in favour or not of writing docs in man? can't tell when you said "free it from the constraints of man"
<midfavila>
docs for the package manager should be included with the package manager and should be written in man or mandoc
<midfavila>
docs for the system should be written in some other format and included under /usr/share/doc
<midfavila>
they're two separate things and should be treated as such
<phoebos>
agreed
<midfavila>
i think netbsd does this for example
<midfavila>
(or at least SDF's setup does)
Torr has quit [Read error: Connection reset by peer]
<wael[m]>
phoebos: whats a proper way to handle arguments in posix sh
<wael[m]>
im currently using eq $# but it doesnt work for empty arguments that are quoted
<wael[m]>
and if i unquote the argument handler, shellcheck will complain about SC2086
aelspire has joined #kisslinux
<aelspire>
Hi
<aelspire>
Sorry for joining so late - I have opinion on linux kernel. Make separate repo (in repo or completly separate) with generic kernel and include it to installation media so KISS could have real working Live CD. And instruct user: or to use this package and expect longer build times and make initramfs somehow atfer this, or fork this package run localyesconfig or localmodconfig on it to get trimmed
<aelspire>
With this solution things are not too automated, but starting/fallback kernel is available
<aelspire>
thx
<aelspire>
other cool idea: put examples from kisscommunity wiki kiss/style-guide in /usr/doc/kiss/templates in kiss package
<wael[m]>
^^ good idea
<wael[m]>
always needed this stuff
<wael[m]>
actually open a proposal instead
<wael[m]>
it can be really useful for templates such as Meson or CMake or makefile or configure projets
<aelspire>
I've copied examples from kisscommunity wiki so much times that I wouldn't be surprised if I'm responsible for significiant percentage of bandwidth usage
<aelspire>
ok, one moment I need more coffee to my text to be coherent