A few questions: Libre SoC, website, Rust

[Jan Wielkiewicz]

Hello,

I'm not sure if you're aware of this, but there's a compeletely libre
CPU+GPU OpenPOWER chip in development and I think supporting it in
the Hurd will be crucial for free software.
https://libre-soc.org/
Full source code is available, drivers and firmware will be also under
a free license.
The OpenPOWER foundation released a libre-friendly EULA this February:
https://openpowerfoundation.org/final-draft-of-the-power-isa-eula-released/
The SoC is going to be 64-bit, mobile-class chip with 3D acceleration.
The developers are open to contributors and I think it is could be
possible to get a grant from NLNet foundation for porting the Hurd to
PowerPC (or whatever the architecture actually is).
Here's the progress of development:
https://libre-soc.org/3d_gpu/
My objective is: x86 processors are really hostile towards user freedom
due to backdoors like Intel ME or AMD PSP, the ISA itself is
proprietary, that's why porting the Hurd to x86_64 is even less
important than porting it to PowerPC.
If everything goes well, OpenPOWER processors will gain in popularity
and the Hurd together with it.

My second question is:
Do you have anything against if I and my friend modernized the website?
It looks like abandonware and is really harmful for the project.
The main page would be dedicated to promoting the project and would be
graphically appealing to convince the visitor the project is not dead.
The current page could be moved to a wiki section or somewhere else.
Also navigation is too complicated and messy, searching doesn't work at
all, because https://darnassus.sceen.net/cgi-bin/hurd-web is dead half
of the time.
Any special wishes?

Third question:
Do you have anything against Rust contributions into the project? My
friend is interested in contributing, but unfortunately in Rust, not C.
I wonder if rump drivers could be written in Rust, thanks
to the Hurd's modular architecture.


Jan Wielkiewicz

[Joshua Branson]

Jan Wielkiewicz <tona_kosmicz...@interia.pl> writes:

Hey Jan,

I'm an occasional Hurd web contribute (I haven't contributed anything
useful in a while). I'm not really a Hurd developer, but if I can
motivate/encourage you to achieve your goal, please let me know!

> Hello,
>
> I'm not sure if you're aware of this, but there's a compeletely libre
> CPU+GPU OpenPOWER chip in development and I think supporting it in
> the Hurd will be crucial for free software.
> https://libre-soc.org/
> Full source code is available, drivers and firmware will be also under
> a free license.
> The OpenPOWER foundation released a libre-friendly EULA this February:
> https://openpowerfoundation.org/final-draft-of-the-power-isa-eula-released/
> The SoC is going to be 64-bit, mobile-class chip with 3D acceleration.
> The developers are open to contributors and I think it is could be
> possible to get a grant from NLNet foundation for porting the Hurd to
> PowerPC (or whatever the architecture actually is).
> Here's the progress of development:
> https://libre-soc.org/3d_gpu/

I wonder if you know about this open 3D GPU:
https://www.crowdsupply.com/libre-risc-v/m-class

I'll email the leader the libre-risc-v and let him know about the
libre-soc.org website. Those guys should work together!

> My objective is: x86 processors are really hostile towards user freedom
> due to backdoors like Intel ME or AMD PSP, the ISA itself is
> proprietary, that's why porting the Hurd to x86_64 is even less
> important than porting it to PowerPC.
> If everything goes well, OpenPOWER processors will gain in popularity
> and the Hurd together with it.

I'm fairly certain that the Hurd developers would agree with you in
this. I believe that they would love it for the Hurd to work on
numerous architectures. I believe that the Hurd's glibc's port to
OpenPower, will need to be completed. For the more technical porting
details, you'll have to ask the other Hurd devs. I believe that this is
quite an involved task. :)

>
> My second question is:
> Do you have anything against if I and my friend modernized the website?
> It looks like abandonware and is really harmful for the project.
> The main page would be dedicated to promoting the project and would be
> graphically appealing to convince the visitor the project is not dead.
> The current page could be moved to a wiki section or somewhere else.
> Also navigation is too complicated and messy, searching doesn't work at
> all, because https://darnassus.sceen.net/cgi-bin/hurd-web is dead half
> of the time.
> Any special wishes?

Please do! We would love it if the Hurd looked "hipster" and fun! The
easiest thing you could do would be to tweak the css files, but I
believe that Samuel would be open to talks to move from ikiwiki to some
other wiki you might prefer. Please send any patches to the website, to
bug-...@gnu.org. We haven't used web-...@gnu.org in a while.

> Third question:
> Do you have anything against Rust contributions into the project? My
> friend is interested in contributing, but unfortunately in Rust, not C.
> I wonder if rump drivers could be written in Rust, thanks
> to the Hurd's modular architecture.

Again, I'm speculating here, but Samuel might be ok with this. I don't
know how well rust support is in the Hurd. You might have to port rust
to the Hurd, which is non-trivial. I think we are still working on
getting Go to work on the Hurd. :)

> Jan Wielkiewicz
>

--
Joshua Branson
Sent from Emacs and Gnus

[Samuel Thibault]

Hello,

Jan Wielkiewicz, le sam. 15 août 2020 18:51:27 +0200, a ecrit:

> I'm not sure if you're aware of this, but there's a compeletely libre
> CPU+GPU OpenPOWER chip in development and I think supporting it in
> the Hurd will be crucial for free software.
> https://libre-soc.org/

That would be interesting indeed.

> The developers are open to contributors and I think it is could be
> possible to get a grant from NLNet foundation for porting the Hurd to
> PowerPC (or whatever the architecture actually is).

More than a grant, it's people that we would need (yes, a grant could
help here but in the end it's people that matter).

> My objective is: x86 processors are really hostile towards user freedom
> due to backdoors like Intel ME or AMD PSP, the ISA itself is
> proprietary, that's why porting the Hurd to x86_64 is even less
> important than porting it to PowerPC.

"Important" is a delicate word to say.

Being able to work on people's hardware is also a very important thing.
You won't attract people to your OS if it can only run on some "obscure"
hardware. Supporting x86 remains some must, and porting to 64bit will be
the most efficient way of fixing the pending year-2038 issue.

Also, we need to port to 64bit at all at some point. It's way easier to
do this from something that works (i386) than from scratch. And then a
powerpc64 port (or whatever 64bit port) will be much easier since the
64bit question will have been solved.

> Do you have anything against if I and my friend modernized the website?
> It looks like abandonware and is really harmful for the project.

It depends what you call "modernization". Putting javascript etc. is
basically a no-go. Redesign the css etc. would probably be useful
indeed. But also we need somebody to keep up with the
quarter-of-the-hurd just to mention on the website what is actually
happening.

> The main page would be dedicated to promoting the project and would be
> graphically appealing to convince the visitor the project is not dead.

I will probably never understand the reasoning behind "graphically
appealing => is alive", but I guess that's the world we live in.

> The current page could be moved to a wiki section or somewhere else.

It is already a wiki.

> Do you have anything against Rust contributions into the project? My
> friend is interested in contributing, but unfortunately in Rust, not C.
> I wonder if rump drivers could be written in Rust, thanks
> to the Hurd's modular architecture.

Yes, some things could be done in rust. But rust would need to be ported
first. I did have a look, and the work needed there (basically, explain
rust the API of each and every function provided by libc, while rust
could merely read it from the .h files) discouraged me quite a bit.

That being said, see fsf's concern about the "rust" trademark:
https://directory.fsf.org/wiki/Rust

Samuel

[Samuel Thibault]

Samuel Thibault, le dim. 16 août 2020 16:39:12 +0200, a ecrit:

> > Do you have anything against if I and my friend modernized the website?
> > It looks like abandonware and is really harmful for the project.
>
> It depends what you call "modernization". Putting javascript etc. is
> basically a no-go.

(I mean, see fsf's concern about javascript).

Samuel

[Andrew Eggenberger]

I'd be willing to write updates for the website on a regular basis with some guidance about topics. One of the problems I'd had using the hurd websites is that information is often duplicated with minor variations and little indication of what is most up-to-date or relevant or its presentation isn't as user-friendly as it could be (chat transcripts, for example). I think a lot could be cleaned up and made more usable short of a complete redesign, not that one couldn't help.

Andrew Eggenberger

[Jan Wielkiewicz]

Dnia 2020-08-16, o godz. 16:39:12
Samuel Thibault <samuel....@gnu.org> napisał(a):

> Hello,

>
> More than a grant, it's people that we would need (yes, a grant could
> help here but in the end it's people that matter).

I believe the website could help here, explanation below.

> Being able to work on people's hardware is also a very important
> thing. You won't attract people to your OS if it can only run on some
> "obscure" hardware. Supporting x86 remains some must, and porting to
> 64bit will be the most efficient way of fixing the pending year-2038
> issue.

I see. I'm not sure if the Hurd's ideal target are x86 devices anyway.
I'm using Guix with Linux-libre on my proprietary machine and the
"experience" is rather limited - like 4 hangs a day due to some
problems with deblobbed firmware and the hardware support is poor
already.
Are companies going to write proprietary firmware for the Hurd in the
near future? Likely not. Is anynoe going to reverse-engineer "modern"
x86 hardware? Likely not, too much effort, it would be done already for
Linux-libre, if it were easy.
Libre SoC is the best opportunity to get the Hurd completely working on
some hardware, not just partially on user-hostile devices.
Running GNU/Linux-libre distributions is already only possible on
"dedicated" hardware like these over 10 years old ThinkPads, not to
mention the Hurd. People who want to run only free software on their
hardware are already forced to buy some obscure hardware and I see no
barriers that would make them not buy also dedidated hardware, but new
and freedom-friendly for the Hurd.
By providing Libre SoC support for the Hurd, the project can prepare
for *new* hardware that's already comming, instead of trying to chase
10 years old proprietary junk.

> Also, we need to port to 64bit at all at some point. It's way easier
> to do this from something that works (i386) than from scratch. And
> then a powerpc64 port (or whatever 64bit port) will be much easier
> since the 64bit question will have been solved.

Then porting to x86_64 is justified.

> It depends what you call "modernization". Putting javascript etc. is

> basically a no-go. Redesign the css etc. would probably be useful
> indeed.

We're not going to add some unneeded bloat, just some CSS eyecandy and
actual features. Also answering your later message, I'm aware of "the
JavaScript Trap" and this is not a big issue here - all we have to do is
to release our scripts (if any) as free software and to add some
metadata on to the website so GNU LibreJS knows the scripts are free
software.

> But also we need somebody to keep up with the
> quarter-of-the-hurd just to mention on the website what is actually
> happening.

Currently the latest news on the website are "2016-12-18-releases".
I'm not talking about news from https://darnassus.sceen.net/ , because
it is not accessible from the official website and is dead half of the
time, for example now.
The lazy solution to this would be:
"The Hurd is still alive, check out our git repository and mailing
list!"
I could write some short notes if my English is good enough.

> I will probably never understand the reasoning behind "graphically
> appealing => is alive", but I guess that's the world we live in.

How we present the project to the world and its appearance is extremely
important to success of the project, a good example of this can be seen
in the animal world:
Some animals pretend to be dead in order to trick predators into
thinking something is wrong with them:
https://en.wikipedia.org/wiki/Apparent_death
We don't want the Hurd to be as successful in pretending we're dead as
these animals, do we? :)
People are simple - they see an old website, with latest news from 2016
and assume the project is dead. Not everyone is as curious as me to
check the mailing list or git repo.
I started contributing to Guix, just because the website convinced me
the project is worth it, also because it is a GNU project, but the
website was more important.
professional website = people thinking the project is professional
By just saying on the main page "we're looking for developers for X" we
can gain new contributors. Just because I told my friend about the
Hurd, he's now willing to contribute.
This is the power of presentation. Really, I had to tell people all
around the Internet, the Hurd is still alive, because they thought
otherwise!

> It is already a wiki.

Yes I know, what I mean by this is we could make the main page with sole
purpose of showing the Hurd is cool and still alive and a candy shop
people want to come and from this cool main page, there would be a link
to the wiki, the current web page we don't want to show anyone but
maintainers. This would save the current maintainers from headaches.
The navigation on the website is also hard, but I'm not sure I'm
competent enough to reorganise the wiki more logically and the main
goal of making the new website is what I said above - showing the Hurd
is cool.

> Yes, some things could be done in rust. But rust would need to be
> ported first.

By this you mean it should just run as on GNU/Linux or are there some
*special Hurd steps* to port a language to it? I can check if Rust runs
already on the Guix Hurd images.

> I did have a look, and the work needed there
> (basically, explain rust the API of each and every function provided
> by libc, while rust could merely read it from the .h files)
> discouraged me quite a bit.

I see, I'll ask my friend if he understands this, he's a better
programmer than me.

> That being said, see fsf's concern about the "rust" trademark:
> https://directory.fsf.org/wiki/Rust

If this is the case, this needs to be also solved in Guix. I wonder if
the problem could be solved by just changing all occurrences of Rust to
say Stainless, just like is done for Firefox -> Icecat.
GNU Stainless sounds pretty good, I'll try doing it quickly and dirty
in Guix.

> Samuel


Jan Wielkiewicz

[Jan Wielkiewicz]

Dnia 2020-08-16, o godz. 09:44:38
Joshua Branson <jbr...@dismail.de> napisał(a):

> Jan Wielkiewicz <tona_kosmicz...@interia.pl> writes:
>
> Hey Jan,
>
> I'm an occasional Hurd web contribute (I haven't contributed anything
> useful in a while). I'm not really a Hurd developer, but if I can
> motivate/encourage you to achieve your goal, please let me know!
>

Okay, nice.

>
> I wonder if you know about this open 3D GPU:
> https://www.crowdsupply.com/libre-risc-v/m-class
>
> I'll email the leader the libre-risc-v and let him know about the
> libre-soc.org website. Those guys should work together!

They're the same actually :)
They changed the name, because they abandoned(?) the idea of using
Risc-V as the Risc-V foundation was hostine towards libre development.
https://lists.libre-soc.org/pipermail/libre-riscv-dev/2019-October/003035.html
OpenPOWER foundation is just more cooperative.

>
> I'm fairly certain that the Hurd developers would agree with you in
> this. I believe that they would love it for the Hurd to work on
> numerous architectures. I believe that the Hurd's glibc's port to
> OpenPower, will need to be completed. For the more technical porting
> details, you'll have to ask the other Hurd devs. I believe that this
> is quite an involved task. :)
>

I just wanted to make sure people are aware of this project, I'm not
competent enough to work on this task, but maybe in the future.

> Please do! We would love it if the Hurd looked "hipster" and fun!

Will do!

> Please send any patches to the
> website, to bug-...@gnu.org. We haven't used web-...@gnu.org in a
> while.

Okay.

> Again, I'm speculating here, but Samuel might be ok with this. I
> don't know how well rust support is in the Hurd. You might have to
> port rust to the Hurd, which is non-trivial. I think we are still
> working on getting Go to work on the Hurd. :)

I don't like Rust (yet) nor Go, but I think the project could gain from
using these new languages, just because they're *brand new* and popular
right now - people are looking for projects to contribute to gain
experience and have fun.

> --
> Joshua Branson
> Sent from Emacs and Gnus
>

I have to try sending my mails from Emacs one day

Jan Wielkiewicz

[Samuel Thibault]

Hello,

Andrew Eggenberger, le dim. 16 août 2020 12:55:29 -0500, a ecrit:

> I'd be willing to write updates for the website on a regular basis with some
> guidance about topics.

That'd be great! See the previous editions for the topics, but basically
anything about what is happening would be useful to talk about.

> One of the problems I'd had using the hurd websites is that
> information is often duplicated with minor variations and little
> indication of what is most up-to-date or relevant

You can check the date, or try or look by yourself to see what is
actually accurate, or ask on IRC or here.

> or its presentation isn't as user-friendly as it could be (chat
> transcripts, for example).

That's "the best that we currently have". Meaning, "yes, if we had time
to fix this it'd be fixed". We don't have that much manpower, so it's
how it is currently, and help is welcome.

Samuel

[Samuel Thibault]

Jan Wielkiewicz, le dim. 16 août 2020 21:00:26 +0200, a ecrit:

> > More than a grant, it's people that we would need (yes, a grant could
> > help here but in the end it's people that matter).
> I believe the website could help here, explanation below.

Sure. But also see below.

> > Being able to work on people's hardware is also a very important
> > thing. You won't attract people to your OS if it can only run on some
> > "obscure" hardware. Supporting x86 remains some must, and porting to
> > 64bit will be the most efficient way of fixing the pending year-2038
> > issue.
> I see. I'm not sure if the Hurd's ideal target are x86 devices anyway.

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.

> Are companies going to write proprietary firmware for the Hurd in the
> near future? Likely not.

Why would they need to be? A firmware is not supposed to be OS-specific.

> People who want to run only free software on their hardware are
> already forced to buy some obscure hardware

Ok, but I believe we do not want to target only them.

> By providing Libre SoC support for the Hurd, the project can prepare
> for *new* hardware that's already comming, instead of trying to chase
> 10 years old proprietary junk.

We are not really chasing for hardware support, we just use existing
drivers (Linux, OpenBSD, etc.)

> > It depends what you call "modernization". Putting javascript etc. is
> > basically a no-go. Redesign the css etc. would probably be useful
> > indeed.
> We're not going to add some unneeded bloat, just some CSS eyecandy and
> actual features. Also answering your later message, I'm aware of "the
> JavaScript Trap" and this is not a big issue here - all we have to do is
> to release our scripts (if any) as free software and to add some
> metadata on to the website so GNU LibreJS knows the scripts are free
> software.

Then that'd be all good.

> > But also we need somebody to keep up with the
> > quarter-of-the-hurd just to mention on the website what is actually
> > happening.
> Currently the latest news on the website are "2016-12-18-releases".

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

> > I will probably never understand the reasoning behind "graphically
> > appealing => is alive", but I guess that's the world we live in.
> How we present the project to the world and its appearance is extremely
> important to success of the project,

I know. That still does not mean I understand the *reasoning*.

> a good example of this can be seen in the animal world:

We are not animals.

> Some animals pretend to be dead in order to trick predators into
> thinking something is wrong with them:
> https://en.wikipedia.org/wiki/Apparent_death

Non-graphically appealing doesn't mean "dead".

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 know, the monkey prefers the red car. But we are not monkeys.

> People are simple - they see an old website,

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.

> with latest news from 2016 and assume the project is dead.

That part makes full sense, yes. Now fixed. Again, as I mentioned, it's
a matter of somebody actually taking the time of putting news there. I
don't have time to do such a thing, and I'm no good at that anyway. I
can proofread what somebody would write, though.

> professional website = people thinking the project is professional

"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.

> By just saying on the main page "we're looking for developers for X" we
> can gain new contributors.

It is actually written there.

> This is the power of presentation. Really, I had to tell people all
> around the Internet, the Hurd is still alive, because they thought
> otherwise!

The Hurd carries a huge background of urban legends etc. and most people
don't bother actually checking for themselves, so I'm not surprised at
all (and no, I don't think things were different in 2016 when the latest
news was fresh).

> > It is already a wiki.
> Yes I know, what I mean by this is we could make the main page with sole
> purpose of showing the Hurd is cool and still alive and a candy shop
> people want to come and from this cool main page, there would be a link
> to the wiki, the current web page we don't want to show anyone but
> maintainers. This would save the current maintainers from headaches.

Which headaches precisely?

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.

Just for instance, the rust support:

> > Yes, some things could be done in rust. But rust would need to be
> > ported first.
> By this you mean it should just run as on GNU/Linux or are there some
> *special Hurd steps* to port a language to it?

Just as on GNU/Linux.

> I can check if Rust runs already on the Guix Hurd images.

It just doesn't.

> > I did have a look, and the work needed there
> > (basically, explain rust the API of each and every function provided
> > by libc, while rust could merely read it from the .h files)
> > discouraged me quite a bit.
> I see, I'll ask my friend if he understands this, he's a better
> programmer than me.

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 don't think making the website shiny-and-brighty will attract people
who will be patient enough to write such a file.

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.

Samuel

[Andrew Eggenberger]

Hi Samuel

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’ve been following the email list for a while and I’ve seen commits. It’s hard to know what merits an announcement. Would a periodic (Monthly, day?) summary or commits and other news be a good starting point?

You can check the date, or try or look by yourself to see what is
actually accurate, or ask on IRC or here.

....

That's "the best that we currently have". Meaning, "yes, if we had time
to fix this it'd be fixed". We don't have that much manpower, so it's
how it is currently, and help is welcome.

Noted. I’ve been looking at the site more closely and may have some patches based on what I’ve found to be helpful to my own Hurd use.

Andrew

--

Andrew Eggenberger

[Samuel Thibault]

Andrew Eggenberger, le dim. 16 août 2020 17:49:37 -0500, a ecrit:

> > 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.

> I’ve been following the email list for a while and I’ve seen
> commits. It’s hard to know what merits an announcement.

If unsure, you can always ask and we'll tell.

> Would a periodic (Monthly, day?) summary or commits and other news be
> a good starting point?

A periodic summry could already be useful, yes (quarterly is probably
enough to have enough content)

> > That's "the best that we currently have". Meaning, "yes, if we had time
> > to fix this it'd be fixed". We don't have that much manpower, so it's
> > how it is currently, and help is welcome.
>
> Noted. I’ve been looking at the site more closely and may have some patches
> based on what I’ve found to be helpful to my own Hurd use.

That'll already be a good start!

Samuel

[Jan Wielkiewicz]

Dnia 2020-08-17, o godz. 00:07:25
Samuel Thibault <samuel....@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-mai...@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

[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.

[Joshua Branson]

You could also check out my GNU/Hurd cheatsheet. It's got lots of ideas
on the wiki that could use some updating:

https://notabug.org/jbranso/cheatsheets/src/master/hurd.org#wiki

[Joshua Branson]

You may also be interested in looking at this:

https://www.gnu.org/software/hurd/community/weblogs/ArneBab/how-i-write-a-qoth.html

It gives you a roadmap about how to regularly write about GNU/Hurd
updates!

It's awesome to have you aboard the team!

[Joshua Branson]

Jan Wielkiewicz <tona_kosmicz...@interia.pl> writes:

> Dnia 2020-08-16, o godz. 16:39:12
> Samuel Thibault <samuel....@gnu.org> napisał(a):
>
>> Hello,

> Currently the latest news on the website are "2016-12-18-releases".

> I'm not talking about news from https://darnassus.sceen.net/ , because
> it is not accessible from the official website and is dead half of the
> time, for example now.
> The lazy solution to this would be:
> "The Hurd is still alive, check out our git repository and mailing
> list!"
> I could write some short notes if my English is good enough.

I thought you were a native speaker! Your English is superb!

>
>> I will probably never understand the reasoning behind "graphically
>> appealing => is alive", but I guess that's the world we live in.
> How we present the project to the world and its appearance is extremely

> important to success of the project, a good example of this can be seen
> in the animal world:

> Some animals pretend to be dead in order to trick predators into
> thinking something is wrong with them:
> https://en.wikipedia.org/wiki/Apparent_death

> We don't want the Hurd to be as successful in pretending we're dead as
> these animals, do we? :)
> People are simple - they see an old website, with latest news from 2016
> and assume the project is dead. Not everyone is as curious as me to
> check the mailing list or git repo.
> I started contributing to Guix, just because the website convinced me
> the project is worth it, also because it is a GNU project, but the
> website was more important.

> professional website = people thinking the project is professional

> By just saying on the main page "we're looking for developers for X" we

> can gain new contributors. Just because I told my friend about the
> Hurd, he's now willing to contribute.

> This is the power of presentation. Really, I had to tell people all
> around the Internet, the Hurd is still alive, because they thought
> otherwise!

This is pretty true. That's kind of the main reason I started playing
with GNU Guix too!

>
>> It is already a wiki.
> Yes I know, what I mean by this is we could make the main page with sole
> purpose of showing the Hurd is cool and still alive and a candy shop
> people want to come and from this cool main page, there would be a link
> to the wiki, the current web page we don't want to show anyone but
> maintainers. This would save the current maintainers from headaches.

> The navigation on the website is also hard, but I'm not sure I'm
> competent enough to reorganise the wiki more logically and the main
> goal of making the new website is what I said above - showing the Hurd
> is cool.

I have thought about this for a long time! That's a fantastic idea!

>
>
>> Samuel
>
> Jan Wielkiewicz

[Joshua Branson]

Samuel Thibault <samuel....@gnu.org> writes:

> Jan Wielkiewicz, le dim. 16 août 2020 21:00:26 +0200, a ecrit:
>> > More than a grant, it's people that we would need (yes, a grant could
>> > help here but in the end it's people that matter).
>> I believe the website could help here, explanation below.

May I suggest we make a business out of the GNU/Hurd? I own the domain
gnu-hurd.com. My original business plan was to host static blog sites
for young programmers for $2 or $3 per month. And or sell librebooted
laptops. We can do both if anyone is interested in joining me in this
endeavor. I'm also open to any and all business proposals. I only own
the domain gnu-hurd.com. I'm not proposing that I own the project or
the direction the GNU/Hurd takes. Samuel is our fearless leader!

>
> Sure. But also see below.
>
>> > Being able to work on people's hardware is also a very important
>> > thing. You won't attract people to your OS if it can only run on some
>> > "obscure" hardware. Supporting x86 remains some must, and porting to
>> > 64bit will be the most efficient way of fixing the pending year-2038
>> > issue.
>> I see. I'm not sure if the Hurd's ideal target are x86 devices anyway.

Again, we could sell hardware that runs on the Hurd. This is a problem
that a business could solve. We could sell a laptop that dual boots the
Hurd and debian or guix. That way the user can choose at boot time: is
it time to play with the Hurd? Or is it time to get work done with a
modern firefox web browser in debian?

>
>> By providing Libre SoC support for the Hurd, the project can prepare
>> for *new* hardware that's already comming, instead of trying to chase
>> 10 years old proprietary junk.

You may be interested in talking to Richard Braun. He's mostly stepped
away from GNU/Hurd development, but he's working on his own
kernel. (it's really similar to the Hurd) He's been porting it to Arm
recently. He could give you some tips about how to port the GNU/Hurd.
Apart from Samuel, Richard Braun may be one of the best and most
knowledgeable GNU/Hurd developers alive today.

https://www.sceen.net/x15/

> 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.
>

You do a terrific job for the Hurd Samuel! You are perhaps the best
leader it's ever had. It would have faded away into nothing without
you. Thanks for your dedication!

>> with latest news from 2016 and assume the project is dead.
>

> That part makes full sense, yes. Now fixed. Again, as I mentioned, it's
> a matter of somebody actually taking the time of putting news there. I
> don't have time to do such a thing, and I'm no good at that anyway. I
> can proofread what somebody would write, though.
>

> 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.

Samuel I don't think you're being negative. You're being somewhat
realistic. For those of you who don't know, Samuel routinely has to
respond to emails like "Why does the Hurd project suck! Do it right!"
I admit that I once sent him such an email. Sorry bro. :(

>
> Samuel

[Joshua Branson]

Jan Wielkiewicz <tona_kosmicz...@interia.pl> writes:

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

>> 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.
>

Do ya'll want to know how I found out about GNU? hahaha. I was reading
Linus Torvald's C standards in the Linux kernel documentation. In it he
said, "Go and read the GNU coding standards. Then burn the documents.
It'll be a good symbolic gesture."

hahaha. I went to the gnu.org website, and I completely agree with
Dr. Stallman and the FSF position over Linus's non-copyleft. :)

>>
>> 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 would tend to agree with this. Sometimes information is duplicated.
etc. What you could do, is show off the wiki to some random people.
Ask them to move around the website. You could ask them to find
specific things. If they have trouble navigating the site, you could
try to figure out why. And then correct the issues.

>> 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.

awesome!

>
>> Samuel
>
> Jan Wielkiewicz

[Joshua Branson]

Jan Wielkiewicz <tona_kosmicz...@interia.pl> writes:

> Dnia 2020-08-16, o godz. 09:44:38
> Joshua Branson <jbr...@dismail.de> napisał(a):

>> I'll email the leader the libre-risc-v and let him know about the
>> libre-soc.org website. Those guys should work together!
> They're the same actually :)
> They changed the name, because they abandoned(?) the idea of using
> Risc-V as the Risc-V foundation was hostine towards libre development.
> https://lists.libre-soc.org/pipermail/libre-riscv-dev/2019-October/003035.html
> OpenPOWER foundation is just more cooperative.

What! No way! How about that shiny Alaskan asparagus tips! I did not
know!

>
>>
>> I'm fairly certain that the Hurd developers would agree with you in
>> this. I believe that they would love it for the Hurd to work on
>> numerous architectures. I believe that the Hurd's glibc's port to
>> OpenPower, will need to be completed. For the more technical porting
>> details, you'll have to ask the other Hurd devs. I believe that this
>> is quite an involved task. :)
>>
> I just wanted to make sure people are aware of this project, I'm not
> competent enough to work on this task, but maybe in the future.

I believe in you. "You are stronger than you feel, braver than you
know, wiser beyond your years. Where-ever you go, there's something
that you must always remember, I'll always be with you."

- Winnie the Pooh

>> Again, I'm speculating here, but Samuel might be ok with this. I
>> don't know how well rust support is in the Hurd. You might have to
>> port rust to the Hurd, which is non-trivial. I think we are still
>> working on getting Go to work on the Hurd. :)
> I don't like Rust (yet) nor Go, but I think the project could gain from
> using these new languages, just because they're *brand new* and popular
> right now - people are looking for projects to contribute to gain
> experience and have fun.

Have you heard about zig yet? It's a language that is faster than C!
Now it depends on LLVM, and we would rather have it depend on GCC. But
maybe you could write a zig alternative that is powered by GCC?

https://ziglang.org/

>
>> --
>> Joshua Branson
>> Sent from Emacs and Gnus
>>
>

> I have to try sending my mails from Emacs one day

https://video.hardlimit.com/videos/watch/22b0af22-f1b3-469c-b09b-65e82b3f9643

That'll give you some tips...Most serious GNU maintainers tend to use
Gnus. I use Gnus, because I want to be just like Samuel :) And Ludo
:). And John Wigley! John Wigley has his Gnus set up, so that, he can
say, "I do not want to hear from this email thread, unless my name is
specifically mentioned again."

I personally am still figuring out how to get searching in Gnus
working. :)

[Samuel Thibault]

Jan Wielkiewicz, le dim. 16 août 2020 21:00:26 +0200, a ecrit:

> Dnia 2020-08-16, o godz. 16:39:12
> Samuel Thibault <samuel....@gnu.org> napisał(a):

> > That being said, see fsf's concern about the "rust" trademark:
> > https://directory.fsf.org/wiki/Rust
> If this is the case, this needs to be also solved in Guix.

There seems to be some move in there, see

https://blog.rust-lang.org/2020/08/18/laying-the-foundation-for-rusts-future.html

Samuel

[Jan Wielkiewicz]

Dnia 2020-08-19, o godz. 10:41:42
Samuel Thibault <samuel....@gnu.org> napisał(a):

> There seems to be some move in there, see
>
> https://blog.rust-lang.org/2020/08/18/laying-the-foundation-for-rusts-future.html

Yes, I saw this, but nothing especially indicates they will make the
trademarks more user-friendly. Someone familiar with trademark law
should probably contact them after the foundation is ready.

> Samuel

Jan Wielkiewicz

[Samuel Thibault]

Jan Wielkiewicz, le lun. 17 août 2020 01:33:41 +0200, a ecrit:

> > I know. That still does not mean I understand the *reasoning*.
> >
> Life is often about accidents, not about reasoning.

Discovering something by accident, yes. But deciding to have a look at
some project only because the website is all shiny, no, I do not
understand. Actually almost the contrary in my case, if I see a shiny
website telling me "this is great software!", I become all wary, for
fear of overzealous marketting.

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

Please keep more mail context, I had to dig back on this one. I still
don't understand what you mean here.

> > 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.

Great!

Samuel

[Samuel Thibault]

Joshua Branson, le mar. 18 août 2020 10:25:17 -0400, a ecrit:

> Samuel Thibault <samuel....@gnu.org> writes:
> > Jan Wielkiewicz, le dim. 16 août 2020 21:00:26 +0200, a ecrit:

> >> > More than a grant, it's people that we would need (yes, a grant could
> >> > help here but in the end it's people that matter).
> >> I believe the website could help here, explanation below.
>
> May I suggest we make a business out of the GNU/Hurd?

I don't think we really can, for various reasons I don't really have
time to explain in details, but basically we can't claim the GNU/Hurd is
actually secure (even if the principles are really good for security,
AFAIK nobody has made an actual security review over the code), it is
slower than Linux, it doesn't support SMP yet, etc. I don't see how
we could be competitive with anything that is currently on the market
already.

> I'm not proposing that I own the project or
> the direction the GNU/Hurd takes. Samuel is our fearless leader!

I'm not, actually.
(I'm not even a Hurd maintainer officially)

Note that I'm really talking about the *lead* part, not the maintenance
part.

Samuel

[Almudena Garcia]

> But deciding to have a look at some project only because the website is all shiny, no.

It is more important than you're thinking now. So many times, when I talk about Hurd with friends, my friends are afraid because the website is old, ugly, out-of-date, and very confusing.

All the time I have to search and share with them the exact links of the main pages (FAQ, docs, latest Debian GNU/Hurd image, Debian GNU/Hurd installing tips...).

I wrote my own tutorials for these people, because they usually aren't able to find information about how to install, how to use... etc, in an easy way.

Many times, some friend who has been interested in Hurd, left the idea of using that system due to these difficulties.

So yes, renew and doing the web more accessible and attractive is very important to get attract new users and contributors

[Samuel Thibault]

Almudena Garcia, le jeu. 20 août 2020 00:03:08 +0200, a ecrit:

> > But deciding to have a look at some project only because the website is all
> > shiny, no.
> It is more important than you're thinking now.

AGAIN I'm saying it's not "important". What I'm saying is that I don't
understand the *reasoning* behind people actually thinking that an
all-shiny website truly means a technically sound project.

Yes, the website probably needs some reorganization so that newcomers
find the information they need more easily etc. I'm not talking about
this.

I'm talking about the flurry of cosmetic *trends* I see on all websites.
Every year or couple of year has its own marketting trend, and if you
don't follow it each time (thus consuming your time just for that),
you'd be considered "old" and "ugly". It's that haste, completely
unrelated to the actual content of the website that I just don't
understand from people with a more evolved brain than monkeys have.

Samuel

[Almudena Garcia]

> Every year or couple of year has its own marketting trend, and if you
> don't follow it each time (thus consuming your time just for that),

In fact, It's not necessary to follow the hype about a technology or a trend.

But It's not necessary to follow the hype to create a beautiful webpage. The current page is many 90s style.

The FSF webpage (https://www.fsf.org/) is more beautiful than the current Hurd webpage, for example. The GNU project's main website (https://www.gnu.org/) is a good example too.

So, It's possible to make a beautiful and useful webpage, without following the latest trends and hype.

[Dr. Arne Babenhauserheide]

Samuel Thibault <samuel....@gnu.org> writes:

> Almudena Garcia, le jeu. 20 août 2020 00:03:08 +0200, a ecrit:
>> > But deciding to have a look at some project only because the website is all
>> > shiny, no.
>> It is more important than you're thinking now.
>
> AGAIN I'm saying it's not "important". What I'm saying is that I don't
> understand the *reasoning* behind people actually thinking that an
> all-shiny website truly means a technically sound project.

I think what people react to is the feeling that the developers care. A
shiny website suggests that the developers care about getting new users.
An trendy website suggests that devevelopment is active right now —
similar to a news section where the last entry is from the current year.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[Richard Braun]

On Thu, Aug 20, 2020 at 02:32:03AM +0200, Almudena Garcia wrote:
> > Every year or couple of year has its own marketting trend, and if you
> > don't follow it each time (thus consuming your time just for that),
> In fact, It's not necessary to follow the hype about a technology or a
> trend.
> But It's not necessary to follow the hype to create a beautiful webpage.
> The current page is many 90s style.
> The FSF webpage (https://www.fsf.org/) is more beautiful than the current
> Hurd webpage, for example. The GNU project's main website (
> https://www.gnu.org/) is a good example too.

As Samuel said, don't mix "beautiful" and "useful" or even "easy to use".
State the subject clearly and stick to it. The reason the Hurd doesn't
have a good web site, or good documentation, or good performance, or
good device support, etc..., is the same as always : too few people.

I'm pretty sure changing the web site won't change much to that, there
needs to be some momentum to bootstrap the first changes in what people
care most about (which for me is a much more reliable system than what
it currently is, or could be without too much effort) and then it'll
attract people.

To all who whine about information not being easy to find : sure, it
could be better, but it's there, so if people give up that quickly, I
believe it says more about our current culture, or even the character
of these people, than it says about the project itself. Grow up and
focus on what matters.

--
Richard Braun

[Almudena Garcia]

> The reason the Hurd doesn't have a good web site, or good documentation, or good performance, or

> good device support, etc..., is the same as always : too few people.

But, about the website, if I remember well, this thread started because of an offer to update the website.

Why don't we accept the offer?

It's a bad idea to reject this type of offer only for prejudices about the attractive.

> I'm pretty sure changing the web site won't change much to that, there
> needs to be some momentum to bootstrap the first changes in what people
> care most about (which for me is a much more reliable system than what
> it currently is, or could be without too much effort) and then it'll
> attract people.

As I told before, I know many people who reject Hurd after showing some interest, simply because the webpage seems to show a dead project (search about "halo effect")

Not only because of the latest news, but the 90s style appearance of the website, and the outdated documentation.

About docs, these days I've been seeing a mail thread about someone which is working to update this.

[Richard Braun]

On Thu, Aug 20, 2020 at 03:19:56PM +0200, Almudena Garcia wrote:
> But, about the website, if I remember well, this thread started because of
> an offer to update the website.
> Why don't we accept the offer?
>
> It's a bad idea to reject this type of offer only for prejudices about the
> attractive.

The help was not refused. Samuel actually said it's all fine after
clarifying a few things.

> As I told before, I know many people who reject Hurd after showing some
> interest, simply because the webpage seems to show a dead project (search
> about "halo effect")
> Not only because of the latest news, but the 90s style appearance of the
> website, and the outdated documentation.

Who's prejudiced now ? And if we're going that way, then the point I was
making in my previous message, which I hoped you would have understood,
is that I don't want to work with people who give up because it takes them
more than a few seconds to find information, or who evaluate a project
based on the look of its web site. You're mentioning the halo effect and
you're right, I'd much rather work with people who have as few cognitive
biases as possible, so call me prejudiced against the others if you want,
at least I have a strong argument for my case.

--
Richard Braun

[Almudena Garcia]

> I don't want to work with people who give up because it takes them
> more than a few seconds to find information, or who evaluate a project

> based on the look of its web site.

This is a prejudice, in fact.

If we want to attract new users who can become contributors, we have to make the beginning and the initial steps as easy as we can.

You talk about "a few seconds" to find information but, when you are a noob, these searches can take hours or even days, because you don't know what is the term to search.

If the website is user-friendly, this type of "explorers" can quickly find all the information about this project, and even know new details that this person doesn't know about.

If the website looks "modern" (not necessarily following the latest hype, simply "elegant"), this explorer will think that the project is in active development and It feels attracted to continue researching about this.

If the website looks ugly and old, the explorer will think that the project is mostly dead, and doesn't take the effort to continue the research.

We have to leave the 90s ideas, and think as younger people thinks nowadays (It don't refers to think as a teenager, simply remove elitists ideas and prejudices about "who merit work in this project")

[Samuel Thibault]

Almudena Garcia, le jeu. 20 août 2020 23:10:53 +0200, a ecrit:

> We have to leave the 90s ideas, and think as younger people thinks nowadays (It
> don't refers to think as a teenager, simply remove elitists ideas and
> prejudices about "who merit work in this project")

It's not a question of merit, but a question of patience. If new
generations have a problem with being patient, they will have a problem
with making computers work at all. Operating systems things *require*
attention and patience, there is no shortcut around it. If we don't
manage to warn new generations about it, they will learn it the very
hard way by suffering from odd bugs that happen randomly and with nobody
out there able to fix them.

Samuel

[Jan Wielkiewicz]

Dnia 2020-08-20, o godz. 18:06:02
Richard Braun <rbr...@sceen.net> napisał(a):

> On Thu, Aug 20, 2020 at 03:19:56PM +0200, Almudena Garcia wrote:
> > But, about the website, if I remember well, this thread started
> > because of an offer to update the website.
> > Why don't we accept the offer?
> >
> > It's a bad idea to reject this type of offer only for prejudices
> > about the attractive.
>
> The help was not refused. Samuel actually said it's all fine after
> clarifying a few things.
>
> > As I told before, I know many people who reject Hurd after showing
> > some interest, simply because the webpage seems to show a dead
> > project (search about "halo effect")
> > Not only because of the latest news, but the 90s style appearance
> > of the website, and the outdated documentation.
>
> Who's prejudiced now ? And if we're going that way, then the point I
> was making in my previous message, which I hoped you would have
> understood, is that I don't want to work with people who give up
> because it takes them more than a few seconds to find information, or
> who evaluate a project based on the look of its web site. You're
> mentioning the halo effect and you're right, I'd much rather work
> with people who have as few cognitive biases as possible, so call me
> prejudiced against the others if you want, at least I have a strong
> argument for my case.
>

Please stop arguing, everyone.
I already made some notes about how to make the web page more readable,
we'll be judging the effects when its done.
Don't waste more time on arguing than it's worth.

As for Samuel's and yours opinion about people with cognitive biases,
etc, remember not everyone who visits the page is a system developer -
sometimes an unrelated person can visit the page. In this case if that
person finds the web page interesting (even due to cognitive bias),
there's a possibility the person will tell others about the finding.
If the web page looks bad, abandoned, isn't convincing, then the person
just won't care or even worse, will tell others the Hurd is abandonware.
There's a small chance an incompetent person will tell their more
competent friends about it, and that's our chance.
All I want to do is to increase the probability.


Jan Wielkiewicz

[Jan Wielkiewicz]

Dnia 2020-08-19, o godz. 23:48:26
Samuel Thibault <samuel....@gnu.org> napisał(a):

> Jan Wielkiewicz, le lun. 17 août 2020 01:33:41 +0200, a ecrit:
> > > I know. That still does not mean I understand the *reasoning*.
> > >
> > Life is often about accidents, not about reasoning.
>

> Discovering something by accident, yes. But deciding to have a look at

> some project only because the website is all shiny, no, I do not
> understand. Actually almost the contrary in my case, if I see a shiny
> website telling me "this is great software!", I become all wary, for
> fear of overzealous marketting.

Don't worry, no marketing, I hate marketing myself.
My favorite example of malicious marketing is Apple telling its
customers about privacy :)
Let's just encourage contributors a bit and show the *actual* state of
the project on the website - updated news and a link to commits will do.

> > > Which headaches precisely?
> > I mean a situation where we reorganise everything and no one knows
> > where something is located.
>
> Please keep more mail context, I had to dig back on this one. I still
> don't understand what you mean here.

Nevermind, nothing important, I just can't explain it in English.

> > > 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.
>
> Great!
>
> Samuel

Jan Wielkiewicz

[Richard Braun]

On Thu, Aug 20, 2020 at 11:10:53PM +0200, Almudena Garcia wrote:
> > I don't want to work with people who give up because it takes them
> > more than a few seconds to find information, or who evaluate a project
> > based on the look of its web site.

> This is a prejudice, in fact.

The definition of a prejudice includes "not being based on reason
or actual experience". That doesn't apply here.

> If we want to attract new users who can become contributors, we have to
> make the beginning and the initial steps as easy as we can.
> You talk about "a few seconds" to find information but, when you are a
> noob, these searches can take hours or even days, because you don't know
> what is the term to search.
> If the website is user-friendly, this type of "explorers" can quickly find
> all the information about this project, and even know new details that this
> person doesn't know about.

Again, you're mixing "beautiful" and "useful". In any big code base, it's
perfectly normal for a newcomer to spend hours or even days looking for
obscure pieces of information without an interactive way to get your answer
(think mailing list or mentor). Anyone who expects things to happen more
quickly and gives up is very likely not willing to make the proper effort
to get things right in their code afterwards.

> If the website looks "modern" (not necessarily following the latest hype,
> simply "elegant"), this explorer will think that the project is in active
> development and It feels attracted to continue researching about this.
> If the website looks ugly and old, the explorer will think that the project
> is mostly dead, and doesn't take the effort to continue the research.

Tell me the state of the Hurd project again ? I think the web site is
pretty honest about that. If I were a newcomer looking at a "beautiful"
web site, whatever that would be, and found an old code base with roughly
one serious maintainer and a few contributors here and there, I'd get to
think the project is vaporware with good marketing and feel pretty cheated,
and may not want to go on further either.

> We have to leave the 90s ideas, and think as younger people thinks nowadays
> (It don't refers to think as a teenager, simply remove elitists ideas and
> prejudices about "who merit work in this project")

I don't see why the "90s ideas", whatever you're referring to, must be
abandoned. I don't see why "we" should adapt to how younger people think,
especially considering how many I know do think (or, really, don't).
I do claim to be an elitist for a project such as the Hurd, in so far as
I am convinced that the project failed in no small part because the initial
code was written by someone who just wasn't good enough for the task,
unlike a project like, say, Linux. Finally, it's not about merit, it's
about who can make the project progress well and who can't. I claim that,
for the most part, people who are not willing to make serious efforts
should just stay away. The Hurd is already buggy enough as it is and
this is not a school.

--
Richard Braun

[Richard Braun]

On Thu, Aug 20, 2020 at 11:24:50PM +0200, Jan Wielkiewicz wrote:
> Please stop arguing, everyone.
> I already made some notes about how to make the web page more readable,
> we'll be judging the effects when its done.
> Don't waste more time on arguing than it's worth.

This discussion relates to the culture of the project itself, so I don't
think it's wasted.

> As for Samuel's and yours opinion about people with cognitive biases,
> etc, remember not everyone who visits the page is a system developer -
> sometimes an unrelated person can visit the page. In this case if that
> person finds the web page interesting (even due to cognitive bias),
> there's a possibility the person will tell others about the finding.
> If the web page looks bad, abandoned, isn't convincing, then the person
> just won't care or even worse, will tell others the Hurd is abandonware.
> There's a small chance an incompetent person will tell their more
> competent friends about it, and that's our chance.
> All I want to do is to increase the probability.

My point isn't to have a bad looking web site, just not to turn it into
something that it shouldn't be for all kinds of stupid reasons. I
personally like what you wrote so far about your intentions.

--
Richard Braun

[Richard Braun]

On Fri, Aug 21, 2020 at 01:28:42AM +0200, Richard Braun wrote:
> On Thu, Aug 20, 2020 at 11:10:53PM +0200, Almudena Garcia wrote:
> > We have to leave the 90s ideas, and think as younger people thinks nowadays

I mean, really, you have to keep in mind that the Hurd originated in the
80s/90s, and is meant to be compatible with a system that dates from the
70s. So what is this nonsense about "90s ideas" ?

--
Richard Braun

[Jan Wielkiewicz]

Dnia 2020-08-25, o godz. 00:04:58
Almudena Garcia <liberame...@gmail.com> napisał(a):

> Jan. I've just written a little draft to help you with the website.
>
> The draft includes some suggestions about index, and some sections
> like "getting started" (how to download, test, and install Hurd,
> putting Debian GNU/Hurd as example), and "how to contribute", with
> some tips about how to write code (follow the coding style), and how
> to generate a patch.
>
> I expect this draft can be useful for your work.
>

Thanks, I'll check it out and I'll try starting working on the website
soon. I just have to finish some boring homework for my university
first.

P.S. I look forward seeing your SMP code working in the Hurd :)


Jan Wielkiewicz

[Richard Braun]

On Sat, Aug 15, 2020 at 06:51:27PM +0200, Jan Wielkiewicz wrote:
> Also navigation is too complicated and messy, searching doesn't work at
> all, because https://darnassus.sceen.net/cgi-bin/hurd-web is dead half
> of the time.
> Any special wishes?

By the way, the main reason why that website is so often unreachable is
netdde freezing. I've restored an old trick I used in the past to mitigate
the problem, which is merely a cron script that kills it every hour.

If you want that to improve, someone will have to hunt that bug down.

--
Richard Braun

[Samuel Thibault]

Richard Braun, le ven. 28 août 2020 18:33:03 +0200, a ecrit:

One way to avoid the bug is to use the e1000 hardware network type. I
guess the rtl8139 driver that we ship in netdde has a bug in its irq
handling (we had already seen that kind of bug a long time ago in the
IDE driver). Moving to rump-based network drivers will probably help
fixing this kind of issue long-term :)

Samuel

[Almudena Garcia]

I've just remembered that, in my document, I forgot to add information about how to compile GNU Mach and Hurd in the "How to contribute" section.

For GNU Mach, you can get information here: https://www.gnu.org/software/hurd/microkernel/mach/gnumach/building.html

This document is incomplete, and lacks information about cross-compile in configure step. You can find the correct configure line here: http://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/README

For Hurd, you can get information here: https://www.gnu.org/software/hurd/hurd/building.html

It's important advice about upstream Hurd could not works properly over Debian GNU/Hurd, so It's recommended only replace the modified translator, and check if this translator requires any patch from Debian (I don't know where check It).

And this is all. I expect this info help you in your work into the website