* Re: GuixSD on arm
2016-07-04 22:18 ` Jookia
@ 2016-07-05 8:21 ` Alex Sassmannshausen
2016-07-05 8:23 ` Ludovic Courtès
` (3 subsequent siblings)
4 siblings, 0 replies; 20+ messages in thread
From: Alex Sassmannshausen @ 2016-07-05 8:21 UTC (permalink / raw)
To: Jookia; +Cc: help-guix, t3sserakt
Hey Jookia,
You might not be looking for this kind of email, but I wanted to send it
anyway, feel free to ignore…
I'm sorry to hear you feel the project is currently not set up to help
people like you contribute. Obviously I cannot speak for the project,
as I'm rather involved on the sidelines (though I follow it with great
interest and am a keen user), but I'm sure people will be dis-heartened
to hear of your experience. My own experience has been, and still is,
that contributing to Free Software in general has a steep learning
curve, and I really don't know if that's just me or whether this stuff
is just hard. I don't know the solution for myself yet.
Anyway, you already say that you don't blame anyone — I just hope you
might still follow the project, and maybe, at some point in the future,
if it feels like the project might work better for you, you might give
it another go.
In the meantime, fwiw, I enjoyed your emails, even if they went totally
over my head :-)
Happy hacking,
Alex
Jookia writes:
> On Mon, Jul 04, 2016 at 05:14:56PM +0000, ng0 wrote:
>> t3sserakt writes:
>>
>> > Hi Ludo,
>> >
>> > I would like to help, but I have no idea where to start.
>> > I am "just" an application developer, and do not have
>> > the right knowledge for doing this task alone.
>> >
>> > Additionally to that I am busy with helping the
>> > secushare (gnunet) project.
>> >
>> > But if there is somebody who knows in more detail
>> > what to do, I can help.
>>
>> I think Jookia was working on this.. or still is.. I am unsure
>> about the state of Jookia's work.
>> I'll CC Jookia and we'll see if this thread gets an reply.
>>
>> Additionally I CC'ed you t3ss because I don't know if you are
>> subscribed.
>
> Hi there!
>
> I started on an ARM port a few months ago with the intention of running the
> system on my Novena, but eventually gave up given the hard development cycle.
> I haven't talked about this before but I don't expect many people to read this
> email, so here goes. The main pain points were these:
>
> - Patches would get lost regularly.
>
> This is probably the biggest issue, and from reading the mailing list it doesn't
> seem to be solved. There was an attempt at adding a patch tracker but I guess
> that was lost too. I suggested at some point to use a newer version of Mailman
> which would help this, but the developers didn't think it useful. The suggested
> way to fix this is to reply and get people's attention about your patches again.
>
> I'm not cut out to what feels like nagging people when I don't know the reasons
> why they haven't replied. Perhaps this is how things work in other systems, but
> as someone that suffers from social anxiety and finds it hard enough to even
> send patches I can't deal with this, and Guix seems to be doing fine without me.
>
> - Feedback is little to none.
>
> As patches were lost and most discussion was done on the mail list, there was
> basically no discussion on patches or design problems. After getting Guix to
> boot on my Libreboot machine I went to work on fixing issues with the boot
> system, such as adding support for legacy Libreboot systems and encrypted
> bootloaders. This was lost.
>
> I also did some work to get LVM+LUKS working on Guix and tried to spark a
> discussion in to fixing the design issues in system configuration. I think there
> was about one reply, and it was lost.
>
> Some of the work that I did do and in fact got in somewhat by proxy is GTK+
> theming. There's a habit of maintainers fixing things themselves rather than
> taking patches, which I feel is a further hindrance to actually working on Guix.
>
> This gives me the impression that Guix doesn't have enough maintainers to
> sustain people doing new development upstream, want to do things themselves, or
> the project is just bad at communication.
>
> - GNUness over pragmatism.
>
> The main issue I had with doing an ARM port is the bootloader, and this is
> because everyone I spoke to except Ludovic seemed to be hesitant towards using a
> bootloader other than GRUB. Looking at the code base, I'd need to do make things
> less GRUB-specific which I was happy to do, but I didn't want to do it wrong or
> end up with my work ignored or thrown away.
>
> To be concrete, the conversation generally went like this: "To get the Novena
> booting Guix I'll need to add support for U-Boot as a bootloader." "I've heard
> GRUB works on ARM, have you tried that?" "Yes, it doesn't work from what I've
> tried." "Perhaps you've done it wrong." "I can't rule that out, but GRUB on ARM
> is still early work compared to U-Boot (which GRUB uses) and it'd work for more
> boards." then the conversation would drop off.
>
> I have a distinct feeling this is due to a bias in building "the GNU system"
> rather than building a fully free Guix-based system. I was originally going to
> do a fork of Guix with my own changes that people could download, but in the end
> I just went back to NixOS which runs happily on my Novena and my Libreboot
> machine. The only reason I wanted to use Guix was so I could contribute patches
> upstream and not maintain ones locally like I do with NixOS.
>
> - Summary
>
> This experience has put me off of Guix, GNU and free software development. I
> don't blame any one, but more a system that doesn't incorporate people like me.
> I'm not going to elaborate more on this, I just had to get it off my chest.
>
> I'm willing to send you code and help you with what I've done: It's mostly
> reworking the bootloader. There's no ARM support yet, but I did identify the
> points that need changing.
>
> Cheers,
> Jookia.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: GuixSD on arm
2016-07-04 22:18 ` Jookia
2016-07-05 8:21 ` Alex Sassmannshausen
@ 2016-07-05 8:23 ` Ludovic Courtès
2016-07-05 15:44 ` Jookia
2016-07-05 8:53 ` t3sserakt
` (2 subsequent siblings)
4 siblings, 1 reply; 20+ messages in thread
From: Ludovic Courtès @ 2016-07-05 8:23 UTC (permalink / raw)
To: Jookia; +Cc: help-guix, t3sserakt
Howdy Jookia,
Jookia <166291@gmail.com> skribis:
> - Patches would get lost regularly.
Lack of responsiveness is terrible, but I think it’s easy to complain
about it until one gets involved in patch reviews.
Also, some reviews are more difficult than other: adding support for
another bootloader is not as simple as upgrading a package.
> - GNUness over pragmatism.
>
> The main issue I had with doing an ARM port is the bootloader, and this is
> because everyone I spoke to except Ludovic seemed to be hesitant towards using a
> bootloader other than GRUB.
I wrote repeatedly that using U-Boot is fine, especially if GRUB doesn’t
work on this platform.
> I have a distinct feeling this is due to a bias in building "the GNU system"
> rather than building a fully free Guix-based system.
There is this bias, which makes a difference from most other distros. I
don’t think I/we are blind though: when GNU lacks the right piece of
software, using another free software package is the right thing to do.
> This experience has put me off of Guix, GNU and free software development.
I think you’re throwing the baby with the bathwater.
Thanks for your feedback,
Ludo’.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: GuixSD on arm
2016-07-05 8:23 ` Ludovic Courtès
@ 2016-07-05 15:44 ` Jookia
2016-07-11 11:47 ` Ludovic Courtès
0 siblings, 1 reply; 20+ messages in thread
From: Jookia @ 2016-07-05 15:44 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: help-guix, t3sserakt
On Tue, Jul 05, 2016 at 10:23:07AM +0200, Ludovic Courtès wrote:
> Howdy Jookia,
Thanks for your reply! I just want to follow up to elaborate on a few things:
> Jookia <166291@gmail.com> skribis:
>
> > - Patches would get lost regularly.
>
> Lack of responsiveness is terrible, but I think it’s easy to complain
> about it until one gets involved in patch reviews.
>
> Also, some reviews are more difficult than other: adding support for
> another bootloader is not as simple as upgrading a package.
I don't want to seem like I'm criticising you or the developers over this,
especially since I do understand why things are this way. But the experience
from things being this way is a pain point for me at least, and there doesn't
seem to be any clear solutions yet. It's a bit annoying for things to move
slowly, but it's demotivating for things to come to a stop.
> > - GNUness over pragmatism.
> >
> > The main issue I had with doing an ARM port is the bootloader, and this is
> > because everyone I spoke to except Ludovic seemed to be hesitant towards using a
> > bootloader other than GRUB.
>
> I wrote repeatedly that using U-Boot is fine, especially if GRUB doesn’t
> work on this platform.
I know that's your stance on it, but there's multiple maintainers on Guix and
multiple people to talk about the issue, especially if I need help or review on
code. It's unsettling emotionally to see different people, especially authority
figures who work with the code and decide what's useful or not, giving mixed
answers as to what direction things should be taken. Implementing something that
only one developer approves of makes me question if it really is the right
approach or worth people's time.
> > I have a distinct feeling this is due to a bias in building "the GNU system"
> > rather than building a fully free Guix-based system.
>
> There is this bias, which makes a difference from most other distros. I
> don’t think I/we are blind though: when GNU lacks the right piece of
> software, using another free software package is the right thing to do.
I'm glad to hear that.
>
> > This experience has put me off of Guix, GNU and free software development.
>
> I think you’re throwing the baby with the bathwater.
Me too, but this isn't really as much as a conscious decision as an emotional
reaction to what I've felt and perceived. I'm sure eventually it'll get better.
> Thanks for your feedback,
> Ludo’.
I'm sorry for the negativity,
Jookia.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: GuixSD on arm
2016-07-05 15:44 ` Jookia
@ 2016-07-11 11:47 ` Ludovic Courtès
0 siblings, 0 replies; 20+ messages in thread
From: Ludovic Courtès @ 2016-07-11 11:47 UTC (permalink / raw)
To: Jookia; +Cc: help-guix, t3sserakt
Hi!
Jookia <166291@gmail.com> skribis:
> On Tue, Jul 05, 2016 at 10:23:07AM +0200, Ludovic Courtès wrote:
[...]
>> > - GNUness over pragmatism.
>> >
>> > The main issue I had with doing an ARM port is the bootloader, and this is
>> > because everyone I spoke to except Ludovic seemed to be hesitant towards using a
>> > bootloader other than GRUB.
>>
>> I wrote repeatedly that using U-Boot is fine, especially if GRUB doesn’t
>> work on this platform.
>
> I know that's your stance on it, but there's multiple maintainers on Guix and
> multiple people to talk about the issue, especially if I need help or review on
> code. It's unsettling emotionally to see different people, especially authority
> figures who work with the code and decide what's useful or not, giving mixed
> answers as to what direction things should be taken. Implementing something that
> only one developer approves of makes me question if it really is the right
> approach or worth people's time.
I don’t remember anyone rejecting the idea of using U-Boot per se.
BTW, formally I’m currently the only maintainer. However, I think most
decisions should be (and indeed are) based on consensus among active
contributors (developers and people who participate in discussions.)
That can introduce delays in the short term, but I think it makes the
whole project stronger in the long run.
Cheers,
Ludo’.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: GuixSD on arm
2016-07-04 22:18 ` Jookia
2016-07-05 8:21 ` Alex Sassmannshausen
2016-07-05 8:23 ` Ludovic Courtès
@ 2016-07-05 8:53 ` t3sserakt
2016-07-05 21:49 ` Jookia
2016-07-05 12:08 ` ng0
2016-07-05 20:46 ` Ricardo Wurmus
4 siblings, 1 reply; 20+ messages in thread
From: t3sserakt @ 2016-07-05 8:53 UTC (permalink / raw)
To: Jookia, ng0; +Cc: help-guix
Am 05.07.16 um 00:18 schrieb Jookia:
> On Mon, Jul 04, 2016 at 05:14:56PM +0000, ng0 wrote:
>> t3sserakt writes:
>>
>>> Hi Ludo,
>>>
>>> I would like to help, but I have no idea where to start.
>>> I am "just" an application developer, and do not have
>>> the right knowledge for doing this task alone.
>>>
>>> Additionally to that I am busy with helping the
>>> secushare (gnunet) project.
>>>
>>> But if there is somebody who knows in more detail
>>> what to do, I can help.
>> I think Jookia was working on this.. or still is.. I am unsure
>> about the state of Jookia's work.
>> I'll CC Jookia and we'll see if this thread gets an reply.
>>
>> Additionally I CC'ed you t3ss because I don't know if you are
>> subscribed.
I am not. Thx!
> Hi there!
>
> I started on an ARM port a few months ago with the intention of running the
> system on my Novena, but eventually gave up given the hard development cycle.
> I haven't talked about this before but I don't expect many people to read this
> email, so here goes. The main pain points were these:
>
> - Patches would get lost regularly.
>
> This is probably the biggest issue, and from reading the mailing list it doesn't
> seem to be solved. There was an attempt at adding a patch tracker but I guess
> that was lost too. I suggested at some point to use a newer version of Mailman
> which would help this, but the developers didn't think it useful. The suggested
> way to fix this is to reply and get people's attention about your patches again.
>
> I'm not cut out to what feels like nagging people when I don't know the reasons
> why they haven't replied. Perhaps this is how things work in other systems, but
> as someone that suffers from social anxiety and finds it hard enough to even
> send patches I can't deal with this, and Guix seems to be doing fine without me.
>
> - Feedback is little to none.
>
> As patches were lost and most discussion was done on the mail list, there was
> basically no discussion on patches or design problems. After getting Guix to
> boot on my Libreboot machine I went to work on fixing issues with the boot
> system, such as adding support for legacy Libreboot systems and encrypted
> bootloaders. This was lost.
>
> I also did some work to get LVM+LUKS working on Guix and tried to spark a
> discussion in to fixing the design issues in system configuration. I think there
> was about one reply, and it was lost.
>
> Some of the work that I did do and in fact got in somewhat by proxy is GTK+
> theming. There's a habit of maintainers fixing things themselves rather than
> taking patches, which I feel is a further hindrance to actually working on Guix.
>
> This gives me the impression that Guix doesn't have enough maintainers to
> sustain people doing new development upstream, want to do things themselves, or
> the project is just bad at communication.
>
> - GNUness over pragmatism.
>
> The main issue I had with doing an ARM port is the bootloader, and this is
> because everyone I spoke to except Ludovic seemed to be hesitant towards using a
> bootloader other than GRUB. Looking at the code base, I'd need to do make things
> less GRUB-specific which I was happy to do, but I didn't want to do it wrong or
> end up with my work ignored or thrown away.
>
> To be concrete, the conversation generally went like this: "To get the Novena
> booting Guix I'll need to add support for U-Boot as a bootloader." "I've heard
> GRUB works on ARM, have you tried that?" "Yes, it doesn't work from what I've
> tried." "Perhaps you've done it wrong." "I can't rule that out, but GRUB on ARM
> is still early work compared to U-Boot (which GRUB uses) and it'd work for more
> boards." then the conversation would drop off.
>
> I have a distinct feeling this is due to a bias in building "the GNU system"
> rather than building a fully free Guix-based system.
I do not really want to start a debate on principles, but isn't the goal
of GNU
to have a fully free system?
> I was originally going to
> do a fork of Guix with my own changes that people could download, but in the end
> I just went back to NixOS which runs happily on my Novena and my Libreboot
> machine. The only reason I wanted to use Guix was so I could contribute patches
> upstream and not maintain ones locally like I do with NixOS.
>
> - Summary
>
> This experience has put me off of Guix, GNU and free software development. I
> don't blame any one, but more a system that doesn't incorporate people like me.
> I'm not going to elaborate more on this, I just had to get it off my chest.
That reads very sad.
> I'm willing to send you code and help you with what I've done: It's mostly
> reworking the bootloader. There's no ARM support yet, but I did identify the
> points that need changing.
That would be very kind. I would endeavor that your work will not be for
nothing.
Like Alex I also had the experience, that you need a lot of patience
when participating
in free software development. There are a lot of volunteer with more or
less time
for working on a huge amount of tasks.
Maybe right now it is not the time for Guix on arm, but I hope you can
be encouraged
to give this community another chance in the future.
t3sserakt
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: GuixSD on arm
2016-07-05 8:53 ` t3sserakt
@ 2016-07-05 21:49 ` Jookia
2016-07-11 11:49 ` Ludovic Courtès
0 siblings, 1 reply; 20+ messages in thread
From: Jookia @ 2016-07-05 21:49 UTC (permalink / raw)
To: t3sserakt; +Cc: help-guix
On Tue, Jul 05, 2016 at 10:53:14AM +0200, t3sserakt wrote:
> That would be very kind. I would endeavor that your work will not be for
> nothing.
> Like Alex I also had the experience, that you need a lot of patience
> when participating
> in free software development. There are a lot of volunteer with more or
> less time
> for working on a huge amount of tasks.
>
> Maybe right now it is not the time for Guix on arm, but I hope you can
> be encouraged
> to give this community another chance in the future.
>
> t3sserakt
Hi again, I've found my old Guix repo: https://notabug.org/Jookia/guix
It's about a month old, and I think works. There's these branches:
- SET_jookia
This is just compilation of all the branches to make a usable system.
- WIP_av
This branch adds JACK support to OpenAL, ffmpeg and ALSA. The ALSA patches can
be used to add PulseAudio configuration.
It also adds the OpenShot video editor, and bumps libsndfile down to allow
Blender to work with FLAC files properly.
Not pushed upstream because of the effort it'd take.
- WIP_freedoom
Adds Odaemx, chocolate-doom, crispy-doom for playing Doom WADs. Includes
Freedoom WAD and these are patched to do autodetection: You can just run 'guix
environment --ad-hoc odamex freedoom' and Odamex will find your WADs!
It also includes the Eureka level editor and Rocket Launcher 2.0 launcher.
Not pushed upstream because of the effort it'd take. Require WIP_sdl-union.
- WIP_gdk-pixbuf
Disables gdk-pixbuf test that freezes my 2G RAM system when building Guix. I
submitted this to Guix, but I think the response was along the lines of 'see why
the test breaks' and I didn't have the resources to debug something that would
completely lock up my system so I gave up.
- WIP_grub-platform
Majority of work to improve/decouple GRUB work here, it's what you'll be
interested in. All patches are thoroughly documented, and tested. In summary it
does some refactoring and adds the ability for GRUB 'platforms' to specified in
the system configuration. This is what you'd find on the mailing list.
My plan of attack for modularing the bootloader system was to reduce the
references to GRUB functions and assumptions as much as possible outside of
gnu/system/grub.scm then create an interface based on that for bootloaders.
- WIP_localstatedir
Not intended to be pushed upstream, it just makes source builds compatible with
binary Guix packages by default by setting the state directory to /var rather
than /usr/local/var. Suggested upstream, but it breaks some conventions.
A fix was implemented where if you already have Guix installed, but why would
you if you're boostrapping from source like I was?
- WIP_luks-keyfiles
Add LUKS device that supports being unlocked by a keyfile. Puts your key in a
globally readable initramfs in /gnu/store. Not secure if for some reason someone
has access to your /gnu/store but wants to unlock your machine when powered off.
Submitted upstream in big LUKS+LVM discussion, didn't really go anywhere.
- WIP_lvm
Adds LVM device mapping. Untested after the rebase, and probably the very wrong
way to do it since the device mapping system needs to be overhauled IMHO to
support concepts of mapping input multiple devices to multiple outputs, like
/dev/sda + /dev/sdf to LVM /dev/matrix/root and /dev/matrix/swap on a RAID
system. Currently it only goes /dev/xxx -> /dev/mapper/xxx. The same flaw
prevents chaining mapped devices like LUKS to LVM as they won't resolve
dependencies.
Submitted upstream in big LUKS+LVM discussion, didn't really go anywhere.
- WIP_mapped-devices
Disables dependency management so devices and device mappings load serially, so
device mappings can depend on each other.
Submitted upstream in big LUKS+LVM discussion, didn't really go anywhere.
- WIP_pioneer
Adds the Pioneer space simulator game.
Not pushed upstream because I didn't want to participate. May require
WIP_sdl-union.
- WIP_proxies
Adds HTTP proxy support for SVN and Git checkouts, so you can build over Tor.
Regular files don't work with HTTPS proxies since Guile doesn't support that.
Submitted upstream, used a wrong SRFI, I forgot about the patch and eventually
didn't want to participate.
- WIP_rsnapshot
Adds rsnapshot.
Not pushed upstream because I didn't want to participate.
- WIP_sdl-union
When bulding either Pioneer or Odamex, I found sdl-config reported the wrong
include directory. This fixes it by having sdl-config report the union's include
directory rather than just SDL's
I was going to submit this upstream, but when I brought up the bug with the
maintainer I got a blunt response implying the bug didn't exist. I gave up
communication altogether with developers altogether after this.
When rebasing I found that a bunch of packages already worked around this bug
which is why it wasn't an issue, so I removed the workarounds in the branch.
- WIP_themes
Adds Numix and Numix icon theme, including circles. Looks great.
Not pushed upstream because I didn't want to participate.
- Summary
I hope you (or the Guix community) get something out of this before it bitrots.
Jookia.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: GuixSD on arm
2016-07-04 22:18 ` Jookia
` (2 preceding siblings ...)
2016-07-05 8:53 ` t3sserakt
@ 2016-07-05 12:08 ` ng0
2016-07-05 20:46 ` Ricardo Wurmus
4 siblings, 0 replies; 20+ messages in thread
From: ng0 @ 2016-07-05 12:08 UTC (permalink / raw)
To: help-guix; +Cc: Jookia, t3sserakt
Hi,
thanks for your reply Jookia.
This message makes it more clear to me why you quit/no longer
consider the other project a while (some months?) ago.
While I can not understand all of it, I have sympathy and can
understand the current decisions you made.
Further below a comment on some topics.
Jookia writes:
> On Mon, Jul 04, 2016 at 05:14:56PM +0000, ng0 wrote:
>> t3sserakt writes:
>>
>> > Hi Ludo,
>> >
>> > I would like to help, but I have no idea where to start.
>> > I am "just" an application developer, and do not have
>> > the right knowledge for doing this task alone.
>> >
>> > Additionally to that I am busy with helping the
>> > secushare (gnunet) project.
>> >
>> > But if there is somebody who knows in more detail
>> > what to do, I can help.
>>
>> I think Jookia was working on this.. or still is.. I am unsure
>> about the state of Jookia's work.
>> I'll CC Jookia and we'll see if this thread gets an reply.
>>
>> Additionally I CC'ed you t3ss because I don't know if you are
>> subscribed.
>
> Hi there!
>
> I started on an ARM port a few months ago with the intention of running the
> system on my Novena, but eventually gave up given the hard development cycle.
> I haven't talked about this before but I don't expect many people to read this
> email, so here goes. The main pain points were these:
>
> - Patches would get lost regularly.
>
> This is probably the biggest issue, and from reading the mailing list it doesn't
> seem to be solved. There was an attempt at adding a patch tracker but I guess
> that was lost too. I suggested at some point to use a newer version of Mailman
> which would help this, but the developers didn't think it useful. The suggested
> way to fix this is to reply and get people's attention about your patches again.
>
> I'm not cut out to what feels like nagging people when I don't know the reasons
> why they haven't replied. Perhaps this is how things work in other systems, but
> as someone that suffers from social anxiety and finds it hard enough to even
> send patches I can't deal with this, and Guix seems to be doing fine without me.
>
> - Feedback is little to none.
>
> As patches were lost and most discussion was done on the mail list, there was
> basically no discussion on patches or design problems. After getting Guix to
> boot on my Libreboot machine I went to work on fixing issues with the boot
> system, such as adding support for legacy Libreboot systems and encrypted
> bootloaders. This was lost.
>
> I also did some work to get LVM+LUKS working on Guix and tried to spark a
> discussion in to fixing the design issues in system configuration. I think there
> was about one reply, and it was lost.
>
> Some of the work that I did do and in fact got in somewhat by proxy is GTK+
> theming. There's a habit of maintainers fixing things themselves rather than
> taking patches, which I feel is a further hindrance to actually working on Guix.
>
> This gives me the impression that Guix doesn't have enough maintainers to
> sustain people doing new development upstream, want to do things themselves, or
> the project is just bad at communication.
At the moment Guix has about 35 regular contributors after 4
years. Gentoo has around 100 (or even more) after 16 or 17 years
or how long they exist now (even after many went on to other
distros).
We started using patchworks, it's okay for now, but I'm still not
completely happy. For me, It helps a bit in addition to marking
done patches as "expired" in my mail client.
Though it does not look like everyone is using patchworks, so
occasionally I go through it, marking resolved patches as what
they were resolved as. The only problem for me with it is a lack
of tls on the instance we use it on, and the register process
reads like you absolutely have to provide a first- and lastname
and it can't just be one word: in my case all patches send in by
'ng0' are now labeled as send by/author 'non such'.
I've got some further feedback regarding contribution and help
from people who don't use Email and who have a dislike for
freenode (contrary to what people claim there's is no freenode
hidden-service left). Feedback I'm taking into consideration for
a constructive proposal on changes, later when I have had enough
time to think and write about it.
It will include some longterm considerations, ideas and a
translations of an article (which is why it is taking some
time).
As a short immediate question: why did we choose freenode? why
not oftc, hackint, or a selfhosted psyced (irc,telnet,xmpp,psyc
access) instance? I know nothing is constant and frozen, and I
will give more input on the pro/cons etc in another thread,
another time.
> - GNUness over pragmatism.
>
> The main issue I had with doing an ARM port is the bootloader, and this is
> because everyone I spoke to except Ludovic seemed to be hesitant towards using a
> bootloader other than GRUB. Looking at the code base, I'd need to do make things
> less GRUB-specific which I was happy to do, but I didn't want to do it wrong or
> end up with my work ignored or thrown away.
>
> To be concrete, the conversation generally went like this: "To get the Novena
> booting Guix I'll need to add support for U-Boot as a bootloader." "I've heard
> GRUB works on ARM, have you tried that?" "Yes, it doesn't work from what I've
> tried." "Perhaps you've done it wrong." "I can't rule that out, but GRUB on ARM
> is still early work compared to U-Boot (which GRUB uses) and it'd work for more
> boards." then the conversation would drop off.
>
> I have a distinct feeling this is due to a bias in building "the GNU system"
> rather than building a fully free Guix-based system. I was originally going to
> do a fork of Guix with my own changes that people could download, but in the end
> I just went back to NixOS which runs happily on my Novena and my Libreboot
> machine. The only reason I wanted to use Guix was so I could contribute patches
> upstream and not maintain ones locally like I do with NixOS.
>
> - Summary
>
> This experience has put me off of Guix, GNU and free software development. I
> don't blame any one, but more a system that doesn't incorporate people like me.
> I'm not going to elaborate more on this, I just had to get it off my chest.
>
> I'm willing to send you code and help you with what I've done: It's mostly
> reworking the bootloader. There's no ARM support yet, but I did identify the
> points that need changing.
>
> Cheers,
> Jookia.
--
♥Ⓐ ng0
For non-prism friendly talk find me on http://www.psyced.org
SecuShare – http://secushare.org
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: GuixSD on arm
2016-07-04 22:18 ` Jookia
` (3 preceding siblings ...)
2016-07-05 12:08 ` ng0
@ 2016-07-05 20:46 ` Ricardo Wurmus
4 siblings, 0 replies; 20+ messages in thread
From: Ricardo Wurmus @ 2016-07-05 20:46 UTC (permalink / raw)
To: Jookia; +Cc: help-guix, t3sserakt
Jookia <166291@gmail.com> writes:
> - Patches would get lost regularly.
Yeah, this is still a problem for me. Many patches slip by because I
have no capacity to review them in time. I have settled on reviewing
things that I feel I’m a little more qualified to review than others,
such as R packages, scientific software, audio software. But it’s
really tough to review things *well* and in time.
In my opinion, patchwork hasn’t improved this, unfortunately, because
patch management requires too much effort (patches aren’t reliably
marked as merged, no email control, etc).
> I'm not cut out to what feels like nagging people when I don't know the reasons
> why they haven't replied. Perhaps this is how things work in other systems, but
> as someone that suffers from social anxiety and finds it hard enough to even
> send patches I can't deal with this, and Guix seems to be doing fine without me.
I’m sad to hear that this makes it hard for you to continue to
contribute to Guix.
In my case a lack of a response is usually just a result of having too
many other things to work on. Sometimes it’s because I really don’t
feel qualified to answer (as in the case of LUKS+Libreboot because at
that time I didn’t have any experience with Libreboot).
> As patches were lost and most discussion was done on the mail list, there was
> basically no discussion on patches or design problems. After getting Guix to
> boot on my Libreboot machine I went to work on fixing issues with the boot
> system, such as adding support for legacy Libreboot systems and encrypted
> bootloaders. This was lost.
>
> I also did some work to get LVM+LUKS working on Guix and tried to spark a
> discussion in to fixing the design issues in system configuration. I think there
> was about one reply, and it was lost.
Now that my laptop is running Libreboot I’m actually looking at the
discussions you started to see how we can move forward there. Thank you
for your experimentation and documenting your work on the mailing list!
I can assure you that it’s not lost (just not used in the moment).
> This experience has put me off of Guix, GNU and free software development. I
> don't blame any one, but more a system that doesn't incorporate people like me.
That’s sad and I hope you will be able to reconsider some time in the
future as the project matures.
~~ Ricardo
^ permalink raw reply [flat|nested] 20+ messages in thread