Re: A few questions: Libre SoC, website, Rust

[Almudena Garcia]

>
> > That'd be great! See the previous editions for the topics, but basically
> > anything about what is happening would be useful to talk about.
>
> Are there any features present in the latest images that weren’t in the 2019
> release that could be the basis of a post?

> I have to admit I don't remember from memory, but probably, yes.

If I remember well, the news in the 2019 image were the adding of the PCI Arbitrer (although a bit buggy, of course) and Lwip as alternative network stack.

> Making the page cool could attract people, yes. These will however have
> a lot of questions (they won't bother reading the FAQ). Personally I
> simply won't have time to answer. If people here on bug-hurd and #hurd
> do have, then sure go ahead.

I agree with Jan: Hurd needs to attract new people. Of course, these new people will have a lot of questions, and some of this could leave the project after a time.

But, if we get to reply successfully to these questions, many of them will be attracted to contribute with the project.

To attract new people we need to think in nowadays, and try to leave comments like "It's an easy problem. In the 90s It tooks so more effort than now"

We need to make the project easier for the novice, and a way for this is improve the website: improve and update the documentation, ease the access to the docs from the website,

ease the contributions (put a section about how to contribute could be a good idea), etc.

About docs, another good idea could be adding a section about "how to install" to Hurd website.

Two years ago, I wrote this guide about how to install Hurd over real hardware (https://gist.github.com/AlmuHS/f0c036631881756e817504d28217a910),

although most advice could apply to a VM installation anyway (the guide requires some update, of course).

The guide tries to be more "user-friendly" than the plain Debian's hurd-install article, and is written like a simple tutorial for Debian GNU/Hurd installation.

You can take this idea to put a "how to install" section in the Hurd website (the current "distrib" section is like a maze for this).

Other necessary tasks, as I told in other threads, it's improve the usability of the Hurd distributions, like Debian GNU/Hurd.

Since 2013 there have been many advances in the Debian installer (even, in 2017 I could install a desktop environment directly from the Debian GNU/Hurd installer).

But in latest versions there are some problems related with dependency problems in package installing, and some little problems in repositories signature, which makes the use of this distro a bit difficult.

If we want to attract new contributors, we need to solve these problems. Don't forget that the contributors, before being this, they are simple users.

If this user, after trying Hurd and research about this, disagrees with the appearance of the project (bad website, bad user experience...), It simply will leave the project, and even will speak badly about this.

So, I think that solving these problems is not a caprice, but a necessity.

El lun., 17 ago. 2020 a las 1:34, Jan Wielkiewicz (<tona_kosmicznego_smiecia@interia.pl>) escribió:

Dnia 2020-08-17, o godz. 00:07:25
Samuel Thibault <samuel.thibault@gnu.org> napisał(a):

> Whatever the "ideal" target would be (we have previously seen people
> saying arm would be), not targetting x86 as well looks like suicide to
> me.
I see.

> Why would they need to be? A firmware is not supposed to be
> OS-specific.
I mean drivers, not firmware, sorry.

>
> Yes, the main website is lagging behind. I don't really know
> how it is supposed to be updated, Thomas knows. Please bug
> hurd-maintainers@gnu.org about it. I have now pushed at least the news
> part.
>
Okay, will do, thanks.

> I know. That still does not mean I understand the *reasoning*.
>
Life is often about accidents, not about reasoning. I discovered GNU by
an accident, because of a proprietary game. Sounds stupid, but this is
the reality.

>
> There is no reason why we should have to chase the
> latest-shiny-brighty design trends (which basically means revamping
> the website every year or two) only to express that the project
> continues.
I just want to make the website cleaner to read and more informative,
that's it. I believe the current state is the opposite.

> I know, the monkey prefers the red car. But we are not monkeys.
Don't know this one.

> I'm afraid I'm not sure I want to attract people who only like
> shiny-brighty websites and can't stand a merely black-blue-on-white
> design. By this, I mean: personally I just ~#{[ don't have the #{[[
> time to answer their probably terribly large amount of questions.
The problem with stupid questions can be solved by putting the FAQ
section on the first plan so the information about asking questions
will be more accessible:
https://www.gnu.org/software/hurd/faq/asking_questions.html
To make my point clear: we're not going to add some stupid and laggy JS
slideshows, I just want the layout of the website to be helpful for the
readers.
Look at the website of Libre SoC as an example, it runs on ikiwiki too,
but one simple CSS file makes it pleasant to read:
https://libre-soc.org/
We could just adapt the CSS file from the website and that's all.

> That part makes full sense, yes. Now fixed.
Thanks.

> "professional" is a very relative thing. For me black-blue-on-white
> looks more professional than shiny-brighty. But again I'm probably
> simply just biaised and just not adapted to the world as it is
> nowadays.
We can leave it black-blue-on-white then.

> > By just saying on the main page "we're looking for developers for
> > X" we can gain new contributors.
>
> It is actually written there.
It was hidden below the outdated news section, didn't notice it.

> Which headaches precisely?
I mean a situation where we reorganise everything and no one knows
where something is located.

> Making the page cool could attract people, yes. These will however
> have a lot of questions (they won't bother reading the FAQ).
> Personally I simply won't have time to answer. If people here on
> bug-hurd and #hurd do have, then sure go ahead.
>
> I'm sorry I'm being very negative here, I know that's definitely not
> the way to run a cool and fun project. The thing is: I never asked
> for being in charge of doing this, and the other thing is: the most
> badly needed things that we lack is not really that much fun and cool.
>
Sorry, maybe I'm just too optimistic, I'm young after all.

> Just to give you an idea, read
> ./liblibc/src/fuchsia/mod.rs
> which is the Fuchsia file needed to make rust work on Fuchsia (there
> are others, but that's the main one).
>
> That's 3950 lines of code, which are neither fun or cool, but that we
> apparently *have* to write to make rust work at all on the Hurd,
> because it seems that rust maintainer never bothered to write
> something that would simply somehow generate these lines from the
> libc headers like compilers for other languages do.
>
I see.

> I don't think making the website shiny-and-brighty will attract people
> who will be patient enough to write such a file.
As above, I just want it to serve its purpose well - I want the website
to be informative and clean to read.

> Again, that's only my own opinion, and what my limited amount of free
> time can permit, I'm sorry that it looks so negative. If other people
> can help with this, feel free, it's an open project, I'm just warning
> what I have seen happening in the past decade.
We'll experiment with the page in a private git repository and if the
results will be good, we will think about the rest later.

> Samuel

Jan Wielkiewicz