<sphalerite>
gchristensen: I didn't see your commends about packageOverrides in #nixos-dev, when was that?
<sphalerite>
the "I don't like overlays" thing?
<andi->
gchristensen: WHY qmail?
<sphalerite>
LnL gchristensen MichaelRaskin: The reason I want to get rid of packageOverrides is that it doesn't provide any additional value beyond what overlays give us, at the cost of confusing pretty much everyone new to nixpkgs
<sphalerite>
I also wasn't aiming to remove it for 18.09, only deprecate it, then remove it in 19.03 maybe
<srk>
+1 :) /me was confused bout that as well
<sphalerite>
and the problem is sort of self-perpetuating because people keep using it and writing new documentation using it
<sphalerite>
or advising newbies to use it
<sphalerite>
The confusion being compounded of course by the triple meaning of the word "override" in nixpkgs.
<srk>
I want a garbage collector for my browser tabs :(
<andi->
is there any (other) technical reason to remove it? Is it somewhat less "good" then overlays? I have exactly one packageOverrides line in my configurations. That one line could as well be an overlay...
<andi->
srk: watch -n 3600 pkill -9 firefox
<srk>
:D
<srk>
at home I'm using killall -STOP firefox to stop the fan during night :D
<sphalerite>
andi-: no technical reason, just the support reason
<andi->
I do kill my browsers whenever I think it's getting too big. I am also hugly betting on the history of firefox and my syncserver..
<andi->
I am not concerned about "forgetting" about a page.
<sphalerite>
it is less "good" than overlays because it doesn't have the self, so it doesn't compose nicely with overlays (or with anything really)
<sphalerite>
otherwise overlays wouldn't exist ;)
<andi->
sphalerite: ok, so I thought :) I think it is a valid reason not sure if anyone has good points against that. Maybe one could make packageOverrides be there only overlay for the transition period?
<andi->
I also didn't find the comments graham talked about. At least not within a few screen sizes of scrollback buffer
<sphalerite>
andi-: packageOverrides is already implemented as an overlay
<LnL>
sphalerit: those are definitely valid points, but not breaking people's configuration every 6 months is also very important IMHO
<sphalerite>
LnL: the point of periodic releases is to give a fixed point in time at which people may expect their config to break and have clear documentation (the release notes) on what will break.
<sphalerite>
LnL: Pretty much all releases of nixos have had breaking changes.
<sphalerite>
These breaking changes are of course not for the sake of breaking people's configs, but for making improvements. And removing packageOverrides is an improvement.
<sphalerite>
additionally, a deprecation warning like this is actually warning people 6 months in advance that their config will break, as opposed to just breaking it outright.
<ldlework>
anyone got some recommendations for sniffing your own traffic
<sphalerite>
LnL: also, comments on the issue/PR would be appreciated as they're a bit more permanent and globally visible
<sphalerite>
ldlework: wireshark
<sphalerite>
ldlework: or tcpdump
<ldlework>
i'm getting that google thing where it forces you to do a robot recaptcha just for using google.com
<ldlework>
because i am supposedly sending them strange traffic
<andi->
ldlework: definitly tcpdump as close to the edge of your network (or wherever that IP terminates) as possible
<ldlework>
i think i figured it out by process of elimination of turning off connected devices
<ldlework>
fairly sure it is my ipad
Guanin has quit [Quit: Leaving]
<ldlework>
sphalerite: andi- what if it is my iphone/ipad which causes it while it is connected to the wifi
<ldlework>
how can i sniff the traffic of arbitrary devices
<sphalerite>
ldlework: use tcpdump on the gateway
<sphalerite>
if you don't have a gateway that lets you run whatever you want on it, get a different gateway I guess? :p
<ldlework>
i just have some netgear thing
<ldlework>
i actually wrote a management suite for microtik routers early in my career
<ldlework>
those were nice
<andi->
Ask apple for root access to your iPad.. (It is yours after all)
<ldlework>
tcpdump is pretty nifty
etu has joined #nixos-chat
<sphalerite>
andi-: yes! :D
<gchristensen>
sphalerite: it is important to think about how much effort people will go through to upgrade. we don't want someone stuck on an old release just because we thought it'd be cool to delete something, that is the worst possible case
<gchristensen>
but it is true, I don't like overlays
<sphalerite>
IMHO: removing one of the (many) stumbling blocks for new users is more important than that.
<sphalerite>
but you do like packageOverrides?
<gchristensen>
I do
<sphalerite>
why?
<sphalerite>
I didn't get that from the #nixos-dev discussion
<gchristensen>
it is less powerful
<gchristensen>
tbh I think overlays are better for users, and removing a confusing stumbling block is valuable to me
<sphalerite>
you like it because it's sless powerful? or…
<gchristensen>
yes
<gchristensen>
I just ... man, wow, I really get skeeved out by people adding random overlays from the internet
<sphalerite>
haha
<gchristensen>
they're _so_ powerful
<gchristensen>
it is practically safe to add a packageOverride for a weird app you want to install and reference a nix expr from the internet, but unsafe to do it with an overlay
<sphalerit>
I don't see how
<gchristensen>
with package overlays I control your scope at inclusion tim
<gchristensen>
with package overrides* I control your scope at inclusion time
<gchristensen>
with overlays if I fetch an overlay and shove it in I have no control over that overlay's scope
<sphalerit>
If I wanted to do nasty things to someone's computer I could just as well write a malicious expression that has a high priority and includes a replacement bash or something
<gchristensen>
so I'm forced to bloat my evaluation time and memory by doing my own overlay, self: super: { youroverlay = import <nixpkgs> { overlays = [ ... ]; }; }
<gchristensen>
andi-: re why qmail: b/c I'm an noob :)
<sphalerite>
hm right
<sphalerite>
I see your point
<sphalerite>
it's not really against overlays in principle though, more against using arbitrary overlays I guess
<sphalerite>
overlays I've written mostly look like `{ foo = super.callPackage ./foo; }`, and there's nothing to stop anyone from writing their own overlays along those lines instead of using whatever I've written
<sphalerite>
but yeah nesting pkgs with different overlay sets isn't nice
<LnL>
gchristensen: there's not really a difference between overrides and overlays in that respect, except that overlays are easier to distribute
<sphalerite>
I guess one could also use arbitrary 3rd-party overlays while limiting their scope by doing something like self: super: {inherit (import ./some-overlay.nix self super) foo bar baz; }
<sphalerite>
although that might break the overlay's own expectations
<sphalerite>
LnL: but by being more powerful in that way it does enable more bad practice than is possible without
<sphalerite>
it makes shooting yourself or other people in the foot easier.
<LnL>
it's not really more powerful tho
<LnL>
packageOverrides literally is an overlay
<sphalerite>
an overlay where self is hidden
<gchristensen>
yes but _I_ have the power, and I'm not granting arbitrary amounts of power to third party code
<sphalerite>
in that case I guess the way to go is having just the one overlay which you write and maintain yourself :)
<sphalerite>
*that* is no different from packageOverrides
<LnL>
you can download a config.nix just the same
<gchristensen>
and in order to use these overlays which are easier to distribute, I have to import a brand new copy of nixpkgs and pay that whole cost again
<gchristensen>
*if I don't want to grant them all that power
<sphalerite>
LnL: but people don't make config.nixs available because you can only use one at a time
<gchristensen>
but I suggest the ease of overlays means people don't think about the power they're granting, whereas with packageOverrides it is explicit
<gchristensen>
its not cool that the mozilla firefox overlay could get pwn'd on github and override `pass` and then steal my credentials
<sphalerite>
you don't need to override pass to steal your pass credentials though, a completely unrelated malicious package can just as well provide bin/pass
<gchristensen>
you're right, *gives up on software*
<gchristensen>
computers suck :P
<sphalerite>
well that's not my point :D I just think that adding overlays you haven't inspected isn't really any worse than installing packages you haven't looked at
<gchristensen>
yeah
<gchristensen>
you're right
<gchristensen>
let's no longer use PATH and only use direct store path references :)
<andi->
you guys invoke `pass` from the shell as part of the system packages? o.O I have an i3 binding that picks pass out of the derivation and launches a shell with that.. But the argument is still true for any overlay. I think adding overlays to the root scope is bad. At the present date I would use packageOverrides (or an overlay...) that just introduces one attribute which would be the contents of an
<andi->
overlay..
<sphalerite>
as gchristensen said that's not great for evaluation time
<andi->
ah
<gchristensen>
someone should write docs on safety considerations around overlays
<gchristensen>
I said that wrong
<gchristensen>
it would be good if there were docs on overlay safety considerations, maybe I'll write some
<andi->
mhm, the "automated" package bumps should probably also look into "new" conflicts with other binaries.. The more I think about it the more scared I get..
<andi->
Since we figured reading changelogs isn't going to happen...
<sphalerite>
maybe we should just move to piggybacking everything off debian :p
<etu>
Make a wrapper buildDebianPackage and pull in the deb :p
<andi->
I think we have fetchDeb already?
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-chat
<manveru>
jup, it's used for the steamOS chroot afaicr
<MichaelRaskin>
sphalerite: I can have a single nixpkgs override list, and install different packages to different layers of trust; that way that extra binary will be in a circle which gets superseded by more trusted packages (installed by attribute name, of course).
<MichaelRaskin>
With overlays there is a need to literally have different sets of overlays
obadz has quit [Ping timeout: 244 seconds]
obadz has joined #nixos-chat
sir_guy_carleton has joined #nixos-chat
__Sander__ has quit [Ping timeout: 276 seconds]
__Sander__ has joined #nixos-chat
Sonarpulse has quit [Ping timeout: 276 seconds]
jtojnar has joined #nixos-chat
Sonarpulse has joined #nixos-chat
__Sander__ has quit [Quit: Konversation terminated!]
<infinisil>
RIP github, didn't take long for microsoft to take it down lol, I hope y'all got your backups!
<infinisil>
(jk, mostly)
<maurer>
infinisil: As much as I dislike MSFT and am worreid about what they'll do to github, they don't even own it yet
<maurer>
that doesn't happen for several months
<infinisil>
Oh I see heh
<MichaelRaskin>
Well, they ruined Nokia just well before owning it
<samueldr>
if you scroll up a tiny bit, you can see "From January 2008 to September 2010, Elop worked for Microsoft as the head of the Business Division, responsible for the Microsoft Office and Microsoft Dynamics line of products, and as a member of the company's senior leadership team"
<MichaelRaskin>
Well, by the time Elop (freshly ex-MS employee) became CEO of Nokia, Symbian was morphing into an open-source smart enough OS, ate featurephones at a rate larger than all other app-supporting platforms together, Nokia _also_ had Maemo (GNU/Linux/X11-based OS for full-power handheld computers) and was dominant in all segments.
<samueldr>
I was a maemo user, and even its early revisions were awesome when compared to other "smart" mobile operating systems
<samueldr>
(well, it wasn't really one!)
<samueldr>
(also had a s40 device a bit before, and for a featurephone os, it felt so much better)
<MichaelRaskin>
Yeah, in 2010 I had full-powered LibreOffice on a handheld with real keyboard.
<samueldr>
:( never got a 810, and the n900 couldn't work on two-thirds of telco providers here
<MichaelRaskin>
Unlike all the Android crap, Nxxx could actually control Nokia (and other) featurephones over bluetooth…
<MichaelRaskin>
N810 just didn't have GSM module
<samueldr>
yeah, only starting with the n900 they moved to being a phone
<samueldr>
before it was an MID
<samueldr>
that class of hardware that really didn't last long
<MichaelRaskin>
All-Nokia bluetooth kit of N810 + featurephone + headset was probably still better mobile experience than anything afterwards
<infinisil>
I see
<MichaelRaskin>
samueldr: oh well, if you don't include pure PDAs on Windown Mobile as a part of the same class, just earlier and worse done
<samueldr>
hmm, it's a hard thing to gauge, the market *segment* wasn't the same, even though hardware implementation was similar
<MichaelRaskin>
I have no idea what _was_ the market segment of Nxxx. Nokia seemed to want to fail to sell them in most places. Failed at failing, probably. Needed a full Elop to kill the line.
<samueldr>
AFAIUI, it was "trying to be an iPad", a bit too soon, with some media capabilities, and full internet browsing
<samueldr>
(they did call then "internet tablets")
<MichaelRaskin>
Fun story from Nokia-mono-brand store in Moscow: when I asked about N810 they started by warning me that Windows Mobile applications do not work there.
<samueldr>
hah, though understandable
<MichaelRaskin>
I said that that was more or less the reason for my interest. Then I poked around a bit and asked how to find terminal (it was in some fun part of the menu).
<MichaelRaskin>
The answer was that he had zero idea what should and what should not work in Terminal, but he was told this question will come up and this is how to find the menu item.
<MichaelRaskin>
That actually impressed me as sane approach to service: give what people will want to see with minimal time spent on training.
<gchristensen>
infinisil: it is cool that github so quickly put together and launched such a good status page for their first-ever production outage
<samueldr>
?!?
<infinisil>
gchristensen: Wouldn't the status page always have been there?
<gchristensen>
oh :)
<MichaelRaskin>
I also think it is not the first outage
<gchristensen>
oh :)
matthewbauer has joined #nixos-chat
<andi->
GitHub has been done a few times.. It is not as rare as a google (search) outage ;-)
sir_guy_carleton has quit [Quit: WeeChat 2.0]
<samueldr>
hmmm, while most of nix is already tested for case sensitivity because of other platforms, I wonder what would break using this on macOS https://worthdoingbadly.com/casesensitive-iossim/
<samueldr>
(I don't have a macOS machine readily available to play around)
Lisanna has quit [Quit: Lisanna]
pie___ has joined #nixos-chat
pie__ has quit [Ping timeout: 260 seconds]
Lisanna has joined #nixos-chat
<matthewbauer>
samueldr: that might be useful for certain derivations. having a bashCaseSensitive binary might be useful
<matthewbauer>
but it's also nice to find things that do not support case sensitive.
<matthewbauer>
you can actually make your Linux drive case insensitive IIRC
<andi->
At some point I'll rewrite that firewall module.. It is so limiting and the extra commands aren't really nice :/
<infinisil>
andi-: You could do a DSL for specifying all ip config via Nix values :o
<andi->
I was thinking about providin a few more primitives via some config options.
<andi->
like at least rules (ordered) that match src/dst ip/port & protocols
<andi->
that would probably already solve 90% of my use-cases
<andi->
I would also like to be able to have it agnostic of iptables/nft etc..
matthewbauer has quit [Ping timeout: 240 seconds]
jtojnar has quit [Read error: Connection reset by peer]