[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How to install a GuixSD desktop?
From: |
maze |
Subject: |
Re: How to install a GuixSD desktop? |
Date: |
Sat, 05 Aug 2017 19:04:29 +0200 |
User-agent: |
Roundcube Webmail/1.3.0 |
Am 2017-08-05 02:31, schrieb Joshua Branson:
I like your idea of a faq! That actually seems like a pretty cool
idea!
I wonder what we could put in it:
- UEFI install issues
- when will guixSD reach 1.0
- why GuixSD
- what's bootstrapping
- what's reproducible builds
- etc.
I personally wish that guixSD would have a wiki. I believe some of the
guix maintainers want to put most of that information in the guix
manual
instead. My personal thoughts is that a wiki can have more information
that a manual. I personally love the Arch Wiki. It's got trouble
shooting tips for various packages. It talks you through filesystems,
boot loaders, desktop environments, etc. I probably know much of what
I
know about GNU/Linux from the Arch wiki.
Now that I read more of the manual, many of my initial questions have
been answered. I think the manual is actually quite good in giving
comprehensive information about many details of the project. But still I
think as a newbie, it can be quite overwhelming.
What is missing is some more quickstart / howto-style guides. That
should be separate from the main documentation, which can still serve as
a reference. The Arch wiki is a very good example, where there are pages
covering different topics. And it's mostly well-maintained.
That said, Wikipedia and Arch are probably the only well-maintained
wikis I know.. A wiki tends to get messy and outdated over time, if
there are no people feeling responsible for specific areas.
It's probably a good thing that the current documentation is kept under
version control alongside the real code. So changes in functionality can
cleanly be adopted in the documentation as well. Maybe it makes sense to
have faq / howto's under VC as well, but I am not sure that is the best
solution. It all depends on if there are (community) people who feel
responsible in doing the "gardening".
2) It looks like the previous email already answered this. But
perhaps an easier option is to pass a bootloader option to not load the
synaptics driver. I had to pass nomodeset for a while. I was having
some issues with my radeon APU. It's now been resolved, so I don't
pass
nomodeset to the kernel arguments anymore.
Well, xf86-input-synaptics is not a kernel driver but an Xorg input
driver. It can only be enabled or disabled through the Xorg
configuration.
3) I believe you can just maintain your own copy of the guix git repo.
You can create your own package sources locally, and then not share
your
new definitions with upstream.
Thanks, I am going that way now.
Or you could use the new guix potlock.
I think that is what they were calling it once upon a time.
Hmm, not sure what it is or how it is supposed to work.
That said, it's not that I want to maintain proprietary software
packages, but about having an "incubator" repository which I might use
for my personal machine(s) until my packages are accepted upstream. (Or
maybe some of them won't ever, who knows.) The GUIX_PACKAGE_PATH
variable is probably sufficient for now.
Best
Martin