IRC channel logs


back to list of logs

<joshuaBPMan>hello, how do I install lspci?
<joshuaBPMan>'s installed
<geemili>I'm trying to run `guix pull`, but it can't find guile-git
<geemili>Wait, nvm
<geemili>Apparently, getting on the IRC is enough to fix it ;P
<geemili>I hadn't exported the guile load path
<sadiq[m]>Hi. I now always get " No space left on device" error on installing any package. my / partition has 7.0 GiB free. Where should I look for hints?
<sadiq[m]>hm.. I get no space left error when downloading files via icecat too. But df -h / says I have 7.0 GiB available
<sadiq[m]>hm.. df -i says 100% for /. So inode is full.
***Piece_Maker is now known as Acou_Bass
<sadiq[m]>hm.. I think it would be better to add mkfs.ext4 -T news (or something like that) in the installation manual, because the high amount of small files and symbolic links shouldn't fill in the inode space
<sadiq[m]>news uses one inode every 4KiB, 1 inode every 8KiB would be enough I hope (rather than the default 1 inode every 16 KiB)
<Apteryx>Can the builder exp of a build-system (such as trivial-build-system) be a gexp? (formed with ~$(...)?)
<efraim>AFAIK not yet, but it might work if you import (guix? gexps)
<Apteryx>I'll try and see :)
<sadiq[m]>Will guix 0.14 be released any time soon? I ran out of space and I need to do a fresh install
<Apteryx>Why do we have to call (mkdir #$output) in gexps? isn't that directory created by default? If not, why? It's boring to see this everywhere.
<efraim>if you're using the trivial build system then nothing is done by default
<efraim>ng0_: i'm trying a test build-out of your mate-additions branch for fun, can't build atril since clisp doesn't currently build on aarch64
<Apteryx>efraim: I see. Maybe we could do one thing in the trivial-build-system (create the output dir)... Otherwise there's no point, unless I'm missing something?
<efraim>i think the output dir is the minimum required for a "successful build"
<efraim>maybe send it as an idea to guix-devel
<rekado>sadiq[m]: have you tried garbage collection?
<rekado>sadiq[m]: you can unlink all previous profile generations and then run “guix gc”
<Apteryx>efraim: It doesn't seem to work, unless I'm doing something wrong. I'll send my example to guix-devel.
<Apteryx>Possibly the compiler hook to lower the gexp into something tangible is missing as I'm seing stuff #<gexp-output out> in the builder.drv
<Apteryx>I would expect an absolute path there instead.
<sadiq[m]>rekado: yup. The problem is with inode space. I submitted a patch for doc regarding that:
<efraim>starting with kernel 4.12(?) the kernel devs/ext4 devs have increased the default number inodes with a flag
<Apteryx>Is it safe to attach a magit diff buffer as a patch? It's just for demonstration purpose.
<sadiq[m]>is it okay to rm -rf /var/log/guix ?
<efraim>i think those are the build logs, so it should probably be ok
<sadiq[m]>also /var/guix/substitute/cache ?
<efraim>the cache won't save much space
<efraim>clearing it also makes you re-get the substitutes available, which is good if you've cached a bad entry
<sadiq[m]>efraim: I need to claim as much inodes I can. the cache contains around 1100 files
<efraim>then yeah, i'd try clearing the cache
<efraim>you could also mount the cache as a tmpfs
<efraim>are you on guixsd or a foreign distro?
<sadiq[m]>on guixSD
<sadiq[m]>hm.. seems like guix gc isn't deleting many of the unused dirs. I see 11 directories the point to xxx-gnome-todo-3.26.1
<sadiq[m]>in /gnu/store
<rekado>are they still referenced somewhere? are they installed to a profile?
<janneke>rekado: just got round to watching your #bootstrapple ghm video
<janneke>very good story and presentation, well done!
<rekado>janneke: thank you :)
<sadiq[m]>rekado: I did do many guix build gnome-todo, but may have installed only once/twice. How can I see if they are referenced somewhere?
<rekado>sadiq[m]: you can also delete store items directly with “guix gc -d /gnu/store/the-thing”
<sadiq[m]>rekado: if it is referenced by my profile (or some other packages), will it be deleted?
<sadiq[m]>hm.. it says 'still alive'. can I poison it to death?
<ng0_>efraim: atril depends somewhere on clisp?
<sneek>ng0_, you have 4 messages.
<sneek>ng0_, lfam says: It's after the end of world, don't you know that yet? <>
<sneek>ng0_, sirgazil says: regarding Guix website, have you tried building the wip-website-update branch? The "guix.scm" file was renamed to "build.scm". Maybe that change is related to the errors you're seeing?
<sneek>ng0_, sirgazil says: FWIW, while working on the website update, I couldn't create an environment either, and had to install packages by hand. Also had to rename the "guix.scm" file to something else; otherwise, importing the guix package installed with guix would not work well.
<sneek>ng0_, lfam says: No spoilers, please ;)
<efraim>atril depends on uglify-js
<ng0>there are 3 grave issues with the whole bunch of mate packages. 1) I want to build mate-screensaver with the lockscreen. I need too debug how we can get it to not log you out forever. this should probably be optional, in other words not in 'mate' or added to a mate-service. 2) and 3) not grave issues, but requests I reported upstream.
<ng0>2 and 3 is about caja and marco extensions/plugins. not a real issue, can certainly be worked out for anyone who has time to work on their code.
<civodul>Hello Guix!
<civodul>rekado: i've jused pushed an update of the 'cuirass' package, which fixes GIT_SSL_CAINFO handling (a problem that's currently preventing Cuirass from doing anything on berlin)
<civodul>could you do a reconfigure of berlin, or do you want me to do that?
<civodul>(also with the latest guix-maintenance.git)
<rekado>civodul: did I not fix the GIT_SSL_CAINFO problem weeks ago?
<rekado>or rather “worked around” that problem
<rekado>I ran a reconfigure on berlin about one week ago, but I haven’t been able to check yet
<rekado>I can’t access berlin right now, only through the serial console :-/
<rekado>IT must have changed the firewall rules again
<rekado>here we go, running guix pull on berlin now
<efraim>i feel like i'm missing something with my openssh-service, I have (service openssh-service-type) in my services list but the ports are all closed
<efraim>also the time on the computer is right, but displayed wrong in xfce
<ng0>In my opionin this is the right way to proceed on the screensaver issue: Add mate-desktop-service as a service (for some polkit things). Remove mate-screensaver from package 'mate'. Test if it no longer breaks when added as package to in screensaver service.
<rekado>reconfiguring berlin now
<ng0>do we have notes somewhere on how to move the /gnu/store to another disk? I'll add one soon and wanted to just move the store to it
<efraim>cp -a
<ng0>oh. nothing special. okay, thanks
<rekado>this doesn’t retain hardlinks, though, does it?
<ng0>it's the same as -dR --preserve=all
<ng0>there's one option missing for links
<ng0>oh, no
<ng0>-d is --no-dereference --preserve=links
<ng0>efraim: are you testing towards GuixSD on armv8 with MATE or why are you interested in it?
<efraim>I build everything on armv8, it has more RAM and better storage than my other machines
<civodul>rekado: the code was mistaking $GIT_SSL_CAINFO for a directory, but it's a file
<rekado>oh, I see
<rekado>I asked IT to open SVN ports on the firewall; right now we can’t build the texlive stuff because that requires downloading from SVN.
<rekado>no response yet
<roptat>hi, I was wondering whether there was a way to set the fqdn in guixsd's configuration file?
<roptat>I'm using opensmtpd, and mails are being rejected because it uses "localhost" as its fqdn
<roptat>I tried to look for "fqdn" or "fully qualified" in the manual, but there doesn't seem to be anything about it
<roptat>one can change the fqdn used by opensmtpd by creating a file, but this file is "/gnu/store/...-opensmtpd-.../etc/mailname" on guix, it's read-only
<roptat>so I could fix that by adding my fqdn in /etc/hosts, just after "" and it works
<roptat>now I wonder, will it survive a reboot? Is there a way to do that declaratively?
<rekado>roptat: the operating-system configuration has a field “hosts-file”
<rekado>where you can specify a hosts file to be used
<Apteryx>hello guix!
<civodul>hey hey, hello Apteryx!
<Apteryx>Should I persist at using gexp inside a package definition? Or is this not ready for prime time yet?
<sadiq[m]>is there a way to add an environment to my profile so that guix gc won't delete those packages?
<amz3>civodul: basically, I have a debian stretch inside an lxc
<amz3>I installed the binary 0.13 guix
<amz3>I ran 'guix pull && guix package -u'
<amz3>It asked to update environment with some stuff to make guile-git work
<amz3>I did that
<amz3>then when guix package -u was finished I tried to install guile@2.2.2 but that failed with an error I don't remember what
<amz3>but now it works
<amz3>next time I will report the issue, it will be better engineering
<civodul>heh, np :-)
<civodul>sadiq[m]: you can add "packages" to your profile, but not "an environment"
<civodul>that said, environments created by "guix environment" can be registered as GC roots
<civodul>meaning they won't be GC'd
<civodul>see --root in
<sadiq[m]>hm.. what should be the content of file in guix environment -r file ?
<sadiq[m]>-l seems to explain that, nvm
<jonsger>how can I find out which formats are support in a command like "guix pack --format= .."?
<jonsger>so something like "guix pack --format=?"
<civodul>jonsger: explains it, but not --help
<civodul>we should fix that
<jonsger>civodul: I found it now. but something like "--format=?" would be very nice
<civodul>yes, agreed
<civodul>sadiq[m]: "-r FILE" will just create FILE as a symlink
<Apteryx>anyway to tell Emacs to ignore .go files when C-x C-f (find-file)?
<Apteryx>Since ido is on by default, I think this variable should do the trick: ido-ignore-files
<Apteryx>Luckily I don't develop in the Go language ;)
<rekado>Apteryx: projectile-find-file ignores files that are not tracked
<rekado>I have all projectile things bound to C-c p; projectile-find-file is C-c p f
<rekado>civodul: berlin is reconfigured
<rekado>I just put six new servers on the rack; will try to install them over the weekend
<Apteryx>rekado: thanks for the suggestion!
<Apteryx>rekado: projectile doesn't seem preinstalled in Emacs, but this lead me to discover project-find-file, which is, and apparently does the same.
<efraim>Yay for Berlin server!
<Apteryx>Indeed! Thanks for making this farm publicly available! It's the most reliable substitute server I've found so for; congrats!
<Apteryx>for the M-x find-file fix, this is what I settled for for now: (add-to-list 'completion-ignored-extensions ".go"). Make ido great again!
<Apteryx>Do I need the transitive closure of (guix build utils) here?
<Apteryx>install-file seems to fail because lacking the copy-file dependency... I would have thought that Guix would take care of this for me if I tell it that `install-file' is in (guix build utils) using the #:modules field (for the trivial-build-system) ?
<Apteryx>hmm. copy-file is a Guile builtin?
<davexunit>part of guile's POSIX API
<civodul>rekado: woohoo, thank you!
<Apteryx>davexunit: Does the last bit of this: simply mean that there was no such file "51-android.rules"?
<Apteryx>Is my assumption that the builder's working directory is the root of whatever archive/SCM was given in the source?
<Apteryx>otherwise how can access the store dir corresponding to my check'd out origin?
<Apteryx>Ahh... I understand the cause of all my confusion now. As rekado told me earlier, the trivial-build-system does nothing. Maybe that's not what I should be using.
<slim404>I need some help with my guix system config
<slim404>so I have a french keyboard and a guix desktop system
<slim404>my config.scm used to have a service configuration for slim display manager to use french keyboard
<slim404>something like this :
<Apteryx>slim404: like what?
<slim404> (slim-service #:startx (xorg-start-command #:configuration-file (xorg-configuration-file #:extra-config '("Option \\"XkbLayout\\" \\"fr\\"\\n"))))
<slim404>consed into #desktop-services
<slim404>Apteryx: sorry :)
<slim404>this used to work, but lately I got an error :
<slim404>xorg-server already defined
<slim404>or something like that
<slim404>guix system: error: service « xorg-server » fourni plus d'une fois
<slim404>xorg-server defined more than once
<slim404>so I tried to (remove) slim-service from #desktop-services
<slim404>like this :
<slim404>(remove (lambda (service) (eq? (service-kind service) slim-service-type)) %desktop-services))
<slim404>it worked, I did not get the error
<slim404>but I did not get xwindows either :/
<Apteryx>ah, there might have been a change in the guix service definitions that would cause the xorg-server to appear twice.
<Apteryx>I'll check the recent commits
<sadiq[m]>won't 'guix environment foo' set runtime environment for package foo? or just build environment?
<Apteryx>sadiq[m]: build. runtime would be with --ad-hoc foo
<sadiq[m]>hm.. I see
<Apteryx>slim404: I don't see anything very recent except one commit by Wingo which added modesetting driver to Xorg default configuration or something like this.
<slim404>Apteryx: it's not recent, my original config.scm is from ~1 year ago
<slim404>maybe more
<sadiq[m]>Is there any built-in environment for C programming? the one that provides, gdb, gcc, binutils, valgrind, GNU global, etc?
<rekado>built-in where?
<rekado>like a meta-package?
<rekado>there is not.
<IpswichTriptych>Hello! I'm interested in trying out Guix on my Libreboot X60.
<janneke>Hi IpswichTriptych, sounds good!
<IpswichTriptych>janneke: do you happen to know the status of GUIX/hurd?
<janneke>IpswichTriptych: no, but fwiw I haven't heard it boots yet
<IpswichTriptych>ah, OK
<IpswichTriptych>after "ip link set ... up" i'm getting "RNETLINK answers: Operation not possible due to RF-Kill"
<IpswichTriptych>What does this mean?
<IpswichTriptych>same after "ifconfig ... up"
<IpswichTriptych>ah, got it! ^.^
<Apteryx>sadiq[m]: at least you should started off gcc-toolchain metapackage.
<laertus>bavier` efraim and janneke: it turns out that the reason tcsh was failing that "nice" test was that i was running guix-daemon as "nice ionice -c3 guix-daemon"
<laertus>when i ran guix-daemon not under nice, then it worked
<laertus>seems running guix-daemon under nice prevents the tcsh it runs from nicing itself
<janneke>laertus: great you found it!
<ng0>shouldn't this give me mate-screensaver in my system-profile? I've read the service description and code.. I've seen mate-screensaver building, but it's not in the resulting system (or at least Mate itself is not aware of it). (screen-locker-service mate-screensaver "mate-screensaver")
<bavier2>laertus: interesting! glad you figured it out.
<ng0>Mate is aware of it when this is in the 'mate' meta-package, but due to a problem with screen locking ability of it I must avoid it
<janneke>hmm, my xbacklight is broken after update to master (intel)
<rekado>same here!
<janneke>xrandr --output --brightness works but manual suggests that's software only and xbacklight is better?
<janneke>ACTION is clueless here
<rekado>I get a hash mismatch for
<rekado>expected: 1asvxkfh85842816wd3yjw7g1pyhjj69lh4ni4ijjpwlicrsws67
<rekado> actual: 1zvpfypd38v8m44lkr6dz4a53avwv4rii8200cs8m4kw7vkr4m03
<lfam>rekado: In general, the linux-libre tarballs are not deterministically created, and we can't expect a long-term archive
<lfam>There is the linux-libre channel if you want to ask the linux-libre people about it
<rekado>erm, wait… why am I getting 4.13.1?
<rekado>latest is 4.13.3 afaics
<lfam>4.13.4 is the latest upstream
<rekado>oh, indeed
<lfam>rekado: What is `guix --version`?
<rekado>it’s all good
<rekado>I just ran a guile script and .config/guix/latest was not on the GUILE_LOAD_PATH
<lfam>Aha. Too bad we already lost the upstream source for 4.13.1, thought :(
<lfam>It's a major problem with long-term reproducibility of GuixSD, IMO
<lfam>4.13.1 was released on September 10
<laertus>lfam: do you know if guix has any plans to address that issue by, say, archiving all the sources?
<rekado>in the past we have copied some of the linux-libre tarballs
<rekado>but that’s not sustainable
<lfam>laertus: We keep a content-addressed mirror of the packages' source code, but we can't keep everything forever, at least with our current resources
<laertus>rekado: could you elaborate on the reasons for the lack of sustainability of that approach?
<rekado>laertus: that’s really an upstream problem
<laertus>i see.. so it's a resource issue?
<laertus>rekado: not every upstream provider is going to care or agree that archives should be kept
<laertus>and they might not have resources either
<rekado>the upstream here is GNU
<laertus>all guix packages are gnu packages?
<rekado>it doesn’t make sense for GNU to copy around linux-libre sources
<lfam>laertus: Also, linux-libre is not the only upstream team that doesn't aim to provide a long-term archive of their source code. And in the long run, it all disappears or changes URL. It's just that some packages, like linux-libre, cause more pain when they don't archive their source code
<rekado>I’m speaking specifically of linux-libre.
<lfam>Also, the linux-libre source code releases are kept upstream for an unusually short period
<laertus>when you refer to resource issues, do you mean manpower or funding or disk space?
<lfam>I would say all 3 are related
<lfam>Storage costs money, must be hosted somewhere (more money), and requires people to maintain it
<laertus>because if it's just disk space, you could store the original and then binary diffs (or just git for source code, so its own diffing algorithm could be used to store changes)
<laertus>you don't have to store huge tarballs for every change
<lfam>Yeah, but it adds up one way or the other :)
<laertus>all true
<lfam>I recently learned that certain types of tarballs generated by GitHub are not intended to be bit-reproducible over time as they are garbage collected at GitHub and regenerated on request
<lfam>That could affect a very large number of our packages. In the long run, we can't store everything forever. In my opinion, a long-term archive needs funding as a business or government entity
<laertus>i wonder if some place like could help
<lfam>Yes, or the Software Heritage project
<laertus>or just dump the stuff on github itself :)
<rekado>the MDC just received hardware to store a limited subset of packages and their sources
<laertus>i think there are also some distributed long-term-storage projects
<lfam>Perhaps, until they end up like SourceForge. About 1.5 years ago, SourceForge changed the URL of hundreds of our package sources, which took many hours of time to fix for us
<lfam>That comment was referring to GitHub
<laertus>yeah, generally it's probably a bad idea to rely on any one solution
<laertus>as it could always go away
<lfam>It's a hard problem, ultimately. How do you preserve information in the long term? I think it's an information theory issue at its heart
<rekado>I think software heritage is going to be very useful for Guix.
<ng0>I know one or two hosters without diskspace limitation who I'll be using as intermediate solution to more long-term solutions… personally I keep copies of every tarball I package and use, so for a mismatch it could be placed anywhere safe.
<lfam>If Software Heritage doesn't work out, I would be willing to donate time and money to a Guix source archive
<lfam>Or a 3rd party project that is friendly to Guix
<lfam>ACTION forever grateful for this channel's cordial and helpful tone
<laertus>i also wonder if it's possible to solicit a donation of space from AWS
<ng0>I have to get back to the email and support threads I had with 3 of my providers. I think 1984 was relatively okay, and iirc they also provide (one of) the download location(s) for torproject
<laertus>some of this stuff could be stored in S3, and long-term archives in their long-term archive service the name of which i'm blanking on right now
<lfam>The thing with Glacier is the super-slow and expensive retrieval
<rekado>ng0: “unlimited” often turns out not to be unlimited
<rekado>hence the name?
<ng0>so 1984 to my question on diskspace and traffic consumption of one of their plans was like "unlimited? yes, really unlimited"..
<laertus>lfam: yeah, but it'd only be for archives.. and, anyway, the idea is to solicit a donation, so price would not be an issue
<laertus>(if they go for it)
<lfam>Yeah, in order to get the data out of the glacier, you first have to have an industrial revolution and melt the glaciers over 150 years ;)
<ng0>I know my current unlimited at IN-Berlin is "fair-use" unlimited
<laertus>lfam: anyway, if Glacier isn't suitable, maybe AWS would just donate S3
<lfam>laertus: It could be a great boon if they went for it. But perhaps that donation would be more effectively utilized by, who have experience and expertise managing archives, and could then host the software
<laertus>does host software?
<lfam>They host anything :)
<lfam>We use them as the source of a handful of packages, IIRC
<lfam>I think we (Guix) are a bit wary of taking on this project ourselves. At least, I know I am.
<laertus>yeah, would be one of the most logical places to ask first
<laertus>btw, does anyone know what (if anything) Nix uses for this sort of thing?
<ng0>I had previous contact with them.. I think all we do is to create an collection and that's it, curate it ourselves. like.. "github" collection etc
<laertus>it also might be worth researching what the major linux/bsd distros use for their packages
<lfam>laertus: They have their own content-addressed archive, and we actually use it as a fallback
<lfam>I think it has a serious drawback, however. It's purely content addressed, unlike ours, which also includes package name and version in the URL.
<laertus>what does "content addressed" mean?
<laertus>just a hash based on contents?
<lfam>You retrieve the data by its hash. Does that make sense?
<laertus>well, could there be an index that maps content hashes to package names and versions in the URL?
<laertus>(and vice-versa)
<lfam>That's what the Guix content addressed server does
<laertus>then is the capability to do that at really necessary?
<lfam>It's relatively difficult to be sure you are getting the right thing from the Nix archive
<lfam>To do what at
<laertus>you said "I think it has a serious drawback, however. It's purely content addressed, unlike ours, which also includes package name and version in the URL"
<laertus>i was referring to the need to do that
<laertus>since Guix content addressed server already does it
<laertus>i think i must be missing something...
<lfam>The problem that I see only manifests when the tarball can't be found from the upstream site or the Guix mirror.
<lfam>Imagine that there is a new version of package foo released. Typically, this is handled by updating the version and the hash in the Guix package definition
<lfam>If the source can't be found upstream, or on the Guix mirror, the Nix mirror is the final fallback option.
<lfam>If the hash provided is for something besides what we expect (the wrong version of foo, or even another package), the mirror will still serve it.
<lfam>And Guix will try building it...
<lfam>Hopefully the build would fail, but I bet that for "merely an old version of foo", it will usually succeed, and we may not notice that we've built the wrong thing
<laertus>why would the wrong hash be provided?
<lfam>It could be a mistake, or it could be malicious. Guix security ultimately rests of the honesty of the committers
<lfam>I mean, 'rests on'
<laertus>so the commiters provide the hash for the new version, and guix tries to fetch the source matching that hash and build it
<ng0>forget my reply on 1984 and torproject, it was something else ( But the reply of 1984 was correct.
<lfam>laertus: But, what if they provide the hash of the wrong version? This has happened before
<lfam>If the packager uses `guix download` to check the hash of the file, they will not notice if they forget to update the hash in the package definition, because the source requirement will already be satisfied by the file that `guix download` put in /gnu/store
<lfam>This is why you should never use `guix download` when packaging things :)
<laertus>lfam: so you're saying if stored not just the content hash but also the package name and version corresponding to that hash, then guix could match those against the hash, package name, and version given by the commiters?
<lfam>Exactly, and that's what the Guix mirror does.
<lfam>The URLs include package name, version, and hash
<lfam>But the Nix mirror only uses the hash
<lfam>It enables mistakes, IMO
<laertus>why can't guix mirror also store the hash, package name, and version of all the content in as well?
<lfam>Can't it? I think somebody just needs to do the work :)
<laertus>ok, so it sounds like it's solvable without needing to use features not available from
<lfam>Sorry if I confused you. I wanted to talk about issues related to content addressing, but I don't see a reason that could not be used
<laertus>i'm glad you did, because i learned a ton
<laertus>btw, slight detour.. but speaking of content... why does /gnu/store contain something like 46 versions of bash when i still haven't finished my first "guix package -i glibc-locales" yet?
<laertus>are all those different versions really necessary?
<laertus>why couldn't guix just use one single version of bash for all its builds?
<laertus>it seems like it must have recompiled bash 46 times, and that seems like a waste
<laertus>what am i missing?
<lfam>That's too many times :)
<lfam>They might be patch files for the Bash source code
<lfam>If not, can you share one of the paths?
<laertus>yeah, i just did a "du" on them, and almost all of them are only 4k in size
<lfam>As far as I can tell, we are only applying 12 patches to Bash currently. So, I hope there are not actually 46 of them :)
<lfam>See %patch-series-4.4 in 'gnu/packages/bash.scm'
<laertus>well, here's the output of "ls -1 /gnu/store | grep bash"
<lfam>Things like bash44-007 are patches
<lfam>Things like bash44-007.drv are derivations (intermediate level build scripts) to create the patches
<lfam>Bash does get built a few times in the bootstrapping process, but not 46, or even 12 ;)
<laertus>ok, cool
<laertus>just wanted to make sure nothing crazy was going on..
<lfam>Not this time ;)
<lfam>Also, I recommend `echo /gnu/store/*-bash-*` as a faster alternative to `ls -l ...`
<lfam>Unless you need the extra info from `ls -l`
<laertus>nah, i didn't
<lfam>Oh, ls -1. That's different
<laertus>though the above command was "ls -1" (as in the number "one")
<lfam>My IRC font doesn't show the difference clearly
<laertus>i'm guessing the reason that /gnu/store is flat is so that files could be more easily looked up by their hashes
<laertus>and i guess there's no reason to separate it in to "packages" and "patches" directories or something
<laertus>or to stick all bash-related stuff under a "bash" subdirectory
<lfam>I don't know the answer to that (probably it's covered in Eelco Dolstra's Nix PHD thesis)
<laertus>wow, i didn't know nix was based on a phd thesis
<lfam>But I do believe that is the reason the hash precedes the name and version (easy lookup)
<lfam>It's published as 'The Purely Functional Software Deployment Model'
<laertus>cool.. i'll check it out
<lfam>There is a much shorter publication, Nix: A Safe and Policy-Free System for Software Deployment
<lfam>And then, the reasoning behind Guix, Functional Package Management with Guix by Ludovic Courtes
<laertus>it's good to know that research in this area is still ongoing
<laertus>and it makes me wonder what innovations the future will bring