<testuser[m]12>
illiliti: What stops programs from using whatever mechanism wf-recorder uses for screen recording instead of pipewire dbus and xdg-portal thingy?
<testuser[m]12>
any reason than abstraction over various compositors
<testuser[m]12>
Exceptions were badly designed in a sense that they could interrupt the control flow unexpectedly. It would be much better if there was a way to ignore exceptions in a scope, like `On Error Result Next` in Basic.
<macslash1[m]>
have u tried rust
<macslash1[m]>
okay but seriously, I'm really considering using KISS and the most complicated thing I've done in linux is install gentoo, I dunno shellscript but tryna learn it so
<macslash1[m]>
feel like I would be completely useless with it xd
<wael[m]>
kiss linux is not very difficult, you dont need to learn shell script to use it
<testuser[m]12>
wael: why does macslash have your avatar
<macslash1[m]>
coincidence
<wael[m]>
yes
<macslash1[m]>
just happen to both like oneshot ig
<testuser[m]12>
sus
<macslash1[m]>
🐴
<macslash1[m]>
also
<macslash1[m]>
wael I see, still feel like it would be useful to have
<wael[m]>
well nothing stopping you from learning it
<macslash1[m]>
true
<testuser[m]12>
u need it only if u need to package or modify something
<testuser[m]12>
its really easy
<wael[m]>
^
<macslash1[m]>
hm
<macslash1[m]>
I will make a live usb
<wael[m]>
?
<wael[m]>
kiss linux is installed via a tarball, similar to gentoo
<testuser[m]12>
i just switched it out for a printf and wc -c
<testuser[m]12>
illiliti: btw should I add a shasum check of the generated file in the build file for nss? Should help identify any portability issues that crop up
<illiliti>
you would have to copy the whole _sh256 func from kiss then
<illiliti>
because there's no simple way to get sha hash
<testuser[m]12>
what check can be implemented portably
<illiliti>
cksum?
<testuser[m]12>
ok
<illiliti>
but actually i don't think that's a good idea
<testuser[m]12>
why
<illiliti>
despite cksum being a posix util, it's not that portable because its algo has been broken and everyone dropping it because of that
<testuser[m]12>
oh i thought u meant the check wasnt a good idea
<illiliti>
and check itself too because it's hard to get right in portable way
<illiliti>
could you make that check optional maybe?
<testuser[m]12>
optional how?
<illiliti>
comment it and left a comment that it's for for maintenance purposes
<testuser[m]12>
but the point is to identify issues on permutations of coreutils and shell
<illiliti>
ah right
<illiliti>
well then we have no choice
<testuser[m]12>
illiliti: what about including a C program for hashing lol
<illiliti>
that's overkill
<testuser[m]12>
~~run kiss c inside the build ?~~
<testuser[m]12>
That actually doesn't sound too bad to me
<illiliti>
using kiss within build scripts is a dirty hack
<testuser[m]12>
nss itself would have some way to hash too like openssl we could just use that after building
<illiliti>
sounds not bad
<midfavila>
idk if recursive calls to kiss are a "dirty hack"
<midfavila>
i can easily think of a way that they could make packaging certain things easier
<illiliti>
i'll always find a better way than calling kiss
<midfavila>
for example, one could include a minimal build for ECL within the files/ of a build for SBCL, and then build it as part of a bootstrap procedure if and only if there isn't already a lisp interpreter
<illiliti>
and there's usually always better way
<midfavila>
in this case the "better way" is just copy-pasting what kiss already does for you :p
<midfavila>
that or having a hard dependency on a lisp interpreter like ecl
<midfavila>
i think this same idea can extend to packages that depend on autoconf-2.13
<midfavila>
similar situations
<illiliti>
sorry mid, but it's shit
<midfavila>
i fail to see how
<midfavila>
recursive calls aren't shit so long as they're used with care
<illiliti>
you want to check if lisp is installed, right?
<midfavila>
in that hypothetical, yes
<illiliti>
then use command -v lisp or something like that
<illiliti>
don't use kiss l
<midfavila>
uh, that was never my point
<midfavila>
the point was that if you fail to detect a lisp, use kiss b to bootstrap a minimal ecl to the current directory
<midfavila>
so you don't have to basically copy-paste the retrieval and build code
<midfavila>
using kiss l to detect the presence of a package *would* be stupid
<midfavila>
because it doesn't tell you anything about what the package actually provides
<illiliti>
so you use this hack to avoid fetching ecl when it's unneeded
<midfavila>
yes
<midfavila>
and to eliminate the amount of redundant shell
<midfavila>
s/eliminate/reduce/
<midfavila>
fek
<illiliti>
there no way to embed it?
<illiliti>
when it's needed
<midfavila>
there is: we do with lisps what we do with autoconf-2.13
<midfavila>
which is *actually* ugly
<midfavila>
unlike a simple switch and call to kiss
<illiliti>
the latter is uglier
<midfavila>
uh, I fail to see how
<midfavila>
do you just have a hateboner for recursion or something?
<midfavila>
legit question
<illiliti>
yep, because i think this all shit should do build system, not kiss
<illiliti>
kiss just need to provide sources
<illiliti>
saving some KB because something is unneeded is meh
<illiliti>
maybe kiss just need some kind of dynamic dependency system
<illiliti>
not the current one which is based on ldd
<illiliti>
could you send me this package where you use this trickery?
<midfavila>
i don't use it atm, it was just something i came up with on the spot while reading the logs
<midfavila>
and it's not just about saving space
<midfavila>
reusing packages can reduce the chance for error
<illiliti>
i see
<illiliti>
maybe we could just extend depends file with weak dependencies
<illiliti>
i.e put autoconf-2.13 weak in depends file. if kiss sees weak dep, it'll check whether it's installed or not. if it's installed, then set env var KISS_WEAK_DEP_<DEVNAME>_INSTALLED=1
<illiliti>
then build script could check that variable and build dependency if it's not installed
<illiliti>
what do you think mid
<illiliti>
or i'm missing the point
<midfavila>
i think that's an inelegant solution
<midfavila>
replacing the existing simple depends system with a "demands" and "provides" system would be more flexible I think
<midfavila>
i.e if there are multiple python implementations, or lisps, or Xaws, or whatever, they provide themselves (their package name) as well as anything in a provides file (so a lisp would provide "lisp", python a "python", so on)
<midfavila>
packages can then demand the presence of either a package by name (hard dependency) or the presence of a faculty on the system (an indirect dependency)
<midfavila>
if the system can't meet an indirect dep, but there are packages available that can, prompt the user to choose one to install; otherwise, fail
<illiliti>
how would you integrate this to resolve your problem?
<midfavila>
if it was integrated, there just... wouldn't be a problem any more
<midfavila>
sbcl would have a lisp entry in its demands file and that would be that
<illiliti>
what if lisp isn't installed and there's no package that provides lisp?
<midfavila>
then the package manager fails with an error, like I said
<illiliti>
how would you bootstrap minimal ecl
<midfavila>
'error: no available package to provide "lisp" found'
<midfavila>
ecl doesn't need bootstrapping
<midfavila>
it's written in C
<midfavila>
but most (all?) other major common lisps are self-hosting
<midfavila>
which is why ECL is important
<illiliti>
no no, i mean if there's no package in system that provides lisp, would you still build minimal ecl to build sbcl?2
<midfavila>
well, at that point, no, you would just move the ecl package to join the rest of the ports
<midfavila>
building ECL iff no lisp is found is only necessary because otherwise SBCL needs to hard-depend on ECL with the current system
<midfavila>
but hard-depending on ECL dramatically increases build times
<midfavila>
especially if you have a CMUCL or CLISP or SBCL available
<illiliti>
in what you're proposing, could sbcl "provide" itself? lisp i mean
<illiliti>
could i build cbcl with cbcl in that case?
<midfavila>
sbcl would provide a lisp, yes.
<illiliti>
ok
<illiliti>
and that would imply that sbcl can depend on itself
<illiliti>
since it provides lisp
<illiliti>
hm
<illiliti>
it complicates dependency system way too much
<midfavila>
not really
<midfavila>
it's one edge case
<midfavila>
"packages can't rely on themselves unless they're already installed"
<illiliti>
ok
<illiliti>
what's the difference between "demands" and "depends"
<midfavila>
demands is generic, depends is specific
<midfavila>
one could, for example, demand *a* TLS library, instead of specifically LibreSSL
<midfavila>
or *a* X server, instead of X.Org
<illiliti>
so demands has support for provides system, whereas depends does not, right?
<midfavila>
yesn't
<midfavila>
you could kludge provides on top of the existing system if you really wanted to
<midfavila>
but... it's not ideal
<illiliti>
ok
<illiliti>
we need to form kiss2 or something
<wael[m]>
o no
<testuser[m]12>
midfavila: Isn't provider system implemented by simple depends in most distros?
<testuser[m]12>
Arch just prompts which provider you want to use but depends file just has the provider name like vulkan-driver
ioraff has joined #kisslinux
<midfavila>
that's basically what I was thinking of
<midfavila>
idk about other distros though
<testuser[m]12>
midfavila: then what's the diff in depends vs demands
<illiliti>
it does not support colon-separated rpath, but i'll implement it if this diff works
<illiliti>
(it works for me for that test package)
sad_plan has joined #kisslinux
<illiliti>
and i forgot about $ORIGIN... will deal with this too
trava4816 has joined #kisslinux
jslick6 has joined #kisslinux
pbsds9 has joined #kisslinux
buffet6 has joined #kisslinux
j3s_ has joined #kisslinux
micr0_ has joined #kisslinux
patwid_ has joined #kisslinux
akspecs_ has joined #kisslinux
Ogromny_ has joined #kisslinux
_ctb_ has joined #kisslinux
akspecs has quit [Ping timeout: 244 seconds]
micr0 has quit [Ping timeout: 244 seconds]
dom96 has quit [Ping timeout: 244 seconds]
_ctb has quit [Ping timeout: 244 seconds]
ax has quit [Ping timeout: 244 seconds]
spacehare has quit [Ping timeout: 244 seconds]
travankor has quit [Ping timeout: 244 seconds]
pbsds has quit [Ping timeout: 244 seconds]
buffet has quit [Ping timeout: 244 seconds]
patwid has quit [Ping timeout: 244 seconds]
Ogromny has quit [Ping timeout: 244 seconds]
j3s has quit [Ping timeout: 244 seconds]
jslick has quit [Ping timeout: 244 seconds]
oldtopman has quit [Ping timeout: 244 seconds]
micr0_ is now known as micr0
patwid_ is now known as patwid
j3s_ is now known as j3s
Ogromny_ is now known as Ogromny
jslick6 is now known as jslick
_ctb_ is now known as _ctb
buffet6 is now known as buffet
wchar_t has joined #kisslinux
pbsds9 is now known as pbsds
dom96 has joined #kisslinux
oldtopman has joined #kisslinux
ax has joined #kisslinux
Guest46 has joined #kisslinux
<Guest46>
Hi
<Guest46>
In your opinion is which is better, writing your real name online (github, social media, etc) or not?
<Guest46>
In other words: Why did you choose the way you write your name over the other?
<virutalmachineus>
yes
<illiliti>
never share your real name
<illiliti>
especially on social media
<virutalmachineus>
why not?
<sad_plan>
because it can and will be harvested and sold for money, and so on
<illiliti>
because it is generally bad idea to share info that's connected to your real life
<illiliti>
people could do nasty things with it
<virutalmachineus>
what about email? should i put my real name?
<ioraff>
that's true regardless of your data whether or not your real name is attached to it or not. one's digital footprint is also probably large enough to tie it back to your real name in any case.
<illiliti>
what about it
<illiliti>
email does not need real name
<Guest46>
illiliti, ioraff, that's what I was thinking, because I might make something online that could be used against me even if I think it wouldn't.
<sad_plan>
a good rule of thumb would be to not give away personal info, unless you absolutely have to
<Guest46>
sad_plan Like banks and official stuff?
<sad_plan>
yeah. you cant really get around those..
<virutalmachineus>
banks will and so sell your info
<virutalmachineus>
s/so/do/
<sad_plan>
I know....
<illiliti>
you could be a stallman
<sad_plan>
even you doctor will do that..
<sad_plan>
^ lol.
<sad_plan>
even as a stallman, you cant get away with your data being sold to some degree
<Guest46>
what is a stallman?
<sad_plan>
richard stallman
<sad_plan>
founder of free software foundation
<illiliti>
if your country doesn't guard your personal data, your data will be sold of course
<sad_plan>
he's abit.. extreme.
<sad_plan>
^ yep
<Guest46>
I know the man but I thought a stallman is an adjective.
<Guest46>
a term*
<sad_plan>
in realitiy is isnt, but in this case we used it as such.
<Guest46>
How one's country guard their data?
<sad_plan>
by implementing laws
<illiliti>
gdpr
<sad_plan>
^ is a good example
<virutalmachineus>
Guest46: by not using banks and using real hard cold cash
<Guest46>
Nice to know.
<sad_plan>
virutalmachineus: thats a tough one to work with though..
<Guest46>
virutalmachineus, haha not an option for me.
<ioraff>
not particularly easy to get cash without a bank
<sad_plan>
I mean, if youre homeless, Im sure you could do that, but most people cant get away with not having to deal with actuall banks
<sad_plan>
under the table work would be a solution, but still. its not really viable
<illiliti>
you could work unofficially
<illiliti>
in country where i live it's viable
<sad_plan>
would that just be under the table work?
<sad_plan>
s/would/wouldnt/
<illiliti>
more or less
<Guest46>
Some say when one writes without their real name sacrifice being not taking seriously. What do you think about that?
<Guest46>
(writes in a blog)
<illiliti>
pick a pseudonym
<illiliti>
problem solved
<sad_plan>
yeah. alot of people do that, especially writers. they do this all the time, and even famous ones have used pseudonyms..
<Guest46>
So a pseudonym is the best all-rounder. I was considering this conclusion.
<sad_plan>
yeah
<sad_plan>
altough, I dont think an employer would be happy with you only supplying a pseudonym though :')
<illiliti>
i doubt that employer is interested in reading your blog :)
<Guest46>
I thought about all this stuff before but, having a discussion is like looking at your head from behind.
<sad_plan>
that too
<Guest46>
true
<Guest46>
Why do you think the people who wrote their real name did it?
<sad_plan>
honesty. we're not tought to not give our real name when someone asks
<illiliti>
those fall under category called "i don't have anything to hide"
<virutalmachineus>
why give info to employers if you can work under the table.
<Guest46>
The don't seam to be concerned or they are using a pseudonym? like is Dylan Dylan?
<illiliti>
both options are possible
<illiliti>
we don't know
<sad_plan>
I hate that one illiliti... its the worst when it comes to trying to share something privacy related...
<Guest46>
illiliti nice
<illiliti>
it's pretty easy to counter
<ioraff>
I don't see my name as particular useful to a data harvester
<ioraff>
s/particular/particularly/
<illiliti>
just say that person that hacker could hack his phone and send dicks to his friends
<illiliti>
or steal money from bank account
<sad_plan>
have anyone really fallen for that one?
<illiliti>
yeah why not. if making your life a real hell isn't convincing, then something wrong with you
<illiliti>
people usually stop saying "i don't care" when i say above arguments
<illiliti>
so "i don't have anything to hide" doesn't work
<sad_plan>
and what would be the odds of getting targeted by a hacker? bit of a long shot perhaps? but I see your point. they look pretty foolish if they just shrugs off an argument which could potentially ruin your life..
<sad_plan>
avoiding identity theft alone, would be a reason enough
<Guest46>
Side story: A scammer got a hold of someone's WhatsApp. He sent to his family I need money so everybody considered sending money to this (good) person because he never asks, so he must be needing the money. After a while he sent a warning from someones number: IT IS NOT ME I REPEAT NOT ME). then he activated his WhatsApp on a new phone, and the
<Guest46>
rest is history.
<illiliti>
getting targeted by a hacker has extremely low chance
<illiliti>
unless you're wanted by NSA
<sad_plan>
illiliti: which would be the counter argument. unfortunatly anyway :p
<illiliti>
yeah, but if you "don't have anything to hide" and you post your log:pass on social media, then ...
<sad_plan>
i know. the argument is just silly, but people just dont care. they dont wanna put any effort into it.
<sad_plan>
privacy/security is so inconvieny
<illiliti>
they just don't know what is ruined life
<virutalmachineus>
illiliti: i run vms, i'm unhackable /s
<sad_plan>
ironically, after switching to grapheneOS from lineageOS, my phone suddenly got more convienent though :p
<sad_plan>
yeah
<illiliti>
how so
<illiliti>
i find grapheneos pretty convenient
<sad_plan>
because LOS didnt have the updater working on my old phone. so I always had to manually download it, reboot to twrp (custom recovery fi you dont know) and flash the new update
<sad_plan>
whereas graphene, it just does everything on its own
<sad_plan>
exacly
<illiliti>
ah updater
<sad_plan>
yeah. and every so often, you had to switch to new newest vendor aswell, so youd have to flash oem zip, then LOS zip, then twrp again. reboot to twrp agaiin, and flash root if you wanted that too
<sad_plan>
it was fun tinkering with it, but it was massivly inconvienient..
<illiliti>
i see
<Guest46>
Is esim good on new phones goodd for privacy?