vika_nezrimaya has quit [Quit: ERC (IRC client for Emacs 26.3)]
slack1256 has joined #nixos-chat
slack1256 has quit [Remote host closed the connection]
LnL has quit [Ping timeout: 260 seconds]
LnL has joined #nixos-chat
<cole-h>
27849 store paths deleted, 75026.23 MiB freed
<cole-h>
Noice
<aleph->
Geez lol
waleee-cl has quit [Quit: Connection closed for inactivity]
<samueldr>
only?
<samueldr>
I've been waiting for a while for a garbage collection off spinning rust
aszlig has quit [Quit: Kerneling down for reboot NOW.]
<samueldr>
what I mean is that `nix-collect-garbage` has been working for a while, my disk is full
aszlig has joined #nixos-chat
endformationage has quit [Quit: WeeChat 2.6]
<srhb>
samueldr: Excited to hear the numbers :-P
<samueldr>
I expect >500GB
<samueldr>
oh, revise that, I expect >400GB
<srhb>
OK, was wondering what "a while" might mean. :P
<samueldr>
I forgot I loaned ~200GiB to something else
<samueldr>
the worst part is that it's a mechanical HDD
<srhb>
Yeah, that really makes a difference I expect. I don't think I've ever run Nix (for development) on spinning rust.
<srhb>
Only servers, and they rarely have a lot of generations on them.
<samueldr>
I really should get SSDs for that build machine
<samueldr>
but I'm such a cheapskate
<srhb>
Hehe, know the feeling. My only real builder is my laptop.
<samueldr>
it *was* running off of an SSD, but was too small, I was always collecting :)
<srhb>
I keep thinking of getting a dual purpose builder/desktop machine, but I'm too cheap.
<srhb>
Any specific drvs that take up all your space? I'm pretty surprised at how rarely I have to GC, but I might just be lucky with path-optimizable stuff.
<samueldr>
isos, sd images, systems for mobile nixos too
<samueldr>
all the big ones :)
<srhb>
Yeah, isos are horrible. :/
<samueldr>
it also ends up building everything for all my machines
<samueldr>
and it's been collecting for a few weeks
<MichaelRaskin>
But I gave up on NixOS mainline primarily because systemd does interfere with my workflows
<armin>
i personally find it pretty hard to maintain, too. man nix<TAB> will reveal 19 manpages starting with nix while man systemd<TAB> will have 180...
<armin>
i have a good feeling there are over 300 when i finished reading those 180.
<srk>
armin: man systemd.directives :)
<armin>
ah yeah, that sure as hell solves ALL problems :)
<srk>
just the 'where's this directive documented' :D
<armin>
:D
<armin>
good pointer still, thanks for that.
<srk>
I wanted to roll my own minimally systemd units compatible haskellish init but didn't quite get to that yet
<armin>
well i'd probably go with something more lightweight like runit.
<srk>
then I would need to add timers and other useful things :|
<armin>
but do you really have to? there's still cron which solved all our needs for decades.
<srk>
not really, it's just convenient
<srk>
and integrates nicely with services
<armin>
i mean talking about init, i prefer reading 200 lines of bash over 20 lines of systemd units any time.
<srk>
I don't :)
<srk>
this is one of the greatest things about systemd - unified service files
<armin>
well i usually like to understand what i read. :)
<srk>
so you don't have to maintain and ship various shell scripts for different distros
<armin>
i never really found that terrible to be honest, i like bash.
<__monty__>
Anyone who claims to understand 100+ lines of bash is suspect.
<srk>
:D
<armin>
oh i totally do.
<armin>
but yeah i admit it took me 20 years to get there. :)
<srk>
do you shellcheck your scripts?
<armin>
rarely as i disagree with most things shellcheck complains about.
<armin>
especially set -u
<armin>
(and others)
<armin>
i don't see much of a reason for it as i usually know what i'm doing.
<armin>
in fact, running shellcheck over my bashrc would probably give a huge list of complaints.
* srk
had to look up what set -u does
<srk>
yeah sure, it's not worth for every piece of bash
<armin>
will let your script go bonkers if you reference any unset variable.
<armin>
it will just teach un-experienced programmers wrong assumptions, that's not necessarily a good thing.
<armin>
some things shellcheck complains about are well thought about that i do.
<armin>
shellcheck won't tell you if the comment you put in your script simply makes no sense at all, either.
<armin>
also using -e is generally a pretty bad idea.
<armin>
if you want your script to bail out if something goes bonkers, check the return codes of what you run and don't rely on -e.
<srk>
yeah but that's tons of boilerplate :)
<srk>
depends..
<adisbladis>
Speaking of which
<srk>
if you don't check return codes -e is fine as without your script can really go bonkers :D
<armin>
not really, no. you can safely write that ONE time and source a library-like file in every one of your scripts, which for example the BSDs do.
<adisbladis>
How do you do -e for subshells?
<armin>
srk: it won't even tell you at what point it did that, it won't even give any meaningful error message whatsoever.
<adisbladis>
I'm super annoyed -e is not inherited by sub shells :/
<adisbladis>
It's not even possible to set it in the sub shell?
<srk>
hah
<srk>
Subshells spawned to execute command substitutions inherit the value of the -e option from the parent shell. When not in posix mode, bash clears the -e option in such subshells.
<srk>
armin: yeah, you need -x for that :D
<adisbladis>
srk: Even in posix mode `set -e; echo $(false)` doesn't bail out
<armin>
srk: exactly, and if i'm debugging with -x already anyways, being 100% respecting what shellcheck would complain about becomes a huge burden.
<adisbladis>
(man I really hate bash)
<adisbladis>
Or more specifically bourne/posix shells
<adisbladis>
srk: It _still_ doesn't bail out with inherit_errexit
<srk>
:((
<adisbladis>
srk: I tend to just go with Python for scripts
<makefu>
adisbladis: thanks for the picture! I think there is a silent minority of people who actually like systemd and what it provides. check out for example a recent hackernews comment chain: https://news.ycombinator.com/item?id=23028968 . people actually seem to be *gasp* happy
<hyperfekt>
drakonis: thanks for that link, as someone who only joined the linux world with systemd entrenched it gives some very helpful historical perspective
<adisbladis>
makefu: I absolutely love systemd :)
<srk>
same
<makefu>
i love that nixos embraces systemd and not try to work around it
<hyperfekt>
i unironically believe systemd is the best thing that happened to desktop linux lol
<hyperfekt>
after nix of course :b
<adisbladis>
hyperfekt: Nice save
<makefu>
;)
<adisbladis>
makefu: I think we're actually a majority
<adisbladis>
And that the systemd hater crowd is a vocal minority
<makefu>
actually i meant majority ... just typed the wrong thing
<adisbladis>
=)
<makefu>
i started https://old.reddit.com/r/systemdUltras/ and right now it still seems to be my personal blog, however i still hope that someday this changes :)
<hyperfekt>
i mean i am known to be a radical anyways so i'm used to people not sharing my opinions
<hyperfekt>
linux is bad, unix is bad, file systems are bad, statements are bad
<MichaelRaskin>
__monty__: I can understand 1000 lines of bash (in some styles)
<srk>
hyperfekt: last one :D .. lol
<srk>
today I'm closing terminals, on workspace 8 out of 25.. just few more hours to go /o\
<MichaelRaskin>
adisbladis: probably true, to dislike systemd one probably needs to not think perfectly aligned with the KDE/Gnome desktop approach.
<MichaelRaskin>
It's like IE5.5
<hyperfekt>
i wonder if we could adopt systemd for stage 1 and stage 2, just for uniformity. i haven't looked into why they aren't already
<sphalerite>
hyperfekt: mostly stalled on the minimal systemd PR I think
<hyperfekt>
oh nice
<makefu>
great stuff!
<srk>
++ withEfi ? stdenv.hostPlatform.isEfi <3
<hyperfekt>
can't wait for systemd on my phone lol
<qyliss>
It has been [2] weeks since systemd last broke my computer
<hyperfekt>
fair, but consider how much it does when it's not broken
<hyperfekt>
:b
<qyliss>
Too much
<MichaelRaskin>
qyliss++
<{^_^}>
qyliss's karma got increased to 57
<qyliss>
systemd as mechanism is fine. It does that pretty well. But it also makes a huge amount of hard-coded policy decisions for no good reason.
<MichaelRaskin>
hyperfekt: well, it has logging done in a way that is unfixably and forever broken for some cases, so…
<qyliss>
This doesn't fit well with the rest of NixOS, which generally tries to give policy decisions to the user where possible.
<hyperfekt>
MichaelRaskin: oh i'd like to read about this
<qyliss>
I'm a big fan of DynamicUser, parallel startup, etc
<qyliss>
But there's no reason for any of those to come with policy decided for me
<qyliss>
e.g. why does StateDirectory have to be in /var/lib? That doesn't personally affect me since I'd put it there anyway, but why enforce that at all?
<hyperfekt>
entirely possible, but i don't see us being able to replace it with remote feature parity any time soon.
<hyperfekt>
maybe we can maintain enough patches to make it amenable for our purposes?
<qyliss>
do we need feature parity?
<qyliss>
example: systemd has recently been inventing a lot of features that only work with btrfs. NixOS users as far as I can tell are near-universally using ext4 or ZFS, so we're clearly getting by fine without those
<MichaelRaskin>
Actually, for /nix/store I like BtrFS
<qyliss>
I doubt much systemd policy applies to /nix/store :P
<MichaelRaskin>
I would hope.
<qyliss>
I generally try to avoid even talking about this too much because people assume I want sysvinit
<hyperfekt>
btrfs features a good actually because they'll be nice and ready by the time we murder btrfs and set bcachefs in its place :b
<srk>
qyliss: and you want selinux? :D
<MichaelRaskin>
Fortunately I turned out not to need any service supervision at all, and config file generation from NixOS can be black-box reused, and I do not like the module system too much, so yep, mainline NixOS might even become applieance-or-webserver-only without anything I reuse from it getting broken
<aanderse>
qyliss: these are good (and interesting) questions
<aanderse>
i think the general idea is that we're trying to offload as much work to systemd as possible
<hyperfekt>
yeah, we have more important things to spend our time on.
<hyperfekt>
let's replace systemd when we rule the world
<{^_^}>
systemd/systemd#2913 (by oconnor663, 4 years ago, open): journald is unable to attribute messages incoming from processes that exited to their cgroup, due to /proc vs SCM_CREDS race
<qyliss>
It is possible to do large supervision systems well, btw.
<qyliss>
I'm not even opposed to that
<qyliss>
SMF on illumos is delightful
<makefu>
qyliss: regarding /var/lib as state directory, i am confident this can be changed on build time and nix gives you the power to utilize this
<MichaelRaskin>
hyperfekt: I have a plausible argument that having more flexible services that are easier to reuse on non-NixOS is _needed_ for world domination anyway
<MichaelRaskin>
(as a stepping stone from Nix-on-Ubuntu to NixOS)
<qyliss>
Anyway, turns out the features you need from a supervision system are extremely minimal when all you're supervising is a bunch of VMs
<hyperfekt>
oh interesting idea!!! i really like it MichaelRaskin
<qyliss>
So I'll be free of systemd soon enough :)
<MichaelRaskin>
hyperfekt: I normally refer to it «we might benefit from porting nix-darwin to Linux»
<qyliss>
I do find it interesting, though, how the conversation has turned from "systemd is the best thing ever" to "systemd is all we have"...
<hyperfekt>
this is actually a really good point, how much does NixOS NEED to be its own OS 🤔
<hyperfekt>
if people can switch piecemeal that's much better, and once they're transitioned they can do the last step and throw away the old distro
<MichaelRaskin>
qyliss: well, technically it doesn't really contradict one another, for a sufficiently grim point of view
<MichaelRaskin>
hyperfekt: I can serve as a case study if anyone is interested
<qyliss>
MichaelRaskin: lol good point
<MichaelRaskin>
NixOS as the last step is nice (if you like how it is done)
<hyperfekt>
qyliss: the view point is very much dependent on how much of what we systemd provides you want to have
<MichaelRaskin>
But it would be nice to consider it «I am doing _everything_ via Nix, now I can switch over the bootloader maybe?»
<makefu>
qyliss: actually the conversation started with "systemd is the worst thing ever"
<hyperfekt>
i think we should make non-nixos compatibility a goal of the inevitable 'service modules' rewrite
<qyliss>
makefu: you're right, I hadn't scrolled that far back
<hyperfekt>
so there's three big parts to nix services i'm aware of rn: running several of them, defining permissions for them, and running them anywhere. would suck to rewrite all our services thrice
<MichaelRaskin>
makefu: let me tie everything together. systemd is the best thing to happen to desktop Linux, and modern desktop is the worst thing to happen to computing.
<qyliss>
ooh I like that
<qyliss>
I'm stealing that.
<hyperfekt>
actually the problem is UNIX
<makefu>
i really like that discussions in #nixos* channels generally do not turn into flamewars but bring forth reasonable arguments
<qyliss>
flaming just doesn't really get you anywhere here, most of the time, from what I've seen
* hyperfekt
dons its armor for its crusade against backwards compatibility
<MichaelRaskin>
hyperfekt: nah, Unix has its problems and moving to Multics or Lisp Machine could be attractive, but appliancisation of desktop is levels of paradigm worse.
<MichaelRaskin>
(of course, Unix is best we have that has any kind of driver support)
<hyperfekt>
care to expound what you mean by the appliancisation?
<hyperfekt>
what i really want can probably best be described as antiauthoritarian urbit
<MichaelRaskin>
netfarm?
<MichaelRaskin>
Re: appliancisation: tools should work out of the box but the user has to always think inside the box.
<MichaelRaskin>
I guess for a hot take form, it would say «Tools that work out of the box but not outside the box»
<hyperfekt>
nothing works outside the box though. and depending on the box isn't bad because it solves problems
<qyliss>
I think we need a better box
<hyperfekt>
if we had infinite developer and maintainer time i'd agree with you
<hyperfekt>
yeah, i'm all for better boxes, always
<MichaelRaskin>
Well, the Unix way is that you have tools that are narrow enough that you can understand what they do, and they are explicitly for combining them in ways that were never planned before you
<MichaelRaskin>
Take the boxes and build your fort out of them
<hyperfekt>
wait i think you just abandoned our shared ad hoc box metaphor
<MichaelRaskin>
With the fort-building line? Yeah, could not resist a motto
<__monty__>
It's the UNIX approach to boxes.
<__monty__>
So it's brilliant, imo.
<hyperfekt>
MichaelRaskin: that's fake though. parts need to coordinate.
<__monty__>
Then again, MichaelRaskin claims to understand bash so he's suspect.
<hyperfekt>
really systemd is about keeping the unix way alive
<hyperfekt>
you wouldn't be complaining that the kernel is too integrated
<julm>
qyliss: what systemd features are you thinking to that only work with btrfs?
<MichaelRaskin>
It actually is, but that's where we have the most drivers
<qyliss>
julm: I saw one last week
<qyliss>
let me see if I can find it
<hyperfekt>
keeping the unix way alive in a world with increased demands on applications
<aanderse>
while i'm a fan of the approach of a large selection of small tools and combining them together i want to point out that each of those tools were written by a different author with different goals and ideas and there lacks conformity between those tools
<qyliss>
tmpfiles(7) has a lot of btrfs-only functionality, but that's not the btrfs-only feature I was thinking of
<aanderse>
which is fine for seasoned unix admins who have been using them forever
<aanderse>
it makes things complicated from an objective perspective, though
<qyliss>
aanderse: I think that's the only defense we have against monoliths enforcing policy
<aanderse>
qyliss: this is the other side of the coin... pros and cons to everything :)
<qyliss>
tmpfiles.d(7), sorry
<MichaelRaskin>
aanderse: I remember switching from ifconfig to ip. One does not really need to be using _the specific_ tools forever, the tools should just come from one of the familiar cultures
<__monty__>
hyperfekt: I don't see many applications that integrate with/rely on systemd tbh?
<qyliss>
julm: found it. machinectl snapshotting is btrfs-only
<hyperfekt>
you need monoliths to enforce policy though. otherwise we'd all still be loading programs into the core everytime the switch is flipped
<julm>
qyliss: thanks!
<aanderse>
MichaelRaskin: sure, familiar to those who have been using the tools forever
<MichaelRaskin>
hyperfekt: Linux kernel is pretty good at enforcing much less policy than a monolith of this size would be expected to
<qyliss>
hyperfekt: no, because you provide better mechanisms
<MichaelRaskin>
aanderse: the fact that people do not use _tools_ at all is exactly the problem in the first place!
<MichaelRaskin>
So in any case, we would not be loading programs, our scripts would be
<qyliss>
hyperfekt: expand the "you need monoliths" statement into general society a bit and see where you end up ;)
<hyperfekt>
monoliths have been responsible for crazy increases in living standards over the past couple hundred years
<__monty__>
Are we talking about governments or megacorps?
<qyliss>
for some fortunate people
<makefu>
politics, in my NixOS channel?
<adisbladis>
makefu: It's more likely than you think
<__monty__>
makefu: *Your* NixOS channel? We're giving it back to the *people*! : >
<makefu>
:D
<aanderse>
an interesting conversation for sure :)
<emily>
"SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to convince the PHB we should rewrite everything in Haskell." lol
<emily>
if only orange website commenters truly knew just how much PHB was within them
obadz has quit [Quit: WeeChat 2.8]
obadz has joined #nixos-chat
<makefu>
"orange website commenters", i like that. also i am looking forward to the n-gate summary of that post :)
<joepie91>
my garage is slowly beginning to look like an actual workshop
<drakonis>
those hn comments are pretty bad
<drakonis>
too many people set in the holy ways of unix
<MichaelRaskin>
eyJhb: there are things where one asks «may I please not rewrite it», and there are things where one asks «may I please rewrite it»
<makefu>
joepie91: parkside, best side
<ornxka>
the systemd war is interesting to me
<ornxka>
the pro-systemd guys go on about how bad sysv was, and the anti-systemd guys go on about how bad systemd is, and nobody actually makes any point about how either side is actually good and the best way to do things
<ornxka>
the attitudes involved seem to range from begrudging acceptance to milquetoast rejection (given that nobody seems motivated enough to write a replacement for systemd that solves all of the problems systemd solves)
<ornxka>
i wonder if init systems are just kind of inherently bad
<cole-h>
All software is inherently bad
<gchristensen>
you're too young to be appropriately bitter
<ornxka>
the only good programs a dead one
* ornxka
cock SIGKILL
<tokudan>
ornxka, well, people are actually talking about the good points, but since that doesn't enrage the "other side", the other side doesn't begin to discuss it and just chose to ignore it, as it's for an "irrelveant" piece of software from their point of view.
<sphalerite>
I think sinit is pretty good as a PID1, also bug free, but then you still need a service manager :p
<ornxka>
sinit has more lines of README + manual page than actual code lol
<sphalerite>
oh yeah, and one thing it can't do which you may need for a pid1 is to switch to a new root and exec something else
<ornxka>
cole-h: i think you are right although for maybe a different reason
<sphalerite>
but other than that it's pretty good
<ornxka>
most software cant be good in itself because you dont actually use the software itself to do something, you use it as a part of getting other things done and for something like an init system, the less you have to use it at all the better
<cole-h>
gchristensen: I was mostly being facetious, so you're probably right.
<gchristensen>
lol
<ornxka>
the ideal computing experience is one where you dont even need to know what an init system is
<ornxka>
good computing is a holistic experience where you just get things done without ever having to think about weird implementation details like pids or signals or orphaned processes or whatever
<ornxka>
something you should never even have to think about is never going to be "good" in a positive sense, only minimally negative/intrusive
<drakonis>
holistic experience?
<gchristensen>
ornxka: I agree
<ornxka>
holistic in the sense of "all-encompassing", or relating to a unified whole
<gchristensen>
the ipad fits that really well for my dad
<ornxka>
apple is good at that, although of course it comes with its limitations
<MichaelRaskin>
ornxka: do you understand just _how much_ trust such a degree of opaqueness requires?
<ornxka>
yes :p
<MichaelRaskin>
Even Apple is not there even with technical competence trust level.
<ornxka>
but you have to have it
<ornxka>
without it, the system becomes too big to easily understand
<MichaelRaskin>
Anything that gets that much _benevolence_ trust is immediately a bigger problem than whatever software was solving
<ornxka>
since you have to take into account the system as a whole, when really you just want to use the thing as a tool to get other things done
<joepie91>
makefu: very yes :P
<ornxka>
i dont think "trust" is the right word though
<ornxka>
i think you can subsitute it with "correctness"
<MichaelRaskin>
No, it is literally trust
<joepie91>
makefu: in all seriousness, like nearly 100% of my electrical tools is parkside
<ornxka>
if everything just worked, you wouldnt need trust
<MichaelRaskin>
NOPE
<ornxka>
you could just check the proofs, without ever having to understand the system they prove the properties of
<MichaelRaskin>
Because we are currently seeing like five simultaneous slow-motion stories where the definitions of «just working» are incompatible
<MichaelRaskin>
I mean, high-profile ones
<ornxka>
well obviously they dont "just work" then :p
<MichaelRaskin>
The definitions don't
<ornxka>
the video conferencing mess is pretty hilarious
<ornxka>
it turns out even money cant buy functioning software
<MichaelRaskin>
I mean, it can buy functioning software
<makefu>
joepie91: i think budget electric tools are absolutely fine for a private workshop. I also only have budget tools, shelling out 100+€ for any tool is just mad
<MichaelRaskin>
Exactly in the sense on which it was graded
<joepie91>
makefu: well, definitely when Parkside is an available option :P like, it's still a budget tool range for sure, but the price/quality ratio is *significantly* better than for the typical budget hardware store tools...
<MichaelRaskin>
And actually, _some_ of the Zoom stuff is literally trying to «just work» to the degree where it becomes literal malware. Sorry, I learned to Internet in 00s, this qualifies as literal malware.
<joepie91>
makefu: I personally really like the approach that revspace has to tool purchases
<joepie91>
buy the cheapo option first; if it breaks quickly, then apparently it gets used enough and isn't robust enough, so next time they buy the next step up
<joepie91>
turns out that there's only a few tools where you really need/want the more expensive option :P
<joepie91>
even for a hackerspace
<ornxka>
what i mean by "just works" isnt that you dont have to think about anything at all (although thats always nice)
<ornxka>
what i mean by it is that it lets you do what you want to do, with minimal intervention required
<cole-h>
For anybody interested in Fantasy, Brandon Sanderson is giving away Book 1 of The Stormlight Archive series, today only: https://ebookclub.tor.com/
<MichaelRaskin>
Yes, this is what I actively do not want
<sphalerite>
is sourceforge broken? Supertuxkart is downloading really slowly for me…
<MichaelRaskin>
Because it makes using software harder for me
<MichaelRaskin>
Because I actually know what I want, and of course to have such wishes one needs to have pretty exotic combo of knowledge.
<MichaelRaskin>
So I know that «with the minimum intervention required» all software with _any_ investment into friendly UI will do an obviously bogus thing
<ornxka>
i think thats a bit pessasmistic - i dont see any reason why "just works" cant be extended to every strata of computer user
<MichaelRaskin>
So give me the knobs. I guess about:config is nice in the sense that you can literally never go there if you do not know why go
<ornxka>
to me "just works" is where the knobs are in front and not inside the device where you need a special hex-screwdriver to open
<MichaelRaskin>
ornxka: Between Zoom and SELinux I do not believe in global and non-conflicting definition of «just works»
<ornxka>
has it ever actually been said that selinux "just works"...
<ornxka>
in any case, if it doesnt work for you, then it obviously doesnt "just works" :p
<MichaelRaskin>
ornxka: remember that all people need different subsets of knobs, and _some_ of the people — if you allow «ust works» to be said as a positive thing — need _fewer_ knobs visible
tokudan has quit [Remote host closed the connection]
<MichaelRaskin>
ornxka: SELinux just works at its original goal set by NSA, do detect the definitely-not-normal-humans who can reconfigure it easily.
<makefu>
joepie91: that is a great way to test. additionally you will have 1 year of guarantee and at discounters you can simply bring back the stuff and get the money back
<ornxka>
lol
<joepie91>
makefu: 3 years*
<joepie91>
for Parkside anyway
<MichaelRaskin>
But the point is that if you look at the definition of just works that Zoom installer follows, and definition of just works that SELinux _mission statement_ follows — these definitions cannot be fully implemented on the same system.
<joepie91>
makefu: and we usually order online from lidl-shop.nl for Parkside stuff, which has a 60-day return period :P
<joepie91>
which is pretty no-questions-asked, it seems
<__monty__>
ornxka: Re "nobody motivated to write a systemd replacement that solves everything systemd solves," that seems tautological. The people who like systemd aren't motivated to replace it. The people who don't like systemd disagree with the all-encompassingness so they would never be motivated to write a spiritual successor : )
<MichaelRaskin>
Lidl-shop a.k.a. the early access program?
tokudan has joined #nixos-chat
<joepie91>
MichaelRaskin: ?
<ornxka>
but basically i think the "apple experience" of not really having to think about uising software and just using it will some day extend over the whole possible range of computing activities, and not in a restrictive "keep things from people so they cant get confused by all the knobs" sense but in the sense that developers and powerusers too will be able to get their jobs done with the same ease that toddlers use iphones
<ornxka>
nobody actually wants to think about using their computer
<ornxka>
but when they do, they want even that to be as easy as possibble
<MichaelRaskin>
joepie91: I have heard (probably here, actually) that the products that get low return rate get a new run in different brand colours. (And the product with high return rate are analysed for «what went wrong»)
<joepie91>
MichaelRaskin: that was probably me, because that is indeed my working theory
<joepie91>
:P
<ornxka>
__monty__: i guess thats true
<MichaelRaskin>
ornxka: «nobody actually wants to think about using their computer» — isn't that measurably false?
<ornxka>
only as a hobby
<ornxka>
and even then, you shouldnt have to think about anything more than necessary
* joepie91
doesn't understand where this assumption seems to come from that "user-friendly" and "knobs to tweak" are opposites
<ornxka>
joepie91: to me, they are the same
<MichaelRaskin>
ornxka: yeah, that's how we got two classes of software. One class that you need to learn to understand, and the other that you actually need to learn to understand but you are actively impeded from doing it
<MichaelRaskin>
joepie91: from users who complain about extra knobs?
<joepie91>
well they aren't the same either, but user-friendliness considerations definitely are - or should be - a part of implementing knobs
<MichaelRaskin>
I mean Pidgin vs. Carrier split was not about quality. It was about actively incompatible values
<ornxka>
im not sure anybody actually does that
<ornxka>
i think people assume that people dont like too many options (and its true that if you want to do something and arent sure how, having lots of extra choices that you dont understand can be annoying), but i dont think that anybody would actually not use something because it had too many configuration options
<MichaelRaskin>
Are you making a statement about human preferences with a universal quantifier?
<ornxka>
yes
<MichaelRaskin>
I am not sure I can provide any example of such a statement that I can believe.
<MichaelRaskin>
Humans are different.
<ashkitten>
people were talking earlier about how they think systemd is better, i'm wondering if there would be active opposition to generifying default nixos services across multiple init systems using the common denominator features? assumedly you'd still be able to write systemd-specific services
<ashkitten>
this would be part of potentially porting nixos to other kernels, since systemd is unflinchingly linux specific
<MichaelRaskin>
I have no idea.
<joepie91>
the "common denominator" is incredibly tiny, IMO too tiny to actually be useful
* gchristensen
agrees
<joepie91>
if you want to actually support arbitrary init systems
<joepie91>
(considering that the least featureful init system is, conceptually, "run this pile of shell scripts upon boot")
<MichaelRaskin>
joepie91: current NixOS provides useful common-denominator functionality for most services that is compatible with any init system
<MichaelRaskin>
Yes, you can kick the evaluation in such a way to obtain a bunch of shell scripts
<ashkitten>
for most services you don't have to write the actual service script stuff yourself
<ashkitten>
many are already nixos modules
<MichaelRaskin>
Exactly, and in many of them «config + one-line start command» is all that there is of value
<ashkitten>
and common denominator probably refers to sysvinit specifically, which is more capable than some people think
<MichaelRaskin>
ashkitten: maybe bringing some BSD to be recognised as Tier-4 or even better Tier-3 platform could help
<MichaelRaskin>
Properly generated shell scripts with some minimal conventions are more capable than some people believe.
<ashkitten>
that would be good, yes. fwiw this isn't all just talk, and i don't have any sort of timeline but me and ky0ko are intending to do work on this issue ourselves
<MichaelRaskin>
It might be that you can get some support behind «we need nix-darwin but for Linux» — NixOS is a leap of faith, just install that one service from nix-services is a stepping stone
<cole-h>
ashkitten: Once you guys start, it would be cool to have a sort of tracking issue or something.
<joepie91>
additionally: the classic lowest-common-denominator-abstraction problem applies, which is that any abstraction with multiple backends which only exposes the lowest common denominator of features, is functionally equivalent to or worse than if the least featureful backend had just been hardcoded
<joepie91>
(more commonly seen in the various failed attempts at writing a single magical database abstraction library which "lets you switch out databases without changing code")
<ashkitten>
the thing is, i'm not saying you shouldn't write systemd specific things
<MichaelRaskin>
joepie91: consider filesystems
<ashkitten>
it's also very difficult for me to come up with a service you might write for a nixos module that would not be possible to write for any init system
<ashkitten>
i'm not about to come and break shit, either
<MichaelRaskin>
Some people want socket activation _and_ do not know how it was done the previous thirty years
<MichaelRaskin>
joepie91: DB abstraction layers (if done right) allow to write 95% of boring stuff in a portable way, and properly mark the last 5%, though.
<joepie91>
MichaelRaskin: emphasis on "only exposes the lowest common denominator of features"
<ashkitten>
i think you're missing the point
<MichaelRaskin>
Well, I think at no point anyone actually proposed to not give _any_ escape hatches.
<ashkitten>
like MichaelRaskin said, you can write the remaining 5% of things for each specific init system separately, if you can't do it portably
<ashkitten>
so the point is not restricting ourselves to the least featureful implementation, but to make it possible to write things like that if they don't need the specific capabilities of one
<joepie91>
no, I understand the point. I am just trying not to get caught into an hour-long discussion that I don't have the energy for tonight :)
<__monty__>
I know I kinda miss that escape hatch in the current module system.
<__monty__>
You can either stick to what a module provides for you or you can not use the module at all and manually specify the necessary services and timers and packages.
<ashkitten>
you can technically override the services the module provides but it gets messy
<__monty__>
You can refactor the module of course but it felt awfully silly to add a bunch of "systemdDirective = mkOption blahblah".
<MichaelRaskin>
I also like self:super: and overrides in Nixpkgs (so when I gave up on NixOS mainline, that's how I structure my system)
<__monty__>
MichaelRaskin: You mean for your module system equivalent?
<__monty__>
ashkitten: Can you override just a couple directives? Cause that sounds like what I want.
<MichaelRaskin>
It's like with systemd. It's not an equivalent, it's just what brings together service scripts.
<__monty__>
s/equivalent/alternative then?
<MichaelRaskin>
Yes, I guess so
<ashkitten>
__monty__: yes, if you read the source code of the module it just sets things like `systemd.service.foo.blah`, you can also set `systemd.service.foo.blah` and override it
<__monty__>
Right, that would've worked. Though it kinda feels like configuring things in multiple places, which nixos is so good at avoiding. Would also be nice if you could make changes at a higher level of abstraction, for all the services generated by a module for example.
<ashkitten>
yeah
<MichaelRaskin>
Well, with overlay-like structure it might be easier to achieve
<MichaelRaskin>
Of course, that would require a rethinking of options.html on a larger scale than typical module system polishing
<__monty__>
Is that for the module documentation?
<MichaelRaskin>
Well, this is extracted from modules
<eyJhb>
joepie91: how big of a space do you have?
<samueldr>
oh, speaking of space (unrelated) I didn't run it with `time`, so I don't know how long it really took once I went to bed
<samueldr>
35483 store paths deleted, 432571.15 MiB freed
<samueldr>
srhb: ^
<srhb>
samueldr: That ain't nothing ^_^
clever has quit [Ping timeout: 265 seconds]
<cole-h>
samueldr: Your initial estimate was wrong, but your revised estimate was correct.
<samueldr>
yep, with my initial estimate I didn't account for the 200GiB that *other thing* was taking
<cole-h>
👀
<sphalerite>
Pirated movie collection? Mobile-nixos trade secrets? Linux distro ISO torrents? We will never know.
<gchristensen>
with the rate at which nixos produces install ISOs it could easily be 200gib
<sphalerite>
except they're not worth torrenting
<samueldr>
I think most of my store cruft was isos, sd images, and misc. mobile nixos big files :)
<samueldr>
but no, less mundane, more annoying, lineageOS build
<sphalerite>
ooooh fun
<samueldr>
"fun"
<samueldr>
the way it's all non-pure makes me shiver
<samueldr>
and it's so much more involved to work with porting than it is Mobile NixOS... somehow
<samueldr>
if they thought NixOS had a documentation problem... they haven't tried to figure out where to start looking for docs about LineageOS and its everythings
<drakonis>
woooooow
<samueldr>
wow?
<drakonis>
you freed up as much space as my entire nix partition
<drakonis>
and i'm surprised at lineageos having bad docs
<drakonis>
but then that explains why the ports are so scarce
<joepie91>
eyJhb: 1 roughly car-sized garage plus change :P
<adisbladis>
samueldr: I think Nix/NixOS has a documentation problem
<adisbladis>
It's not that we don't have docs
<samueldr>
(I was being mostly fascetious)
<adisbladis>
It's a bit of a needle in a haystack ;)
<adisbladis>
samueldr: I understand
<adisbladis>
:)
<samueldr>
(I certainly didn't want to bring up docs in the offtopic channel... again...) :)
<cole-h>
Speaking of docs, is it <code>binary</code> or <literal>binary</literal>?
<joepie91>
eyJhb: (as a workshop space, I mean. I also have a "bedroom" dedicated to electronics stuff, although currently it is the sorting-my-boxes-of-crap room)
<joepie91>
frame for tool wall has been installed \o/ or well, sorta anyway...
<joepie91>
one part is too far from the wall, need to fix that
<eyJhb>
We are currently living two people in the apartment I sent you joepie91. I want to have a propper shop, atm. I just have all the tools under my desk
<joepie91>
ah yeah that's tiny :P
<joepie91>
the size of my house is about normal for a 'real' house (ie. not apartment in block), which was a requirement for me for noise reasons
<eyJhb>
38 m^2 is not much yeah.. - Did you just aquire it?
<joepie91>
eyJhb: moved here in december of last year
<joepie91>
only got around to the workshop recently :P
<joepie91>
and I kinda need it now that I want to build raised garden beds
<joepie91>
eyJhb: btw, actual pics of my house, prior to moving in most of my stuff: https://imgur.com/a/oN2r4KI
<joepie91>
also of the garden :P
<eyJhb>
How I dream about getting done with my education and start having money. Then again, getting paid to study and having a car isn't that bad
<eyJhb>
MichaelRaskin: that is still quite impressive I would say :D
<joepie91>
they're now also quite a bit taller
<MichaelRaskin>
Compared to that, I almost speak German… (because in German and in French I don't need to hit anywhere close to any of the correct pronounciations)
<MichaelRaskin>
From reading point of view Danish is simpler than German, I think.
<joepie91>
anyway, time for a bath and then sleep :D
<eyJhb>
MichaelRaskin: Hmm... But that might be because we have borrowed a lot of words from english as well
<MichaelRaskin>
Not really. But you have a pretty simple grammar which also happens to be in line with general western-European grammars
<MichaelRaskin>
German is all «nice word you have learnt, would be a shame if we broke it up and shoved the pieces in the different ends of the sentence»
MichaelRaskin has quit [Ping timeout: 256 seconds]
<joepie91>
eyJhb: that doesn't make vegetables! :P
MichaelRaskin has joined #nixos-chat
parsley936 has quit [Remote host closed the connection]