Re: KMScon vs. AMD Radeon

[Mathieu Othacehe]

> On Arch Linux it shows:
>
> [florian@floriandesktoppc ~]$ ls /sys/class/drm  
> card0  card0-DVI-D-1  card0-HDMI-A-1  card0-VGA-1  renderD128  ttm  version
> [florian@floriandesktoppc ~]$ 

That's strange I was expecting this folder to be almost empty. Could you
do the same test from a GuixSD iso image, the 0.16 would be fine?

For the record, here's the output that Pierre Neidhardt gave me:

Without amdgpu:

--8<---cut here---start->8---
/sys/class/drm/ttm
/sys/class/drm/version
--8<---cut here---end--->8---

With amdgpu:
--8<---cut here---start->8---
/sys/class/drm/card0
/sys/class/drm/card0-DP-1
/sys/class/drm/card0-DP-2
/sys/class/drm/card0-DVI-D-1
/sys/class/drm/card0-HDMI-A-1
/sys/class/drm/card0-HDMI-A-2
/sys/class/drm/renderD128
/sys/class/drm/ttm
/sys/class/drm/version

Thanks for your help,

Mathieu

Re: KMScon vs. AMD Radeon

[Pierre Neidhardt]

Mathieu Othacehe  writes:

>> On Arch Linux it shows:
>>
>> [florian@floriandesktoppc ~]$ ls /sys/class/drm  
>> card0  card0-DVI-D-1  card0-HDMI-A-1  card0-VGA-1  renderD128  ttm  version
>> [florian@floriandesktoppc ~]$ 
>
> That's strange I was expecting this folder to be almost empty.

Florian said this output came from Arch Linux, which by default ships
the nonfree amdgpu.

In my understanding, this matches my output.

To sum up, if /sys/class/drm/card* or /sys/class/drm/render* files are
found then KMS is probably supported.

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Software Heritage & Guix

[Pjotr Prins]

Brilliant. One of those things where people don't realise they need it
until they hit it. I have hit it many times. Some projects even have
it as a policy to remove old links to code.

Pj.

On Fri, Mar 29, 2019 at 05:05:10PM +0100, Ludovic Courtès wrote:
> Hello!
> 
> I’ve written a post on the Software Heritage support in Guix:
> 
>   
> https://gnu.org/s/guix/blog/2019/connecting-reproducible-deployment-to-a-long-term-source-code-archive/
> 
> Happy reading!  :-)
> 
> Ludo’.
> 

Re: Naming, hacking, and policies

[sirgazil]

El 29/03/19 a las 11:42 a. m., Ludovic Courtès escribió:

[...]



Packages usually have a “system name” (that’s the terminology used on
Savannah) and a “pretty name”, like ‘guix’ and ‘GNU Guix’.  I believe
the intent of those guidelines was to suggest keeping the system name,
not the fancy name.  Perhaps this is what should be clarified?

Thanks,
Ludo’.


A comment on the accessibility of names:

Last time I tried browsing packages in a GTK+ application on Debian 
using a screen reader, I didn't like the experience. The screen reader 
read in Spanish (my system language) all the names of the packages, most 
of them in "system name" format and made of English words. No good. 
Also, if I recall correctly, the screen reader didn't read initialisms 
correctly.


I bet there are things to improve in screen readers, accessibility of 
GUI toolkits, and package definitions. At that time, for example, Orca 
could not read multilingual HTML documents that used explicitly the LANG 
attribute in elements. I don't know if GTK+ offers something similar to 
the HTML LANG attribute for GUI components. Package definitions I've 
seen don't indicate in which language a package name is written so that 
a screen reader could switch its voice if necessary, nor they provide a 
way to know if a package name is an initialism, so that the screen 
reader can read it as such.


I don't know exactly what should be done in Guix, though, but I think 
having a "system name" and a "pretty name" that is translatable could 
help a little bit.


I hope libre screen readers get so smart they will figure all these 
things by themselves :)



My 2¢


--
Luis Felipe López Acevedo
http://sirgazil.bitbucket.io/

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Sat, Mar 30, 2019 at 09:40:19AM +0100, Pierre Neidhardt wrote:
> Mathieu Othacehe  writes:
> 
> >> On Arch Linux it shows:
> >>
> >> [florian@floriandesktoppc ~]$ ls /sys/class/drm  
> >> card0  card0-DVI-D-1  card0-HDMI-A-1  card0-VGA-1  renderD128  ttm  version
> >> [florian@floriandesktoppc ~]$ 
> >
> > That's strange I was expecting this folder to be almost empty.
> 
> Florian said this output came from Arch Linux, which by default ships
> the nonfree amdgpu.
> 

On Guix System 0.16 the directory /sys/class/drm contains only
ttm and version.

Re: Software Heritage & Guix

[znavko]

Very useful for learning and deeping.
First distributions provisioned a base for working.
GuixSD provisions tools for hacking on meta-level.
Containers, virtual-machines, sharing of environment, time-back machine, think 
it's important for industry 4.0.


Mar 29, 2019, 4:05 PM by l...@gnu.org:

> Hello!
>
> I’ve written a post on the Software Heritage support in Guix:
>
>  > 
> https://gnu.org/s/guix/blog/2019/connecting-reproducible-deployment-to-a-long-term-source-code-archive
>  
> 
>
> Happy reading!  :-)
>
> Ludo’.
>

Re: Software Heritage & Guix

[Pjotr Prins]

On Sat, Mar 30, 2019 at 04:51:57PM +0100, zna...@tutanota.com wrote:
>Very useful for learning and deeping.
> 
>First distributions provisioned a base for working.
> 
>GuixSD provisions tools for hacking on meta-level.
> 
>Containers, virtual-machines, sharing of environment, time-back
>machine, think it's important for industry 4.0.

Especially for science where we want to reproduce results from even 10
years ago. Virtually impossible right now.

Pj.

Re: Software Heritage & Guix

[znavko]

I've translated into Russian here https://www.opennet.ru/tips/info/3100.shtml 

It is interesting occupation to study and translate something when I have free 
time.


Mar 29, 2019, 4:05 PM by l...@gnu.org:

> Hello!
>
> I’ve written a post on the Software Heritage support in Guix:
>
>  > 
> https://gnu.org/s/guix/blog/2019/connecting-reproducible-deployment-to-a-long-term-source-code-archive
>  
> 
>
> Happy reading!  :-)
>
> Ludo’.
>

Re: Software Heritage & Guix

[swedebugia]

On 2019-03-30 19:03, zna...@tutanota.com wrote:
> I've translated into Russian here
> https://www.opennet.ru/tips/info/3100.shtml
> It is interesting occupation to study and translate something when I
> have free time.

Nice. I like translating too :)

--

Thanks Ludo, I liked the article.
Maybe this could be spread in more places like slashdot, reddit,
wikinews etc. to reach a wider audience.

Is it ok if I request for an interview in Wikinews with you Ludo?
https://en.wikinews.org/wiki/Wikinews:Request_an_interview

-- 
Cheers Swedebugia



signature.asc
Description: OpenPGP digital signature

Guix on a microkernel

[mikadoZero]

# Appreciation

I appreciate:

* many of Guix's design decisions.  The one that is relevant to this
  discussion is the kernel.  I like that Guix uses the linux-libre (no
  binary blobs) instead of the linux kernel.

* that work is underway to get Guix to work with GNU Hurd.  I like that
  a microkernel is a potential kernel option. 

  http://lists.gnu.org/archive/html/guix-devel/2016-12/msg00857.html

* the effort that has been put into GNU Hurd to get it to where it is.

* the bootsrapping initiative.

  https://bootstrappable.org/
  https://fosdem.org/2019/schedule/event/gnumes/

# Intent

* I would like to understand why GNU Hurd is being focused
  on (my perception) given other microkernel options. 
* I want to share what I have found after doing some looking into
  microkernels.
* I am curious what others think of microkernels.

I mention the appreciations above because I am aiming for a tone of
appreciation and curiosity and not a critical one.  The tone can be a
challenge for written communication. 

# My microkernel experience

Currently I do not have any practical experience using any microkernel.
I have just spent time looking into the topic as it is interesting to
me.

# Why microkernels?

I think Andrew Tanenbaum explains benefits of microkernel entertainingly
in this talk:
http://www.youtube.com/watch?v=bx3KuE7UjGA

The talks has a focus on Minix but I think the benefits are transferable
to other microkernels.

# GNU Hurd

## Perceived focus

I looks to me like there is a effort (which I appreciate) to get Guix
working on Hurd.  I get this perception from:

http://lists.gnu.org/archive/html/guix-devel/2016-12/msg00857.html

These comments from this thread:

https://lists.gnu.org/archive/html/help-guix/2019-03/msg00158.html

Ricardo Wurmus:  "Let’s work on the Hurd, people!  It’s beautiful!"

Jan Nieuwenhuizen: "FWIW the Mes port to the Hurd is ongoing and mes now
runs, next thing up is fork which we need for running mescc."

## Critiques of Hurd

I would be curious what people think about these third party critiques
(not mine) of Hurd.

### From X15

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

"Although the design of the Hurd is promising and attractive, its
implementation has a number of severe issues. X15 takes the approach of
the complete rewrite to make sure that key ideas are kept in mind at all
times during development. Since it’s not meant to be compatible with the
Hurd, critical interfaces such as IPC and signals can be re-implemented
completely differently. There is a lot of emphasis on code quality and
ease of maintenance, obtained from disciplined application of best
practices."

### From HelenOS

http://www.helenos.org/wiki/FAQ#HowisHelenOSdifferentfromGNUHurd

### Why Hurd?

Why the focus on Hurd given other microkernel options?  I ask this
question out of curiosity and a lack of practical experience with
microkernels.

# Microkernel wish list

These are things that I see as desirable in a microkernel.

## Free software

It should be completely free software.  No binary blobs included.  It
looks like all of the microkernel listed here are:
http://www.microkernel.info/

## RISC-V

RISC-V a free and open instruction set architecture is a nice complement
to a free operating system.  It is nice if a mircokernel already has
plans to run on RISC-V. 

Intel security issues:
https://libreboot.org/faq.html#intel

ARM security issues:
https://libreboot.org/faq.html#amd

### Entirely free RISC-V computers

These two initiatives are entirely free hardware based on RISC-V.

* HiFive Unleashed
  https://www.sifive.com/boards/hifive-unleashed

* lowRISC
  https://www.lowrisc.org

## Formal verification

An application of the minimality principle in the design of microkernel
leads to smaller code bases which are amenable to formal verification. 

https://en.wikipedia.org/wiki/Microkernel#Essential_components_and_minimality

I see the extra security assurance that formal verification provide as
desirable.

# Alternative microkernels

I used http://www.microkernel.info/ as the starting point when I began
looking into microkernels. 

## Summary of interesting microkernels

This is a high level summary based on the "Microkernel wish list" above.
All of these are free software.  I am likely missing some other
interesting microkernel projects.

| projects | RISC-V efforts | Formal verification |
|--++-|
| sel4.systems | Yes| Yes |
| genode.org   | Yes| Yes |
| helenos.org  | Yes| No  |
| muen.sk  | ?/No   | Yes |
| minix3.org   | ?/No   | No  |
| hurd.gnu.org | ?/No   | No  |

Note:

* ?/No is where (to me without asking) there does not look like there
  have been efforts to make the project work with RISC-V. 

* Genode is different than the others as it is not just a microkernel.
  I have given Genode Yes f

Re: Zotero Packaging Request

[mikadoZero]

Raghav given Pierre's assessment I just wanted to suggest some potential
Zotero alternatives.

They would require using a document compiler like latex, groff or
pandoc.  I do not know if the following have the feature set that you
are looking for.  I have not used these myself but they would be what I
would look at using if I needed to create citations or bibliographies.

For use with latex:
* biber
* texlive-bibtex

For use with pandoc:
* ghc-pandoc-citeproc

For use with emacs/org:
* emacs-biblio
* emacs-org-ref

I do not know if `refer` is included in the `groff` packaged.

As an aside it is interesting to see that `emacs-zotxt` is packaged.


Pierre Neidhardt writes:

> Hi Raghav,
>
> I'm very sorry, I looked a little too fast (did I look at the wrong
> program? :p), and Zotero is actually the very opposite of what it
> thought, it's a hard one.
>
> It turns out that Zotero needs... NodeJS (!) and XULrunner (!!!).
>
> As long as Guix won't have a recursive importer for NodeJS, it will be
> a big hassle to package Zotero.
>
> Besides, isn't XULrunner deprecated?
>
> More details there:
> https://www.zotero.org/support/dev/client_coding/building_the_standalone_client
>
> Sorry, I'm out :(

Re: Software Heritage & Guix

[mikadoZero]

This is a nice initiative.

>From reading the post I found it unclear what this Software Heritage
group is and what it's relation to Guix is.

Would it make sense for the "Software Heritage" to be decentralized
through free peer to peer software similar to what is discussed here: 

https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00135.html

https://issues.guix.info/issue/33899

Potential benefits being organization and geographic redundancy.

Ludovic Courtès writes:

> Hello!
>
> I’ve written a post on the Software Heritage support in Guix:
>
>   
> https://gnu.org/s/guix/blog/2019/connecting-reproducible-deployment-to-a-long-term-source-code-archive/
>
> Happy reading!  :-)
>
> Ludo’.

Re: Zotero Packaging Request

[Raghav Gururajan]

Pierre!

Ah! That's okay. Thanks for trying. I just found out Zotero in Flatpak 
(https://flathub.org/apps/details/org.zotero.Zotero).

Regards,
RG.

March 30, 2019 12:45 PM, "Pierre Neidhardt"  wrote:

> Hi Raghav,
> 
> I'm very sorry, I looked a little too fast (did I look at the wrong
> program? :p), and Zotero is actually the very opposite of what it
> thought, it's a hard one.
> 
> It turns out that Zotero needs... NodeJS (!) and XULrunner (!!!).
> 
> As long as Guix won't have a recursive importer for NodeJS, it will be
> a big hassle to package Zotero.
> 
> Besides, isn't XULrunner deprecated?
> 
> More details there:
> https://www.zotero.org/support/dev/client_coding/building_the_standalone_client
> 
> Sorry, I'm out :(
> 
> -- 
> Pierre Neidhardt
> https://ambrevar.xyz

Re: Software Heritage & Guix

[znavko]

Hello! Looks like reproducible builds are like videos on video hosting. You may 
share your screencast or videos, the others can see your screen exactly. But 
there are limitations: you need to have an account on exactly one video 
hosting. There were challenges in Ludovic Courtès article. Releases tarballs 
are not the same as version control revisions: tarballs may have `configure` 
scripts and developers signatures. What to choose for using in certain 
reproducible build?

There is in need a help from FSF for definition of standards. What do you think?


Mar 29, 2019, 4:05 PM by l...@gnu.org:

> Hello!
>
> I’ve written a post on the Software Heritage support in Guix:
>
>  > 
> https://gnu.org/s/guix/blog/2019/connecting-reproducible-deployment-to-a-long-term-source-code-archive
>  
> 
>
> Happy reading!  :-)
>
> Ludo’.
>

Re: Guix on a microkernel

[znavko]

Thanks for your compilation.
Do you have found actual benchmark tests? 
https://www.gnu.org/software/hurd/faq/slow.html 

"The Hurd is currently slower than Linux, yes. But not very much, so it is 
completely usable."
Vulnerabilities of processors is also sensitive task. Maybe RISC-V will not 
have such bugs? Need to know in a practice.

Mar 31, 2019, 12:05 AM by mikadoz...@yandex.com:

> # Appreciation
>
> I appreciate:
>
> * many of Guix's design decisions.  The one that is relevant to this
>  discussion is the kernel.  I like that Guix uses the linux-libre (no
>  binary blobs) instead of the linux kernel.
>
> * that work is underway to get Guix to work with GNU Hurd.  I like that
>  a microkernel is a potential kernel option. 
>
>  > http://lists.gnu.org/archive/html/guix-devel/2016-12/msg00857.html 
> 
>
> * the effort that has been put into GNU Hurd to get it to where it is.
>
> * the bootsrapping initiative.
>
>  > https://bootstrappable.org 
>  > https://fosdem.org/2019/schedule/event/gnumes 
> 
>
> # Intent
>
> * I would like to understand why GNU Hurd is being focused
>  on (my perception) given other microkernel options. 
> * I want to share what I have found after doing some looking into
>  microkernels.
> * I am curious what others think of microkernels.
>
> I mention the appreciations above because I am aiming for a tone of
> appreciation and curiosity and not a critical one.  The tone can be a
> challenge for written communication. 
>
> # My microkernel experience
>
> Currently I do not have any practical experience using any microkernel.
> I have just spent time looking into the topic as it is interesting to
> me.
>
> # Why microkernels?
>
> I think Andrew Tanenbaum explains benefits of microkernel entertainingly
> in this talk:
> http://www.youtube.com/watch?v=bx3KuE7UjGA 
> 
>
> The talks has a focus on Minix but I think the benefits are transferable
> to other microkernels.
>
> # GNU Hurd
>
> ## Perceived focus
>
> I looks to me like there is a effort (which I appreciate) to get Guix
> working on Hurd.  I get this perception from:
>
> http://lists.gnu.org/archive/html/guix-devel/2016-12/msg00857.html 
> 
>
> These comments from this thread:
>
> https://lists.gnu.org/archive/html/help-guix/2019-03/msg00158.html 
> 
>
> Ricardo Wurmus:  "Let’s work on the Hurd, people!  It’s beautiful!"
>
> Jan Nieuwenhuizen: "FWIW the Mes port to the Hurd is ongoing and mes now
> runs, next thing up is fork which we need for running mescc."
>
> ## Critiques of Hurd
>
> I would be curious what people think about these third party critiques
> (not mine) of Hurd.
>
> ### From X15
>
> https://www.sceen.net/x15 
>
> "Although the design of the Hurd is promising and attractive, its
> implementation has a number of severe issues. X15 takes the approach of
> the complete rewrite to make sure that key ideas are kept in mind at all
> times during development. Since it’s not meant to be compatible with the
> Hurd, critical interfaces such as IPC and signals can be re-implemented
> completely differently. There is a lot of emphasis on code quality and
> ease of maintenance, obtained from disciplined application of best
> practices."
>
> ### From HelenOS
>
> http://www.helenos.org/wiki/FAQ#HowisHelenOSdifferentfromGNUHurd 
> 
>
> ### Why Hurd?
>
> Why the focus on Hurd given other microkernel options?  I ask this
> question out of curiosity and a lack of practical experience with
> microkernels.
>
> # Microkernel wish list
>
> These are things that I see as desirable in a microkernel.
>
> ## Free software
>
> It should be completely free software.  No binary blobs included.  It
> looks like all of the microkernel listed here are:
> http://www.microkernel.info 
>
> ## RISC-V
>
> RISC-V a free and open instruction set architecture is a nice complement
> to a free operating system.  It is nice if a mircokernel already has
> plans to run on RISC-V. 
>
> Intel security issues:
> https://libreboot.org/faq.html#intel 
>
> ARM security issues:
> https://libreboot.org/faq.html#amd 
>
> ### Entirely free RISC-V computers
>
> These two initiatives are entirely free hardware based on RISC-V.
>
> * HiFive Unleashed
>  > https://www.sifive.com/boards/hifive-unleashed 
> 
>
> * lowRISC
>  > https://www.lowrisc.org 
>
> ## Formal verification
>
> An application of the minimality principle in the design