Re: package manager guix on Windows and OSX
June 25, 2021 7:18 PM, indieterminacy@libre.brussels wrote: > I love Latex, Context, I feel a bit weird for not having dabbled with > Texinfo. Im not sure Texinfo > is going to sway enough younger programmers (Im neither young nor old), I > fear too many have been > malconditioned into accepting delible communication techniques - Texinfo may > no longer cut it. We all owe Ludo a big thanks for writing Skribilo. > I would consider Org mode to probably be the most acceptable default, though > in many respects > Skribilo could be more of a purer expression of a complete Guix approach. Are > the aforementioned > all different ways of dissuading people from considering Guix or documenting > for it? My understanding is that GNU Guix is a GNU project. As such we abide by the GNU coding standards, which means that our documentation standard is GNU Texinfo. It was suggested to Stallman a while ago that we should make the documentation standard Org mode, but Stallman did not like to force people to use Emacs to write GNU documentation. I would love to re-implement Org mode in GNU Guile, but that would probably be several years worth of effort. :) Or perhaps not. I could just write a reader in Skribilo! > FYI, I have been wading into the Gemini protocol the last two months. Beyond > its more noticable > security and publishing advantages, I have been entranced by the terseness of > its Gem .gmi > (minimalist MarkDown) format. I consider it has crossover appeal (as least > between documenting > power users across OSes). FYI, the OpenBSD crowd seem to have the lead in the > Gemini space - but > this is presumable for the protocol rather than the markdown. I tend to agree. Drew Devault likes it a lot. I'm hoping to set up my blog to be hosted via gemini too. > Since then I stopped annotating in Orgmode and will be building workflows to > (eventually?) > approximate a lot of Orgmode functionality. Obviously Orgmode is awesome but > I wonder if it is too > designed around individual workflows and procedures - where greater payoff > comes from pooled > workflows and procedures. > > I had success/pleaseure converting from .gem to .org formats with this > experimentation (concerning > annotations for a Guix CWL blog post) > => https://git.sr.ht/~indieterminacy/q1q20hqh_kq_oq_parsing_gem_zsh/tree > > From the tree you can see that it is feasible to output to *tex* or *html* > formats, using simple > REGEX foo. > > Additionally there is an unfinished attempt at exporting to (sic) Skribilo. > > (You may want to ignore the potentially impenitrable annotations, which > concerns a 'Recursive > Modelling Language' Ive been working on - it would certainly confuse this > topic) That sounds fun! Chat to me off list if you care to explain it. > I would be happy if Guix writing was done with minimal Gem markup but with > heavy Lisp usage for > interpretation, synthesis, collection and publishing of content. I had > originally taken the > approach that there should be Tex heavy markup first and then simplified > transposing into other > formats later. Now Im on the other end of the horseshoe. > > I miss experimenting with regards to Tikz as a mechanism for generating > graphics. I understand why > other tools are used and ho programmers tend to seemingly think in terms of > characters. It bothers > me that I do not have beautiful graph displays representing my environment - > to consider things > from an impressionistic viewpoint and a contrast to text-editor/browser > dualism. I suspect it isnt > insurmountable and could allow visually minded people to not feel aggrieved > by TUIscapes. > >> What do you mean by: >> >>> empathise regarding why networking engineers may prefer having a licence >>> which permits encapsulation more readily. > > I mean: the MIT license allows you to operate in a commercial setting, > whereby only the binaries > are provided, without the requirement to provide the source content. While I > normally am against > this, an OpenBSD networking head has explained to me how there would be > usecases where this would > be useful - if only to provide the commercial breathing space for niche > projects. I probably should > stop paraphrasing this person now. I suppose that's fair. > Jonathan McHugh > indieterminacy@libre.brussels
Re: package manager guix on Windows and OSX
There are many bawdy jokes Id like to make concerning that citation. June 25, 2021 10:56 PM, jbra...@dismail.de wrote: > That and their software is top notch! Linus called their developers > "masturbating monkeys", because of their obsessive pursuit of security! > hahaha. At every shutdown, the OpenBSD kernel is re-linked. It's the same > kernel when you reboot it, but the binary is re-ordered. That's amazing! Yes, they are highly capable and ambitious. I picked up that information, having researched Hyperbola... based upon your prompt. >> Additionally, while I understand that MIT is in many ways deficient >> compared to GPL licenses, if not pernicious and counterproductive I do >> empathise regarding why networking engineers may prefer having a licence >> which permits encapsulation more readily. > > Well, what is interesting, is that the HyperbolaBSD developers intend to > rewrite 20% of the BSD kernel and license the whole project GPL. :) > > My personal feeling is that GNU should adopt Org mode as their documentation > standard. It's slightly easier to use than texinfo. Thought texinfo is > pretty rad. :) I love Latex, Context, I feel a bit weird for not having dabbled with Texinfo. Im not sure Texinfo is going to sway enough younger programmers (Im neither young nor old), I fear too many have been malconditioned into accepting delible communication techniques - Texinfo may no longer cut it. I would consider Org mode to probably be the most acceptable default, though in many respects Skribilo could be more of a purer expression of a complete Guix approach. Are the aforementioned all different ways of dissuading people from considering Guix or documenting for it? FYI, I have been wading into the Gemini protocol the last two months. Beyond its more noticable security and publishing advantages, I have been entranced by the terseness of its Gem .gmi (minimalist MarkDown) format. I consider it has crossover appeal (as least between documenting power users across OSes). FYI, the OpenBSD crowd seem to have the lead in the Gemini space - but this is presumable for the protocol rather than the markdown. Since then I stopped annotating in Orgmode and will be building workflows to (eventually?) approximate a lot of Orgmode functionality. Obviously Orgmode is awesome but I wonder if it is too designed around individual workflows and procedures - where greater payoff comes from pooled workflows and procedures. I had success/pleaseure converting from .gem to .org formats with this experimentation (concerning annotations for a Guix CWL blog post) => https://git.sr.ht/~indieterminacy/q1q20hqh_kq_oq_parsing_gem_zsh/tree >From the tree you can see that it is feasible to output to *tex* or *html* >formats, using simple REGEX foo. Additionally there is an unfinished attempt at exporting to (sic) Skribilo. (You may want to ignore the potentially impenitrable annotations, which concerns a 'Recursive Modelling Language' Ive been working on - it would certainly confuse this topic) I would be happy if Guix writing was done with minimal Gem markup but with heavy Lisp usage for interpretation, synthesis, collection and publishing of content. I had originally taken the approach that there should be Tex heavy markup first and then simplified transposing into other formats later. Now Im on the other end of the horseshoe. I miss experimenting with regards to Tikz as a mechanism for generating graphics. I understand why other tools are used and ho programmers tend to seemingly think in terms of characters. It bothers me that I do not have beautiful graph displays representing my environment - to consider things from an impressionistic viewpoint and a contrast to text-editor/browser dualism. I suspect it isnt insurmountable and could allow visually minded people to not feel aggrieved by TUIscapes. > What do you mean by: > >> empathise regarding why networking engineers may prefer having a licence >> which permits encapsulation more readily. I mean: the MIT license allows you to operate in a commercial setting, whereby only the binaries are provided, without the requirement to provide the source content. While I normally am against this, an OpenBSD networking head has explained to me how there would be usecases where this would be useful - if only to provide the commercial breathing space for niche projects. I probably should stop paraphrasing this person now. Jonathan McHugh indieterminacy@libre.brussels
Re: package manager guix on Windows and OSX
June 25, 2021 1:53 PM, "Jonathan McHugh" wrote: > Hi Joshua, > > A Guix-BSD hybrid would be delectable. > > I consider the OpenBSD community to be excellent, not only for their > prioritising a tight kernel and high levels of security standards but > because they refuse to release updates until documentation such as > manpages are comprehensively written. That and their software is top notch! Linus called their developers "masturbating monkeys", because of their obsessive pursuit of security! hahaha. At every shutdown, the OpenBSD kernel is re-linked. It's the same kernel when you reboot it, but the binary is re-ordered. That's amazing! > This final point is something which the Guix community needs to > improve - there is too much of a publish first - decribe later philosophy. As > somebody still trying > to fully master I get the feeling that > their are things which will elude me until I get enough battle scars and > my productivity will be hampered until I reach that sweet spot (or at > least become more proficient/confident at just asking!) My personal feeling is that GNU should adopt Org mode as their documentation standard. It's slightly easier to use than texinfo. Thought texinfo is pretty rad. :) > I should state that I consider the help-guix and devel-guix to be highly > informative, friendly and professional. There should be greater > expectations of contributors to explain their improved functionalities > in advance. Additionally, I hold your individual support to be > exemplary. Well thanks! I might mount that compliment on my wall! > Additionally, while I understand that MIT is in many ways deficient > compared to GPL licenses, if not pernicious and counterproductive I do > empathise regarding why networking engineers may prefer having a licence > which permits encapsulation more readily. Well, what is interesting, is that the HyperbolaBSD developers intend to rewrite 20% of the BSD kernel and license the whole project GPL. :) What do you mean by: > empathise regarding why networking engineers may prefer having a licence > which permits encapsulation more readily. > Joshua Branson writes: > >> Edouard Klein writes: > > To port Guix to another operating system such as BSD (including OSX), > one would have to translate these calls. > > For example, Guix is the only software I've actually encountered that > can not run in SmartOS' emulation of Linux, because the system calls it > uses are not implemented there. > > I would love for Guix to be a Multi Kernel package manager (I mean it > works on the Hurd also, but I have never encountered a Hurd user in real > life). My dream would be to port Guix to Plan 9 ;-) >> Why Plan 9? May I ask? And I do really like the Hurd, but I use the >> dvorak keyboard layout. My understanding is that the Hurd does not >> support variant keyboard layouts yet... :( >> >> I actually think that the Guix developers may want to consider a port to >> the OpenBSD kernel, provided that the Hyperbola developers get >> HyperbolaBSD working. Though I guess the Debian guys sort of did >> already. :) >> >> https://www.hyperbola.info/news/announcing-hyperbolabsd-roadmap > > -- > Jonathan McHugh > indieterminacy@libre.brussels
Re: package manager guix on Windows and OSX
Hi Joshua, A Guix-BSD hybrid would be delectable. I consider the OpenBSD community to be excellent, not only for their prioritising a tight kernel and high levels of security standards but because they refuse to release updates until documentation such as manpages are comprehensively written. This final point is something which the Guix community needs to improve - there is too much of a publish first - decribe later philosophy. As somebody still trying to fully master I get the feeling that their are things which will elude me until I get enough battle scars and my productivity will be hampered until I reach that sweet spot (or at least become more proficient/confident at just asking!) I should state that I consider the help-guix and devel-guix to be highly informative, friendly and professional. There should be greater expectations of contributors to explain their improved functionalities in advance. Additionally, I hold your individual support to be exemplary. Additionally, while I understand that MIT is in many ways deficient compared to GPL licenses, if not pernicious and counterproductive I do empathise regarding why networking engineers may prefer having a licence which permits encapsulation more readily. Joshua Branson writes: > Edouard Klein writes: >> >> To port Guix to another operating system such as BSD (including OSX), >> one would have to translate these calls. >> >> For example, Guix is the only software I've actually encountered that >> can not run in SmartOS' emulation of Linux, because the system calls it >> uses are not implemented there. >> >> I would love for Guix to be a Multi Kernel package manager (I mean it >> works on the Hurd also, but I have never encountered a Hurd user in real >> life). My dream would be to port Guix to Plan 9 ;-) > > Why Plan 9? May I ask? And I do really like the Hurd, but I use the > dvorak keyboard layout. My understanding is that the Hurd does not > support variant keyboard layouts yet... :( > > I actually think that the Guix developers may want to consider a port to > the OpenBSD kernel, provided that the Hyperbola developers get > HyperbolaBSD working. Though I guess the Debian guys sort of did > already. :) > > https://www.hyperbola.info/news/announcing-hyperbolabsd-roadmap/ > -- Jonathan McHugh indieterminacy@libre.brussels
Re: Blender freezes i3wm
Well I was wrong about the patch applying cleanly too. Not paying close attention, apparently. And that patch was merged already in the current version of Blender we ship. It looks like my GPU, which is (according to lspci): 00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (Whiskey Lake) has particular trouble: https://developer.blender.org/T80458#1182395 Frustrating. - Chris Chris Lemmer-Webber writes: > Spoke too soon, unfortunately. :\ > > My whole desktop still crashed after some period of use. However, let > me give some better news... the patch I linked is not yet in the latest > version of Blender we ship. So this can probably be fixed either by > upgrading Blender or, should that be annoying to do temporarily, by > backporting this patch, which merges quite cleanly. > > Chris Lemmer-Webber writes: > >> I've had the same issue. I think for me at least, here's the relevant >> issue: >> >> https://developer.blender.org/T72902 >> >> Apparently if someone encounters other issues with their card, these >> need to be added "on a case per case basis" >> >> https://developer.blender.org/rBb7acb8690a4d189868c6e0b57057b6fcd8a5a96d >> >> However adding new cards doesn't look too hard. >> >> Not sure if this is too helpful to anyone but I suspect this might keep >> happening with intel cards as they roll out. >> >> Ekaitz Zarraga writes: >> >>> Weirdly enough, yesterday I sculpted for 2h in a row and everything >>> went well. >>> >>> After that, I opened the model I worked on and it freezed my screen >>> again, but this time some buttons of other screens started to appear >>> on top of the frozen window. >>> >>> Very weird. >>> >>> Anyway, this looks like it's impossible to debug so I'm going to act >>> as it didn't happen.
Re: package manager guix on Windows and OSX
Edouard Klein writes: > Hi ! > > The real problem will not be the languages (guile or C++), but the > system calls used by Guix. Ahh! Thanks for pointing that out! > > Guix makes use of some recent (less than 2 decades) and somewhat > advanced features of the Linux kernel, such as namespaces. True true! > > To port Guix to another operating system such as BSD (including OSX), > one would have to translate these calls. > > For example, Guix is the only software I've actually encountered that > can not run in SmartOS' emulation of Linux, because the system calls it > uses are not implemented there. > > I would love for Guix to be a Multi Kernel package manager (I mean it > works on the Hurd also, but I have never encountered a Hurd user in real > life). My dream would be to port Guix to Plan 9 ;-) Why Plan 9? May I ask? And I do really like the Hurd, but I use the dvorak keyboard layout. My understanding is that the Hurd does not support variant keyboard layouts yet... :( I actually think that the Guix developers may want to consider a port to the OpenBSD kernel, provided that the Hyperbola developers get HyperbolaBSD working. Though I guess the Debian guys sort of did already. :) https://www.hyperbola.info/news/announcing-hyperbolabsd-roadmap/ > > jbra...@dismail.de writes: > >> June 24, 2021 2:26 PM, "Patricio Martínez" wrote: >> >>> Do anyone know the posibilities about install Guix on another system >>> diferent of Linux? >> >> Awesome! I love speculating on topics I know virtually nothing about! Most >> of my information comes from a mailing list thread that is about a year old. >> So the situation may be better than I describe it. :) >> >> The easiest way is to use GNU Guix on Windows is WSL (Windows subsystem >> for Linux): >> >> https://www.mail-archive.com/guile-user@gnu.org/msg12167.html >> >> I'm not a big fan of that, because of Window's history of "embrace, extend, >> extinguish." And that only lets you run Guix in Windows...what about Mac? >> The Hurd? React Os? Redox Os? >> >> https://www.mail-archive.com/guile-user@gnu.org/msg12173.html >> >> >> GNU Guix runs entirely on GNU Guile with some C++ for the build daemon. >> >> C++ is fairly portable. That bit should be possible to port, though I >> believe that the development plan is to eventually rewrite the C++ build >> daemon in GNU Guile. >> >> GNU Guile is the tricky bit. To the best of my knowledge, the newer >> versions of GNU Guile run exclusively on GNU/Linux, which is NOT the >> fault of the Guile developers! It's REALLY HARD to port things to all >> OSes. None of the Guile developers are paid for their fabulous work. >> And it's not like Windows or Mac make it easy to port to their platform. >> >> https://www.mail-archive.com/guile-user@gnu.org/msg12172.html >> >> Though, the Lilypond developers did get guile 2.2 version working on Windows. >> >> https://www.mail-archive.com/guile-user@gnu.org/msg12163.html >> >> So did the gnucash guys for GNU Guile 2.2, but it is fairly tough to >> get it to build: >> >> https://www.mail-archive.com/guile-user@gnu.org/msg12164.html >> >> Also, it's a 32-bit GNU Guile that was ported to windows and it does >> not supports thread. >> >> Also Guile 3.0's JIT works on lightening, which is a C library (program ?). >> And I do not know if that supports Windows. But C is really portable. :) >> >>> Thanks you very much and sorry for my english >> >> It was marvelous English! You should teach it! > -- Joshua Branson (joshuaBPMan in #guix) Sent from Emacs and Gnus https://gnucode.me https://video.hardlimit.com/accounts/joshua_branson/video-channels https://propernaming.org "You can have whatever you want, as long as you help enough other people get what they want." - Zig Ziglar
Re: DISTRHO-Ports license situation
On Tue, 22 Jun 2021 21:12:35 +0200 Thorsten Wilms wrote: > I created a package for https://github.com/DISTRHO/DISTRHO-Ports. > I now wonder if I should submit a patch, because the licensing > situation is a mess, with several of the plugins having no information > attached at all, though most have at least a pointer to a repo that > claims a license (gpl2, gpl3, gpl3+, agpl3, MIT). > > The original versions of all plugins have been created with JUCE, > which I though would require GPLing when using the free/personal > license, but at least currently does so only when exceeding $50k > revenue (https://juce.com/juce-6-licence). > > So parts of this is Free Software, other parts are ... just > technically open-source. Would you accept this in Guix? I went ahead and submitted http://debbugs.gnu.org/cgi/bugreport.cgi?bug=49224
Re: package manager guix on Windows and OSX
Hi ! The real problem will not be the languages (guile or C++), but the system calls used by Guix. Guix makes use of some recent (less than 2 decades) and somewhat advanced features of the Linux kernel, such as namespaces. To port Guix to another operating system such as BSD (including OSX), one would have to translate these calls. For example, Guix is the only software I've actually encountered that can not run in SmartOS' emulation of Linux, because the system calls it uses are not implemented there. I would love for Guix to be a Multi Kernel package manager (I mean it works on the Hurd also, but I have never encountered a Hurd user in real life). My dream would be to port Guix to Plan 9 ;-) jbra...@dismail.de writes: > June 24, 2021 2:26 PM, "Patricio Martínez" wrote: > >> Do anyone know the posibilities about install Guix on another system >> diferent of Linux? > > Awesome! I love speculating on topics I know virtually nothing about! Most > of my information comes from a mailing list thread that is about a year old. > So the situation may be better than I describe it. :) > > The easiest way is to use GNU Guix on Windows is WSL (Windows subsystem > for Linux): > > https://www.mail-archive.com/guile-user@gnu.org/msg12167.html > > I'm not a big fan of that, because of Window's history of "embrace, extend, > extinguish." And that only lets you run Guix in Windows...what about Mac? > The Hurd? React Os? Redox Os? > > https://www.mail-archive.com/guile-user@gnu.org/msg12173.html > > > GNU Guix runs entirely on GNU Guile with some C++ for the build daemon. > > C++ is fairly portable. That bit should be possible to port, though I > believe that the development plan is to eventually rewrite the C++ build > daemon in GNU Guile. > > GNU Guile is the tricky bit. To the best of my knowledge, the newer > versions of GNU Guile run exclusively on GNU/Linux, which is NOT the > fault of the Guile developers! It's REALLY HARD to port things to all > OSes. None of the Guile developers are paid for their fabulous work. > And it's not like Windows or Mac make it easy to port to their platform. > > https://www.mail-archive.com/guile-user@gnu.org/msg12172.html > > Though, the Lilypond developers did get guile 2.2 version working on Windows. > > https://www.mail-archive.com/guile-user@gnu.org/msg12163.html > > So did the gnucash guys for GNU Guile 2.2, but it is fairly tough to > get it to build: > > https://www.mail-archive.com/guile-user@gnu.org/msg12164.html > > Also, it's a 32-bit GNU Guile that was ported to windows and it does > not supports thread. > > Also Guile 3.0's JIT works on lightening, which is a C library (program ?). > And I do not know if that supports Windows. But C is really portable. :) > >> Thanks you very much and sorry for my english > > It was marvelous English! You should teach it!
Re: Environment variables hint
Maybe I'm misunderstanding it but I think the manual is simply mistaken: “Unless you're using Guix System, the 'guix install' command must have printed this hint:” amuza 写道： hint: Consider setting the necessary environment variables by running: I expect this to happen on Guix System, for the same reason it happens on other distributions: Guix can't sanely modify the environment of its parent shell or other already running processes. Kind regards, T G-R signature.asc Description: PGP signature
Environment variables hint
Hello! I installed the Guix system. Sometimes, after installing a program I get the following message: hint: Consider setting the necessary environment variables by running: GUIX_PROFILE="/home/me/.guix-profile" . "$GUIX_PROFILE/etc/profile" Alternately, see `guix package --search-paths -p "/home/me/.guix-profile"'. However I read in the manual that that message is only supposed to be received when using Guix in a foreign system. Should I do anything about it?
