jtojnar has quit [Remote host closed the connection]
jackdk has quit [Ping timeout: 244 seconds]
jackdk has joined #nixos-chat
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-chat
drakonis1 has joined #nixos-chat
drakonis2 has joined #nixos-chat
drakonis_ has quit [Ping timeout: 252 seconds]
drakonis2 has quit [Client Quit]
drakonis has quit [Ping timeout: 252 seconds]
pie__ has quit [Remote host closed the connection]
pie__ has joined #nixos-chat
pie__ has quit [Remote host closed the connection]
pie__ has joined #nixos-chat
Jackneill has quit [*.net *.split]
avn has quit [*.net *.split]
ekleog has quit [*.net *.split]
srk has quit [*.net *.split]
drakonis1 has quit [Quit: WeeChat 2.3]
pie___ has joined #nixos-chat
drakonis has joined #nixos-chat
pie__ has quit [Ping timeout: 245 seconds]
jackdk has quit [Ping timeout: 240 seconds]
srk has joined #nixos-chat
ekleog has joined #nixos-chat
Jackneill has joined #nixos-chat
avn has joined #nixos-chat
MichaelRaskin has quit [Quit: MichaelRaskin]
endformationage has quit [Quit: WeeChat 2.3]
etu has quit [Remote host closed the connection]
etu has joined #nixos-chat
etu has quit [Client Quit]
etu has joined #nixos-chat
__monty__ has joined #nixos-chat
johanot has joined #nixos-chat
jasongrossman has joined #nixos-chat
jasongrossman has quit [Quit: ERC (IRC client for Emacs 26.1)]
tilpner has quit [Quit: WeeChat 2.4]
tilpner has joined #nixos-chat
itorres has joined #nixos-chat
* manveru
is getting so frustrated by all the time wasted by people not knowing nix :|
<joepie91>
manveru: in what sense?
<manveru>
like having a readme in every project of dependencies to work through to maybe get that thing running to develop it
<manveru>
or watching the same builds happening over and over again for docker images...
<__monty__>
Tbh, having a nix expression and no readme description sounds equally bad.
<joepie91>
right - Nix isn't a zero-cost replacement to that, though
<manveru>
i'm not against readmes :)
<joepie91>
and there needs to be way better tooling (including introspection, for the reason __monty__ is probably thinking of) before Nix can realistically be presented as a universal way of specifying dependencies
<manveru>
what tooling would you want to have?
<manveru>
at this point, i'm too used to it to notice a lack... :P
<joepie91>
manveru: for starters, tooling that actually makes it ergonomic to write an expression without frontloading full knowledge of all of Nix and nixpkgs... current errors coming out of Nix are basically useless if you don't already have strong familiarity with the language, there's no real debuggers that I know of, there's no way to trace evaluation for a real-world expression, etc.
<joepie91>
manveru: on top of that, better tooling for testing out builds; right now, stepping through build phases is inconsistent and awkward at best
<joepie91>
basically, the usecase of "incrementally put together an expression through trial-and-error and observing results" is totally unsupported right now
<__monty__>
nix-env's UX would also have to be seriously improved.
<joepie91>
most of the information that comes out of Nix isn't really actionable
<manveru>
i avoid nix-env whenever possible
<manveru>
but still use it via home-manager i guess
<__monty__>
manveru: Yeah but that's not reasonable if you want this to be a generic cross-platform cross-person solution.
<joepie91>
manveru: then on top of that, to remove the need for every single user of the software to use Nix, there needs to be a way to produce a list of human-readable dependencies (ideally integrated with something like Repology to match to packages from other distros) so that the maintainer can just write a Nix expression and then automatically end up with install instructions for other platforms
<joepie91>
and so on
<joepie91>
maintainers aren't going to learn Nix _and_ write instructions for other platforms; it's gotta be one or the other
<joepie91>
so you need to make Nix attractive to *them* from an automation perspective as well
<__monty__>
Some people like the nix-shell approach but I'd expect the sort of people that'd want as little to do with nix as possible and just "get things done," would prefer to just do nix-env -i package and be done with it.
<joepie91>
manveru: and there's a bunch of smaller papercuts as well that I haven't listed and probably can't even recall in full here on the spot :P
<joepie91>
but basically, right now you just can't realistically pitch Nix to somebody who isn't already invested in it for other reasons
<joepie91>
because it won't make their life easier
<joepie91>
manveru: btw, to be clear, I share your frustration :)
<joepie91>
I just think that the burden to change that currently lies on the side of Nix, and not on the side of software maintainers
<manveru>
true that
<manveru>
i just wish i had some way to make that happen at least for people i work with
<manveru>
i think the core conflict is that other approaches give you small incremental successes, while with nix you have quite a delay until you get a huge success
<joepie91>
right
<joepie91>
and I don't think that that's a necessary tradeoff
<joepie91>
the incremental successes don't actually have to be useful, they just have to be *visible*, give the user an indication that they're on the right path
<manveru>
exactly
<joepie91>
hence needing better tooling for stepping through build phases and tracing evaluation, just so that the user has some notion of "it's doing the right thing, right up until this point"
<joepie91>
and so that they can advance to a slightly further point gradually
<sphalerit>
run builds in a VM and have it snapshot frequently so you can go back in time! :D
__monty__ has quit [Quit: leaving]
endformationage has joined #nixos-chat
johanot has quit [Quit: WeeChat 2.2]
<emily>
joepie91: I'll be around revspace later today apparently :o
<emily>
forget who if anyone was awaiting that >_>
<joepie91>
emily: oh!
<joepie91>
sudden appearance :P
<joepie91>
emily: being dragged along by somebody else, or? you sound very surprised that you're going, heh
<emily>
something like that, yes :p
<emily>
other plans got rescheduled
<joepie91>
aha
<joepie91>
dunno if I'll be at revspace today, probably not, have a bunch of work left to do :(
<emily>
*nods*
<emily>
I'll return some other time I'm sure
<joepie91>
wait what, I thought it was friday today, but apparently it's thursday...?
* joepie91
blinks
<joepie91>
emily: but yeah, I'm sure we'll run into each other at some point, if you end up visiting more often :P
<joepie91>
also, seems like it's going to be very quiet at revspace tonight, judging from the lack of people in the topic who are gonna order food...
<emily>
quiet works for me, I hear there's a PC-98
<joepie91>
that is correct
<joepie91>
though recently it was in a medium state of disassembly
<joepie91>
it's currently sitting on a project shelf in the lounge, I think
<joepie91>
and I dunno if it's been fixed yet :P
johanot has joined #nixos-chat
johanot has quit [Quit: WeeChat 2.2]
drakonis1 has joined #nixos-chat
* pie___
wonders why firefoxs upstream declarative/external configuration support seems so crappy
<pie___>
maybe i can just hack something tgther that generates a prefs.js ... :/
<clever>
noonien: if you use physical access to mess with /boot/, then the measured boot will have a different recording, and the TPM wont unlock
<elvishjerricco>
noonien: So in theory, with a TPM that's not terrible, it won't be possible to boot off untrusted code
<noonien>
secureboot is not totally useess, coupled with TPM boot measuring you get better security, however, i would still prefer a secure enclave for booting, which is hard to mimick just with secureboot+tpm
<pie___>
clever, context?
<elvishjerricco>
noonien: How are you differentiating "Secure Enclave"?
<noonien>
a secure enclave would be something like a TPM that can also execute code
<clever>
pie___: a tpm in measured boot mode should provide complete security against an attacker with physical access, as long as the bios firmware and tpm are not comprimised
<pie___>
whats measured boot
<noonien>
i don't trust the bios at all
<noonien>
sure, you can lock it with a key
<clever>
pie___: the bios reporting the hash of the bootloader to the TPM before handing over control
<noonien>
but i'm pretty sure there are way of going around the key while keeping the TPM keys intact
<clever>
pie___: and then the bootloader reporting the hash of the linux kernel, initrd, and cmdline, before handing over control
<pie___>
clever, oh that makes more sense than what i was thinking of. what a weird way to name it
<clever>
pie___: and only if the series of hashes is un-altered, will the TPM unlock, and then linux can decrypt the hdd
<elvishjerricco>
noonien: You don't have to trust the bios hasn't been modified after the fact; the tpm will fail then. You just have to trust that the one you measured isn't compromised
<clever>
but in theory, if you can reflash the bios, your fake bios can play back a fake recording, and unlock the TPM
<clever>
enless the tpm has some way to verify the bios image as well
<elvishjerricco>
clever: It can? I thought the boot rom measured the firmware first
<elvishjerricco>
So you'd have to change the boot rom
<clever>
elvishjerricco: how?, the cpu comes out of reset and begins running unsigned code from the bios rom
<noonien>
i don't care at all about the hashes of different parts of the system
<clever>
so you need gameconsole level DRM to secure things that early on
<noonien>
that sounds like the wrong way of going about securing one's systemm
drakonis1 has quit [Quit: WeeChat 2.3]
<noonien>
sure, there might be cases where that is actually useful
<elvishjerricco>
clever: as I understand it, the boot rom is not mutable. It starts up and loads the firmware after measuring it
<noonien>
but i have an encrypted root
<noonien>
i trust my root not to be modified, that should be enough
<clever>
noonien: your initrd could be modified to record the password to /boot/ and then continue booting normally
<noonien>
if an attacked has taken over my unencrypted root, that's a bigger issue than having a corrupted boot
<clever>
noonien: measured boot in TPM would detect that /boot has been modified (either maliciously, or just plain corruption)
<elvishjerricco>
noonien: I think there's value in making physical access attacks as difficult as possible. If you don't measure your boot then it's always trivial to attack
<noonien>
yes, that's why i want the code that asks for the password to be encrypted, and executed in an environment i trust
<pie___>
its supply chain attacks all the way down
<elvishjerricco>
Ahh hence the Secure Enclave idea
<pie___>
(?)
<noonien>
yup
<clever>
noonien: measured boot would allow the tpm to lock things, and refuse to unlock if things have been modified
<elvishjerricco>
noonien: But you don't know that the prompt you're typing into is the one that you wanted it to be
<samueldr>
>> a portion of territory within or surrounded by a larger territory whose inhabitants are culturally or ethnically distinct.
<samueldr>
you put your computer on the island on the middle of a lake
<noonien>
i create a boot image from within my os, encrypt it using a key, the secure enclave would decrypt it using the key in the TPM, then run the code, without the code ever having been in ram or the systme having access to it
<samueldr>
(though it doesn't really fit the actual description I pasted)
<elvishjerricco>
Ah that's a cool idea
<elvishjerricco>
There's still firmware attacks though right?
<elvishjerricco>
Oh no you said to use the tpm
<clever>
noonien: you could look into custom firmware for IPMI modules, or a custom bios that can use the uber-scary things like intels secure element thingy
<noonien>
usually, the secure enclave is different hardware, just like the TPM
<clever>
ipmi is like that
<elvishjerricco>
Regardless, I fail to see the advantage over regular measured boot
<clever>
its basically a 2nd self-contained computer
<pie___>
except one usually (jokes) that ipmi is the insecure enclave
<noonien>
from what i can remember, apple produces have secure enclaves, and so does the nintendo switch, or other nvidia tegra based products
<pie___>
[scandal] theres a lot of computers in a computer :V [scandal]
<clever>
pie___: with stock firmware, yeah :P
<noonien>
sure, there is the additional problem of not being able to tell if the prompt that is asking the password is your code or another's
<noonien>
i read that linux has some basic support for measured boot, but it looked really complicate
<elvishjerricco>
noonien: Linux just gives you the tpm interface and tells you to do it yourself. And the secure enclave in Apple devices is really good
<clever>
the bigger problem, is that any time the boot cfg changes, you have to go thru a special procedure to unlock the tpm and re-record the boot log
<clever>
noonien: and nixos-rebuild changes the boot cfg every time you run it .....
<elvishjerricco>
clever: That's why I want to combine secure boot and measured boot
<elvishjerricco>
If you measure the firmware and particularly the secure boot settings, you can be sure that secure boot is in proper effect
<elvishjerricco>
Then you just sign your boot stuff
<elvishjerricco>
And you only need to remeasure when the firmware or firmware settings change
<noonien>
my reasoning is: why sign the kernel?
<noonien>
if it resides on an encrypted root anyway
<elvishjerricco>
noonien: because you don't want to run a compromised kernel?
<clever>
elvishjerricco: it doesnt have to be real secureboot, you can just use measured boot to trust a given efi binary
<noonien>
also, if signing the kernel, why not sign every single file on the filesystem?
<elvishjerricco>
clever: That's also an option
<clever>
elvishjerricco: and then have your public keys baked into that binary, and configure it to only run signed things
<elvishjerricco>
Same thing really
<clever>
and just ignore secureboot
<clever>
then sign the bootloader cfg
<elvishjerricco>
noonien: The idea is to sign everything that comes before decrypting the disk. Once decrypted, you can trust all that decrypted data is trustworthy
<clever>
noonien: if you sign the kernel, kernel cmdline (to avoid init=/bin/sh), and initrd, then you can trust that the password prompt is not maliciously modified
<clever>
noonien: and then the rootfs is safe
<elvishjerricco>
So I guess when your kernel is on the encrypted disk it doesn't need to be signed; just the bootlosded
<clever>
yep
<noonien>
Yup, but the kernel resides on the encrypted root, so i can't think of a reason to sign it, since it's in a trusted zone
<clever>
also note, rdinit=/bin/sh is a thing (changes the init within the initrd)
<noonien>
Yes, just the bootloader
<clever>
noonien: the bootloader must ask for the rootfs pw then, to find the kernel
<noonien>
yup
<elvishjerricco>
clever: Is there a convenient way to do the remeasuring without rebooting and trusting on first measure?
<noonien>
idealy, the bootloader asks for a password that unlocks a section of the TPM, that communicates the encryption key to the rootfs directly
<clever>
elvishjerricco: not sure
<clever>
elvishjerricco: part of the problem, is that the first few measurements might be the bios internal hashes
<clever>
elvishjerricco: and the tpm likely wont give you the current measurement, for security reasons, so an attacker wont know what to replay
<noonien>
i'd store a script in the TPM, or encrypted on the boot fs, decrypt it using the TPM, and in that script i prompt for the password and boot the system
<elvishjerricco>
clever: Even ignoring that, you can't encrypt things with the new measurements yourself. So you have to boot unmeasured once to do the encryption over the tpm
<noonien>
i would also have antother password setup, that, when entered, executes a script that nukes the luks header
<gchristensen>
I'm too coercable with a wrench to do these thinsg
<noonien>
hehe, it's more of an academic exercise tbh
<elvishjerricco>
gchristensen: Heh yea I mostly just interest myself with these things for fun. But property simply being stolen without your presence is a concern
<noonien>
it's kind of sad that our phones way better security than our PCs
<noonien>
and/or servers
<gchristensen>
don't worry
<gchristensen>
your home isn't very safe either
<elvishjerricco>
noonien: Do androids typically have security on par with iPhones? I've read the iOS security guide and it's really impressive
<noonien>
it's not about safety. it's more about "why not?"
<elvishjerricco>
gchristensen: So when your home is broken into and your computer is stolen, it's nice if it's hard to break into
<gchristensen>
for sure
<gchristensen>
please don't break in to my home
<noonien>
elvishjerricco: i actually have no idea, i'm guessing the newer models are on-par
<elvishjerricco>
Lol
<clever>
elvishjerricco: baring exploits, android typically forces a format of the device to disable the security
<elvishjerricco>
clever: What does that mean?
<clever>
elvishjerricco: an attacker cant just get root and read all of your secrets
<noonien>
there are several security layers of protecting an android device
<clever>
elvishjerricco: he has to factory reset the device to get root, and then the secrets are gone
<noonien>
i believe most vendors implement their own
<noonien>
mostly for the reason of not being able to jailbreak your phone more than actually securing it for users
<noonien>
(i'm guessing)
<noonien>
imho, if you have a "secure enclave"-type device available, this kind of security becomes a lot easier to implement
<elvishjerricco>
noonien: That's definitely true.
<clever>
like all software, android does have some exploits to gain root
<noonien>
gaining root wouldn't matter
<clever>
for example, when restoring a software backup, android would restore directory modes, before writing files into the directory
<clever>
so, if you have a backup, containing a chmod 777 directory, and 1000 files
<clever>
then it makes the dir 777, then it procedes to create 1000 files
<clever>
what if another process makes the 1000'th file a symlink?
<clever>
because you made the dir 777 first!
<clever>
(cp, and mv will chmod after creating all files, for this reason)
<clever>
noonien: i could maybe do it on the kindle fire, but i havent rooted any newer devices, so it would rely on non-root namespacing
<gchristensen>
clever: sounds like a fun pam module
<clever>
which reminds me
<clever>
one of the must-have android apps i use, shows a graph of cpu usage, and the top 3 cpu using procs, in the notification tray
<clever>
so you can instantly know why your device is lagging
<clever>
modern android, uses pid namespacing, to hide all other apps
<clever>
so that is now useless!
<clever>
so every app is essentially running in a container
<elvishjerricco>
That's probably a good thing to be honest. Though it'd be good if a user could manually allow a process to have that info.
<clever>
you likely have to modify the manifest.xml for the app, to request such permissions
<clever>
which means decompiling and recompiling the app, after figuring out what the flag is
<clever>
which reminds me, all android apps are signed by a pub/priv keypair
<clever>
and unlike apple, the keypair doesnt have to be signed by an evil overlord :P
<clever>
when upgrading an app, the new version must be signed with the same keypair
<clever>
if its signed by a diff keypair, you must uninstall it (wiping all app related data), and then install the new one
<noonien>
tbh, i'm really looking forward to fuchsia
<clever>
so, a malicious app, cant gain acces to secrets the original app was storing on the device
<noonien>
security in fuchsia is a more baked-in concept
<clever>
you would need root to bypass such security
<gchristensen>
fuschia is definitely interesting
<gchristensen>
deny-lists were such a bad idea
<noonien>
i like passing down exactly what the process needs, instead of passing everything and then controlling access
<gchristensen>
yay capabilities
<samueldr>
what I fear from fuschia is that since the code will not be "touched" by GPL, no source release for device-specific stuff will happen...
<gchristensen>
yes...
<samueldr>
... and this will in turn reduce the desire of making bootloaders unlockable
<elvishjerricco>
Oh fuschia isn't linux-based?
<samueldr>
fuschia is its own os
<gchristensen>
clean-room os
<elvishjerricco>
wow
<elvishjerricco>
is it posix-y?
<noonien>
samueldr: i don't mind that as much tbh
<gchristensen>
barely
<samueldr>
on the technical side: yes fuschia; on the pragmatic "open device" side: please don't close devices
<noonien>
since quite a few drivers are already provided as binary blobs
<noonien>
especially in the embedded/phone market
<gchristensen>
noonien: it is sort of a "tide" problem
<samueldr>
I prefer being Free to use binary blob drivers than being forced to not have control of my devices
<noonien>
yup
<gchristensen>
the tide of having GPL pulling things open, vs. ... not, b/c it isn't required.
<noonien>
GPL is nice, but the market should requite the vendors to open source their drivers, not the OS, imho
<samueldr>
there are enough android-based devices with completely un-openable bootloaders (locked down is a misnomer here)
<noonien>
there can be good reasons not to provide the source for your program/driver
<gchristensen>
(psst: the market doesn't care)
<noonien>
well, in most cases, the initial market for hardware is developers
<noonien>
and developers might want to have access to the source code to better debug their environment
<samueldr>
closed firmwares are the scourge of anything electronic in my opinion: LET ME SEE AND CHANGE THE FIRMWARE FROM MY DAMN CLOTHES WASHER
<noonien>
sure, these can be released with an NDA
<samueldr>
(sorry for the outburst)
<noonien>
i completely agree
<gchristensen>
samueldr: I think you've turned me in to a zealot
<samueldr>
really?
<noonien>
i also hate not being able to update my phone, not because i don't have software compatible with it, but because the binary blob driers are not compatible with the newer kernel
<samueldr>
I can deal with the initial bootloader (e.g. the uefi) being un-open, as long as it doesn't restrict the use, but would greatly prefer an open one
<noonien>
with a microkernel, that is less of an issue
<noonien>
what i like most about fuchsia is that the IPC is really easy to define, i like the protobuf-like approach, having an IDL from which code for a number of langauges can be generated
<joepie91>
"Finally: today, the Dutch privacy watchdog has issued official guidance that GDPR walls that refuse entry unless you agree to tracking, are in unambiguous *violation* of the GDPR."
<gchristensen>
ooh
<elvishjerricco>
completely unrelated: man pages are always better than --help. I should just stop trying to use --help
<clever>
elvishjerricco: `nix-store --help` agrees with you :P
drakonis_ has joined #nixos-chat
drakonis1 has joined #nixos-chat
drakonis_ has quit [Read error: Connection reset by peer]
drakonis has quit [Ping timeout: 250 seconds]
<colemickens>
Is anyone familiar with libva-vdpau-driver-chromium, particularly the chromium variant and why its necessary, etc?
* colemickens
would assume Google would still have some clean devices they'd release. Chromium's been more open than Android and Fuschia dev style seemed more like Chromium from my totally unqualified third party view.
<gchristensen>
having it be a "best behavior" thing vs. a "license requires it" is a loss
<gchristensen>
I need some narative to go with your exhibits :P
<samueldr>
google somehow coaxed OEMs of all chromeos-based hardware to play ball with a completely open bootloader
<samueldr>
while google somehow didn't coax android OEMs of the same
* colemickens
nods
<samueldr>
chromium devices being open up to the firmware (excluding one management chip which is source-publicly available, but not rewritable)
* colemickens
is cynical though, my hope is surely misplaced
drakonis has joined #nixos-chat
<samueldr>
I hope *too* that the chromium's team way of doing things will be used for anything fuschia related
<colemickens>
samueldr: aren't all or most all of the devices still in the main tree too?
<samueldr>
chromium engineers are also taked to mainline everything
<colemickens>
at one point, that was the case, for ChromeOS devices.
<samueldr>
but I'm not sure how true it is in the end, given the new MTK hardware using an old 3.x kernel
<samueldr>
tasked to*
<gchristensen>
that is sort of my point, though
<gchristensen>
who cares what google is doing today when they could change it in an instant tomorrow
<samueldr>
setting a good example is good too
<gchristensen>
sweet whispers the moment they decide to change
<samueldr>
until the whole software stack is behind a non-tivoization license, which might not be possible, that's going to be hard to ensure under licenses
drakonis1 has quit [Ping timeout: 252 seconds]
<samueldr>
I mean, software being open is linked to hardware being open, but both of those can happen independently
<gchristensen>
and here we're presented with an OS where we could get neither
<samueldr>
you can very well have a fully open stack, but verified at the bootloader, meaning that while the software stack is open, you cannot change the running software
<samueldr>
I'm not sure how other than businesses making the bootloader open, it will happen; it cannot be enforced other than through legislation I guess
<samueldr>
(or through the market, but market will not care)
<samueldr>
unless I'm not seeing something?
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-chat
<gchristensen>
at this point I must assume I'm missing something
srid has quit [Read error: Connection reset by peer]
<samueldr>
hmm, hard to make a point when the thought is nascent, but I prefer willingness to do something rather than being bound to by words (e.g. a license or requirements); requirements or licenses will be followed (hopefully), but can also be twisted back around I think
<samueldr>
I'm thinking things like requirements to hide a binary blob on side storage and cpu to conform to RYF
<gchristensen>
I feel that both are important to allow the community to continue when it stops being commercially expedient
<samueldr>
definitively
<gchristensen>
I feel the GPL has fallen out of popularity for individuals lately, because of annoyances to businesses (whose values don't align to that of the hacker)
<gchristensen>
for example, minix's author for example was disappointed when Intel followed minix's license
<samueldr>
yeah, that feeling I have seen echoed
<drakonis>
the values of the individuals have recently shifted towards being business friendly
<samueldr>
I feel the GPL is partially toothless, since the end-user cannot do anything about violations, only the rights holder :/
<gchristensen>
yes that is interesting, isn't it :)
<gchristensen>
such is the way of copyright
<samueldr>
ooh, speaking of, anyone with a verizon set top box, a recent one, I belive there is GPLv3 software on them
<samueldr>
I was privvy to some info about a product being based on their hardware and software, and have seen a list of licenses
drakonis_ has joined #nixos-chat
<drakonis_>
rather, disregard their own rights in favour of businesses
<gchristensen>
right
<samueldr>
here I'm not sure I agree; they decided they want the software to be made available more Freely in one way; the GPL *is* more restrictive and it is one of its arguable advantage
<drakonis_>
folks using bsd and derivative licenses being okay with freeloading
<drakonis_>
because the license allows it
<samueldr>
then don't license under BSD/MIT if it's an issue, and don't go all entitled that there are freeloaders if you decided to license it in a freeloadable license
drakonis has quit [Ping timeout: 240 seconds]
<joepie91>
there's a difference between what one is okay with, and what one formally allows
<joepie91>
see also: legalization of recreational drugs
<drakonis_>
i've seen a couple projects get big users but no contributions kicked back
<joepie91>
similarly, I license stuff under WTFPL/CC0 not because I'm ethically okay with businesses freeloading off my code, but because I want to optimize for trivial reuse for individuals, and businesses freeloading off it qualifies as an acceptable risk
<joepie91>
especially given that the reality is that license violations by businesses are rarely enforceable against, and so a license like the GPL (or even an attribution-requiring license) puts non-business users at a disadvantage
<joepie91>
because now ethical individuals are paying the cost while unethical companies are just going "shrug, whatever" and doing what they want
<joepie91>
I'd much rather level the playing field and have businesses be outcompeted through collaborative action ;)
<drakonis_>
there's a bit of a catch right now
drakonis has joined #nixos-chat
drakonis_ has quit [Read error: Connection reset by peer]
<noonien>
searching for trunk returns some results
<samueldr>
/nixos/search is lacking the "q" parameter for a query
<noonien>
but if you search for `svn` for example, it returns some more lines that contain `trunk` which were not in the results when searching for `trunk`