[Nix-dev] Ideas for a NixOS-related bachelors thesis?

Erik Rybakken erik.rybakken at math.ntnu.no
Thu Oct 29 13:28:10 CET 2015


Yes, there is still the trust issue, but one only has to trust the
provider of the hashes, not the ones providing the actual files in the
IPFS network. Also,if the build is deterministic (another feature
mentioned on the GSOC 2015 ideas list), anyone can verify if the hash is
valid.

One aspect of using IPFS, is that in addition to the nix store, one also
have the IPFS store. These two stores have a similar functionality. How
will we avoid duplication? Should we just use one store for both nix and
IPFS?

Best regards,
Erik Rybakken

On 2015-10-29 12:22, Matthias Beyer wrote:
> This sounds also really interesting.
> 
> As far as I can tell, IPFS wouldn't protect me against malformed
> packages, so there is still the trust issue.
> 
> Anyways, binary cache on a per-user basis (where I only have to trust
> myself) would be a nice thing for the first step.
> 
> Will note that as an idea!
> 
> On 29-10-2015 11:16:51, Domen Kožar wrote:
> > I'd go for: https://ipfs.io/ for binary substitues
> > 
> > On Thu, Oct 29, 2015 at 11:15 AM, Joel Moberg <joel.moberg at gmail.com> wrote:
> > 
> > > There are some ideas presented for GSOC 2015 here
> > > https://nixos.org/wiki/GSOC_2015_ideas_list, my fave is P2P substitutes.
> > > This would mean it would be easy to share a cache and in some cases improve
> > > speed. Maybe not all features are needed for this project. For example, a
> > > interface where you can control what to seed can be added later on.
> > >
> > > In the end I think you should choose what you think will be most fun or
> > > the project that you think will make nix or nixos stronger. Good luck :)
> > >
> > > On Thu, Oct 29, 2015 at 9:01 AM, Matthias Beyer <mail at beyermatthias.de>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> for those who don't know me: I'm a 24 year old student at a university
> > >> of applied sciences in the black forest, germany. I'm in my 6th
> > >> Semester right now, the 7th (bachelors thesis) starting in
> > >> Feb/March 2016.
> > >>
> > >> I'm writing you people because there might be ideas for a
> > >> NixOS-related bachelors thesis?
> > >>
> > >> The constants are:
> > >>
> > >>     - Time: Something 4-month-is
> > >>
> > >>     - I don't want to do it at a company and I want to remain at my
> > >>       university for the time of the thesis, if possible. Also because
> > >>       I still want to attend some (voluntary) lessons there
> > >>
> > >>     - The topic should be NixOS related (personal interest), I have to
> > >>       convince my professor, though
> > >>
> > >>     - It should be programming-related
> > >>
> > >>     - I want to be able to create, I want to be able to be creative
> > >>
> > >>     - I want to be able to choose the language I program in, if
> > >>       possible. Candidates are:
> > >>
> > >>         - C (not unconditionally)
> > >>         - C++ (I'm not so good at it)
> > >>         - Ruby (I'm really good, I guess)
> > >>         - Bash (I'm okay at it)
> > >>
> > >>     - I can relate to the topic. I have no personal use for nixops and
> > >>       therefor never used it, so I won't have any relation to a
> > >>       nixops-related topic... I guess you understand what I mean here.
> > >>
> > >> I guess there are more things to this list and I just cannot remember
> > >> them right now.
> > >>
> > >> I already had an idea, where a prof told me that he would do this and
> > >> the scope is okay for a thesis at a university of applied sciences:
> > >>
> > >>     The idea was to create a source-to-source compiler and translate
> > >>     (for example) Archlinux pkgbuild files to nix expressions.
> > >>
> > >>     There would be three steps in complexity:
> > >>
> > >>         Simple: compile one package to one package. Just AST
> > >>         transformation, nix files have to be manually edited
> > >>         afterwards, eventually
> > >>
> > >>         Medium: compile a tree of packages (optionally find cyclic
> > >>         dependencies), nix files have to be manually edited
> > >>         afterwards, eventually
> > >>
> > >>         Complex/Large: compile a tree of packages, find cyclic
> > >>         dependencies, be able to build the expressions without further
> > >>         modification (the compiler resolves dependencies
> > >>         appropriately)
> > >>
> > >>     I guess I would do Simple and Medium, Large if I have too much
> > >>     time left.
> > >>
> > >>     I'd do this in Ruby and I'd use a parser generator for this and
> > >>     not write a parser on my own.
> > >>
> > >> This is considered a great amount of work for a bachelors thesis by
> > >> one of my profs, but he also things I'm a rather good student and I
> > >> can do this. I hope this gives you an idea of what amount is
> > >> appropriate.
> > >>
> > >>
> > >> So why this mail? Just a quick POLL to get some more ideas out of the
> > >> community. Maybe there are more interesting topics around, I don't
> > >> know.
> > >>
> > >> I will be at NixCon and almost certainly at 32C3, so we can discuss
> > >> there as well.
> > >>
> > >> --
> > >> Mit freundlichen Grüßen,
> > >> Kind regards,
> > >> Matthias Beyer
> > >>
> > >> Proudly sent with mutt.
> > >> Happily signed with gnupg.
> > >>
> > >> _______________________________________________
> > >> nix-dev mailing list
> > >> nix-dev at lists.science.uu.nl
> > >> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> > >>
> > >>
> > >
> > > _______________________________________________
> > > nix-dev mailing list
> > > nix-dev at lists.science.uu.nl
> > > http://lists.science.uu.nl/mailman/listinfo/nix-dev
> > >
> > >
> 
> -- 
> Mit freundlichen Grüßen,
> Kind regards,
> Matthias Beyer
> 
> Proudly sent with mutt.
> Happily signed with gnupg.



> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev



More information about the nix-dev mailing list