<andi->
I only always forget "create" for creating a new backup... not sure why that doesn't stick
disasm has quit [Quit: WeeChat 2.0]
disasm has joined #nixos-chat
drakonis has joined #nixos-chat
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-chat
jasongrossman has quit [Quit: ERC (IRC client for Emacs 26.1)]
pie___ has joined #nixos-chat
pie__ has quit [Ping timeout: 240 seconds]
endformationage has quit [Quit: WeeChat 2.3]
drakonis has quit [Quit: WeeChat 2.3]
MichaelRaskin has joined #nixos-chat
drakonis has joined #nixos-chat
johanot has joined #nixos-chat
johanot has quit [Quit: WeeChat 2.2]
johanot has joined #nixos-chat
disasm has quit [Quit: WeeChat 2.0]
johanot has quit [Ping timeout: 245 seconds]
asymmetric has joined #nixos-chat
aanderse has joined #nixos-chat
johanot has joined #nixos-chat
johanot has quit [Quit: WeeChat 2.2]
johanot has joined #nixos-chat
pstft has joined #nixos-chat
__monty__ has joined #nixos-chat
johanot has quit [Ping timeout: 255 seconds]
<joepie91>
it's... interesting how many bugs you can discover by having a mouse with a 'doubleclick' button
<joepie91>
which double-clicks faster than the average human would
asymmetric has quit [Ping timeout: 245 seconds]
johanot has joined #nixos-chat
<clever>
joepie91: and how many bugs you find by using middle-click paste
<clever>
joepie91: many websites will only update the UI via onkeyup, not onchange
<joepie91>
I'm actually still looking for a way to kill that feature everywhere
<clever>
so middle-click doesnt do anything
<joepie91>
middle-click paste that is
<clever>
some websites dont use placeholder correctly
<clever>
joepie91: middle click is probably somewhere in the xorg config
<joepie91>
aye, I've fiddled with it in the past, but somehow there's always a nook or cranny somewhere where it still happens
pstft has quit [Remote host closed the connection]
<infinisil>
joepie91: My mouse can do such a doubleclick thing!
<infinisil>
Although, I can't control it, it's very random..
<infinisil>
Let's call it a feature anyways
<gchristensen>
hahaha
<joepie91>
infinisil: lol
<joepie91>
infinisil: I meant as an actual feature :D
<joepie91>
an intentional one
<joepie91>
(my mouse has a dedicated doubleclick key)
<infinisil>
I saved some time with this feature yesterday, when I pressed the "next video" button while watching a series it skipped an episode
<joepie91>
lol
<joepie91>
also, in the category of "things you knew existed but couldn't recall the name of so it took ages to find any documentation about it": https://en.wikipedia.org/wiki/Prefix_code
<__monty__>
infinisil: It's hard to avoid considering there's no good definition of what intelligence is though.
<joepie91>
infinisil: I'm wholly in favour of the "AI is just algorithms" viewpoint for this reason
<joepie91>
:P
<simpson>
No worries; nearly everybody has some sort of bias around AI. It's an inevitable consequence of people having theories of mind.
<__monty__>
Most people presume an intelligent being is a conscious being and we don't even have a definition of consciousness really, so we can't even begin defining intelligence.
<MichaelRaskin>
I don't have this bias, I also assume most things _people_ do they do without actually using their intelligence
<infinisil>
That's why I like using the term neural network when you have one instead of AI, neural net has a decently good definition
<simpson>
MichaelRaskin: Sure. For example, I believe that I am a p-zombie, and then by Turing's convention I believe that all humans are p-zombies. However, this also surely taints my ability to treat AIs and computers as anything but machines.
<simpson>
infinisil: Except for the part where neurons don't behave that way, sure. We should use "activation net" or "Petri net" or similar, rather than focusing on the skeuomorphic aspect.
<MichaelRaskin>
Too bad Petri net is actually from verification side, not machine learning side
<simpson>
Sure, one thing that pops out as soon as we switch to more formal methods is that the various nets can have the same shape but different usage due to slight internal differences.
<MichaelRaskin>
Erm. Petri Nets are really not unifiable with input-summing response nets.
<simpson>
And surely both are different from interaction nets, which are also different from rewriteable graphs.
<simpson>
And yet they're all more similar to each other than neural nets are to actual networks of neurons.
<MichaelRaskin>
Well, depends on the timescale…
<simpson>
I'm still wondering about https://arxiv.org/abs/1806.06850 and whether polynomial regression really is an acceptable substitute.
johanot has quit [Ping timeout: 240 seconds]
<gchristensen>
"Disk size 507840355 is not a multiple of sector size 512; the remainder will not be visible to the guest." lol really
johanot has joined #nixos-chat
<MichaelRaskin>
Secret invisible bytes
<gchristensen>
feels like that is probably the wrong thing to do
<MichaelRaskin>
What are the alternatives? I guess the emulated interface would break in interesting ways with non-whole sectors
<MichaelRaskin>
And «nobody» cares about storage size up to a single sector anyway!
<gchristensen>
I guess I think padding it with nul bytes, or failing would be reasonable approaches
<gchristensen>
as it stands I'm fixing to get some bad reads
disasm has joined #nixos-chat
<MichaelRaskin>
Padding: just say no. I mean, if you have an image with non-zero bytes, and add some non-zero bytes on the host side, and on the guest side some zero bytes are replaced with non0zero ones — that seems to be an unfriendly interpretation of growing the image
<gchristensen>
:)
<gchristensen>
MichaelRaskin: is there a lightweight "pid1" I could use not as pid1?
<MichaelRaskin>
Failing — well, I guess for no actual-use intents always failing at the last sector is better than the last sector not existing
<gchristensen>
like I want to light-weight process management for developing a project, and you seem like the person who'd know
<MichaelRaskin>
There is only one lightweight PID1 (up to isomorphism), a constructive existence proof of the universal PID1 is provided by sinit…
<MichaelRaskin>
I am chronically too lazy to actually start using s6, but my impression is that they don't really want to be PID1
<gchristensen>
hah
<gchristensen>
hmm okay, I'll give it a look. thanks :)
<samueldr>
MichaelRaskin: `==` and `==` is mediawiki
<MichaelRaskin>
Maybe
<samueldr>
it's # for a h1, ## for h2 or ### for a h3
<MichaelRaskin>
I suspect I understand actual HTML better than all this quasimarkups
<samueldr>
or text\n---- text\n==== never quite remember which is h1 and which is h2
<samueldr>
pretty sure everything markdown will output you can use as-is with github's markdown processing
<samueldr>
I know I used tables directly with the tool I used ~6 months ago for ZHF
<MichaelRaskin>
I shoul give up and say txt
<samueldr>
I don't think you're far off, if you replaced all equal signs at the start of lines with hashes (#) and removed those ending lines which initially started with equal signs you'd be marking down
<MichaelRaskin>
Will try if I get any answers to the questions in the gist
drakonis1 has quit [Read error: Connection reset by peer]
drakonis1 has joined #nixos-chat
drakonis1 has quit [Read error: Connection reset by peer]
drakonis1 has joined #nixos-chat
drakonis1 has quit [Read error: Connection reset by peer]
drakonis1 has joined #nixos-chat
<infinisil>
MichaelRaskin: "Can we describe the usage levels of packages?" I'd love for nix to somehow have some simple form of analytics for this
<samueldr>
without a popcon-like package (which is self-selective, but might be alright) I don't know if we have any relevant analytics :/
<infinisil>
No idea what you mean by popcon-like (popcorn?) package or self-selective
<joepie91>
MichaelRaskin: on case-sensitivity, I would expect that to matter for reproducibility reasons
<MichaelRaskin>
I think case-insensitive is a low enough tier that reproducibility is beyond the list of worries?
<joepie91>
MichaelRaskin: support tier in terms of platforms extends beyond just CPU architecture; for example, a noteworthy failure mode is that a ton of games on non-NixOS apparently run into trouble due to the opengl-drivers hack in NixOS
<joepie91>
and Nix packages being designed against that
<joepie91>
so despite it being Linux and x86_64 it still breaks
<MichaelRaskin>
Hm right, we indeed have Nixpkgs packages that want NixOS
<joepie91>
MichaelRaskin: and I don't know, I've run into very real issues with case sensitivity in dev projects for example
<MichaelRaskin>
(or NixOS-lookalike)
<joepie91>
so I would not underestimate the possible consequences of that
<MichaelRaskin>
The funniest issue with case sensitivity I know, is that netfilter source code in Linux kernel has files that _only_ differ in case
<joepie91>
differences in case sensitivity can become very irritating when transferring stuff between different systems in some manner
<joepie91>
heh, why?
<MichaelRaskin>
Yes, I have tried to build Linux kernel on FAT32… breaks just like that
<MichaelRaskin>
xt_rateest and xt_RATEEST
<MichaelRaskin>
I guess one of these is about the concept and the other about a specific directive
<joepie91>
MichaelRaskin: in the 'packages' section, the last bit, "would prefer any co-maintainers to..." seems to be a conflation between commitment level and package fragility
<joepie91>
if I understand what you mean correctly
<joepie91>
rest of the gist looks good to me and all seem like good questions/concerns
<MichaelRaskin>
Not really — that a maintainer should reasonably try not to make changes that break the package is a general expectation; only being willing to add people with whom you have worked together on this package for some time, and who have demonstrated commitment to this area and with whom you don't have unresolvable differences is a specific situation
<MichaelRaskin>
Not sure how to describe it better
<joepie91>
MichaelRaskin: then I feel like we're conflating commitment levels to communicate to other potential maintainers, with commitment levels to communicate to users
<joepie91>
users would not care about the type of maintainer being looked for
<joepie91>
they want to know whether it is kept updated etc.
<MichaelRaskin>
Well, this is the first dimension in my gist
<MichaelRaskin>
The second dimension is for developers only. indeed
<MichaelRaskin>
Just wanted to stress that all the words are ambiguous and communication is impossible
<joepie91>
right
<joepie91>
maybe this distinction should be applied to all support level considerations; user expectations vs. maintainer expectations
<MichaelRaskin>
Thanks for suggestion about fragility, by the way, it is a useful characteristic of a package
<MichaelRaskin>
And for reminding me about NixOS-assuming Nixpkgs packages, of course
<MichaelRaskin>
A problem with distinguish target audience for platforms is that the level of support just gradually slides into being less and less interesting for non-developer users
<joepie91>
MichaelRaskin: I more mean distinguishing between whether the concerns listed in your gist (and others) are relevant to maintainers or users
<joepie91>
for the purpose of defining concrete support levels, you probably indeed want to treat every audience the same
<MichaelRaskin>
Well, the concerns also have the same tendency — they are on a sliding scale of «if this is even a question, users are less interested»
<MichaelRaskin>
A support level is a set of expectations, as stated in the preamble
<MichaelRaskin>
I guess we want to have a list of issues first, a list of expectations second, and then for presenting the expectations in a concenient way we will need to think about audience
<joepie91>
can you give some examples of what you mean? with the sliding scale thing
<MichaelRaskin>
Well, if there is no reference to a usable bootstrap tarball for a native-build platform, users are probably not interested by definition
<MichaelRaskin>
Because you probably need developer-type involvement just to create the bootstrap
<MichaelRaskin>
If the platform has a good track record of «hello» running, but not much is used/tested, then some adventurous users with niche needs might look at it, but maybe the platform support is more suitable for developers to expand.
<joepie91>
right
<joepie91>
so maybe we're using different definitions of 'user' here
<MichaelRaskin>
If non-GUI stuff works more often than not and has non-trivial amount of longterm users among committers, then maybe many users can just assume this is OK for their personal need; some other needs are not covered unless people are ready to go and fix
<joepie91>
I'm referring to the entire set of users, regardless of technical competence or usecase
<joepie91>
I feel like maybe you're more referring to specifically office-type users
<MichaelRaskin>
No-GUI case being declared as already interesting to users seems to rule out office-type users!
<samueldr>
maybe we need a "reference desktop"?
<joepie91>
okay, maybe I'm just not focused enough to understand your point :)
<MichaelRaskin>
I thought that «users» = «I want a mostly working deployment before editing any Nixpkgs source file»
<MichaelRaskin>
Developers being the people who plan to checkout Nixpkgs and edit stuff
<MichaelRaskin>
Basically, blackbox/whitebox approach to Nixpkgs as a codebase