unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Catonano <catonano@gmail.com>
To: Jan Nieuwenhuizen <janneke@gnu.org>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: interesting thread
Date: Wed, 24 May 2017 21:26:28 +0200	[thread overview]
Message-ID: <CAJ98PDwmN+rticC1dhvud8ipx4Pv6m8VR+irj8VdBAVPTfYAbw@mail.gmail.com> (raw)
In-Reply-To: <878tlmqlf4.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 3770 bytes --]

2017-05-24 18:17 GMT+02:00 Jan Nieuwenhuizen <janneke@gnu.org>:

> Catonano writes:
>
> > no comments ?
>
> I saw this message, had a quick look and a frown...
>
> > I was so enthsiast of aving discovered this
>
> Can you summarize what's to get enthousiastic about?
>
> >     https://lists.w3.org/Archives/Public/public-lod/2017May/0005.html
> >
> >     they published the metadata about the WHOLE collection of packaged
> in npm !!
>
> Having looked into npm and worked on the guix npm importer, I found that
> even the some of the most trivial packages cannot be built from source.
> Cyclic dependencies in the build systems.
>
> So after having tried to get npm into GuixSD, I'm at the point of giving
> up on npm and am planning to migrate away from it.
>
> I can hardly imagine...but does this report in any way hint that some
> packages can be built from source and how to do that?
>

I only skimmed through it but I think it doesn' t

I think the authors are not well versed in software engineering, they might
be not completely aware of the issues involved in software reproducibility.

This is one of the reasons why this post is interesting. These people might
be interested in learning about Guix and its reasons

And frankly, I believe that the "data oriented" approach could help Guix;
so yes, I think that Guix has something to learn from their effort too

I know the issues that plague the npmjs world.

In my grand plan, we would have a complete graph of the npmjs packages and
the dependencies among them.

This could help in doing a sane bootstrap of nodejs in Guix. Sort of what
Ricardo is doing with Java

He' s doing that manually, discovering binary blobs in "sources" as he
proceeds

Because the nodejs graph is so large and dense, a more systematic approach
would be, in my opinion, necessary, in order to achieve the same result.

I have been thinking about giving up on the web entirely because of
javascript

I never liked the idea of apps in the browser, anyway. I still miss my
favourite native email client, Eudora

But the community working with nodejs, around the world, is enormous. Huge

Think about the Mediawiki foundation, or Wordpress.

Think about Ruby on Rails.

Recently I even found an IDE for Postgresql, it looked like a native
application, instead it has a frame with javascript infested content in it

Renouncing to nodejs would be a huge blow to Guix. As huge as the nodejs
community is

Then, add Gnunet to the equation: if there was a set of native Gnome apps
integrated with Gnunet, the Free Software movement could offer something
valuable to many people working with php/nodejs off the shelve solutions
today.

It would be an important opportunity for the Free Software at large, not
Guix only.

I believe this is important

Now: as you might remember, I made an effort to collect the jquery
dependencies graph and store it in a graph db

The Graph db I used was not mature enough, so that when a version
advancement came, I discovered that there was no upgrade path for my data

I thought to re-do that from scratch using Postgresql

But I slacked off and I had some difficulties in wrapping my mind around
the possibility to make such a scraper concurrent

But that's another story

Anyway, this is the reason why I am enthusiastic about this release: they
published a COMPLETE nodejs dependencies graph as linked data

So my scraping effort is not needed anymore !

Now it' s just a matter of querying those data to identify culprit
packages, unbuildable or otherwise problematic

I think it' s an advancement !

As for my personal projects, I could prefer usig Gnome over the web based
stuff too. But what I was thinking is not only my personal toys.

So, these is my reasoning.

I hope I made myself clearer now

[-- Attachment #2: Type: text/html, Size: 5447 bytes --]

  reply	other threads:[~2017-05-24 19:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-19 17:16 interesting thread Catonano
2017-05-24 15:57 ` Catonano
2017-05-24 16:17   ` Jan Nieuwenhuizen
2017-05-24 19:26     ` Catonano [this message]
2017-05-24 20:16   ` ng0

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJ98PDwmN+rticC1dhvud8ipx4Pv6m8VR+irj8VdBAVPTfYAbw@mail.gmail.com \
    --to=catonano@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=janneke@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).