Re: [arch-general] dash as default shell?
On Wed, 17 Jun 2020 at 21:21, brent s. wrote: > Now, to init- because Arch uses systemd (and, yes, now Debian and > Ubuntu), one must wonder what benefit, if any, this actually serves. > systemd invokes the command directly, it does not spawn a shell to run > an init script like sysvinit, upstart, openrc, etc. This is, primarily, > the purpose of the system shell. > > I don't really see much of a benefit to it being that Arch uses systemd. > Granted, it probably wouldn't harm much either given the purpose of the > system shell, and probably why those who have already changed it haven't > seen any noticeable effects. It just seems like an unnecessary change. It's a good point you made that with systemd there are less benefits of a fast /bin/sh. Ubuntu made its switch to dash in 2006 [1] and Debian in 2011 [2], [3], and they switched to systemd later in 2013 and 2012, respectively [4]. But switching to dash would also be about security, as less code means less bugs [5]. I found only one CVE for dash, an old one when dash is used as a login shell [7]. There are a number of bash bugs but they tend to be in various devices that are not necessarily using the latest bash version so most would not apply to Arch (it would take a long time to go through the list [8] in detail so I won't do it). [1] https://wiki.ubuntu.com/DashAsBinSh [2] https://wiki.debian.org/Shell [3] https://www.debian.org/News/2011/20110205a [4] https://en.wikipedia.org/wiki/Systemd#Adoption [5] https://lwn.net/Articles/614218/ [6] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bash [7] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0854 [8] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bash+
Re: [arch-general] dash as default shell?
On Wed, 17 Jun 2020 at 20:19, Kusoneko wrote: > Pretty much this, to be honest. I don't really see the point of changing > everyone's /bin/sh for one person's personal preference when there isn't > really any point in doing so to begin with. The reasons Ubuntu switched in 2006 and Debian in 2011 were speed, less bugs and more security. A simple benchmark I ran with several shells using konsole (which is one of the fastest terminals according to my simple benchmarks): time ls -R / • dash 8.45 • zsh 8.53 (1 % bigger) • bash 17.1 • fish 19.55 Times are in seconds, on my desktop that has a spinning drive. The first time it takes longer as the system caches stuff so the times above are after running a few times. I read that in some benchmarks dash is up to 4 times faster than bash.
Re: [arch-general] dash as system /bin/sh? (Was: dash as default shell?)
On Wed, 17 Jun 2020 at 19:39, Eli Schwartz via arch-general wrote: > > On 6/17/20 2:36 PM, David Rosenstrauch wrote: > > > > > > On 6/17/20 2:18 PM, Piscium via arch-general wrote: > >> Today I set dash as my default shell [1] on two PCs. We will see if I > >> get into trouble. > >> > >> This question was asked years ago but maybe good to ask again. Could > >> dash be made the default shell in Arch? > > > > > > Couldn't you just set it as the default for your user using chsh? > > This isn't about using it as a login shell. Describing this as "my > default shell" is a very bad description. > > This is actually about setting dash as the system /bin/sh implementation. Indeed, poor choice of words, sorry for the confusion, however in the link I provided in my original email [1] it was clear in what sense I meant it to be a default. [1] https://wiki.archlinux.org/index.php/Dash#Use_DASH_as_/bin/sh
[arch-general] dash as default shell?
Today I set dash as my default shell [1] on two PCs. We will see if I get into trouble. This question was asked years ago but maybe good to ask again. Could dash be made the default shell in Arch? I did some simple benchmarks and dash is much faster than bash, moreover being far smaller there is less chance of bugs. A possible issue is bashisms, however Ubuntu has been using dash as default for 14 years and Debian also for several years so hopefully most scripts have had bashisms removed by upstreams. What do you think? [1] https://wiki.archlinux.org/index.php/Dash#Use_DASH_as_/bin/sh
Re: [arch-general] Network manager package naming
On Fri, 5 Jun 2020 at 18:39, Andreas Bosch wrote: > One issue that could be fixed is adding "NetworkManager" to the description > of e.g. network-manager-applet, and plasma-nm so that they can be found with > a search for that name. Good idea. The lack of consistency in naming from upstream caused me to lose time over the years, not just in Arch but in Fedora and other distros that I used before.
Re: [arch-general] latest kernel update surprise
On Sun, 22 Mar 2020 at 14:59, Eli Schwartz via arch-general wrote: > Note that backporting an upstream fix is not considered "patching > upstream code". Yes, that is more precise. Fedora packagers would do both, backporting and patching according to what they thought it was needed. > In that case, it will just depend on how problematic the > issue is and whether it justifies the effort of a backport. A good example below, thanks! https://aur.archlinux.org/cgit/aur.git/commit/?h=zfs-dkms&id=d364766c9b790b02ca72e38146a7d7ee21ca05ae
Re: [arch-general] latest kernel update surprise
On Sun, 22 Mar 2020 at 14:03, wrote: > > Before Arch I used Fedora for 7 years. I found Fedora far more stable > > than Arch when upgrading to a new Fedora version 3 months after > > release when most bugs have been fixed. With Arch there is always > > something that does not work properly and then days or weeks later it > > starts working again. > Hi > Did you installed Arch in the right way? > The only Arch installation method is here. > https://wiki.archlinux.org/index.php/Installation_guide Yes, that is what I used. > Since 22 years, i use Linux. After redhat, suse, gentoo, fedora, debian > stable,testing and sid, i went to Arch. I get rare problems with Arch, > less than with other distributions (except with venerable debian/stable) Like I said above, " It is not Arch's fault, rather it results from its KISS principle of making minimal or no changes to upstream packages so you get all the issues from upstream." I will say the obvious that different people have a different experience of Arch (and other distros) as it depends on what they use it for and what packages they have installed, as well as on the hardware. When I moved from Fedora to Arch I continued using the same packages and had more issues in Arch, not with Arch but with third party packages. I never had an issue with Arch software like pacman, etc. :-) In other words, I totally believe you when you say you have less problems in Arch but that does not disprove that I have more in Arch, it is just that you use a different set of packages on different hardware! That said Arch is far more reliable than Ubuntu non-lts! Some examples: yesterday I had to kill Firefox because it got stuck with one core at 100%. In Arch problems with FF come and go. In Fedora I also sometimes had problems with FF but far less than in Arch. Another example, Conky. There was an upstream bug when displaying used RAM, which was fixed in upstream git but months passed and upstream would not release a new version. So after months of wait I got pissed off with this RAM display issue and installed the AUR version of conky. In Fedora in a similar situation typically the Fedora packager would create a new version of the package with the patch. I don't know if that happened in the specific case of conky, I have not checked, I am just talking about what typically happened. Arch has the policy of not patching upstream code unless needed to fit the Arch way of doing things. That is one of the reasons why I said that Fedora is more stable than Arch. That said, Fedora 13 for me was an horror story, I had lots of kernel crashes! > To become happy Arch user: > First, very important: use linux-lts all and "lts" or "still" packages > you can find. Non lts kernels *are not* stable. Then, don't update each > day. Then, when you do something, you have to know what you are doing. Yes, a while back I was having lots of problems with the standard kernel and then I started using the lts kernel, but sometimes the lts does not work and I switch to the standard one! But mostly for the past year and half I have used the lts kernel. I use the still version of Libreoffice, which is perfectly fine for me as I don't need the latest features.
Re: [arch-general] latest kernel update surprise
On Sun, 22 Mar 2020 at 11:03, Jude DaShiell wrote: > > 5.59-10 on the machine I use. I'm using a different version of linux on > another disk to write this message. > Strangely, both speaker-test and espeakup no longer work. The > speaker-test failure would of course > cover espeakup since espeakup uses sound card resources to do screen > reading. > Was anything done to the kernel to cause these failures? Before Arch I used Fedora for 7 years. I found Fedora far more stable than Arch when upgrading to a new Fedora version 3 months after release when most bugs have been fixed. With Arch there is always something that does not work properly and then days or weeks later it starts working again. It is not Arch's fault, rather it results from its KISS principle of making minimal or no changes to upstream packages so you get all the issues from upstream. Fedora does lots of patching and updates things less often so it is more stable than Arch. My suggestion is that if you are looking for reliability to use Debian Stable which has a big choice of packages and it stable, or else Fedora which is in between Debian Stable and Arch with respect to up-to-date packages and stability. Arch might not be the best distro for you. My €0.02.
Re: [arch-general] can't 'pacman -Syu' to xorgproto 2019.2-2
On Thu, 9 Jan 2020 at 00:55, Greg Minshall wrote: > no, i hadn't seen (or paid sufficient attention to) that message. and, > that seems to get me past the dependency problem. I find it useful to be subscribed to the Arch Announce mailing list. It has low traffic with news items about upgrading, such as for the issue above.
Re: [arch-general] libx11/xorgproto dependency
On Sat, 4 Jan 2020 at 21:45, Lone_Wolf wrote: > The proper solution is to file a bug to have the package makedepend on > xorgproto . Done. https://bugs.archlinux.org/task/65052
Re: [arch-general] libx11/xorgproto dependency
On Sat, 4 Jan 2020 at 21:27, Piscium wrote:
>
> On Sat, 4 Jan 2020 at 21:17, Neven Sajko wrote:
> >
> > I assume you did not hear about the following:
> >
> > https://bugs.archlinux.org/task/64892
>
> Thanks. Yes, I had seen that, but that bug is closed and if there is
> an answer in it to my question above I don't know what it is.
Thanks. You put me on the right track. I modified the PKGBUILD as
below and with this change xf86-input-evdev builds without errors
(though I have not tested it yet).
makedepends=('xorg-server-devel' 'X-ABI-XINPUT_VERSION=24.1' 'xorgproto')
So problem is solved for me - though the package is still broken in the repos.
Re: [arch-general] libx11/xorgproto dependency
On Sat, 4 Jan 2020 at 21:17, Neven Sajko wrote: > > I assume you did not hear about the following: > > https://bugs.archlinux.org/task/64892 Thanks. Yes, I had seen that, but that bug is closed and if there is an answer in it to my question above I don't know what it is. The xf86-input-evdev package in the repos is broken as it cannot be built. Does it mean that it and other broken packages will be removed from the repos?
[arch-general] libx11/xorgproto dependency
Hi, I use a customised version of xf86-input-evdev (I tweaked the source code to better support my trackball). This package is now broken as xorgproto used to provide resourceproto and scrnsaverproto but the current version does not provide it anymore. I suppose somebody will fix this broken package at some stage, but in the meantime, what is the advice on this? Should I use xorgproto from AUR instead of the "official" xorgproto if I need to rebuild the package? (It is working fine, I want to know just in case.) - $ makepkg -s ==> Making package: xf86-input-evdev 2.10.6-1 (Sat 04 Jan 2020 20:30:46 GMT) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Installing missing dependencies... error: target not found: resourceproto error: target not found: scrnsaverproto ==> ERROR: 'pacman' failed to install missing dependencies. ==> Missing dependencies: -> resourceproto -> scrnsaverproto ==> ERROR: Could not resolve all dependencies.
