<clever>
pie_: nix will pass the attrset to the __functor as the 1st arg, so you can share the entire `self: y: self.x * y;` between many objects, and not have to know what obj a copy is attached to
<clever>
pie_: and it happens at the time of calling, so it properly deals with the set being modified after __functor was attached
<infinisil>
pie_: You can indeed do some screwy stuff with it, I'm (ab)using __functor to make https://github.com/Infinisil/nixlisp work for example :P
<clever>
callPackage also makes some use of functor
<MichaelRaskin>
Oops, wrong channel, CrosVM complaints were for #spectrum
<colemickens>
wait what is spectrum then if its related to crosvm
<MichaelRaskin>
qyliss wants to give up the purity in Qubes and run something generic-hardware-friendly with VM isolation on KVM.
<colemickens>
Why is that giving up purity?
<MichaelRaskin>
Because Xen does have better separation of concerns
<colemickens>
TIL. I also have wondered if there's room for a Qubes / Tails competitorand have been imagining something built with Nix(OS).
<colemickens>
Well, if Matrix fixes their stuff I'll join the channel and follow along. I
<MichaelRaskin>
Tails and Qubes are completely independent things (and stageable), and I think qyliss does have a VM generator for Qubes based on Nix
<colemickens>
'm getting a 502 right now.
<colemickens>
sure, I suppose I meant independently. I'd like to have a Qubes-alike built with Nix, Wayland native, using KVM, and then I'd also like to see a privacy-oriented guest VM built with Nix as well.
<MichaelRaskin>
And qyliss wants to reach better granularity than practical with Qubes, and I am trying to sell her on all the ideas I have got from using my container-isolation stuff
<MichaelRaskin>
colemickens: SpectrumOS goals seem to include all of this, except that _one_ privacy oriented VM is definitely not enough granularity
* colemickens
nods
<colemickens>
once its built with Nix though, the possibilities get fun
<colemickens>
similar to how I think about building containers with Nix. I'm curious what your container isolation lessons are!
<MichaelRaskin>
Well, these ae basically that you do end up wishing to pass through _interesting_ sets of resources inside the isolated environment
<MichaelRaskin>
For example, if you want to isolate _all_ PDF viewers, you want to be able to pass live PDF file access, not just a copy (with containers it is done via bind-mount)
<adisbladis>
I wonder if the stable channel should pull in unstable for a set of packages...
<adisbladis>
andi-: ^
<adisbladis>
I'm curious what you think
drakonis1 has joined #nixos-chat
<andi->
adisbladis: well that originated from my PR to mark it as stable and stopping to care maintaining it..
<andi->
adisbladis: I think we should keep a stable FFX in 19.09 and further stable releases. We just must provide them their own dependencies (overrides, copies, …)
<adisbladis>
andi-: That sounds pretty unmaintainable..
<andi->
adisbladis: well we could also use the vendored dependencies.
<adisbladis>
And what would the advantage be over stable referencing unstable for those subsets of packages?
<andi->
How do you plan to references that for now? Flakes aren't a thing yet.
<adisbladis>
andi-: I think I'm talking about a hypothetical future where flakes are a thing :)
<adisbladis>
Right now I agree, there is no good way to do so, barring IFD
<andi->
The more general topic I'd see covered is what we declare a stable release. I don't see a reason to be version pedentaic like Debian.
<andi->
adisbladis: regarding pulling it from unstable: there are often rendering issues in my experience. I haven't tracked them down as we usually have been building it for stable as well...
<__monty__>
manveru: Thanks for the link. Mozilla rolling out DoH with CloudFlare does seem incredibly shortsighted.
<manveru>
yeah... been dealing with occasional dns breakage ever since :(
<joepie91>
pulling from unstable has quite a few caveats
<joepie91>
if there's a glibc mismatch, virtually anything from unstable will crash on launch
<joepie91>
there's indeed often rendering issues, presumably because of a mismatch between Gtk libraries
<joepie91>
it also often pulls in a whole parallel stack of dependencies
<joepie91>
packages on unstable, in my experience, are also broken more often than those on stable (and I mean "broken" as in "compiles and passes tests but does not work at all")
<joepie91>
tbh, I don't think we can handwave away the question of "what constitutes stable" by saying "well if you want something newer, just grab it from unstable"
<joepie91>
it's useful to have it as an escape hatch, but I think there are too many caveats to brand it a recommended approach, at least at this point in time
<joepie91>
cc adisbladis
<adisbladis>
joepie91: I was only talking about it as an "escape hatch" for packages like firefox, I'm aware of a lot of the issues
<adisbladis>
It's just a random idea, and I'm not sure it's a good one :)
* manveru
would really like more install checks in derivations :P
<joepie91>
adisbladis: right, but if you make it policy that "stable will only ship ESR and not update for new features", then that "escape hatch" is no longer an escape hatch, it becomes a necessary thing to do/use for anyone who actually wants to use the web properly
<joepie91>
the main characteristic of escape hatches is that you're not usually supposed to need them, after all :P
<adisbladis>
joepie91: That was not my suggestion, my suggestion is esentially to let `firefox = unstable.firefox` _in_ the stable channel
<gchristensen>
I much prefer the method of just dealing with the deps and having the packages needed to make ff work
<joepie91>
adisbladis: ah, right, perhaps I misunderstood then.
<joepie91>
and maybe it was someone else who suggested the ESR thing
<adisbladis>
Also I'm not a maintainer of any of these packages. I'm not aware of the peculiarities of them.
<joepie91>
adisbladis: anyway, without stable dependency overrides, there's still a decent chance that that'll cause a big closure
<adisbladis>
joepie91: For sure.
<joepie91>
because the firefox in unstable will be built against a different stack of deps
<adisbladis>
gchristensen: Of course that's ideal if it can be maintained
<joepie91>
and yeah, I'm in favour of "just make it work" too
<joepie91>
entirely unrelated and much less topical:
<joepie91>
just got the construction schematics of the possible 'kitchen upgrade' of the house I'm about to rent
<joepie91>
they say 'upgrade', but....
<joepie91>
it's a downgrade from the current kitchen in almost every aspect :P
<joepie91>
you will note the severe lack of cupboard space :P
<gchristensen>
hum.
<gchristensen>
is there a dishwasher?
<joepie91>
and the fridge would have one of those irritating 'freezer compartments', not a proper freezer
<joepie91>
gchristensen: yeah, supposedly(tm)
<gchristensen>
oh man those are terrible
<joepie91>
the 'upgrade' kitchen would have everything built into it
<etu>
joepie91: That's not even a sidegrade
<joepie91>
which is nice from a space perspective
<joepie91>
but it kinda gets negated by a) an awful fridge, b) lack of storage space
<joepie91>
yeaaahhhh
<__monty__>
Unpopular opinion, I consider it an upgrade. Just ask for an actual fridge.
<joepie91>
it'd be a downgrade frankly
<joepie91>
__monty__: not an option
<joepie91>
as in, it is literally not an option available to me
<joepie91>
the choices of kitchen are "basic" or "luxury" :P
<gchristensen>
how about "current"?
<joepie91>
current == basic
<joepie91>
and I'll be taking over the dishwasher that's currently there, from the current tenant
xd1le has quit [Quit: leaving]
<joepie91>
I already have a tabletop microwaven/oven combo thing
<__monty__>
But there's always people involved. Just share your concerns with them.
<joepie91>
which means that I just need to buy a proper new fridge, because my current one is very EOL
<gchristensen>
oh yeah I forget kitchens often move with occupants
<joepie91>
__monty__: this is a massive rental agency where the answer is generally "sorry, the owner is not willing to consider this"
<joepie91>
it's a small miracle that I've been able to get construction schematics
<__monty__>
Just circumvent them.
<adisbladis>
joepie91: Also it looks like a ceramic hob in the new kitchen?
<joepie91>
gchristensen: well the kitchen stays, just the appliances would move, normally
<adisbladis>
And gas in the old
<joepie91>
__monty__: I literally can't!
<adisbladis>
Major downgrade!
<joepie91>
adisbladis: new kitchen would likely be gas also, though possibly induction
<adisbladis>
Induction :(
<joepie91>
eh, induction is fine
* adisbladis
<3 gas
<adisbladis>
Induction is the second best, but only acceptable if gas is not an option
<__monty__>
adisbladis: There's talk of stopping distribution of gas in Belgium though, I think there's similar talk in NL.
* adisbladis
hears the cries of 1000 kitchens crying out at once
<joepie91>
__monty__: anyway, there's no point in putting in more effort than I already have, frankly. I'd be paying extra for something that's not really much of an upgrade, and stressing out about it a lot, and possibly poisoning the relationship with the rental agency before even moving in
<joepie91>
and yeah, natural gas is being toned down here
<__monty__>
Yah, I've mused about how hard it would be to get insurance with a propane based kitchen >.<
<joepie91>
newly built houses generally don't have any gas at all
<joepie91>
old ones are getting retrofitted
<joepie91>
there are ideas to reuse the gas infrastructure for hydrogen distribution
<gchristensen>
wow
<joepie91>
apparently it basically already meets all the infrastructural requirements for hydrogen infra
<__monty__>
"Holland Hydrogen, we deliver the Hindenburg to your stove."
<gchristensen>
will they make it smell?
<joepie91>
but yeah, for that, natural gas needs to GTFO first :P
<joepie91>
anyway! I'm excited about moving!
<joepie91>
gchristensen: if it's distribution to end users, almost certainly
<worldofpeace>
so that's peti's haskell stream and office hours all possibly falling on the same day 🤣
<andi->
competition!
<worldofpeace>
zimbatm: It is 😺
<zimbatm>
I will try and make sure to not overlap with the other streams
<zimbatm>
a few more and we can have a full day of nix content back-to-back :D
<worldofpeace>
I know, we're reaching a weekly Nix streamathon. Let me organize that set list :D 🌟 everywhere
<worldofpeace>
I think the format you have there is very interesting zimbatm
<zimbatm>
thanks :)
<zimbatm>
I've been thinking about this a long time, even before office hours became a thing
<zimbatm>
let's see how it goes :)
<worldofpeace>
When I watched those streams I was thinking, "I wonder how this could be become a regular thing" because it appeared you really enjoyed doing the teaching.
<qyliss>
joepie91: "if there's a glibc mismatch" with what?
<joepie91>
qyliss: between your release branch and unstable
<joepie91>
I've had issues with this like a year ago
<qyliss>
well right, but where does the conflict actually happen?
<qyliss>
I'd like to understand why different packages using different glibcs would be an issue
<joepie91>
I have not looked into it that much :) but the conclusion was given in various issue threads that it was a glibc mismatch
<joepie91>
there's a few threads on the nixpkgs issues iirc
<gchristensen>
there were the troubles with glibc and locales I think?
<qyliss>
This sort of thing must be solvable
<qyliss>
How does it work with AppImage or whatever?
<joepie91>
I've heard vague mumblings about similar issues with appimages actually
<joepie91>
but never anything particularly concrete
<qyliss>
interesting
<qyliss>
If we were to include latest firefox in stable for no reason other than people might want it, I'm not sure what the point of stable is
<qyliss>
And any problems that affect pulling from unstable are going to be bigger problems for other people because of AppImage and Flatpak, so I think they can only get better
<joepie91>
qyliss: what *is* the point of stable?
<joepie91>
because I - and probably most desktop users - would interpret "stable" as "is reasonably guaranteed to work"
<joepie91>
but that is very different from what "stable" means for server installations, where it usually means "doesn't change in functionality or support"
<qyliss>
Alternatively, there can be a firefox overlay
<qyliss>
That approach works well for Rust and Emacs
<qyliss>
joepie91: I think "doesn't change in functionality or support" would satisfy everybody's requirements
<joepie91>
qyliss: I don't think it does at all
<qyliss>
that sounds like a stricter version of "is reasonably guaranteed to work"
<joepie91>
because to a desktop user, that means they don't get new features/versions/support
<joepie91>
yes, the strictness is the problem
<qyliss>
They do every six months
<joepie91>
six months is a long time
<qyliss>
Is it really?
<joepie91>
that's like 1/160th of a human lifespan
<qyliss>
How often do we think stable users are even updating their channels and rebuilding?
<spacekookie>
joepie91: does a distro like fedora that has a release every 6 months update Firefox major versions inside its release cycle?
<spacekookie>
And also, I would argue that for most distros, 6 months is pretty short
<joepie91>
spacekookie: no idea about Fedora, but desktop users rarely use Fedora
<joepie91>
Ubuntu is probably a better benchmark
<spacekookie>
Oh you would be surprised
<joepie91>
or Mint
<spacekookie>
My old company had fedora as a computer policy
<qyliss>
I've met lots of people using Fedora I think
<qyliss>
Fedora is my go-to "normal" distribution
<joepie91>
qyliss: I mean, the whole story about rebuilds is a problem in and of itself. but the benchmark to compare against here is "how often do people install updates", and on a distro like Ubuntu, the answer to that is "whenever the update checker says it needs to"
<joepie91>
qyliss: I mean, I'm looking at a broader userbase, not just the bit that's biased towards techies
<joepie91>
amongst techies there's much higher distro diversity than across vaguely-somewhat-technical-but-not-really users
<spacekookie>
I would also say that there's a difference between holding back a package for policy reasons or holding it back because of technical reasons
<qyliss>
I'm also failing to understand here why somebody would need such frequent firefox updates
<qyliss>
What changes so quickly that you need absolute latest firefox?
<joepie91>
because it is continuously getting performance and functionality improvements?
<joepie91>
even ignoring the security updates
<qyliss>
Right
<qyliss>
So is every other program
<qyliss>
If you cared about that you'd presumably run unstable
<qyliss>
And the security updates are irrelevant because the LTS gets those too
<joepie91>
qyliss: except a browser is a critical part of almost everybody's workflow
<joepie91>
and "If you cared about that you'd presumably run unstable" is nonsense
<joepie91>
because running unstable comes with reduced working-ness of your system
<joepie91>
and "if you cared about new updates, you'd presumably be willing to put up with your system not working" doesn't make any sense
<joepie91>
these are two entirely separate considerations
<joepie91>
your system potentially not working is an entirely reasonable tradeoff if you want bleeding-edge updates, eg. testing versions of Firefox
<joepie91>
it is not a reasonable tradeoff if you just want whatever has been most recently declared "stable and tested" by the vendor
<qyliss>
unstable isn't "your system potentially not working", though
<qyliss>
at least not if we're doing our job correctly
<joepie91>
that is why I'm trying to draw this distinction between the two definitions of "stable"
<joepie91>
qyliss: in practice, yes, it absolutely is
<adisbladis>
Omg, I opened a can of worms :=
<joepie91>
because the test coverage we have in nixpkgs is nowhere near complete enough to reliably prevent breakage, and given that there's no release preparation process (it's auto-updated) there's no human check either
<qyliss>
And even if something does break, it doesn't particularly matter.
<qyliss>
You just roll back.
<joepie91>
and this is *fine* for unstable, *if* you treat it as "the branch that has the latest updates, and that might break"
<joepie91>
qyliss: rollbacks are an escape hatch, they should not be necessary in normal operation
<joepie91>
especially because they are whole-system rollbacks
<joepie91>
and so can block updates/rebuilds elsewhere
<qyliss>
It sounds like you want a release channel that is extremely well tested but also software is immediately updated, and you're saying those two things are unrelated
<joepie91>
no
<joepie91>
I did not say "immediately" anywhere
<spacekookie>
joepie91: nixos via unstable is just as rolling release and well tested as arch is for example. Shit still breaks on arch sometimes. But you get fast updates.
<qyliss>
"very quickly", then
<joepie91>
I'm saying that artificially grouping/blocking those updates by 6-month releases makes no sense for typical desktop usage, and that instead updates should be available as quickly as reasonably possible, after having tested them
<qyliss>
Perhaps there should be another release type for this
<qyliss>
You're right I think that there are competing desires for stable
<adisbladis>
Not more release types /o\
<qyliss>
Exactly my fear
<joepie91>
yes, that's what I'm trying to argue, that there's a third category of expectations :)
<qyliss>
There'd be a tricky policy question, though
<joepie91>
not just "unchanging" vs. "bleeding edge and maybe broken", but also "updated asap so long as it doesn't break stuff"
<adisbladis>
Unpopular bold opinion: Point-in-time releases for software distributions are a broken concept.
<qyliss>
Presumably Firefox 69 -> 70 is okay, but GNOME 2 -> 3 is not
<qyliss>
You'd have to come up with some criteria for when updates released by upstream are excluded
<joepie91>
qyliss: those don't need to be strictly-defined criteria, and can be based on judgment calls
<qyliss>
You need guidelines, still
<qyliss>
What software would and wouldn't you update?
<infinisil>
Maybe something like "if it's been in unstable for X days without anybody reporting an issue it can be included"
<qyliss>
If you updated everything you'd be the same as unstable
<joepie91>
sure. the main guideline should probably be "would this generally be considered an improvement by users"
<qyliss>
that sounds too nebulous to be useful to me
<qyliss>
virtually anything could satisfy that
<srhb>
Clearly the right approach here is to allow people to easily construct their own release!
<srhb>
(Only partially joking here...)
<srhb>
If only software were good enough to allow something like that :-)
<adisbladis>
srhb: Well, that's essentially what a lot of us end up doing ;)
<srhb>
adisbladis: What! I took your for a "master all day every day" kind of person :)
<adisbladis>
srhb: On my personal machines, yes
<srhb>
It's lonely up here on HEAD.
<joepie91>
qyliss: I'm not even necessarily saying you shouldn't update everything; the point is that there is a higher expectation of working-ness, and so things should be tested more intensively before being ported
<srhb>
adisbladis: Ah, phew ;-)
<joepie91>
qyliss: I mean, we're talking about user-facing things here, it's necessarily going to be nebulous.
<adisbladis>
All releases are broken!
<joepie91>
not everything can be captured in tidy rules
<qyliss>
tested how? by whom?
<joepie91>
by whoever handles the porting to the stable-but-recent branch, by actually trying to eg. start the software and verify that its most important things are functional
<adisbladis>
srhb: But sometimes master is not fast enough, so you need overlays :)
<srhb>
adisbladis: Indeed. :-P
<srhb>
And overlaying modules is still kind of messy... Or rather, being disciplined about it is hard.
<srhb>
I feel that master matches my expectations with my experience best.
<qyliss>
You're going to need a dedicated team to do that -- as a committer I'm happy to backport to stable, but not if extensive testing is required.
<srhb>
It's broken, but not in ways I find unreasonable. :P
<qyliss>
And unless you have a critical mass you're going to end up _behind_ stable
<adisbladis>
srhb: Exactly!
<adisbladis>
And if you're on master via a git checkout things are pretty easy to fix generally
<joepie91>
qyliss: if there were a clear process to follow for the testing-and-merging (and I don't mean the criteria for porting, but the actual process), I'd be happy to contribute to that, for example; and I suspect I wouldn't be the only one
<srhb>
adisbladis: I do that nowadays, I used to go with source patching for a while.
<srhb>
(At least, on my personal systems...)
<adisbladis>
That's a PITA :/
<adisbladis>
Used to do that for work
<joepie91>
qyliss: (ie. the process needs to be documented more clearly than processes currently are for triaging and backporting etc.)
<srhb>
I thought it was sort of clever, but in the end not so much
<srhb>
Most things can be solved via disabledModules and overlays, thankfully..
Synthetica has joined #nixos-chat
<joepie91>
at which point I might as well segue into another complaint: the processes for nixpkgs management do not seem well-documented enough, and this impairs the onboarding of new contributors, especially on the reviewing-and-porting side
<joepie91>
eg. there's a lot of assumptions that those doing the reviewing Just Know how to test certain things with Nix
<__monty__>
Would faster than unstable be possible too? I think Tumbleweed manages this by building more modularly?
<srhb>
__monty__: We have faster than $foo-unstable for some values of $foo
<srhb>
... and there's always master.
<srhb>
(come to the dark side)
<__monty__>
Yeah, but Tumbleweed does actually test stuff.
<__monty__>
They don't just build things afaik.
<joepie91>
there seems to be a long-running problem with there not being enough capacity on the review-and-merge side of nixpkgs and NixOS, and I think that could probably be largely addressed by making it a more accessible job to do
<srhb>
You can always lock things behind whatever test set you like.
<joepie91>
so that every suggestion of changing the release/merge process doesn't need to be met with a "but where will we get the capacity?" :)
<adisbladis>
joepie91: It's in the works with unprivileged maintainers and whatnot
<srhb>
I think there's been almost constant work on improving "processes" for like almost two years now.
<srhb>
It is being improved. The bandwidth on the improving-things-side is probably hard to increase, but I don't think it's necessarily needed either.
<joepie91>
adisbladis: I don't mean the policy side, I mean the documentation side. as an example, the local hackerspace obsessively labels everything in the space: https://www.nycresistor.com/2019/01/12/hackerspace-envy-a-visit-to-revspace-in-the-hague/ -- with as a result that everybody can figure out where to put stuff so that others can find it again; which means that we don't have the problem of a handful of members being
<joepie91>
overburdened with returning all the tools to their correct places
<gchristensen>
I think you necessarily have to improve slowly, to make sure workflows actually fit
<srhb>
I'd argue against speeding up much, gradual change is good for reviewing consequences. :)
<srhb>
^
<adisbladis>
gchristensen: Do you have some good resource for finding out about these things?
<joepie91>
adisbladis: we need something similar for the review side of nixpkgs, I think. clear, concise, easy-to-follow documentation on what the processes look like, what the considerations should be, and basically how to get started with it - without ever needing to ask someone else anything up until the moment where you request access to try it out
<gchristensen>
adisbladis: which things?
<adisbladis>
gchristensen: openzfs summit :)
<gchristensen>
I saw it scroll by on twitter 12h ago and have held the tab open since :P
<srhb>
Ah yes, the "browser buffer"
<joepie91>
adisbladis: right now most or all of that knowledge is institutional knowledge in the heads of nixpkgs maintainers, and it gets dispensed inconsistently and piecemeal to people who, presumably, have already made a large commitment
<joepie91>
and imo that's an unnecessary bottleneck
<srhb>
joepie91: Is there some specific knowledge that you feel this is true for? I feel like most of this is already documented, but the discussions too handwavy to actually point to it so that maybe we could make access more direct.
<joepie91>
(and someone who isn't sure whether helping out on the review side is for them, probably are never going to ask for that information, because it would feel like imposing on the already-busy maintainers; whereas if it were a document they could just pull up and read, they probably would)
<srhb>
(For instance, the nixpkgs manual has grown a lot better in this regard)
<joepie91>
srhb: it's a recurring problem that I keep running into. for example, I don't know if this is fixed yet, but the issue template mentions (mentioned?) building in a sandbox, but did not include any instructions on how to do that, why it is necessary, etc. - and I found it impossible to find this information. a more recent example of this is the packages/services blurb at the bottom of the issue template, which also doesn't
<joepie91>
document what it's for, who needs to fill it in, etc.
<gchristensen>
*everything* has grown better imo
<joepie91>
then if I look at the more hands-on review side, where do I find the review process for a nixpkgs PR?
<joepie91>
where do I find the guidelines for backporting into different branches and whether it should be considered and how it should be done?
<joepie91>
where do I find out what would be expected from me, if I were to commit to doing nixpkgs review?
<gchristensen>
(this last one should have been moved in to the manual a long time ago)
<joepie91>
right, that's the sort of thing I mean - they're all disparate things, there's no one-stop-shop that gives a good idea of what it involves
<gchristensen>
let's put our boots on and make things better!
<joepie91>
like, to illustrate what the perfect process would look like:
<joepie91>
hey, there's a button on nixos.org that says "help out reviewing!" - let's click it
<joepie91>
hey it's a page that explains why reviewers are needed, and what kind of commitment is expected, and a list of the different kinds of review, each a link to the instructions for that type of review
<joepie91>
checklist, preferably
<joepie91>
and at the bottom are links to some contact methods for expressing interest in helping out with review
<joepie91>
basically, I should be able to get to the stage of deciding "is this for me?" without having to do any investigative work myself
<joepie91>
and if I decide "yes", it should be clear what to do next
<joepie91>
gchristensen: a concrete example of a problem with the 'reviewing contributions' manual entry (aside from the general "one giant page" issue): it says "Ensure that the commit text fits the guidelines" and "Ensure that the package versioning fits the guidelines", but no link to those guidelines is provided
<joepie91>
I now need to go look for that myself
<joepie91>
"Add labels to the pull request" -- okay, which labels, and when?
<joepie91>
these are all friction points where a potential contributor is likely to go "hm this looks like a lot of work to even figure out, nevermind"
<gchristensen>
then make it better!
<joepie91>
(and to be clear, those are just examples -- this sort of issue is still pretty pervasive throughout the documentation)
<joepie91>
gchristensen: making this better is not a one-man PR
<gchristensen>
start with one change making it a little better
<joepie91>
the documentation in its current state was written by someone, it came to exist in a way, with certain reasons, through a certain process, that keeps resulting in documentation with the same problems
<joepie91>
unless that process is addressed and fixed to prevent these issues in the future, it'll be an endless cycle of new problems being created and having to be fixed etc., which is a waste of energy for everybody
<joepie91>
that is why I'm pointing out these problems here, rather than just creating a PR; they are systemic issues
<gchristensen>
then make the system better
<joepie91>
... that is what I am trying to do here
<joepie91>
I can't make a PR to human behaviour, as convenient as it would be :)
<gchristensen>
not sure it is really doing much to issue critique in -chat without follow-up and next steps
<avn>
Folks, anyone can hint proper (nixish) way to deal with ttyUSB serial ports? (I want to assign them fixed names)
<joepie91>
gchristensen: I'm trying to start a conversation about the topic, address the issues that exist, hopefully discover the reasons and processes that led to those issues - because again, this is happening outside of my view, in a process I don't understand
<joepie91>
right now I don't even know how that doc came to be, who wrote it, what process was followed
<adisbladis>
avn: It's not really possible
<adisbladis>
iirc
<joepie91>
there is literally nothing I can do here, other than to try and understand better how things came to be, through conversation
<adisbladis>
You can create udev rules to do that, but usually serial devices dont have unique identifiers
<adisbladis>
You could do it by port or something if that's stable
<joepie91>
services.udev.extraRules, yeah
<adisbladis>
\
* joepie91
hands adisbladis their backslash back
<joepie91>
you dropped this
<adisbladis>
Heh :)
<adisbladis>
I was plugging something in behind the screen
<joepie91>
:P
<samueldr>
fun thing I realized lately, hand mirrors are amazing for plugging things behind something
<adisbladis>
samueldr: That's next level
<samueldr>
definitely true
<adisbladis>
I'm gonna steal that and claim it was my idea
<samueldr>
ideas should be shared openly, not stolen :[
<adisbladis>
:)
waleee-cl has joined #nixos-chat
drakonis has quit [Ping timeout: 245 seconds]
drakonis has joined #nixos-chat
<avn>
samueldr: I though about put my old webcam behind monitors, to plug/unpug things
drakonis_ has joined #nixos-chat
drakonis has quit [Read error: Connection reset by peer]
* joepie91
is still a little weirded out by being about to sign a rental contract, without ever actually having met anyone from the rental agency in person
<qyliss>
I've been wondering if the issue template ought to be trimmed down
<qyliss>
It's pretty overwhelming
<qyliss>
And most of it is stuff that isn't necessary, easy, or even particularly useful -- nix-review, for example
<adisbladis>
avn: Ahh, right :)
<qyliss>
nix-review can be extremely useful
<avn>
adisbladis: I can tell -- it survive reconnect in random order, but not sure about host reboot
<adisbladis>
I see the difference, all my devices had the same serial attr
<qyliss>
But I'm not sure about its place on the checklist
<adisbladis>
avn: They were super cheap though.. I guess you get what you pay for :P
<avn>
adisbladis: is customer provided hw ;) So I just win some lottery ;)
<adisbladis>
Yay
<adisbladis>
qyliss: We might just want to move a few things to a notes section?
<qyliss>
Still in the pull request template?
<adisbladis>
Yeah, but less overwhelming
<qyliss>
I'm not sure it can be much less overwhelming
<qyliss>
How much to we expect people to read and fill in?
<qyliss>
I think most of it should go into CONTRIBUTING
<qyliss>
Possibly even all of it.
<qyliss>
GitHub invites you to read CONTRIBUTING on your first contribution, and every time it changes
<adisbladis>
/buffer 84
<gchristensen>
too many buffers
<andi->
adisbladis: install go.py in weechat and then just alt-g <express>
<adisbladis>
andi-: Usually I don't use the weechat interface at all
<adisbladis>
But weechat.el broke recently :/
<adisbladis>
gchristensen: It's only too many in the weechat interface, as emacs buffers I don't really care how many I have
<qyliss>
how is weechat.el?
<adisbladis>
qyliss: It's.... Not great :) But also awesome
<adisbladis>
It's a great interface, but notifications are not visible enough (it doesn't highlight the buffer for example)
<adisbladis>
And it can easily hang emacs
<adisbladis>
But... It's the only IRC experience I find tolerable except for ERC
<adisbladis>
I'd love to use ERC if a keyboard phone was my daily driver
vika_nezrimaya has quit [Remote host closed the connection]
pie_ has quit [Quit: pie_]
Remosi has quit [Ping timeout: 264 seconds]
psyanticy has quit [Quit: Connection closed for inactivity]
<elvishjerricco>
Anyone know if `services.znapzend.zetup.<name?>.destinations.<name?>.presend` runs before the snapshot being sent is taken at all? I'd like to collect garbage before snapshotting for a backup pool
<elvishjerricco>
infinisil: My goal is to have local snapshots with a plan of `10min=>5min,1h=>10min,1d=>1h`, and a destination pool with backups at `1m=>1d,1y=>1m,10y=>6m`
<elvishjerricco>
And I really don't wanna collect garbage every 5min :P
<elvishjerricco>
i.e. local for the past day, destination for past beyond that
<infinisil>
Yeah znapzend doesn't support that unfortunately :/
<__monty__>
gchristensen: I assume this blew up on twitter or something?
<elvishjerricco>
Oh :(
<infinisil>
I wanted that too
<__monty__>
Can you create two znapzend services, where one does remote backups and the other doesn't?
<elvishjerricco>
infinisil: Which part does it not support? Running a script before backup snaps, or making plans where the backup goes further back than the local?
<{^_^}>
#72060 (by lopsided98, 1 week ago, open): sanoid: add package, NixOS module and test
<infinisil>
And of course my future own backup tool which will be better than all current ones :P (only problem is it doesn't exist yet)
<elvishjerricco>
infinisil: How would yours work?
<infinisil>
I don't feel like explaining the nitty-gritty details, but essentially it will unify data synchronization and backupping and can simulate a single unified history over multiple machines
<__monty__>
How about running two? Znapzend for remote and something like borg for local?
<gchristensen>
elvishjerricco: what if you didn't snap / send /nix?
<elvishjerricco>
gchristensen: That's the other option I'm considering.
<elvishjerricco>
__monty__: The issue is that I don't want 10 years of backups on the local pool. znapzend won't let the backup pool have older backups than the local one
<infinisil>
Oh yeah I'm not backing up /nix for sure
<infinisil>
I'm only doing /home and /var/lib
<gchristensen>
elvishjerricco: eh? it wont?
<elvishjerricco>
gchristensen: That's what that issue that infinisil linked said, I thought
<gchristensen>
huh
<__monty__>
elvishjerricco: Ok, then znapzend for local and something else for remote?
<infinisil>
elvishjerricco: Nah, znapzend doesn't support having less frequent snapshots on the destinations
<elvishjerricco>
ah
<__monty__>
Right, then either way works, just use two distinct backup methods.
<elvishjerricco>
Currently just looking into sanoid instead :P
<infinisil>
It's unfortunate that znapzend isn't really maintained anymore :/
<infinisil>
Or at least it seems that way
<gchristensen>
probably got burned out on all the z's
<gchristensen>
sanoid is a person's business, so probably maintained
<elvishjerricco>
Looks like syncoid just syncs exactly what's on the local pool. So not any more useful
<elvishjerricco>
But sanoid would be fine for the local half
<infinisil>
Huh
<infinisil>
It's kind of amazing how we have such a nice filesystem but all backup tools kinda suck in their own way xD
<__monty__>
elvishjerricco: You create the backups locally, sync them, remove them locally. That's what you want, no?
<infinisil>
Although, I guess all software does
<elvishjerricco>
I'd like something that's just like sanoid's config file, but one for both the local pool and each backup pool you want.
<elvishjerricco>
Maybe something like tinc, where you have a different systemd service for each daemon, running on its own config file
<gchristensen>
I guess I'm not sure why you wouldn't send your 5m snaps remotly
<elvishjerricco>
gchristensen: I wouldn't. That's the problem with znapzend. It FORCES you to do so, if you want local 5m snaps
<elvishjerricco>
oh you asked why I wouldn't, not why I would :P
<gchristensen>
right
<elvishjerricco>
Seems like a lot of unnecessary IO if the destination is over the network, especially if it's across the internet. Currently it's just an external disk but I do plan to move it remote
<gchristensen>
it makes it frequent small sends instead of infrequent large sends
<elvishjerricco>
gchristensen: "small". I can churn through a gig on disk within 5 minutes frequently enough :P
<gchristensen>
in such a way that it isn't sent remotely?
<elvishjerricco>
Like if I happen to download an iso for a linux distro to my home directory, and the backup gets taken, that's easily a gig that I didn't want to upload
<infinisil>
I guess with lots of temporary files
<gchristensen>
right, and you'll have deleted it before the next "long term" snapshot?
<infinisil>
Though yeah, realistically it probably doesn't save all that much to only send every 1hour instead of every 5 mins
<__monty__>
elvishjerricco: A gig every couple hours might still be better on bandwidth than 10G once a day I guess.
<elvishjerricco>
gchristensen: In that case the issue isn't the space usage it's the network usage
<gchristensen>
sorry I'm still trying to establish the part about it'll have been deleted before the nextlong term snap?
<elvishjerricco>
__monty__: But this is a gig that wouldn't have been sent by the end of the day at all
<elvishjerricco>
because I'd burn the iso to USB and delete it
<infinisil>
gchristensen: I think that's the idea yeah
<__monty__>
gchristensen: Without judging the content. It's admirable that this sort of discussion is held in the open imo. Don't think many companies would have the guts.
<gchristensen>
got it
<gchristensen>
__monty__: agreed
<__monty__>
elvishjerricco: Ah, anyway you can move these temporary things out of the scope of the backups? If you don't want them backed up anyway?
<elvishjerricco>
__monty__: That's what I currently do :P
<infinisil>
elvishjerricco: Oh um, slight problem I'm just noticing: zfs can't send just the incremental update from snapshot A to C. It has to send B as well
<infinisil>
I think
<__monty__>
*any way (Typo made it sound like I was telling you to do this, but it was intended as a question.)
<elvishjerricco>
infinisil: Depends on if you use `-i` or `-I`. But I think `-R` requires sending everything in between
<infinisil>
Ahh yes, forgot about -i vs -I
<infinisil>
Ah and then you can check what differenc this would make: sudo zfs send -vI tank/root/data/varlib@2019-11-04-200000 tank/root/data/varlib@2019-11-04-210000 >/dev/null
<infinisil>
And swap the -I with -i to get the amount of data for a big step
<elvishjerricco>
Also, Firefox is a bitch on your home directory if you take snapshots every five minutes. You'll be sending many pointless megabytes to your backup server that will soon be deleted if you backup every 5min
<infinisil>
(assuming you have a bunch of small snaps inbetween)
<infinisil>
elvishjerricco: Yeah noticing that too..
<elvishjerricco>
It's not bad in the long term, hence daily sends being good. But short term is really thrashy
<gchristensen>
I see ~1.6MiB/s sends from my 5m backups
<infinisil>
As a datapoint, doing -I with one day of snapshots (that never get deleted) gives me 3.8MB, with -i it's 1.1MB
<elvishjerricco>
gchristensen: What does transfer rate have to do with it?
<__monty__>
Ugh, why does everyone have so much bandwidth? Feels like we're stuck with dialup comparatively.
<infinisil>
Wait this is my /var/lib dataset, that's why it's so low
<gchristensen>
well I thought it'd be interesting since we're talking about how much we're sending
<gchristensen>
but you're right, it isn't really
<infinisil>
For home: 1.2GB without intermediate snaps, 3.7 with intermediate snaps
<__monty__>
Seemed relevant to me.
<elvishjerricco>
infinisil: Yea and it'd be more if you considered every 5min snapshot that's been deleted each hour or whatever you have set
<infinisil>
Actually that's the case for me right now because my destination is offline for a while
<infinisil>
That's about 200 snapshots inbetween
<elvishjerricco>
So over 3x the network usage and disk wear
<infinisil>
This was for 5min vs 1day snapshots though, it's probably gonna be a bit different for 5min vs 1hour
<infinisil>
But yeah, it can very much be significant
<elvishjerricco>
I need to get my jellyfin cache files off my backed up dataset. I bet that takes a tooon of space :P
<infinisil>
Another datapoint: 1 hour of 5 minutes intermediate snaps of /home gives me 124MB vs 249MB
<elvishjerricco>
zpool list
<elvishjerricco>
whoops. Thought I was in my terminal :P
<infinisil>
elvishjerricco: There was once a bug in a weechat plugin that lets any other irc user execute code as yourself..
<elvishjerricco>
Wow
<infinisil>
Or a weechat script rather
<infinisil>
(For weechat users, run `/script upgrade` to make sure you have a patched version)
<elvishjerricco>
infinisil: For the record, I just tested using `-i` instead of `-I` with `-R`, and it still did not send intermediate snaps, even with a child dataset that changed. So I was wrong when I said `-R` always sends intermediate ones
<infinisil>
Huh
<infinisil>
But -R specifically says "When received, all properties, snapshots, descendent file systems, and clones are preserved."
<elvishjerricco>
Maybe only when `-i` isn't specified?
<infinisil>
" If the -i or -I flags are used in conjunction with the -R flag, an incremental replication stream is generated. The current values of properties, and current snapshot and file system names are set when the stream is received. If the -F flag is spec‐"
<infinisil>
Hm
<infinisil>
Kind of unclear imo
<elvishjerricco>
infinisil: Yea, but experimentally, it's good :P
<elvishjerricco>
infinisil: That's what it looks like after making the data in `source` and doing `(sudo zfs send -R source@a | sudo zfs receive dest/source) & (sudo zfs send -R -i @a source@c | sudo zfs receive dest/source)`
<elvishjerricco>
s/&/&&/
<infinisil>
I'd expect the same with -I to also have @b
<elvishjerricco>
Probably. I can try
<infinisil>
Hm, would I want to use -R for backups? I'm not sure
<elvishjerricco>
infinisil: Yes, it does have @b
<elvishjerricco>
infinisil: It depends. In my case I'd like to
<infinisil>
I see nice
<infinisil>
Why so?
<infinisil>
I guess properties could be useful, mountpoints e.g.
<elvishjerricco>
I like having a bunch of different datasets to contain different data that I might want to delete at different times. Like each client gets its own dataset. I want it all backed up, but I want to be able to delete each client's data from my backups separately from each other and from the root
<infinisil>
descendent filesystems is kind of neat, no need to do each child filesystem on its own then
<elvishjerricco>
And yea, with an ever changing hierarchy of child datasets, it's nice to just use `-R`
<infinisil>
What's the deleting things separately got to do with -R though? Wouldn't -R make this harder because you can't delete a child filesystem on the destination?
<infinisil>
(since it would just get replicated again on the next backup)
<elvishjerricco>
infinisil: If all clients are on the same dataset, the only way to delete all backups of client A is to delete all backups of all clients. Give them separate datasets, and you can just delete that client's dataset from the backup
<infinisil>
elvishjerricco: Yeah, but with say the datasets clients/foo and clients/bar, you run `zfs send -R clients` and it would backup both foo and bar. But now when you delete foo on the destination, it would just get synced over again with the next send -R
<elvishjerricco>
infinisil: This is more about deleting foo EVERYWHERE
<infinisil>
Oh, so you mean deleting client/foo on the source host
<elvishjerricco>
The case you describe would actually raise an error, since it'd try to send an incremental backup of foo to a destination without its source
<infinisil>
And -R would sync over the deletion too
<infinisil>
Ah true dat
<elvishjerricco>
infinisil: Don't think -R deletes automatically without a separate flag, but I can also just delete it manually on the backup
<elvishjerricco>
This is just one example though. The general problem is: You can only delete things as granular-ly as you have divided them into datasets, when you're taking backups
<infinisil>
Yeah, I'm also using different datasets for different purposes
<infinisil>
Really useful :)
<elvishjerricco>
This is one area that Time Machine has us trumped. You can delete all backups of a file in a Time Machine. It's very nice. Relies on HFS though -_-
<infinisil>
Though I guess with tools like syncthing you can have that on a per-file basis even
<infinisil>
Hm that is neat..
<__monty__>
It doesn't work on AFS? Or is it APFS? Isn't apple moving to that?
<elvishjerricco>
__monty__: Your Time Machine backup disk MUST be HFS+, even if your local machine uses APFS. This is because Time Machine fundamentally relies on directory hard linking lol
<__monty__>
Hmm, when is Windows gonna move to a more ZFS like FS?
<__monty__>
TIL o.O
<elvishjerricco>
macOS used to use directory hard links a lot as well. They stopped so they could use APFS. Surprised they didn't just implement directory hard linking in APFS
<elvishjerricco>
Wonder if CoW file systems make that difficult or something
<infinisil>
Doesn't apfs has its own hardlink kind of thing?
<__monty__>
Aren't there issues with directory hardlinks? I know ln tries hard to stop you from doing that.
<elvishjerricco>
catalina added some firmlink thing but I have no idea what it is. And I think it has a version of reflinks as well, but that's more of a copy operation and only works on files
<elvishjerricco>
__monty__: They're not possible on most operating systems because they're logically insane :P Don't think ANY Linux FS supports it
<__monty__>
Wth, joepie91. Did you somehow tabbomb yourself?
<__monty__>
How do you even do this?
<joepie91>
__monty__: a few weeks of computer use since my most recent spring cleaning
<joepie91>
people never believe me when I tell them that the first thing that breaks on mice for me, is the middle mouse button, because I use it intensively to open and close tabs, more intensively than normal computer users
<joepie91>
well, here you have the evidence :P
<joepie91>
Chrome breaks at about 1000 - 1500, btw.
<joepie91>
Firefox can sorta mostly deal with it, though I usually need to restart it every few days or so
<joepie91>
as the UI starts becoming laggier due to something leaking somewhere
<infinisil>
Oh chrome is still not lazy in its tabs right?
<__monty__>
How do you even read 7k pages in a couple weeks?
<joepie91>
infinisil: not on Linux, I believe. but it's not actually that that breaks
<joepie91>
the UI just starts hanging at some point
<joepie91>
or used to, anyway, when I last used it before switching to FF
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 245 seconds]
<__monty__>
joepie91: Do you actually read even half of these pages? (I cannot deal with this level of productivity, so please say no.)
<joepie91>
__monty__: it's not just stuff I read. it's everything from articles to search/index things, to tweets, to youtube videos (incl. music), to google maps tabs, to company registers, etc.
<joepie91>
it's not like I have 7k extensive articles open :)
<__monty__>
But why keep all this open?
<joepie91>
but I have a habit of diving into a topic or thing, and going breadth-first
<joepie91>
__monty__: because bookmarks lose context
<joepie91>
tab position, relation to other tabs, browsing history, etc.
<joepie91>
tabs essentially function as contextual bookmarks to me
<__monty__>
I do depth-first but with a threshold where I start trying my hardest to reduce the number of tabs. I never let it get to 100. It's like my todo list. Doesn't work when I get over 30.
<joepie91>
this is why I've been waiting for some browser to start merging the two concepts
<__monty__>
joepie91: Wouldn't org-mode be a good way to organize all this in a permanent record?
<infinisil>
__monty__: Same, when I have too many tabs (maybe 100-200) I can't resist the urge to close all unnecessary crap
<joepie91>
I don't think the distinction between 'tab' and 'bookmark' is very useful
<joepie91>
__monty__: I'm not looking for a new editor :)
<__monty__>
infinisil: But I don't keep crap open. They're very much "READ THIS ASAP," most of the time.
<infinisil>
Well yeah me too, I only keep open what's *not* crap after the cleanup
drakonis has quit [Ping timeout: 246 seconds]
<joepie91>
__monty__: anyway, when researching something, I don't observe tab limits or anything. I just middle-click-open whatever looks relevant that I run into, and then work through tabs going left, closing them when done
<joepie91>
most of those tabs only have a minimal amount of relevant information
<__monty__>
I observe hardware limits mostly. I've never been able to work with 100 tabs. Old hardware.
<joepie91>
when you think of it as "7000 documents that have 2 relevant sentences, so 14k sentences read over several weeks", it's suddenly not that insane anymore :)
<joepie91>
I had that problem with chrome, but Firefox doesn't keep everything in memory constantly
<__monty__>
I guess we read different kinds of sources. I'm the kind of person that reads the article, the comments and then the comments on reddit and HN if applicable.
<joepie91>
Chrome capped out at about 1000-1500 tabs, that's when my RAM started getting full or the UI started locking up
<__monty__>
Never used chrome.
<__monty__>
FF uses like half my memory with ~20 tabs.
<joepie91>
__monty__: I mean, I do also read articles. but that's not most of my workload
<joepie91>
two typical examples:
<joepie91>
1) "hey, that company looks a bit weird and sketchy, let's see who they're actually owned by and what their history is" -> several hundred tabs of company registers, historical DNS/WHOIS data, forum threads, privacy policies, etc.
<joepie91>
2) someone in #Node.js asks about a problem with their code, I have no idea what causes it, but let's find out! 20 pastebins later (all kept open for reading-back and mental diffing purposes), a few Node.js docs / MDN reference pages, various forum threads and blog posts later....
<__monty__>
Ok, granted, that's not the kind of thing I ordinarily do.
<__monty__>
joepie91: But you then don't close these until a couple weeks later when you quit ff to erase them all?
<__monty__>
Looking for insight in this peculiar workflow.
<joepie91>
__monty__: when I finish investigating something, I usually close all the tabs afterwards. if I get distracted by something else halfway through, not so much :)
<joepie91>
and then unrelated tabs start getting interspersed with them and ohno.gif
<joepie91>
and then it all goes on the big Eventually pile
<joepie91>
and usually rotated out to my bookmarks, in whole
<joepie91>
(you can bookmark an entire window worth of tabs with a few clicks)
<joepie91>
and every once in a while, after it's been rotated out to bookmarks, I realize "hey I was looking at that thing a few weeks ago, where was I with that" and I can find some chunks of it again in my bookmarks
<joepie91>
the Actual Bookmarks, I assign tags to for finding later, and those tags get prioritized over page title etc., so the 'archived bookmarks' (the many many thousands of them) don't clutter up my address bar bookmark search
<joepie91>
I'm, uh, probably a good stresstest for several parts of a browser :D
<__monty__>
Are you looking for a new file manager? We could use more stress testing : >
<joepie91>
haha
<joepie91>
I don't stress my folesystem much unfortunately
<joepie91>
filesystem*
<joepie91>
"ingest tons of disparate data and distill it into something coherent" is something I spend a significant part of my time on, in a lot of contexts, and that's mostly focused around stuff on the web
<__monty__>
You sound like a member of bellingcat : )
<__monty__>
Ok, but did you quit FF to close all these tabs?
<joepie91>
__monty__: I'm not, but I have to admit when I first heard of them, I went "it me"
<joepie91>
they do seem to have a very similar approach
<joepie91>
__monty__: nah, I need to restart FF every few days because something in FF leaks and the UI starts slowing down and the main process starts pegging a core
<joepie91>
also, I've actually been working on some tooling to make these sort of investigations easier, for quite some time (it's been semi-shelved for most of that time)
<joepie91>
where 'quite some time' basically means 'since 2010'
<__monty__>
Have you ever talked to FF devs about these leaks?
<infinisil>
Reminds me of my own 20 semishelved miniprojects
<__monty__>
I only have 2 : )
<__monty__>
Well, 2 that I actually started.
<joepie91>
__monty__: nah. the FF bugtracker is a black hole, and I don't know where to find the right person to bother for some real-time debugging :)
<joepie91>
if you can find an FF dev who's interested in debugging things under this workload, I'd be happy to help
* joepie91
has a little more than 20 projects...
<joepie91>
anyway, the investigation-y one is not dissimilar in concept to Palantir's Gotham, though not as shit as Gotham
<elvishjerricco>
joepie91: I think there's a FF extension that lets you organize tabs hierarchally, if that's something you're interested in
<joepie91>
and more designed to be useful for grassroots stuff, not designed for intelligence agencies and corps
<joepie91>
elvishjerricco: tree tabs, I know, I've used it
* infinisil
kind of assumed joepie91 is using hierarchical tabs already
<joepie91>
it can't deal with my workload in the slightest
<joepie91>
plus I don't actually find it to improve anything for me
<joepie91>
it tracks the wrong information
<joepie91>
position + tab history is far more useful to me than tab origin
<joepie91>
and it slows down my browser to the point of unusable
<joepie91>
the thing is that most of the time I don't care how I got somewhere, I just care about how it relates to the things I currently have open
<joepie91>
it'd be handy to track tab origin/paths in the background, but it's certainly not something I want front-and-center in the UI
<joepie91>
TL;DR: I'm the XKCD 1172
<infinisil>
,xkcd 1172
<infinisil>
(I wish I implemented that)
<samueldr>
spacebar heater
<joepie91>
:P
<infinisil>
Ahh
<joepie91>
well, specifically, I was going for 'bizarre workflow', heh
<joepie91>
anyway, I realize that I'm a super super super edgecase, but I do think that I've gained some insights with that that can be ported back to make (browser) life better for non-crazy users
<joepie91>
eg. the merging of tabs and bookmarks as a concept
<__monty__>
joepie91: I don't really understand how you want to merge tabs/bookmarks? I wouldn't want bookmarking something to mean keeping an open tab of it.
<samueldr>
infinisil: use have i been pwnd directly, might be easier?
<samueldr>
haven't checked the integration though
<samueldr>
so it might be the same
<samueldr>
though if you control a domain, hibp will allow you to scan for the domain name
<infinisil>
Yeah would probably work for my older accounts where I use the same mail for everything
<joepie91>
__monty__: like, the specifics of merging bookmarks and tabs are going to involve a lot of nuance, of course. but terms like "open tab" don't necessarily make sense if you're going to change around the entire concept.
<infinisil>
samueldr: Oh neat
<joepie91>
__monty__: and it's my understanding that Firefox is actually already kinda sorta experimenting with this on Android, with their experimental 'sessions' thing, though I haven't used it
<samueldr>
have i been pwnd will also sent e-mails on new breaches
<samueldr>
including for a domain name
<elvishjerricco>
I've seriously been thinking about learning to use qutebrowser. The point and click nature is really getting on my nerves
<__monty__>
elvishjerricco: The vim-ish extensions don't cut it for you? Saka Key for example.
<elvishjerricco>
Never looked into those really
<elvishjerricco>
I should though
<elvishjerricco>
But qutebrowser is also just weirdly very fast :P
<__monty__>
They aren't as good as VimFx was but still better than nothing.
<__monty__>
How reliable is qutebrowser when it comes to security issues though? Is using webkit enough?
<__monty__>
For some background: pentadactyl and vimperator were pre-quantum addons for FF. They transformed the UI fairly radically. That's one approach, another is the approach shared by addons like vimFx and vimium (chrome). Those took a more light-handed approach. Not changing the UI but enhancing it with many of vim's idioms. Tridactyl is pentadactyl's successor in spirit if not in implementation.
<__monty__>
Just so you know what the choice is. Tridactyl will probably move in the direction of pentadactyl/vimperator whenever it can. If that's what you're looking for that's great ofc.
<infinisil>
Ah nice to know
<infinisil>
I really want to give trydactyl a proper shot, I only tried it really quickly for a PR once
<infinisil>
(which is how I heard about it)
<__monty__>
The reason I like Saka Key isn't the current state of the project btw. It's the motivation, which is *accessibility* rather than "vim-esque browser for people who like vim." Seems like a cool project to contribute to.
* infinisil
looks up saka key
<__monty__>
I bet tridactyl has some of the most knowledgeable contributors regarding vim browser behavior though.
<infinisil>
What I'd really like to have at some point is that I can be in full control of all keyboard shortcuts
<__monty__>
Yes please.
<infinisil>
Every program just exposes a generic set of actions you can interact with
<__monty__>
Though I think maybe Q/TMK keyboards may be the closest we can get?
<infinisil>
Each program should then also be able to assign some custom notions like "new", "save", "close", etc.
<infinisil>
Then you can assign a key to "new" globally and it would apply in every program
<infinisil>
One of the main problems I can see is that it's really hard to even write a compatibility layer for this
<infinisil>
Because there's no general way to control programs by sending literal actions, all of them listen to keyboard shortcuts
<infinisil>
Meaning a compatibility layer would have to emulate key presses, which is bound to give problems with different keyboard layouts and stuff
<infinisil>
Ignoring compatibility, one could probably use dbus to implement such a system
<__monty__>
I think it also needs to be more specific. Like Apple's HIG (HID?) means that ⌘n means "New *window*" pretty much in every application.
<__monty__>
Not just "New *something*".
<infinisil>
Hm yeah
<infinisil>
__monty__: Or maybe even with more structure: "New <object>" and the application exposes an enumeration of objects
<infinisil>
That actually sounds a lot like AppleScript now
<__monty__>
I'm happy I managed to get a Compose key working on macOS.
<__monty__>
Not gonna start thinking about mapping keys to applescripts based on active apps : )
<infinisil>
:P
<infinisil>
I wrote a couple of AppleScript scripts in my apple days, really useful
<infinisil>
I think I even used Swift's AppleScript interface to do some stuff
<infinisil>
I gotta say, I kind of miss these things
<infinisil>
__monty__: Oh btw, Karabiner is a great app for managing keyboard customizations of all kinds on macOS
<__monty__>
Yah, I use it for the "Compose" key.
<__monty__>
: )
<__monty__>
Karabiner-Elements now.
<infinisil>
Ahh :)
<__monty__>
Haven't been able to get it working when installed from a nix expression though.
<__monty__>
: /
<infinisil>
Ah that's unfortunate
<infinisil>
Alright ima head to bed, I'm heavily sleep deprived, good night :)