bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Wielkiewicz
Subject: Re: A few questions: Libre SoC, website, Rust
Date: Sun, 16 Aug 2020 21:00:26 +0200

Dnia 2020-08-16, o godz. 16:39:12
Samuel Thibault <samuel.thibault@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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]