<sad_plan>
or do as I did, create a separate one for tinyx
<wael[m]>
> Get the font in .bdf format.
<wael[m]>
Im sorry what
<sad_plan>
midfavila: I would rewrite the make stuff. which
<wael[m]>
can tinyx not do ttf fonts at all?
<midfavila>
tinyx can do ttf
<midfavila>
just not directly like X can
<sad_plan>
wael[m]: nevermind that, just build the package from there, and run the sed on sx. once you ran the sed, you wont be able to launch X anymore, as youve modified sx. hence why I made a separate script for it
<midfavila>
it's passed to your applications to handle, which they usually do anyway
<sad_plan>
tinyx does ttf yes
<midfavila>
although your font scaling is gonna be wonky
<sad_plan>
curl -F'file=@/bin/sxfb' 0x0.st
<sad_plan>
ffff
<wael[m]>
simply launching the modified sx still wont work kinda
<wael[m]>
i should probably nvidia-drm modeset=1 then
<midfavila>
anyway sad_plan what were you saying about the make stuff?
<midfavila>
is it really as simple as that?
<wael[m]>
............it works
<sad_plan>
the makefile is a disaster. its one makefile which runs multiple makefiles. not to even mention the use of autotools
<midfavila>
unfortunately that kind of stuff is standard
<midfavila>
:X
<sad_plan>
wael[m]: great, now go run all your favorite tools, and be amazed that they just still works :p
<sad_plan>
I knooow. and its still horribe. I hate it
<wael[m]>
well dwm doesnt launhc
<sad_plan>
strange
<midfavila>
it'll be interesting to see if tinyx can be compiled with tcc
<midfavila>
i've spent the past few hours working on my fork's next release
<midfavila>
most of core can self-host and there's five or six dozen packages that are confirmed working, with more otw
<midfavila>
need to replace alsa-* with tinyalsa, and if X.Org can be replaced with TinyX, well...
<midfavila>
that's an entire system sans GCC
<wael[m]>
is it possible to log tinyx? the errors/logs dont tell me anything at all, i cant launch dwm or terminals using the default keybinds, as i tried tinyx before and it WILL NOT accept modkey (super key)
<midfavila>
fek
<midfavila>
looks like X11 is held back by the same stuff the rest of the distribution is
<midfavila>
lack of perl support
fitrh has quit [Quit: fitrh]
<midfavila>
once perl and by extension autotools and libtool are up, things will become a lot nicer
<sad_plan>
wael[m]: if you have super key binded, those wont work. just fyi.
<sad_plan>
but no, theres not much logs afaik
<sad_plan>
try a different wm perhaps
<midfavila>
anyway i'm going to head off for the night
<midfavila>
if any of you guys are willing, i'd appreciate someone taking a peek at building perl with tcc
<sad_plan>
midfavila: what about sndio aswell with tinyalsa? its what I use
<midfavila>
i'll have to look at it
<midfavila>
sndio is what obsd uses right?
<wael[m]>
sad_plan: wtf why cant i use super key
<sad_plan>
no alsa-lib/alsa-util at all
<midfavila>
wael[m] tinyx reads directly from the kernel
<sad_plan>
unfortunatly no, tinyx doesnt seem to recognize it
<midfavila>
it doesn't have input abstractions
<wael[m]>
also with ffmpeg, x11grab lags the shit out of tinyx
<midfavila>
that's why tinyx doesn't need drivers
<midfavila>
and yeah, uh, of course it does
<wael[m]>
how come
<midfavila>
it's not really accelerated
<midfavila>
at least afaik
<midfavila>
but someone please correct me if i'm wrong
<sad_plan>
theres no hardware accelerateration afaik anyway
<wael[m]>
ok maybe i should stick with X
<midfavila>
tl;dr tinyx trades performance for compatibility
<midfavila>
and yes, you should, if you want lots of extra features and decent performance
<sad_plan>
^
<midfavila>
tinyx excels only in portability, memory and disk usage
<wael[m]>
what about Xenocara then
<midfavila>
good luck porting it
<midfavila>
but also it's just hardened x.org
<wael[m]>
nvm
<midfavila>
:p
<midfavila>
anyway i need to get to bed for real now
<midfavila>
remind me about sndio next time you see me, sad_plan
<midfavila>
i'll definitely look into it
<wael[m]>
what about OSS4 tho?
<sad_plan>
midfavila: will do
<sad_plan>
noocsharp: seeing as you stopped using kiss. what did you end up with instead? oasis? and why?
<sad_plan>
does anyone knows why exacly toybox complains about line 4 on inittab? Ive been trying to get toybox's init to work, buuut nope
<sad_plan>
line 4 is the respawn runsvdir command, starting runit. respawn is a supported command on init afaik, so I dont get it
<wael[m]>
the respawn:runsvdir ?
<sad_plan>
yepp
<wael[m]>
if runsvdir just launches services in /var/service, why not just add the services to inittab lol
<sad_plan>
if the respawn command is the issue, the tty probably wont start either.. ill have to doublecheck. I might have to create a bootscript for both, like we used to on sinit etc :p
sad_plan has quit [Quit: brb]
<virutalmachineus>
does toybox better?
<wael[m]>
yes
<virutalmachineus>
* is toybox better?
<virutalmachineus>
weal do you use wayland or xorg?
<wael[m]>
i dont believe weal is here
<virutalmachineus>
wael?
<wael[m]>
yes what about him
sad_plan has joined #kisslinux
<sad_plan>
nope. complained about not being able to run /lib/rc.boot instead
<sad_plan>
hm
<wael[m]>
aw
<sad_plan>
virutalmachineus: toybox is smaller in any case, but less complete
<sad_plan>
so wether its *better* is probably subjectiv..
<wael[m]>
wait toybox comes with no shell right
<sad_plan>
currently no. but toysh is planned
<sad_plan>
there is some code on toysh, but it doesnt work
<wael[m]>
so if im gonna switch to toybox id have to package busybox ash on its own them hm
<testuser[m]12>
use yash or ksh
<sad_plan>
no, you could just use dash, bash, zsh, oksh yash, mksh etc...
<sad_plan>
lots of shells to choose from
<sad_plan>
not all work as expected with kiss though.
<wael[m]>
i used to use yash/mksh/oksh before i switched to kiss but i just used the default shell (ash) and ive been quite happy with it
<sad_plan>
I belive i.e. mksh has some globbing issue with kiss. Ive never tried it with kiss though..
<wael[m]>
the tab completion sucks tho so yeah i should probably switch to a better shell
<sad_plan>
ash is fine I suppose, but I currently use oksh instead. vi feature is pretty neat. I used to use zsh, but I find it to be a tad bit big..
cennedy has joined #kisslinux
<wael[m]>
inb4 yash isnt in community repo
<sad_plan>
zsh has really nice completetion, but is waaay bigger..
<wael[m]>
zsh is just too big for me i dont ever want to use it
<cennedy>
hi Im new here rn I'm installing kiss on my machine and I got error when compiling kernel
<sad_plan>
iirc carbs has yash packaged. in any case, yash isnt hard to package anyway
<wael[m]>
whats the error?
<wael[m]>
sad_plan: i think i will have to use yash, i really like the way i can select with tab complete rather than to have to type the name manually
<cennedy>
Warning: Kernel ABI header at tools/arch/x86/lib/insn.c differs from latest version at arch/x86/lib/insn.c
<cennedy>
Warning: Kernel ABI header at tools/arch/x86/lib/inat.c differs from latest version at arch/x86/lib/inat.c
<phoebos>
that's a warning, not an error
<wael[m]>
thats normal
<sad_plan>
wael[m]: you do that. yash is a great option anyway
<cennedy>
But it's canceling
<phoebos>
post the full log
<phoebos>
on a pastebin
<wael[m]>
or pipe it to nc termbin.com 9999
<cennedy>
How I can paste it
<cennedy>
It's on my pc
<cennedy>
Which kernel version should I use
<cennedy>
For best experience
<phoebos>
make >log 2>&1; nc termbin 9999 <log
<phoebos>
whichever you want
cennedy has quit [Ping timeout: 252 seconds]
<wael[m]>
sad_plan: holy shit i love yash
<wael[m]>
bit sad i cant do tab select with oksh/mksh tho
<sad_plan>
great
<sad_plan>
there is a way to do it iirc. but Im not sure how. im sure you can script it or something instead
<wael[m]>
i did try to incoprerate commands inside keybindings but i could never get that to ever work
<sad_plan>
hm
<wael[m]>
last time i used mksh it was so painful to do commands inside keybindings
<sad_plan>
Ive never really done that too much, except in zsh, but its way different. lots of docs available, so its mostly just copy/paste at that point..
<midfavila>
you'll want to enter rc after chroot'ing
<midfavila>
the standard shell is dash without readline
<midfavila>
userland is suckless with minor supplements, KISS_DL should be set to axel
<midfavila>
uhhhh
<midfavila>
only other thing of note is that the standard editor is se
<midfavila>
but you should be able to compile mg or something if you'd rather
<testuser[m]12>
sad_plan: name/email
<midfavila>
>forward slash as separator
<midfavila>
how un-unix
<midfavila>
we use colons in this chat
<sad_plan>
nice. ill check it out once I get back on my laptop
<midfavila>
kk
<midfavila>
it's kind of shit because i haven't shown it to anyone else
<midfavila>
so pls be gentle
<midfavila>
uwu
<midfavila>
but yeah rn there's maybe ~150 packages that work oob
<sad_plan>
no worries C:
<sad_plan>
thats a higher number than expected tbh
<midfavila>
tcc is shockingly capable
<midfavila>
i'm gonna spend some time today going through and sorting the rest of my repo
<midfavila>
i figure most of it will work just fine, considering it's basically just C
<midfavila>
maybe a few perl programs here and there that'll require a binary from my host machine
<phoebos>
why not name <email>
<midfavila>
not as easy to parse
<midfavila>
names might include spaces
<midfavila>
name:email is better afaic
<sad_plan>
sounds great. are you using any patches for using s/ubase with linux btw? or does it work out of the box?
<midfavila>
works oob
<midfavila>
i've dailied the suckless utils basically since day one on kiss
<midfavila>
with a few exceptions (which I've already dealt with) you can even compile a kernel with 'em
<sad_plan>
yeah, ive tried them couple times, but had some issues, so always reverted back to busybox really..
<midfavila>
rip
<sad_plan>
yup
<midfavila>
i've only had a handful of issues, and it usually comes down to either a)
<midfavila>
someone's port isn't written properly
<midfavila>
or b)
<midfavila>
someone's build system uses non-POSIX stuff
<sad_plan>
kinda wanna redo my setup from scratch again, with the tools I wanna use, and just work my way up from there, and fix stuff along the way. not the other way around.
<midfavila>
i've run into so many buildfiles that place parameters *after* filenames, it's hilarious
<midfavila>
and yeah, go for it
<sad_plan>
ill lay a plan this weekend perhaps, and start monday or something. i really wanna do toybox, because its more ních, but s/ubase is way smaller, which is also appesling to me :c
* midfavila
nod-nods
<sad_plan>
s/appesling/appealing/
<sad_plan>
I also just dont wanna deal with pesky shared libs, but we all know that aint happening any time soon :')
<midfavila>
i mean, i've gotten pretty close to a completely static userland and dev toolchain
<midfavila>
only persistent problem is what i mentioned the other day, with some symbols from stdlib being undefined during static links
<sad_plan>
yeah, ive previously created a fully static system, but the lack of usable browser is for the most part whats bothering me the most. perhaps just use a chroot for that, but that would be cheating :c
<midfavila>
if you include links under the set of usable browsers, you can statically link it
<wael[m]>
what is it with people and having a thing for static linking
<sad_plan>
i know. but i cant seem to get the graphical part to work. for whatever reason..
<midfavila>
makes portability a non-issue, wael[m]
<sad_plan>
because static linking is based
<midfavila>
can also increase system reliability
<midfavila>
so like, as an example,
<midfavila>
if I delete the C runtime from my distro, basically everything still works fine
<midfavila>
because they each include the necessary components of the C runtime to do their job
<midfavila>
even the compiler and such works without the C runtime