ChanServ changed the topic of #kisslinux to: Unnofficial KISS Linux community channel | https://kisscommunity.bvnf.space | post logs or else | song of the day https://vid.puffyan.us/H7PvgY65OxA
soliwilos has quit [Remote host closed the connection]
soliwilos has joined #kisslinux
Torr has joined #kisslinux
Torr has quit [Quit: leaving]
<testuser[m]> Hi
<wael_> Hi
geekthattweaks has joined #kisslinux
<niceguy5000[m]> Openbsd kiss when? never?
<wael_> Deprecated
<wael_> i'm pretty sure it was done once but now is unmaintained
<niceguy5000[m]> where is the source code?
<wael_> no clue
<wael_> some other guys are making a freebsd kiss tho
<niceguy5000[m]> freebsd is the same as linux it's bloated
<wael_> lol
<wael_> tell that to the guys who are making kissbsd
teddydd has quit [Ping timeout: 260 seconds]
teddydd has joined #kisslinux
soliwilos has quit [Remote host closed the connection]
soliwilos has joined #kisslinux
floorcrawler has joined #kisslinux
phinxy has quit [Ping timeout: 252 seconds]
geekthattweaks has quit [Quit: Connection closed for inactivity]
soliwilos has quit [Ping timeout: 255 seconds]
soliwilos has joined #kisslinux
Torr has joined #kisslinux
<Ellowee[m]> <wael_> "some other guys are making a..." <- Where?
<wael_> phoebos: is there a cleaner way of silencing a command instead of using something like >/dev/null 2>&1 or i dont have a choice?
<wael_> oh yeah is there a 'pgrep' alternative for POSIX? i don't see it in sbase or ubase
<wael_> i guess maybe ps?
<wael_> piped to grep
<Torr> So Pgrep is its own binary, eh.
<wael_> watr
<wael_> twa
aelspire has joined #kisslinux
<aelspire> Hi
<wael_> oih my gos its awelk spirte
<Torr> aelspire: Hey
<aelspire> anyone has thoughts on what is happening with GTK4?
<aelspire> I immediately noticed this "bug"
<aelspire> and there is problem with another one breakage of themes it seems?
<aelspire> when libadwaita will land there will be probably even more split betwee GNOME and rest of GTK users
<aelspire> so I anticipate 4 versions of GTK in the wild: GTK2, GTK3, GTK4+libadawita and GTK4 without libadawita
<aelspire> fun times are comming
<wael_> ERROR 'gtk4' not found
<aelspire> it isn't available on KISS
<aelspire> but I got it on Arch
<wael_> What;;;;;;;;;;;;;;;;;;;
<aelspire> I've installed some app on Arch linux (on work PC) and gtk4 app looks bad
<aelspire> bad font rendering mainly
<aelspire> so I'm thinking what will happen when this version will become main one
<aelspire> once again there will be terrible font rendering on linux
<wael_> font rendering on kiss is just good by default
<aelspire> today fonts on Linux look good but latest changes in pango seems to cause blurry font rendering
<aelspire> I've found venom linux when looking for distro for me but KISS looked better so I didn't check venom
<aelspire> "written in bash" - doesn't look very promising…
<wael_> bruh i didn't read that and the shebangs are #!/bin/sh
<wael_> fucking bullshit
<aelspire> but I've checked scripts and I don't see any bashisms
<wael_> yeah idk about that honestly
<aelspire> I didn't checked much but venom has a lot of packages and not much of contributors/developers
<aelspire> the same problem as with Void linux
<wael_> atleast it doesnt have many users
<wael_> which means the contributors/developers count doesnt conflict with the amount of users
<aelspire> the rest looks fine
<aelspire> why number of users matters?
<aelspire> quick calculation if distro have chance to maintain itself is number_of_packages/active_contributors
<aelspire> IMHO
<wael_> X.org is dying................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<aelspire> it is dying since 2008 its nothing new
<wael_> nooooooooooooooooooooooooooo
<aelspire> it will probably continue to work without problems next 10 years at last
<aelspire> BSDs probably will be interested in keeping X alive
<aelspire> I'm Wayland fan but XOrg is not dead yet and probably will survive for a while
<wael_> how the hell do i write man pages manually by hand without scdo
<wael_> c
<wael_> its painful
<aelspire> welllllll
<wael_> is there some guide out there
<aelspire> you can make Your own markup lang for manpages
<wael_> that just a harder scdoc
<wael_> is there a guide to write man pages
<aelspire> yup
<wael_> whererwrewr
<wael_> werwehrewhrwrhewhrewhrwrew
<wael_> okay okay i found uh
<wael_> man-pages(7)
<wael_> ill use that
<wael_> mfw you can use man pages to write man pages
<wael_> nvm its incredibly hard to understand
<wael_> i give um
<wael_> i give up
<wael_> im using scdoc
<niceguy5000[m]> X is dead
<niceguy5000[m]> How can they kill XORG!!!!!!!!!!!!!!
midfavila-tab has joined #kisslinux
<wael_> i already love scdoc
<wael_> so so so so easy
<phoebos> it's an extra dep and compiles to man, but ok
<aelspire> I think the best solution will be something similar to solution for autohell
<midfavila-tab> >compiling documentation
<midfavila-tab> there's an autohell workaround?
<aelspire> the release tar should contain manpages already compiled
<aelspire> the same idea with html docs for gtk and other perversions
<wael_> the only project that i know of that does this is illiliti
<wael_> 's tinyramfs
<aelspire> but this is more like cultural problem than technical one
<aelspire> manpages are portable, html docs the same
<phoebos> mdoc is a nice language, easy to learn, and has semantic benefits; man is not
<wael_> is mdoc not man
<midfavila-tab> it's not
<wael_> i saw suckless man pages be very different compared to phoebo's man pages
<wael_> oh
<wael_> ,hy79608hgru7e6ytgwerzu47e4wehgetg78agae3
<midfavila-tab> -man vs -mdoc
<aelspire> why everyone need to run scdoc or other things on release tar if developer could make this part of pipeline the same as with automake 's ./configure
midfavila-tab has quit [Ping timeout: 246 seconds]
midfavila-tab has joined #kisslinux
midfavila-tab has quit [Ping timeout: 260 seconds]
<illiliti> it reminds me a problem when developer does not vendor dependencies for go/rust packages and instead force users to have internet connection to fetch them at build time
<aelspire> this is quite sad, AFAIK vendoring deps in Rust is one line in cargo
<aelspire> I think this should be doable to grab info from cargo what it needs when creating KISS package and simulate vendoring deps
<illiliti> i gave up on this ^
<illiliti> aelspire: that's what we do for cbindgen package iirc
<illiliti> but my point is that it should be by default and that current rust/go ecosystem is deeply flawed because people not doing it
<illiliti> for example most C packages don't suffer from this problem
<aelspire> illiliti: yeah build script for cbindgen is quite interesting
midfavila-tab has joined #kisslinux
<aelspire> I still stand with my opinion that this is cultural problem
<illiliti> not really
<illiliti> it is security matter
<aelspire> npm, pip, cargo etc. are tools for *developers* and developers only
<illiliti> what the hell i need internet connection at build time
<illiliti> those are cursed tools
<aelspire> but weird culture somehow expect users to use cargo to install packages locally for users
<illiliti> that's why language-specific package managers are considered harmful
<aelspire> source tarbar should contain dependencies if they are as granual as in Rust and other such systems
<aelspire> I would disagree on this one
<illiliti> use distro package manager
<aelspire> possibility to quickly test few libraries before commiting them is nice
<aelspire> quickly starting working on other machine or even in sandbox is nice
<illiliti> you don't need the whole package manager for that
<aelspire> but downloading tons of packeges during install on user machine is cursed concept
<illiliti> yes
<aelspire> or when building package as ideally packages should be reproductible
<aelspire> so I can build one and check if the package my distro provides is identical
<aelspire> but npm, cargo etc are breaking this assumption
<aelspire> but still language package managers are not so bad IMHO
<illiliti> the point of npm, cargo is to avoid distro package manager
<illiliti> and thus undermine it
<aelspire> yup
<aelspire> thats the point
<illiliti> and that's bad
<aelspire> so I can work on my application on Arch or on Debian and I don't care about available versions and so on
<aelspire> it's better than containers
<niceguy5000[m]> what you want for a secure system is openbsd. They have a good record.
<aelspire> but those tools are for developers IMHO
<aelspire> not for users/package maintainers
<aelspire> but culture around those tools is weird one and expect package maintainers to use it too
<aelspire> vendoring or providing list of dependencies with point where you can grab them should be a norm
<aelspire> so package maintainers could vendor them if developer don't want too
<aelspire> and AFAIK cargo is able to work with vendored packages without problems
<aelspire> I'm not sure about pip, npm and whatever go has
<illiliti> problem is that nobody is vendoring dependencies
<illiliti> it is fatal problem in go/rust packages
<illiliti> again, C packages don't have this problem
<illiliti> there's a long-standing war between developers and package maintainers, if you didn't know
<illiliti> former want ship their crap to users asap, latter want stability and security
<aelspire> I've read on Drew DeVault blog about tit
<noocsharp> depends on the developer and depends on the package maintainer
<aelspire> but yup the culture is bad
<illiliti> depends on language
<aelspire> you can write crap in C and good apps in brainfuck
<aelspire> languages are just tools
<noocsharp> there's nothing stopping language specific package managers to falling back to a package installed on the system
<aelspire> it will not fix the problem if developer is the problem
<illiliti> language-specific package manager should not exist in the first place
<aelspire> Rust and Go has bad rep because bad developers uses those languages more than C
<aelspire> package manager is one of reason why
<aelspire> but it is nice tool to have
<aelspire> there is a problem with packaging things on linuxes as every distro has its own set of ideas how to package something and in which version
<aelspire> there are countless attempts to solve this: flatpack, containers etc.
<aelspire> and language-specific package managers
<aelspire> so even if such tools doesn't existed today, someone will make one
<aelspire> problem is that those tools are for developers and users/package maintainers shouldn't have to use it
<aelspire> as downloading packages during build is not the best solution - someone could use MITM attack to swap build script with something malicious
<aelspire> or other way to do so
<aelspire> corrupting for eg. build server of well known linux distro will be cataclysm
<aelspire> so all sources should be available before attempting to use them
<illiliti> yeah, downloading packages increases attack surface
<illiliti> completely locking down internet connection would remedy it
<aelspire> yup, I agree with this
<illiliti> actually what developers want is windows
midfavila-tab has quit [Ping timeout: 252 seconds]
<noocsharp> illiliti: aren't you a developer?
<aelspire> surveys on SO disagrees wih this
<aelspire> linux has something like 43% of usage?
<illiliti> i mean developers that use flatpak to ship their apps
<illiliti> there they can ship apps without any user concern
<aelspire> there is other problem - Rust Go etc libraries are not stable and basically unshippable with OS if there is no C interface for them
<aelspire> AFAIK .so files need C-like API
<illiliti> those developers can't understand that linux/bsd/any traditional unix os don't work in that way
<aelspire> C++ solves this by separating header and source so templates are allowed only in header files
<illiliti> there are package managers and developers have to work with them
<illiliti> but what we see is an attempt to reinvent windows approach of shipping apps
<illiliti> do i need to remind how chaotic it is?
<aelspire> but Rust has generics so it need source to build correct lib
<aelspire> appimages?
<aelspire> I've thought that this mess was already reinvented
<illiliti> they suck
<aelspire> the same idea - pack all dll/so with apps
<aelspire> flatpak tries to reuse some common base at last
<illiliti> flatpak is windows store
<aelspire> but yes this sucks and containers too except one thing
midfavila-tab has joined #kisslinux
<aelspire> I develop app for ancient Debian on latest Arch without problem
<aelspire> I've made container of this Debian version
<aelspire> and build app using bubblewrap
<aelspire> X11 connection works and other things too
<aelspire> > https://codeberg.org/kiss-community/community/issues/976 - there is no way to vendor deps in Go?
<aelspire> the way cbindgen does it?
midfavila-tab has quit [Ping timeout: 252 seconds]
<illiliti> developer should do this, not us
<illiliti> cbindgen is an example of workaround
<illiliti> it should be fixed in cbindgen
<aelspire> yup but I doesn't expect every single one to do this…
<aelspire> this issue shows that no one cares…
<illiliti> and C packages don't have this problem at all, which again reinforces my opinion that rust/go is deeply flawed
<illiliti> C developer care enough to provide self-contained tarballs, are rust developers careless? seems so
<aelspire> I disagree but our values differs so it is matter of opinion
<illiliti> disagree in what
<illiliti> that rust ecosystem is broken?
<aelspire> the rust being deeply flawed
<aelspire> it has flaws
<aelspire> but so C
<aelspire> and Python has flaws and Go has
<aelspire> the developer role is to decide which set of flaws we can tolerate in this case
<niceguy5000[m]> isn't python kiss?
<aelspire> python has pip
<illiliti> so you admit that C is superior than rust in this case because it does not have this problem?
<aelspire> yes
<aelspire> but C has other flaws which Rust solves
<illiliti> yes
<aelspire> it depends on what you need or what your values are
<aelspire> there are only 2 programming languages I've used and decided that their whole desing is terrible
<aelspire> JavaScript and C++
<aelspire> others has strong points that sometime can outweights their flaws
<aelspire> anyone can tell me how the cbindgen sources was generated?
<aelspire> this idea is great when devs are stubborn
<illiliti> for me it is more important that language should not scatter and undermine relationship between developers and package managers and instead make them friends
<illiliti> it is only possible without language-specific package manager
<aelspire> or when the language package manager has well defined role and is marketed as tools for developers and developers only
<aelspire> as I said I needed Debian container for developing app on Arch
<illiliti> because once you add package manager to your language, you declare a war to package maintainers
<aelspire> if I could define one file with all deps I need and with versions available on ancient Debian and run one script to has them installed my work would be much easier…
midfavila-tab has joined #kisslinux
<aelspire> and this project was in C
<aelspire> but I agree that forcing package manages to use such tool is bad idea
<aelspire> ooh, thanks a lot illiliti
<aelspire> and for tinyramfs too
<aelspire> why this script is not in official KISS release?
<illiliti> i don't remember
<midfavila-tab> language PMs are annoying
<midfavila-tab> i don't want to have five different programs to do the same shit
<phoebos> that script doesn't really merit being in kiss, it just prints urls
<midfavila-tab> does wayland seriously require a daemon to manage wallpapers?
<illiliti> i don't have/need wallpaper, no idea
<aelspire> it depends on compositor
<aelspire> but with current state of affairs yes
<aelspire> hyprland is capable of displaying hardcoded image on the bottom of stack
<aelspire> but the situation looks the same in XOrg AFAIK
<aelspire> what feh is?
<midfavila-tab> xorg has never needed a daemon to set a root pixmap
<midfavila-tab> x11 in general rather
<aelspire> and wayland doesn't too
<aelspire> but compositors doesn't implements this except of hyprland where wallpaper is hardcoded
<midfavila-tab> seems kind of bleh
<aelspire> the server is replaced with compositor
<aelspire> wayland is X11 and compositor is XOrg in this world
<soliwilos> hikari has wallpaper support built-in, set it it's config file.
<soliwilos> s/it/in/
<soliwilos> You can also edit the wallpaper in the config and reload (not restart) to change it.
<aelspire> it draws it itself or relies on some kind of deamon to do so?
<illiliti> shitstorm is coming
<illiliti> phoebos: i've sent proposal btw
<illiliti> CURDIR
<aelspire> there is very important project in Rust world that vendors its dependencies and this should be shown as the proof that this is intended usage
<aelspire> rustc itself
<illiliti> ofc this is intended usage
<illiliti> otherwise why cargo vendor exist
<phoebos> illiliti: oh cool
<phoebos> nice
midfavila-tab has quit [Read error: Connection reset by peer]
midfavila-tab has joined #kisslinux
midfavila-tab has quit [Ping timeout: 255 seconds]
midfavila-tab has joined #kisslinux
aelspire has quit [Quit: leaving]
Torr has quit [Quit: leaving]
Torr has joined #kisslinux
midfavila-tab has quit [Read error: Connection reset by peer]
midfavila-tab has joined #kisslinux
midfavila-tab has quit [Read error: Connection reset by peer]
midfavila-tab has joined #kisslinux
midfavila-tab has quit [Ping timeout: 272 seconds]
midfavila-tab has joined #kisslinux