Re: [arch-general] Configuring enabled services
Am 19.03.2014 20:16, schrieb Ary Kleinerman: There's not really much magic going on. Are you aware of: /etc/systemd/system This contains symlinks that do already pretty much what you describe, and this is systemd's native configuration. Paul, Don't forget /run/systemd/system: Runtime units and /usr/lib/systemd/system: Units of installed packages /usr/lib/systemd only contains configuration managed by the package manager and /run/systemd contains only runtime configuration - this is all irrelevant for backups. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Configuring enabled services
Am 26.03.2014 23:13, schrieb Gesh: Thanks for the pointers. If I understand what's going on correctly, units specify in their [Install] section whether, when they're enabled, they should be pulled in by other units. Those symlinks usually populate the appropriate directory under /etc/systemd/system/. Besides that, some packages install symlinks under /usr/lib/systemd/system/ as part of their files to get pulled in by other units without requiring user intervention. What this means for backing up the configuration is that you simply back up /etc/systemd/system without resolving symlinks (and ignore that those symlinks point to paths outside of your backup). rsync can do that for you. This has the benefit of also backing up all permanent unit overrides and drop-ins that the admin may have made. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Hello, 2014-03-26 20:18 GMT+01:00 Leonid Isaev lis...@umail.iu.edu: On Wed, 26 Mar 2014 19:56:26 +0100 Thomas Bächler tho...@archlinux.org wrote: Hello all, it won't be too long until 3.14 is out and I want to address a topic that has been bugging me for a while. Our kernel includes everything and the kitchensink. I have no problem with delivering drivers that can be built modular, but there are other things that have an unknown impact on everyone. I want to trim our kernel down to what we actually support. Thanks for doing this. 1) Once we agreed to disable one LSM, everyone else said we can enable LSM XYZ, too. And so we did. Right now, we enable SELinux, SMACK, Tomoyo, AppArmor and Yama, although we don't support the userspace for any of those. I propose to drop all of them. I agree regarding SELinux/Apparmor (it's not only userspace tools, but also sane application policies that are missing). I strongly disagree with removing LSM from the packaged kernel. I'm currently using SELinux with AUR packages [1] (which I help to maintain) and a custom policy (basically a mix of Tresys' Reference Policy, Fedora policy and Debian patches [2]) and it works fine. The only reason behind why nobody hasn't asked yet to make libselinux and libsepol official packages? is that before this happens, the current maintainer of these AUR packages wants a working SELinux policy [3]. Here are three arguments to motivate my disagreement. * First, removing LSM support makes it difficult for users to test LSM. Before 3.13 kernel, users needed to recompile their kernel (or to install linux-selinux AUR package) to be able to use SELinux. This is a hard first step and I know too many people who thinks I don't want to recompile my kernel as I've already done magical things to make my graphic card works and I don't want to break my fragile config. Now people just needs to install packages (from unofficial repos or from the AUR) as described in the wiki [4] and reboot to start using SELinux. * Second, it's possible to compile things which are disabled at runtime. For example, I don't need to compile the kernel without IPv4 to test what breaks when running a non-IPv4 kernel, I only need to add a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing for LSM. Even if they are compiled, they can be enabled/disabled with such runtime configuration and this config doesn't require much work. * Third, users who want to combine several unofficial features for their kernel already have to do weird things. For example, I'm using a grsec kernel with SELinux. A few months ago, there were linux-grsec and linux-selinux in the AUR but no package which provided both. Hence I needed to build a custom package to have both. Now, the next time linux-grsec's maintainer will sync its config with the official repo, SELinux will be available in this package (unless I've missed something) and I'll no longer need to build my custom kernel. That been said, I agree that having a kernel with less features would be good. To my mind, here are possible ways : a) Create a linux-light package with less features than the linux package, and don't trim linux' configuration. b) Rename linux as linux-full (as an official package) and trim linux' config. c) Create a package (linux-src?) which install the kernel sources and provides an easy way to customize the config before making the packages (with pkgbuild). Currently linux-grsec AUR package provides this feature by using the MENUCONFIG environment variable [5]. d) Don't create new packages and trim linux' config (this is your idea, if I understood correctly). Any of a) or b) would suits fine for me if you choose to drop LSM in the lighter config. Regards, Nicolas [1] https://github.com/Siosm/siosm-selinux [2] https://github.com/fishilico/selinux-refpolicy-patched [3] https://github.com/Siosm/siosm-selinux/issues/6#issuecomment-32793261 [4] https://wiki.archlinux.org/index.php/SELinux [5] https://github.com/nning/linux-grsec/blob/master/PKGBUILD#L32
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
I think what Nicolas says is a good idea. I realise that Arch is not really a security-focused distro, but having to not recompile the kernel on my laptop after every upgrade with SELinux enabled is a pretty awesome thing. I realise that this is not really relevant to most Archers, but with Siosm working on a working Arch SELinux Policy, I think that having something like the SELinux LSM is not really a burden on the user. On the other hand, (seeing that it has come up) a package like linux-sources would be wonderful. In short, I think that for something as essential as the kernel, having multiple configurations (viz. linux, linux-lts, linux-light and linux-sources) in the official repos is a pretty good idea. I hope it can be realised. On Thu, Mar 27, 2014 at 5:07 PM, Nicolas Iooss nicolas.io...@m4x.orgwrote: Hello, 2014-03-26 20:18 GMT+01:00 Leonid Isaev lis...@umail.iu.edu: On Wed, 26 Mar 2014 19:56:26 +0100 Thomas Bächler tho...@archlinux.org wrote: Hello all, it won't be too long until 3.14 is out and I want to address a topic that has been bugging me for a while. Our kernel includes everything and the kitchensink. I have no problem with delivering drivers that can be built modular, but there are other things that have an unknown impact on everyone. I want to trim our kernel down to what we actually support. Thanks for doing this. 1) Once we agreed to disable one LSM, everyone else said we can enable LSM XYZ, too. And so we did. Right now, we enable SELinux, SMACK, Tomoyo, AppArmor and Yama, although we don't support the userspace for any of those. I propose to drop all of them. I agree regarding SELinux/Apparmor (it's not only userspace tools, but also sane application policies that are missing). I strongly disagree with removing LSM from the packaged kernel. I'm currently using SELinux with AUR packages [1] (which I help to maintain) and a custom policy (basically a mix of Tresys' Reference Policy, Fedora policy and Debian patches [2]) and it works fine. The only reason behind why nobody hasn't asked yet to make libselinux and libsepol official packages? is that before this happens, the current maintainer of these AUR packages wants a working SELinux policy [3]. Here are three arguments to motivate my disagreement. * First, removing LSM support makes it difficult for users to test LSM. Before 3.13 kernel, users needed to recompile their kernel (or to install linux-selinux AUR package) to be able to use SELinux. This is a hard first step and I know too many people who thinks I don't want to recompile my kernel as I've already done magical things to make my graphic card works and I don't want to break my fragile config. Now people just needs to install packages (from unofficial repos or from the AUR) as described in the wiki [4] and reboot to start using SELinux. * Second, it's possible to compile things which are disabled at runtime. For example, I don't need to compile the kernel without IPv4 to test what breaks when running a non-IPv4 kernel, I only need to add a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing for LSM. Even if they are compiled, they can be enabled/disabled with such runtime configuration and this config doesn't require much work. * Third, users who want to combine several unofficial features for their kernel already have to do weird things. For example, I'm using a grsec kernel with SELinux. A few months ago, there were linux-grsec and linux-selinux in the AUR but no package which provided both. Hence I needed to build a custom package to have both. Now, the next time linux-grsec's maintainer will sync its config with the official repo, SELinux will be available in this package (unless I've missed something) and I'll no longer need to build my custom kernel. That been said, I agree that having a kernel with less features would be good. To my mind, here are possible ways : a) Create a linux-light package with less features than the linux package, and don't trim linux' configuration. b) Rename linux as linux-full (as an official package) and trim linux' config. c) Create a package (linux-src?) which install the kernel sources and provides an easy way to customize the config before making the packages (with pkgbuild). Currently linux-grsec AUR package provides this feature by using the MENUCONFIG environment variable [5]. d) Don't create new packages and trim linux' config (this is your idea, if I understood correctly). Any of a) or b) would suits fine for me if you choose to drop LSM in the lighter config. Regards, Nicolas [1] https://github.com/Siosm/siosm-selinux [2] https://github.com/fishilico/selinux-refpolicy-patched [3] https://github.com/Siosm/siosm-selinux/issues/6#issuecomment-32793261 [4] https://wiki.archlinux.org/index.php/SELinux [5] https://github.com/nning/linux-grsec/blob/master/PKGBUILD#L32 --
Re: [arch-general] Configuring enabled services
On March 27, 2014 9:25:24 AM GMT+02:00, Thomas Bächler tho...@archlinux.org wrote: Am 26.03.2014 23:13, schrieb Gesh: Thanks for the pointers. If I understand what's going on correctly, units specify in their [Install] section whether, when they're enabled, they should be pulled in by other units. Those symlinks usually populate the appropriate directory under /etc/systemd/system/. Besides that, some packages install symlinks under /usr/lib/systemd/system/ as part of their files to get pulled in by other units without requiring user intervention. What this means for backing up the configuration is that you simply back up /etc/systemd/system without resolving symlinks (and ignore that those symlinks point to paths outside of your backup). rsync can do that for you. This has the benefit of also backing up all permanent unit overrides and drop-ins that the admin may have made. Basically, if I understood what happens correctly, the units under /etc/systemd/system/*.wants/ - or their targets, if they're symlinks - replace their corresponding units in the dependency graph. In addition, all unit files are installed to /usr/lib/systemd/system/, and the symlinks must have the same name as their targets, so only the symlinks' names need to be backed up. Therefore, only what's under /etc/systemd/system/ needs to be backed up, ignoring symlinks' targets. Besides that, the .wants directories in /usr/lib/systemd/system/ are managed by pacman, and represent upstream decisions to automatically start their units. Is this understanding correct? Thank you for your time, Gesh
Re: [arch-general] Configuring enabled services
Am 27.03.2014 09:41, schrieb Gesh: Basically, if I understood what happens correctly, the units under /etc/systemd/system/*.wants/ - or their targets, if they're symlinks - replace their corresponding units in the dependency graph. Not exactly. When you place a unit in foo.wants, then foo gets an additional Wants= dependency. Basically, this is a way to extend units with new Wants= and Requires= statements without modifying unit files. You don't *replace* the dependency graph, but *extend* it. In addition, all unit files are installed to /usr/lib/systemd/system/, Unit files can also be installed to /etc/systemd/system/, for example if you want to use a modified version of a system-supplied unit file. When you run start or enable on a unit name, system looks into those directories, taking the first one it finds. /run/systemd/generator.early /etc/systemd/system /run/systemd/system (*) /run/systemd/generator (*) /usr/lib/systemd/system /run/systemd/generator.late I am not 100% sure if I got the order of the ones marked with (*) right. As you can see here, there are units installed by the package manager (/usr/lib), units installed by the admin (/etc), temporary units installed either by automatic tools or by the admin (/run/systemd/system) and units installed by generators during systemd startup or reload (/run/systemd/generator*). Again, backing up the ones in /usr/lib does not make sense since those are contained in packages and can be reinstalled. Backing up the ones in /run makes no sense either since they only live until you reboot (or reload the configuration, in the case of generator units). However, backing up /etc/systemd/system entirely (not just the symlinks) make lots of sense, since the admin is likely to have custom units in there. and the symlinks must have the same name as their targets, so only the symlinks' names need to be backed up. Not necessarily. For example, /etc/systemd/system/display-manager.service points to /usr/lib/systemd/system/kdm.service. Most symlinks have the same name, but that's only convention, not necesity. Therefore, only what's under /etc/systemd/system/ needs to be backed up, ignoring symlinks' targets. I'd back up the symlinks including their targets. This makes it easier to restore configuration. Besides that, the .wants directories in /usr/lib/systemd/system/ are managed by pacman, and represent upstream decisions to automatically start their units. Indeed. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Thursday 27 Mar 2014 09:07:23 Nicolas Iooss wrote: c) Create a package (linux-src?) which install the kernel sources and provides an easy way to customize the config before making the packages (with pkgbuild). Currently linux-grsec AUR package provides this feature by using the MENUCONFIG environment variable [5]. One of my machines requires a patched kernel, but I've never felt the need for a linux-src package. I use Yaourt as an ABS client, but there are others available: # yaourt -G linux # cd linux --- do patching --- # makepkg The PKGBUILD even contains instructions on how to tweak the configuration, if I remember correctly. Paul
Re: [arch-general] Configuring enabled services
On March 27, 2014 11:20:04 AM GMT+02:00, Thomas Bächler tho...@archlinux.org wrote: Am 27.03.2014 09:41, schrieb Gesh: Basically, if I understood what happens correctly, the units under /etc/systemd/system/*.wants/ - or their targets, if they're symlinks - replace their corresponding units in the dependency graph. Not exactly. When you place a unit in foo.wants, then foo gets an additional Wants= dependency. Basically, this is a way to extend units with new Wants= and Requires= statements without modifying unit files. You don't *replace* the dependency graph, but *extend* it. But what if bar.unit Wants=foo.unit and I add a custom foo.unit to bar.unit.wants/ ? Will both be run? Will the custom foo.unit replace the built-in? In addition, all unit files are installed to /usr/lib/systemd/system/, Unit files can also be installed to /etc/systemd/system/, for example if you want to use a modified version of a system-supplied unit file. I meant in the sense of convention. Of course a sysadmin can drop units into /etc. It's its entire raison d'être. When you run start or enable on a unit name, system looks into those directories, taking the first one it finds. /run/systemd/generator.early /etc/systemd/system /run/systemd/system (*) /run/systemd/generator (*) /usr/lib/systemd/system /run/systemd/generator.late I am not 100% sure if I got the order of the ones marked with (*) right. As you can see here, there are units installed by the package manager (/usr/lib), units installed by the admin (/etc), temporary units installed either by automatic tools or by the admin (/run/systemd/system) and units installed by generators during systemd startup or reload (/run/systemd/generator*). Again, backing up the ones in /usr/lib does not make sense since those are contained in packages and can be reinstalled. Backing up the ones in /run makes no sense either since they only live until you reboot (or reload the configuration, in the case of generator units). However, backing up /etc/systemd/system entirely (not just the symlinks) make lots of sense, since the admin is likely to have custom units in there. and the symlinks must have the same name as their targets, so only the symlinks' names need to be backed up. Not necessarily. For example, /etc/systemd/system/display-manager.service points to /usr/lib/systemd/system/kdm.service. Most symlinks have the same name, but that's only convention, not necesity. Therefore, only what's under /etc/systemd/system/ needs to be backed up, ignoring symlinks' targets. I'd back up the symlinks including their targets. This makes it easier to restore configuration. So basically, you back up the directory under /etc not following symlinks, then when restoring use pkgfile, filenames and installed-package-list to determine what packages you need to reinstall to get those links working. Besides that, the .wants directories in /usr/lib/systemd/system/ are managed by pacman, and represent upstream decisions to automatically start their units. Indeed. OK. I assume the links under /etc are generated by systemctl when enabling a unit with an [Install] section? Thanks for the clarifications, Gesh
Re: [arch-general] Configuring enabled services
Am 27.03.2014 13:26, schrieb Gesh: But what if bar.unit Wants=foo.unit and I add a custom foo.unit to bar.unit.wants/ ? Will both be run? Will the custom foo.unit replace the built-in? I don't know what happens if you try, but there can only be one unit of the same name. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Am 27.03.2014 09:07, schrieb Nicolas Iooss: I agree regarding SELinux/Apparmor (it's not only userspace tools, but also sane application policies that are missing). I strongly disagree with removing LSM from the packaged kernel. I'm currently using SELinux with AUR packages [1] (which I help to maintain) and a custom policy (basically a mix of Tresys' Reference Policy, Fedora policy and Debian patches [2]) and it works fine. The only reason behind why nobody hasn't asked yet to make libselinux and libsepol official packages? is that before this happens, the current maintainer of these AUR packages wants a working SELinux policy [3]. You use AUR packages for all kinds of SELinux stuff, so why not use a custom kernel for that? Here are three arguments to motivate my disagreement. * First, removing LSM support makes it difficult for users to test LSM. Before 3.13 kernel, users needed to recompile their kernel (or to install linux-selinux AUR package) to be able to use SELinux. So, installing packages from AUR is easy, _except_ when you need to install the kernel? This is a hard first step and I know too many people who thinks I don't want to recompile my kernel as I've already done magical things to make my graphic card works and I don't want to break my fragile config. Now people just needs to install packages (from unofficial repos or from the AUR) as described in the wiki [4] and reboot to start using SELinux. So, install a kernel from unofficial repositories or AUR? It's just a package. * Second, it's possible to compile things which are disabled at runtime. That they are disabled at runtime does not mean that they have no impact at runtime. At best, it's only a performance impact and at worst, it even causes problems. The whole idea is to make the kernel smaller and to avoid problems caused by things we don't make use of. Even if they are compiled, they can be enabled/disabled with such runtime configuration and this config doesn't require much work. Do you even know what that means? If I see this right, every time the kernel needs to do some permission check, it needs to ask are we using LSM xyz?. In any case, it's more code and thus more room for failure. I see where you are coming from and I used to think the same way. But after we enabled AppArmor and SELinux in 3.13, the audit subsystem was silently enabled - and it is _on_ by default. This whole story got me thinking, do we even have any idea what the consequences of adding these features are? And I don't think we do. The fact that these LSMs must be compiled into the kernel and cannot be built as modules tells you something important: These options change the behaviour of the kernel at its core. I don't have a really strong argument against these options, except that once we enable them, we need to deal with problems that they may cause users. I think we are better off going with what the majority of Arch users use these days (simple DAC LSM) and let everyone else deal with their use case themselves. * Third, users who want to combine several unofficial features for their kernel already have to do weird things. Users competent enough to do weird things can compile their own kernels. a) Create a linux-light package with less features than the linux package, and don't trim linux' configuration. b) Rename linux as linux-full (as an official package) and trim linux' config. I won't maintain two kernels just for the sake of feature-creep. c) Create a package (linux-src?) which install the kernel sources and provides an easy way to customize the config before making the packages (with pkgbuild). Currently linux-grsec AUR package provides this feature by using the MENUCONFIG environment variable [5]. What is this supposed to do? Makepkg is for building packages, pacman is for installing binaries. If you want automated package building on upgrades, use Gentoo. d) Don't create new packages and trim linux' config (this is your idea, if I understood correctly). signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Am 27.03.2014 13:46, schrieb Thomas Bächler:
Do you even know what that means? If I see this right, every time
the kernel needs to do some permission check, it needs to ask are
we using LSM xyz?. In any case, it's more code and thus more room
for failure.
Not necessarily, i do not know the code of all the policy enforcement
points, but if you have a function pointer to the policy decision
function, you only have to query this function. So if you enable
SELinux, you let the pointer point to the SELinux function.
Maybe you don't understand what i mean because of my bad english, here
an example code:
int (*func)( char *arg, ... );
int SELinux_pdp( char *arg, ... ) { Code }
int pdp( char *arg, ... ) { Code }
if( SELinux ) {
func = SELinux_pdp;
} else {
func = pdp;
}
So you only have to call func( arg, ... ) and test the returned value.
Besides that, i'd prefer a smaller kernel, too.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iF4EAREIAAYFAlM0NKkACgkQkr64biT2RYQzegD+MU+yBgTPoIA0RB9CH9l2CFpp
dEEGg5FfYVdodSYtAGsA/jOmUhnz+DvogZDYVHpsPmjObexou6qcGRpJPMxIL8jK
=igbX
-END PGP SIGNATURE-
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Am 27.03.2014 15:24, schrieb Simon Brand: Am 27.03.2014 13:46, schrieb Thomas Bächler: Do you even know what that means? If I see this right, every time the kernel needs to do some permission check, it needs to ask are we using LSM xyz?. In any case, it's more code and thus more room for failure. Not necessarily, i do not know the code of all the policy enforcement points, but if you have a function pointer to the policy decision function, you only have to query this function. So if you enable SELinux, you let the pointer point to the SELinux function. Do you know that Linux operates this way? If so, at least we don't have to assume that performance suffers. This again begs the question, why do the LSMs need to be built-in? Why can't they be modular? I don't expect you to answer these questions, they are just things that I consider. Perhaps let me rephrase my rationale: If we include support for an LSM in Linux, it should be because we support it in our user-space, too. I don't see SELinux being supported by default in Arch anytime soon. _If_ at some point we make a decision to support it (optional or by default), we can enable it in the kernel. The whole idea of trimming down the kernel is to stop enabling things because some users _may_ _possibly_ want to use them. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
În ziua de Miercuri 26 Martie 2014, la 19:56:26, Thomas Bächler a scris: I want to trim our kernel down to what we actually support. 1) Once we agreed to disable one LSM, everyone else said we can enable LSM XYZ, too. And so we did. Right now, we enable SELinux, SMACK, Tomoyo, AppArmor and Yama, although we don't support the userspace for any of those. My opinion on this is that the kernel should be the ground on which userspace should always work. Features should be taken out with bug reports demonstrating breakage in general usage, slowdowns or security risks. Another important point of view should be the maintenance required to support these seldom used features and I have nothing to comment on this. Specifically regarding slowdowns, my layman opinion on this is that they are meaningless in the general usage of the -ARCH kernel. If taking out theoretically useful features out of the kernel means that in the end we gain 2 Mb of free memory or Apache is able to sustain 10500 connections instead of 1 I personally don't see it as good bargain. Building a personal or an AUR linux package is easy. Maintaining one is a lot harder. The most important thing that is lost in this process is the community support. One cannot compare the scrutiny and the testing of any AUR linux package with those of the -ARCH kernel. That being said I'd like to read and help test a before and after kernel in regards to performance or any other concerning factor. -- Arthur Țițeică signature.asc Description: This is a digitally signed message part.
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Thu, Mar 27, 2014 at 09:07:23AM +0100, Nicolas Iooss wrote: Here are three arguments to motivate my disagreement. * First, removing LSM support makes it difficult for users to test LSM. Before 3.13 kernel, users needed to recompile their kernel (or to install linux-selinux AUR package) to be able to use SELinux. This is a hard first step and I know too many people who thinks I don't want to recompile my kernel as I've already done magical things to make my graphic card works and I don't want to break my fragile config. Now people just needs to install packages (from unofficial repos or from the AUR) as described in the wiki [4] and reboot to start using SELinux. * Second, it's possible to compile things which are disabled at runtime. For example, I don't need to compile the kernel without IPv4 to test what breaks when running a non-IPv4 kernel, I only need to add a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing for LSM. Even if they are compiled, they can be enabled/disabled with such runtime configuration and this config doesn't require much work. * Third, users who want to combine several unofficial features for their kernel already have to do weird things. For example, I'm using a grsec kernel with SELinux. A few months ago, there were linux-grsec and linux-selinux in the AUR but no package which provided both. Hence I needed to build a custom package to have both. Now, the next time linux-grsec's maintainer will sync its config with the official repo, SELinux will be available in this package (unless I've missed something) and I'll no longer need to build my custom kernel. As a lowly end-user, I'll have to disagree with you. The bulk of your reasoning comes down to *I* use it, so don't take it away from me. But your case is hardly representative; I highly doubt that the typical desktop user (that is, the typical Arch user) makes use of SELinux or its cohorts; no doubt there are people running Arch servers that use it, but again that's not representative of the community at large, in which many people just install Arch on their laptops and desktops for everyday production and entertainment use. When I build a custom kernel for my laptop, the LSM stuff and kernel debugging options are the first to go, as they have absolutely no benefit for someone who uses a computer primarily for reasearch and writing, coding and design work, web browsing and music. They're complements for specific use-cases---server administration (most likely when multiple users are involved) and kernel hacking, respectively---and are of no use to anyone who doesn't partake in those use-cases (how necessary is MAC to someone who interacts with and monitors a single machine all day?). Besides, as you've said, you already need to build the userspace utilities from source (because not too long ago, the devs voiced their opposition to maintaining SELinux officially), so leaving such features in the kernel to ease testing is both specious and a mismeasure of how useful or vital they might be. Suppose the majority of people who test SELinux decide to drop it, as seems to be the case in my (admittedly limited) observations. Of what value, then, is the work the devs did to maintain it? That been said, I agree that having a kernel with less features would be good. To my mind, here are possible ways : a) Create a linux-light package with less features than the linux package, and don't trim linux' configuration. b) Rename linux as linux-full (as an official package) and trim linux' config. c) Create a package (linux-src?) which install the kernel sources and provides an easy way to customize the config before making the packages (with pkgbuild). Currently linux-grsec AUR package provides this feature by using the MENUCONFIG environment variable [5]. d) Don't create new packages and trim linux' config (this is your idea, if I understood correctly). Any of a) or b) would suits fine for me if you choose to drop LSM in the lighter config. I've used Arch for years now, but I can remember what it was like as a n00b. From the perspective of someone who is new to Arch, this is grossly misleading. Someone unfamiliar with how Arch packaging works (or a long-term Archer who doesn't pay close enough attention to the news and mailing lists) will conceivably reason that linux-full = linux-not-broken, and linux-light and linux-src = I have to screw with it for two hours to get my GPU working. They'll likely just install linux-full anyway, unaware of the distinction. It seems far more reasonable to me to trim the kernel to those things typical of everyday desktop use, and trust that members of the community will maintain those things which they find useful separately. I don't mean to be presumptuous, but it's my understanding that the primary goal of the Arch devs and repo maintainers is to provide a minimal, functional distribution platform that users can utilize to craft their
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Wed, 26 Mar 2014 22:17:25 +0100 Thomas Bächler tho...@archlinux.org wrote: Am 26.03.2014 21:31, schrieb Leonid Isaev: On Wed, 26 Mar 2014 21:00:15 +0100 Thomas Bächler tho...@archlinux.org wrote: Am 26.03.2014 20:18, schrieb Leonid Isaev: However, I don't think that Yama requires any userspace components, does it? Currently, I boot with security=yama and completely disabled non-admin ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels should keep Yama available albeit disabled by default (as they now do). Once yama is built-in, the ptrace_scope protection is enabled by default. There is no option to change that. But by default, kernel.yama.ptrace_scope = 0 No. The default is 1. Yes, you are right, I was speaking from the old memory... If this causes problems and a default sysctl.d/ conf file is not desired, then I guess, Yama can go away as well. Does this discussion also apply to the -lts kernel? Thanks, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] graphical display management
On 2014-03-25 15:59, arch-general-requ...@archlinux.org wrote: -- Message: 1 Date: Mon, 24 Mar 2014 22:49:06 +0100 From: Jakub Klinkovsk? j@gmx.com Subject: Re: [arch-general] graphical display management Interestingly, 'su a' results in the cursor 'pwd' to be the root home directory and not '/home/a'. This is the expected behaviour. Just run the command 'cd', without arguments it will get you into the home directory, which should be '/home/a'. Or run 'su -l a'. I would have expected the home directory for 'root' _not_ to be accessible to other users.
Re: [arch-general] graphical display management
On Thursday 27 Mar 2014 16:45:35 message wrote: On 2014-03-25 15:59, arch-general-requ...@archlinux.org wrote: -- Message: 1 Date: Mon, 24 Mar 2014 22:49:06 +0100 From: Jakub Klinkovsk? j@gmx.com Subject: Re: [arch-general] graphical display management Interestingly, 'su a' results in the cursor 'pwd' to be the root home directory and not '/home/a'. This is the expected behaviour. Just run the command 'cd', without arguments it will get you into the home directory, which should be '/home/a'. Or run 'su -l a'. I would have expected the home directory for 'root' _not_ to be accessible to other users. By root home directory, do you mean / or /root? You are correct that /root should only be accessible by root. If the pwd command returns /root and whoami command does not return root, then there's something wrong with your directory permissions. Paul
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Thursday, March 27, 2014 04:45:24 PM Arthur Țițeică wrote: My opinion on this is that the kernel should be the ground on which userspace should always work. Features should be taken out with bug reports demonstrating breakage in general usage, slowdowns or security risks. Another important point of view should be the maintenance required to support these seldom used features and I have nothing to comment on this. Specifically regarding slowdowns, my layman opinion on this is that they are meaningless in the general usage of the -ARCH kernel. If taking out theoretically useful features out of the kernel means that in the end we gain 2 Mb of free memory or Apache is able to sustain 10500 connections instead of 1 I personally don't see it as good bargain. This seems like it doesn't exactly fit with the Arch Way though. Arch is supposed to be simple and minimal. Why should the default be add all the features for a distribution that is partially based on being minimal and lightweight? I guess I just don't see the reason for adding in feature by default that so few people will actually use. And the people who will be using it should have the knowledge and ability to build their own kernel that will have those features enabled.
Re: [arch-general] graphical display management
On 2014-03-25 15:59, arch-general-requ...@archlinux.org wrote: -- Message: 2 Date: Tue, 25 Mar 2014 00:15:27 +0100 From: Guus Snijders gsnijd...@gmail.com Subject: Re: [arch-general] graphical display management Ok. Could you try resetting the password for user a? You could do this (as root) with: passwd a And then try again to login to a tty. This was successful thanks, but the dvorak keyboard layout is not recognised at the graphical sign-in prompt. The layout is recognised when a command terminal is opened within the graphical user session. Just to be sure: you do realise that the password shown in /etc/shadow is the encrypted password and not the literal string to type in? (no offence). Using 'less' to access the file, the password is visible as literal text.
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
TL;DR: this is a technical answer which can be seen as slightly off-topic as it focus only on SELinux and not much about kernel config trimming. 2014-03-27 13:46 GMT+01:00 Thomas Bächler tho...@archlinux.org: Am 27.03.2014 09:07, schrieb Nicolas Iooss: I agree regarding SELinux/Apparmor (it's not only userspace tools, but also sane application policies that are missing). I strongly disagree with removing LSM from the packaged kernel. I'm currently using SELinux with AUR packages [1] (which I help to maintain) and a custom policy (basically a mix of Tresys' Reference Policy, Fedora policy and Debian patches [2]) and it works fine. The only reason behind why nobody hasn't asked yet to make libselinux and libsepol official packages? is that before this happens, the current maintainer of these AUR packages wants a working SELinux policy [3]. You use AUR packages for all kinds of SELinux stuff, so why not use a custom kernel for that? Because there is a chicken-and-egg issue here. The long term motivation is to migrate SELinux-compiled duplicated packages (like sudo, systemd...) from the AUR to official packages (long term meaning no timeline can be given as there are way too many people against it). Currently there is a security issue due to package duplication in the AUR (when a security patch is made for systemd for example, it takes some time before systemd-selinux is updated). I won't discuss this more in this thread as it is off topic. Here are three arguments to motivate my disagreement. * First, removing LSM support makes it difficult for users to test LSM. Before 3.13 kernel, users needed to recompile their kernel (or to install linux-selinux AUR package) to be able to use SELinux. So, installing packages from AUR is easy, _except_ when you need to install the kernel? Yes, because there is no easy way to mix two packages. I don't know any other software which is provided in different packages depending on their configuration. Most Archlinux packages support via configure-time switches many things I've never heard about. Why would it be different for the kernel? (I'm expecting people to ask me this question and as I don't have any relevant answer yet, I ask it here.) This is a hard first step and I know too many people who thinks I don't want to recompile my kernel as I've already done magical things to make my graphic card works and I don't want to break my fragile config. Now people just needs to install packages (from unofficial repos or from the AUR) as described in the wiki [4] and reboot to start using SELinux. So, install a kernel from unofficial repositories or AUR? It's just a package. If you installed modules with DKMS, you also need to recompile these modules and it may break. I agree that it's just a package and nothing should break, but that's just theory and in the real world, things like unsupported DKMS modules break with a custom kernel and this increases the difficulty a lot. However this increases the maintenance burden of unsupported things so it's not relevant here. * Second, it's possible to compile things which are disabled at runtime. That they are disabled at runtime does not mean that they have no impact at runtime. At best, it's only a performance impact and at worst, it even causes problems. The whole idea is to make the kernel smaller and to avoid problems caused by things we don't make use of. Even if they are compiled, they can be enabled/disabled with such runtime configuration and this config doesn't require much work. Do you even know what that means? If I see this right, every time the kernel needs to do some permission check, it needs to ask are we using LSM xyz?. In any case, it's more code and thus more room for failure. According to http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/security.c?id=v3.13 and http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/selinux/hooks.c?id=v3.13#n5977 , the security checks are done using a structure of function pointers (struct security_operations *security_ops) and the execution path to check a file permission (at http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/read_write.c#n367 for example) looks exactly the same in both SELinux not compiled and SELinux compiled but disabled configurations. I may have misunderstood the code, in such case I'd be glad if you correct me. I see where you are coming from and I used to think the same way. But after we enabled AppArmor and SELinux in 3.13, the audit subsystem was silently enabled - and it is _on_ by default. This whole story got me thinking, do we even have any idea what the consequences of adding these features are? And I don't think we do. This does sound weird. Could you please give me some references to this so that I can understand better? I only know that SELinux uses the audit subsystem to report denials and that the audit subsystem can
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
2014-03-27 16:31 GMT+01:00 Bigby James bigby.ja...@crepcran.com: On Thu, Mar 27, 2014 at 09:07:23AM +0100, Nicolas Iooss wrote: Here are three arguments to motivate my disagreement. * First, removing LSM support makes it difficult for users to test LSM. Before 3.13 kernel, users needed to recompile their kernel (or to install linux-selinux AUR package) to be able to use SELinux. This is a hard first step and I know too many people who thinks I don't want to recompile my kernel as I've already done magical things to make my graphic card works and I don't want to break my fragile config. Now people just needs to install packages (from unofficial repos or from the AUR) as described in the wiki [4] and reboot to start using SELinux. * Second, it's possible to compile things which are disabled at runtime. For example, I don't need to compile the kernel without IPv4 to test what breaks when running a non-IPv4 kernel, I only need to add a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing for LSM. Even if they are compiled, they can be enabled/disabled with such runtime configuration and this config doesn't require much work. * Third, users who want to combine several unofficial features for their kernel already have to do weird things. For example, I'm using a grsec kernel with SELinux. A few months ago, there were linux-grsec and linux-selinux in the AUR but no package which provided both. Hence I needed to build a custom package to have both. Now, the next time linux-grsec's maintainer will sync its config with the official repo, SELinux will be available in this package (unless I've missed something) and I'll no longer need to build my custom kernel. As a lowly end-user, I'll have to disagree with you. The bulk of your reasoning comes down to *I* use it, so don't take it away from me. But your case is hardly representative; I highly doubt that the typical desktop user (that is, the typical Arch user) makes use of SELinux or its cohorts; no doubt there are people running Arch servers that use it, but again that's not representative of the community at large, in which many people just install Arch on their laptops and desktops for everyday production and entertainment use. When I build a custom kernel for my laptop, the LSM stuff and kernel debugging options are the first to go, as they have absolutely no benefit for someone who uses a computer primarily for reasearch and writing, coding and design work, web browsing and music. They're complements for specific use-cases---server administration (most likely when multiple users are involved) and kernel hacking, respectively---and are of no use to anyone who doesn't partake in those use-cases (how necessary is MAC to someone who interacts with and monitors a single machine all day?). Besides, as you've said, you already need to build the userspace utilities from source (because not too long ago, the devs voiced their opposition to maintaining SELinux officially), so leaving such features in the kernel to ease testing is both specious and a mismeasure of how useful or vital they might be. Suppose the majority of people who test SELinux decide to drop it, as seems to be the case in my (admittedly limited) observations. Of what value, then, is the work the devs did to maintain it? Sorry if my message sounded too much as I use it so I want other people to make my life easier. That was not the intended tone at all. If you need a bit more background about how I use ArchLinux, let me say I'm using it on my laptop, where I don't fear to do things that breaks my system (and if often breaks) because I have easy physical access. When I needed to set up SELinux on a server (not running Arch) a few months ago, I decided to first familiarize myself with this software on my laptop. It took me a long time before having a working system and I'm trying to reduce that time for other users who might have same ideas as I (eg. by reporting and helping fixing bugs like http://lists.gnu.org/archive/html/bug-coreutils/2014-01/msg9.html). Of course, I'm biased when I speak of SELinux so basically I try to imagine the state of mind of normal people by replacing SELinux with Linux containers, which I've never used and see as unneeded weight (this is a biased unmotivated statement which may be untrue). I don't know if currently to run LXC or systemd-nspawn you need to recompile your kernel, but you need at least UTS namespaces, network namespaces... and I don't know if anyone will consider disabling these features, but I expect voices to be raised if someone thinks of removing CONFIG_UTS_NS and CONFIG_NET_NS (or are such decisions expected to happen without anybody noticing?). That been said, I agree that having a kernel with less features would be good. To my mind, here are possible ways : a) Create a linux-light package with less features than the linux package, and don't trim linux'
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
I am a complete noob and only follow the lists out of interest. I am also very young, so please forgive my impertinence. Thanks Thomas for your work!! Just my 2c: On 03/27/2014 08:34 PM, Nicolas Iooss wrote: 2014-03-27 16:31 GMT+01:00 Bigby James bigby.ja...@crepcran.com: On Thu, Mar 27, 2014 at 09:07:23AM +0100, Nicolas Iooss wrote: Here are three arguments to motivate my disagreement. * First, removing LSM support makes it difficult for users to test LSM. Before 3.13 kernel, users needed to recompile their kernel (or to install linux-selinux AUR package) to be able to use SELinux. This is a hard first step and I know too many people who thinks I don't want to recompile my kernel as I've already done magical things to make my graphic card works and I don't want to break my fragile config. Now people just needs to install packages (from unofficial repos or from the AUR) as described in the wiki [4] and reboot to start using SELinux. * Second, it's possible to compile things which are disabled at runtime. For example, I don't need to compile the kernel without IPv4 to test what breaks when running a non-IPv4 kernel, I only need to add a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing for LSM. Even if they are compiled, they can be enabled/disabled with such runtime configuration and this config doesn't require much work. * Third, users who want to combine several unofficial features for their kernel already have to do weird things. For example, I'm using a grsec kernel with SELinux. A few months ago, there were linux-grsec and linux-selinux in the AUR but no package which provided both. Hence I needed to build a custom package to have both. Now, the next time linux-grsec's maintainer will sync its config with the official repo, SELinux will be available in this package (unless I've missed something) and I'll no longer need to build my custom kernel. As a lowly end-user, I'll have to disagree with you. The bulk of your reasoning comes down to *I* use it, so don't take it away from me. But your case is hardly representative; I highly doubt that the typical desktop user (that is, the typical Arch user) makes use of SELinux or its cohorts; no doubt there are people running Arch servers that use it, but again that's not representative of the community at large, in which many people just install Arch on their laptops and desktops for everyday production and entertainment use. When I build a custom kernel for my laptop, the LSM stuff and kernel debugging options are the first to go, as they have absolutely no benefit for someone who uses a computer primarily for reasearch and writing, coding and design work, web browsing and music. They're complements for specific use-cases---server administration (most likely when multiple users are involved) and kernel hacking, respectively---and are of no use to anyone who doesn't partake in those use-cases (how necessary is MAC to someone who interacts with and monitors a single machine all day?). Besides, as you've said, you already need to build the userspace utilities from source (because not too long ago, the devs voiced their opposition to maintaining SELinux officially), so leaving such features in the kernel to ease testing is both specious and a mismeasure of how useful or vital they might be. Suppose the majority of people who test SELinux decide to drop it, as seems to be the case in my (admittedly limited) observations. Of what value, then, is the work the devs did to maintain it? Sorry if my message sounded too much as I use it so I want other people to make my life easier. That was not the intended tone at all. If you need a bit more background about how I use ArchLinux, let me say I'm using it on my laptop, where I don't fear to do things that breaks my system (and if often breaks) because I have easy physical access. When I needed to set up SELinux on a server (not running Arch) a few months ago, I decided to first familiarize myself with this software on my laptop. It took me a long time before having a working system and I'm trying to reduce that time for other users who might have same ideas as I (eg. by reporting and helping fixing bugs like http://lists.gnu.org/archive/html/bug-coreutils/2014-01/msg9.html). Of course, I'm biased when I speak of SELinux so basically I try to imagine the state of mind of normal people by replacing SELinux with Linux containers, which I've never used and see as unneeded weight (this is a biased unmotivated statement which may be untrue). I don't know if currently to run LXC or systemd-nspawn you need to recompile your kernel, but you need at least UTS namespaces, network namespaces... and I don't know if anyone will consider disabling these features, but I expect voices to be raised if someone thinks of removing CONFIG_UTS_NS and CONFIG_NET_NS (or are such decisions expected to happen without anybody
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On 27.03.2014 21:59, Bennett Piater wrote: I am a complete noob and only follow the lists out of interest. First lesson which also applies to a bunch of other people in this thread: only quote what you need. 129 lines of quoted text before your reply is bad. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Thu, Mar 27, 2014 at 5:46 AM, Thomas Bächler The fact that these LSMs must be compiled into the kernel and cannot be built as modules tells you something important: These options change the behaviour of the kernel at its core. I was under the impression that this was s security feature to make it a bit more difficult to switch off your configured LSM. -- Pete
Re: [arch-general] What's with F# and mono?
On Wed, Mar 26, 2014 at 11:54:29AM -0600, Squall Lionheart wrote: On Tue, Mar 25, 2014 at 4:55 PM, Magnus Therning mag...@therning.orgwrote: I'm just starting to dip my toes in the mono waters. Slightly prompted by my current situation at work. In particular I'm interested in F#, but I'm finding the whole situation around mono/monodevelop + F# a bit confusing. 1. There are indications online that mono ships with F# [^1][^2]. But the mono package in Arch doesn't include F#. Looking at the sources used to build the mono package there is no F# in sight. Was it ever there? 2. The package on AUR[^3] for fsharp is rather outdated. Not such a big problem, the building received a lot of TLC so the package is extremely simple to bring up-to-date. 3. Is there an F# add-in for monodevelop? There seems to have been one back in 2010, but it's not distributed any more, [^4]. However, other places say there is an add-in available, [^5] (however, downloading fails). So, can anyone help me get a clearer picture of F# on mono (and ArchLinux)? /M [^1]: http://tirania.org/blog/archive/2010/Nov-11.html - talking of plans to include F# in mono. [^2]: http://is.gd/cNC5xb- - F# is included in the standard Mono release, but it's still missing from the MonoDevelop IDE. [^3]: https://aur.archlinux.org/packages/fsharp/ [^4]: http://is.gd/YndnsA- - bug on F# add-in missing, closed for MD 2.4, the last comment suggests it'd be re-opened [^5]: http://is.gd/YndnsA- which links to http://addins.monodevelop.com/Project/Index/48 I had this running in Arch using the packages from the standard repositories several months ago (new system since then). I had to compile and install F# manually from [1]. If memory serves, I had to install an add-on/plug-in in mono develop for F# support to work. [1] https://github.com/fsharp/fsharp Great, there is hope then :) Do you happen to remember where you found that add-on for MonoDevelop? I can't seem to find one that can be downloaded AND plugged into MD. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Goto labels should be left-aligned in all caps and should include the programmer's name, home phone number, and credit card number. -- Abdul Nizar pgpnpsxeFiBTK.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Thu, Mar 27, 2014 at 10:11 AM, Kevin Ott This seems like it doesn't exactly fit with the Arch Way though. Arch is supposed to be simple and minimal. Why should the default be add all the features for a distribution that is partially based on being minimal and lightweight? I guess I just don't see the reason for adding in feature by default that so few people will actually use. And the people who will be using it should have the knowledge and ability to build their own kernel that will have those features enabled. I thought part of 'minimal' meant that the packages were as stock as possible. I was under the impression that we shipped minimally altered packages and it was up to the administrator to perfect each package to her liking. I thought we only make a few little patches to the default kernel in the repo and anyone who wants to strip drivers and use BFS is welcome to do so through the AUR and/or ABS. I don't really use stock kernel so it doesn't matter to me, but for point of reference, (and please correct me if I'm wrong here) I thought default in the repos was the generally accepted Arch Way. -- Pete
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Thu, Mar 27, 2014 at 2:19 PM, Peter Baldridge petebaldri...@gmail.com wrote: I thought part of 'minimal' meant that the packages were as stock as possible. I was under the impression that we shipped minimally altered packages and it was up to the administrator to perfect each package to her liking. The kernel doesn't need to be patched to remove any of this functionality. It's all done though the kernel configuration file which isn't supplied upstream. Joel
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Am 27.03.2014 20:33, schrieb Nicolas Iooss: TL;DR: this is a technical answer which can be seen as slightly off-topic as it focus only on SELinux and not much about kernel config trimming. Very interesting, thanks for looking into it deeper. I'll leave most of this uncommented. This does sound weird. Could you please give me some references to this so that I can understand better? I only know that SELinux uses the audit subsystem to report denials and that the audit subsystem can be disabled at boot time using audit=0 kernel command line parameter (and also I've read http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/audit.c?id=v3.13#n1001). Okay, you are right, it wasn't AppArmor, it was SELinux. According to Kconfig, SELinux depends on Audit. And here is my problem: Audit is enabled by default and must be explicitly disabled by the admin. This is a showstopper for me! There is no kernel option to configure audit to be disabled by default (as far as I am aware) so that it can be enabled with 'audit=1' on the command line. As long as SELinux needs audit and audit is enabled by default, SELinux will not make it to the 3.14+ versions of our linux package. signature.asc Description: OpenPGP digital signature
Re: [arch-general] GNOME Software: Status and integrable?
On Tue, Mar 25, 2014 at 5:26 PM, Karol Babioch ka...@babioch.de wrote: Hi, now that GNOME 3.12 has been released and probably will hit the repos in the next couple of days/weeks, I'm wondering what the current status of Software is [1]? This is an application similar to an app store in the mobile world. I couldn't find it in the repos, and I wouldn't expect it to even work without some patching, because obviously it would have to be integrated into the packet management system. The only reference I could find in regards to Arch Linux was a forum thread from last year [2], which basically ended up in a mess without any real answers. It is correct that GNOME Software uses PackageKit. As can be seen on the feature matrix[1], libalpm support (which is upstream, so no patching), while a little spotty, is fairly decent. I can't back this up with code or documentation, but from my very cursory testing, the PackageKit backend appears to do the right thing with regards to updates (it doesn't sync the database). You may also be interested in a recent thread which was started on the GNOME desktop-devel-list list[2]. [1]: http://www.freedesktop.org/software/PackageKit/pk-matrix.html [2]: https://mail.gnome.org/archives/desktop-devel-list/2014-March/msg00107.html On the other hand I may have missed it, because GNOME is really good in using generic terms like Software and Web to name their applications, which are not great to search for :'(. You are looking for the gnome-packagekit package. I'm not interested in another flame war about GNOME, when it hits the repos and things like that. I just want to know whether this particular application is available/works and if not what the technical hurdles would be to make it work and whether it is feasible to get it working in the near term. Arguably users of Arch Linux are expected to know how to use use the command line (including pacman) and I'm fine with that, but I wouldn't mind to be able to browse an app store, just for the fun of it ;). Best regards, Karol Babioch [1]: https://wiki.gnome.org/Design/Apps/Software [2]: https://bbs.archlinux.org/viewtopic.php?id=170223
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On 27 March 2014 21:34, Kevin Ott supercodingmon...@gmail.com wrote: I'm pretty sure your summary is accurate. However, these are things done in a configuration file when building the kernel. There isn't really a default. There is -- download the kernel sources and run make defconfig. It'll start with the current default for the architecture you're building on [1 - x86_64][1 - i386], (which might not be up-to-date), then sets any new flags to their default state. I dunno how usable the default config is though, presumably not very, or else Arch wouldn't deviate so from the defaults so much as to need to ship custom configs with ABS. WorMzy [1 - x86_64] https://github.com/torvalds/linux/blob/master/arch/x86/configs/x86_64_defconfig [1 - i386] https://github.com/torvalds/linux/blob/master/arch/x86/configs/i386_defconfig
