What is Reddit's opinion of
Arch Linux?
From 3.5 billion Reddit comments
➔ Arch Linux website
By popularity on Reddit, this Service is:
100 reviews of this app found across Reddit:
https://www.archlinux.org/retro/2002/
Hello, it appears you tried to put a link in a title, since most users cant click these I have placed it here for you
^I ^am ^a ^bot ^if ^you ^have ^any ^suggestions ^dm ^me
*Arch Linux
Arch Linux is the sweet spot between the two.
Have you heard about Arch Linux?
I use Arch Linux.
I think you should try Arch Linux.
Arch Linux is the best.
Did I mention Arch Linux already?
Everybody should use Arch Linux.
You should use Arch Linux.
Arch Linux is the way to go!
Arch Linux^Arch Linux^Arch Linux^Arch Linux^<strong>Arch Linux</strong>
Edit: Disclaimer: I ^do ^^actually ^^^use ^^^^Arch...
Google's Noto fonts package needs 5 MB for emojis, 19 MB for all languages except Japanese/Chinese/Korean … and 284 MB for those three.
This is why I use an audio normalization filter.
Movies constantly do this shit. I don't want quiet dialog and super loud explosions. I just want to listen to things at a normal volume.
EDIT:
If you're on arch, install swh-plugins, then create the file ~/.config/pulse/default.pa and add the following lines:
.nofail .include /etc/pulse/default.pa load-module module-ladspa-sink sink_name=ladspa_sink plugin=dyson_compress_1403 label=dysonCompress control=0,1,0.5,0.99 load-module module-ladspa-sink sink_name=ladspa_normalized master=ladspa_sink plugin=fast_lookahead_limiter_1913 label=fastLookaheadLimiter control=10,0,0.8 set-default-sink ladspa_normalized
Reload pulseaudio (pulseaudio -k) and presto, now all your audio is normalized. You can quickly toggle the filter on and off through the pulseaudio GUI or even set it to only run on certain streams. I have the filter set to my Chromium and VLC streams, but not my music player stream because that's the only one where I appreciate the higher dynamic range.
Edit2:
VLC has a built-in normalization setting. You can just use that if you're not on Linux or don't feel like fucking with pulseaudio.
Former Manjaro user here. In the 2 years it was my daily driver, my system broke twice. I'm all for a 2 week delay to make a more stable system. But what is the point if you are never going to act on the issues reported upstream?.
Unlike Arch, they include an distro automatic updates by default. Yet they don't act on major bug. And they don't rush those bug fixes. So you have to wait 2 weeks for the fix to automatically be applied.
Funny this bug is getting so much attention. Far more serious issue have gotten through their nonexistent QC.
Check https://www.archlinux.org/news/ before running an update and 99% of those problems are gone. I'm an arch user since 2013 and had only a couple of problems since and most of them were fixed by a later update. Had more trouble with Ubuntu to be honest.
> https://www.archlinux.org/packages/
This one sparks joy
This one also sparks joy
> https://www.microsoft.com/en-us/store/b/windows
This one does not spark joy
BTW, I use pacman and yay
This, I think is something most people who already use Linux don't get. Like, think of the iPhone. Imagine if it had repos. How the hell would a new developer get traction on his software? The App Store team collates, editorialises and promotes software. I can literally go on the App Store, look at the programs there and download/buy one if I like it. If I were to go on the App Store and find nothing but a list of software available organised either alphabetically or date last updated, well, why the fuck would I want to even open the app store? Case in point: if the App Store looked like this, I'd be one of the first to nope out and I like to think I'm pretty tech savvy.
Sure, you could build a GUI like synaptic, but the point is that the App Store model is built on top of the repo model to ensure discoverability, something most ordinary people need, and even tech nerds on occasion appreciate. Synaptic attempts to do it, but it doesn't have traction because people in this realm don't really see the need for discoverability. There's other channels in the FOSS world for that, and there aren't enough new programs coming up for one to require curation.
You are forgetting the trusted users.
Developers maintain [core] and [extra]. They also do the decisions regarding the distribution.
Trusted Users maintain [community] and the AUR. https://www.archlinux.org/people/trusted-users/
>How can such a small team support so many packages and make sure everything works?
[core] and [extra] are tested while [community] is not. We also do close to none patching and mostly package whatever upstream gives us. Most of the bugs/problems are usually related to the software from upstream, and not us doing something wrong with N number of patches.
There was a better one in 2012: https://www.archlinux.org/news/the-lib-directory-becomes-a-symlink/
It was nice when pacman deleted everything in my /lib except for two items, preventing me from even opening a shell.
> Who uses bleeding-edge systemd anyway? Arch?
Core is at 239, https://www.archlinux.org/packages/core/x86_64/systemd/
240 is available in the testing repo, but I'm guessing it won't be moved to core because of this.
My advice:
Install newsbeuter (RSS feed reader).
Put
https://www.archlinux.org/feeds/news/
in your ~/.newsbeuter/urls file
Put
alias update='newsbeuter && sudo pacman -Syu'
in your ~/.bashrc
now typing
update
will start newsbeuter so you can read the Arch news about current updating issues, then as soon as you quit it, start pacman.
The Arch Wiki has database backups but it's also distributed in a couple forms via Arch Linux packages.
- https://www.archlinux.org/packages/community/any/arch-wiki-lite/
- https://www.archlinux.org/packages/community/any/arch-wiki-docs/
Even if the wiki and all the backups were wiped out, the rendered formats (lite, html) would still be present on many people's machines and archives of old packages.
>Following 9 months of deprecation period, support for the i686 architecture effectively ends today. By the end of November, i686 packages will be removed from our mirrors and later from the packages archive. >For users unable to upgrade their hardware to x86_64, an alternative is a community maintained fork named Arch Linux 32. See their website for details on migrating existing installations.
Here's my long-ass alias that I use:
alias pac='curl -s https://www.archlinux.org/feeds/news/ | xmllint --xpath //item/title\ \|\ //item/pubDate /dev/stdin | sed -r -e "s:<title>([^<]*?)</title><pubDate>([^<]*?)</pubDate>:\2\t\1\n:g" | colout "^.*$" 205 && sudo pacman -Syu'
Through the second pipe fetches the latest news on updates from Arch. Gives you the heads up if there is an issue with a pkg that might be coming your way. The 'colout' part is a program that adds a bit of color to the output from Arch news, so not necessary. And lastly the actual update part. It's a long one-liner, but pretty useful.
E: Took out an extra space out that was causing it sed to error out. Thanks /u/ronjouch
Or you can try Arch. Lightworks is in the AUR ( https://aur.archlinux.org/packages/lwks/ ) and Opera 26 is in the official repos ( https://www.archlinux.org/packages/community/x86_64/opera/ ).
If you want AMD proprietary drivers, just follow this guide ( https://wiki.archlinux.org/index.php/AMD_Catalyst#Installing_from_the_unofficial_repository ), to install a repo to avoid compatibility issues with latest Xorg packages.
Why not? On Arch at least, the Intel microcode is managed through pacman, as is the more generalised linux-firmware package which includes AMDs ucode and WiFi chip firmware among other things. There's zero reason to force people to do it through the software center when the distributions package manager and maintainers can do all the work and make it just another update.
That refers most probably to the linux-firmware package. It contains many proprietary binary blobs, that are required to get certain hardware to function, even if the corresponding kernel module is free software. Might also refer to some proprietary kernel modules in Arch's repos (like nvidia).
Alternatively, subscribe to the RSS feed.
(On a related note, get a feed reader. They're brilliant for following blogs, webcomics, service status feeds, news and all manner of things.)
Of course it will :)
5.0rc2 is already in Arch Linux's package repository: https://www.archlinux.org/packages/community/x86_64/dolphin-emu/
Give your distribution's maintainer time to package it :)
And you can't attach to instances created with the older version if you update:
>Gaetan Bisson wrote:
> Upstream improvements in screen-4.2.1 will make users unable to reattach instances created with version 4.2.0 or older. Please upgrade to screen-4.2.1-2 only when they are unneeded. Apologies again for the inconvenience.
> URL: https://www.archlinux.org/news/screen-421-cannot-reattach-older-instances-either/
Should be the IP address of the Arch Linux homepage btw.
Edit: I found it. Take a look at /usr/lib/NetworkManager/conf.d/20-connectivity.conf. NetworkManager requests https://www.archlinux.org/check_network_status.txt to check for connectivity. This should be changeable by copying /usr/lib/NetworkManager/conf.d/20-connectivity.conf to /etc/NetworkManager/conf.d/20-connectivity.conf.
Long-time lurker, but I have to post a first comment sometime. Check that your Certificate Authority certificates are properly installed (the ca-certificates package).
https://bugzilla.mozilla.org is signed by DigiCert, which looks like it should be included according to the package manifest.
In theory that should be Aaron Griffin, but he isn't super active these days. I recommend sending an email to a few Arch developers, and possibly send an email towards our mailing list.
I also proposed adding an [email protected] email address, so i'll notify you if anything changes.
I would say that distro that shall not be named. Simple, unadulterated packages, hot off the press. Amazing wiki, thousands of high-quality unofficial packages easily available.
Why don't you simply use <code>reflector</code> and a pacman mirrorlist hook?
https://wiki.archlinux.org/index.php/Reflector#Pacman_Hook
See reflector --help for all available parameters.
I'm not certain, but I think even on Gnome (and other DE's) you can just install KDE Connect without the entire KDE/Plasma desktop.
On Arch at least, it only lists 9 dependencies, and in my non-expert poking around they don't seem to be too heavy or anything!
Archlinux made the switch almost 5 years ago with barely any issues. If you need to use Python 2, just specify it at the beginning of your script, or simple use a virtualenv with Python 2.
Don't use pacman to install stack (or any haskell libraries). It pulls in ghc and all the dependent libraries - and will update them frequently. https://www.archlinux.org/packages/community/x86_64/stack/ is terrifying. It's on release 101!
Just install using the instructions on haskellstack.org. I also use stack to install haskell executables.
As for the resource, u/lexi-lambda wrote https://lexi-lambda.github.io/blog/2018/02/10/an-opinionated-guide-to-haskell-in-2018/ which gives a lot of detail (but you did ask for comprehensive).
You'll need to boot your system with an Arch installation disc and mount your system. DO NOT CHROOT. Note pacman's man under options: https://www.archlinux.org/pacman/pacman.8.html#_options
Use pacman with the -r option to reinstall the affected packages.
Why, systemd-kcm does the job pretty well. Prior to that I used systemd-ui with similar capabilities.
Awesome work!!
Also I'm completely unexperienced to packaging so maybe I'm wrong here, but I noticed VS code uses D-Bus to pass the menu trough too KDE/plasma for its global menu support. Is it worth including libdbusmenu-glib as an optional dependency? :)
it's also defense against MITM attacks:
the websites hosting the md5 are using https, while the ones hosting the .iso aren't on https
for example:
website with https and md5 : https://www.archlinux.org/download/ (your browser would tell you if you were victim of a MITM attack as the certified public key would not match the one given by the attacker)
one of the mirror to download the iso : http://mirror.rackspace.com/archlinux/iso/2016.02.01/ (this is not over ssl so anyone could intercept your http connection and server you something else)
Just check out the brief bios of the developers and trusted users. Most of them have occupations like "software developer" or "network admin" or "engineer". Scanning through the people, I found that one of them is a train driver, which is pretty cool, but that's more of an outlier from the rest.
GIMP 2.10 requires GEGL 0.4. GEGL 0.4 is currently stuck in [staging] until the ffmpeg 4.0 rebuild is done.
When those remaining few packages are rebuilt and gegl and ffmpeg have been moved to [testing], we well probably see GIMP 2.10 appear in [testing] soon afterwards.
It just updates things directly to their current version.
However, there can be compatibility problems. Earlier this year there was a two-month period to upgrade Pacman. This sort of thing is done to make everyone's lives drastically simpler.
I've done an upgrade on a machine that sat dormant for a few years, and it was rather ugly (mostly the systemd migration), but successful.
It's worth noting that most Linux distro mirrors don't hold onto old versions of packages, which precludes the possibility of doing incremental upgrades like you mention.
To me, at least, compiling stuff in Arch and Slackware is easier than Debian or Red Hat distros. The reason being Arch and Slackware both package their libraries with development headers included, meaning you install the package, and you have everything you need to compile against it.
For example, to compile something that requires gtk3 as a dependency, in Arch I would install the gtk3 package, except I don't, assuming it's in the AUR, because all I need is the PKGBUILD. In Debian, I need libgtk-3-0, and then the package libgtk-3-dev to provide the devlopment headers to compile against. And then should I choose to make a package, I have to deal with making the package by hand (AFAIK, there is no way as simple as PKGBUILDS, but they do have helpers, so you're not all alone in the process). For both cases, the dependencies for Arch are still easier because I only need half the packages.
I'd say Slackware is still easier than Debian for the same reason that Arch is even without dependency handling because most libraries you'll need are installed (install the L group from the ISO and you're mostly covered).
Do you mean search for programs in the repositories?
Use pacman -Ss package to search.
If you mean the complete list of programs, check the arch repository.
Arch can be left without updating for a few years and still be updated to the most recent packages. You just need to read the Latest News and do everything that's written in there for the time you haven't updated your machine. Then update the system. If there are errors, I don't think they'll be hard to resolve unless you use very custom settings, configs, etc. Also, when doing an update after a few years, update only the main packages, don't update anything from the AUR yet.
But if you're talking about 6-10 months, you should be able to update without a hassle, just read the Latest News in case there's some action needed (same as above). I've seen people comment about their 5-year-old installations being updated successfully.
So it's all up to the user.
And remember - never issue pacman -Syyu --noconfirm or pacman -Sy in these situations and it's recommended you never do those. If there are errors but your packages are ok, you can pacman -Syuw just to download the packages, then do your manual configuration, file removes/renames, etc. and then issue pacman -Su to update the system.
Also, keep your archlinux-keyring package updated first so you don't have any GPG key errors
#!/bin/bash arch="$(curl -s https://www.archlinux.org/packages/core/x86_64/linux/ | grep version | cut -d "\"" -f 4 | cut -d "-" -f 1)" fedora="$(curl -s https://apps.fedoraproject.org/packages/kernel-core | grep package-name | cut -d ">" -f 2 | cut -d "-" -f 1 | head -1)" version_gt() { test "$(echo "$@" | tr " " "\n" | sort -V | head -n 1)" != "$1"; }
version_gt $fedora $arch ret=$?
if [[ $ret -eq 0 ]];
then
echo "why the fuck would you want the newest kernel?... Thanks, but I prefer a system that actually works."
else
echo "Omfg can you believe these scrubs using that old kernel? I've been on uname -a for 6 weeks."
fi
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git
Among a few other things, iirc, but primarily this is what people complain about.
Under debian, this is firmware-linux-nonfree. Arch has linux-firmware
Arch at least just has /usr/bin and /usr/local/bin
/bin, /sbin and /usr/sbin are all just symlinks to /usr/bin for backwards compatibility.
The historical reasons are:
- /bin - Essential general binaries such as ls, mv, etc.
- /sbin - Essential System binaries like init, su, etc.
- /usr/bin - Non-essential general binaries (aka "other" or most binaries you actually use). These were often mounted via NFS or seperate drives on early Unix systems due to storage limits, which is the reason they're seperate. The real reason for its creation was that the computer the original version of Unix was developed on (remember the version 3 manual boasted that it had 10s of deployments, basically all in AT&T) ran out of space for /bin .
- /usr/sbin - Non-essential system binaries, at least to the definition of 70s/80s users. Networking binaries for example, even though most modern users would consider them pretty essential. Logic the same as /usr/bin
Xonotic! - fast paced and tactically deep fully open source arena shooter. Wonderfully optimised, I get an acceptable framerate on my laptop with an integrated intel card without turning the settings all the way down, and my beefy desktop gets a couple hundred frames with the settings allll the way up.
The community is quite friendly as well; development is mostly in QuakeC. It's available in [community].
Various games with zsnes and espxe. (Super Mario World, Castlevania: Symphony of the Night)
And The Operational Art of War III via wine (where it runs flawlessly). If anyone wants to get some games going, let me know: 20th century operational level turn based (PBEM) combat, give it a google and shoot me a PM if you have trouble finding it. ;)
My Arch Laptop (yes I use it, btw) just got this ucode update recently:
https://www.archlinux.org/packages/core/any/amd-ucode/
Looks like it's just for Vega, Picasso and Raven though: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
>Then you have distros that are bleeding-edge. Arch is the best known example of this. It's rolling release, meaning updates to programs are pushed to users not long after being released uptream. This can result in breakages as things are not as heavily tested as in the previously mentioned distros.
Although this is not untrue, and I think you typed up a great summary post, I'd just like to add that aside from things like the move to systemd or the shift to /usr/bin there usually isn't much to worry about. And they do publish notes on their main website when user intervention is expected, such as the link posted above.
I've started to object a bit to the idea of calling Arch bleeding edge because we're assigning that label to packages that were released as stable by the developers of those applications. So before they go through the testing that Arch does do, they have first also gone through whatever internal QA the upstream devs have done.
I don't use Arch, btw. :-) (Though I do run a derivative on two of my boxes.)
The official news on the Arch home page. That is largely what is going on with Arch at a high level. Otherwise the Arch mailing lists for more detailed info about different areas. As well as Planet Arch Linux.
But honestly the most exciting news is related to the software packages you pick and choose to use, which Arch has no dedicated channels for and you should follow the upstream channels if they exist for general news about them.
What's the purpose of this blog entry? Arch has a VirtualBox package which will work just fine (furthermore it includes the correct kernel module for you current arch kernel). You refused to use it, and instead installed the thing directly into the system, possibly unremovable from now on.
The arch package is up-to-date by the way. And if it was not, just flag it as outdated and it will be updated by the community quickly.
Linux never was Burger King™ and it never will be.
If you go to one of the package pages, under Package Actions on the right side you can click on View Changes.
In this case the reason is:
> ncurses 6.0 rebuild.
https://www.archlinux.org/packages/community-testing/any/npm/
The package no longer ships npm because it's been split out.
It's not in the news because either it's not considered important enough, the message is considered to be enough or... because it's still in community-testing.
>Then they removed it just to spite people.
Gotta love uninformed people who are the loudest one to shout...
It wasn't done "to spite people". It was done because there was no one to maintain the installer. Same way any other project works - if there's no one willing to maintain code, then the code will be eventually dropped.
> No they are not, install process is really well documeneted even for a someone new to Linux and AUR is really, really, very, really unsafe place to be for a newbie (not only from security point of view, but mostly because of stability).
As if the the main repos can be considered a pinnacle of stability. IIRC there were like 3-4 updates of python-setuptools in the last 2 days. And hey, pacman still can't figure out library version dependencies like apt or yum/dnf (and we like to laugh at these two so much, because they are bloated and slow). You need to do pacman -Syu <package> to be safe.
Perhaps we should stop being such elitist and just give people the right tools right away in the main repos. If people want to break their shit, they will break it anyway. I don't buy the 'let's keep the newbies safe' argument. If AUR is really that unsupported, why do we even link to it on https://www.archlinux.org/ ?
Edit: -Sy -> -Syu
> except for large videos on websites it does everything else remarkably well
That's actually one of the reasons non-gamers do need new hardware. New codecs, e.g. H.265 in full HD are remarkably resource-hungry. And I wouldn't say it's an unnecessary development; I'm in awe how much information can be crammed into a low-bandwidth bitstream these days. Also, I have a hard time believing a Pentium 4 with Firefox none the less can run modern web content without a hitch. The client side of web applications has become increasingly complex and taxing on resources.
>The annual OS X upgrade cycle is too much of a drag, especially with all the third party software needing upgrading also
Why not use Linux on the Mac? I'd recommend a rolling-release distro (like Arch) so you can update your system to the bleeding edge at any time you wish with a simple sync + update via the package manager.
You're overthinking it way too much. Antergos comes with access to the Arch User Repository, where people did all the overthinking for you. Here's Waterfox, and Cherrytree is actually in the Arch Linux repository itself. All you need to do is yaourt -S waterfox-bin cherrytree.
> Not really, starting from here essentially the commands ran could've been put in a script which runs them in sequence though some of them are interactive but even that could've been given a menu.
Those are just example commands. Not everyone installs the entire base group, or uses genfstab, or adds hosts entries as described there, or sets a root password, or installs a boot loader (and if so, not the same one and/or the same way). Not to mention any additional steps not mentioned there that one may want to take.
There was a TUI installer that came with the official install ISO once, and it mostly just had options like "Edit /etc/vconsole.conf", "Edit /etc/fstab", "Edit /etc/hosts", etc., and it would simply drop you into a text editor that you'd chosen at the beginning of the installation.
After they removed the TUI installer, the installation process actually became less scary: the existence of a TUI installer in an otherwise pretty transparent and simple distro like Arch made it seem like the installation involved some really gory low-level magic that needed to be hidden from any user. But there was none (and I only realised that after seeing the manual steps required instead). Removing the TUI installer thus brought:
- More power/choice for the user (suddenly, people realised they could run their own low-effort spin of Arch; you may notice that both Antergos and Manjaro started very shortly after the TUI was removed in 2012)
- Less obscure magic and abstraction (primary reason why many use Arch in the first place)
- Less work for the maintainers (why automate a procedure that most users don't perform much more than once anyway?)
You can get a local copy of the wiki by installing the arch-wiki-docs package, if you need to browse it offline or you just want to keep a backup.
1) yay is a popular choice, you can use it. If you use combinedupgrade, then avoid skipping packages (probably ok if it's from AUR, not a dependency and requires a long build time, just be aware it might break)
Use <code>checkupdates</code> if you just want to see what updates, so it won't make permanent changes (it's a problem to update list of packages and then only install a single package without upgrading all packages)
2) Arch doesn't automatically try to merge. Certain packages list files to back up. In that case they get .pacnew after an upgrade or .pacsave after removal. The wiki has a list of tools you can use to easily manage them (including merging)
3) Update as often as you want. As you probably had in Sid as well, the security updates aren't separated, so not updating at all also have an effect on security
If you don't upgrade for months, then it's best to check the Arch News, and you might need to update mirror list and archlinux-keyring, before being able to do a full upgrade
>is this a setup for disaster?
Why should it? Arch is just one of many distributions. Unfortunately, there are just too many myths surrounding it. The installation instructions are basically very detailed, so you can work through them if you have a halfway technical understanding. A degree in rocket science is not necessary. In case of need you can always ask in the official forum if you ask smart questions.
There is only one important rule for day-to-day operations. You should check before every update (especially if it's an important one) whether the developers have published a note. You should definitely pay attention to it. Considering that, Arch is very stable in my experience. Almost boring, actually.
Uhhh the last time systemd was updated was
> Last Updated: 2017-01-31 15:48 UTC
Info from: link
Maybe stop blaming everything on systemd when it hasn't been updated for > 1.5 months?
Arch doesn't use /bin. In fact, /bin is just a symlink to /usr/bin on my machine.
$ cat /etc/os-release NAME="Arch Linux" ID=arch PRETTY_NAME="Arch Linux" ANSI_COLOR="0;36" HOME_URL="https://www.archlinux.org/" SUPPORT_URL="https://bbs.archlinux.org/" BUG_REPORT_URL="https://bugs.archlinux.org/" $ which python /usr/bin/python $ python --version Python 3.5.1
Install sl. In your .bashrc, alias sl to apt-get. Now, everytime you run apt-get, you have to wait for an ASCII art locomotive to cross your terminal. This should train you to think twice before typing apt-get.
A minor point to note OP, is that contrary to popular belief, Arch isn't a bleeding-edge distro, but rather a cutting-edge. Bleeding edge implies zeto-day package updates, but in reality new packages sit in the testing repo for a while - especially with major components like the kernel or the DE. Take for instance, Gnome 3.16, which was released on 25th March, but is still currently in testing.
skype is only available in the multilib repo for your architecture.
Add this to your /etc/pacman.conf (should already be in there, just uncomment it. > [multilib]
> Include = /etc/pacman.d/mirrorlist
then do a sudo pacman -Sy skype
Now how did I know that skype was in the multilib repo?
"Main repository"? I see it's in staging, but core is still on 4.19.
https://www.archlinux.org/packages/?sort=&q=linux&maintainer=&flagged=
pacman isn't trying to remove the Arch default kernel.
You're looking for orphan packages with no connection to anything else. linux-lts is an independent package with nothing depending on it, no groups, no anything. Obviously, linux-lts-headers depends on linux-lts. linux-firmware is not a dependency, so it was also listed.
If you'll look here, you'll see the linux package is in the base group, so it's not trying to uninstall the kernel, but rather the linux-lts package you manually installed after.
The responsible thing to do would be to read the output and, from there, figure out what you want to/can remove. This is also why you should never run a script until you know what it does (which you've shown you know, asking here before just doing it).
usr/share/doc/conky-1.10.0/conky.conf Retrieved from: https://www.archlinux.org/packages/extra/x86_64/conky/
If I had conky installed:
pacman -Ql conky would have shown all of the files installed by conky.
I don't have conky installed but I do understand the frustration of not being able to find documentation for software that's installed. pacman is your friend.
There is this package that you can install on arch, but it's just an archive with the html files. Might be a bit out of date, but you can always use this to grab them if you want to.
https://www.archlinux.org/packages/community/any/arch-wiki-docs/
As far as epub goes, people online recommend calibre for converting html to epub
<semi-fun mode>
I don't get why you need to Call for action. Arch Linux just uses your latest commits in their stable repository - It's available in stable repository already, no need for testing.
And people call me crazy when I say it's irresponsible
</semi-fun mode>
As for me, I will update in a bit and report if anything is not working. I like living on the edge.
To quote another thread I commented in:
>I used the locally downloadable copy of the Arch Wiki to avoid ddosing the actual servers. To extract the data I used bs4 to find all links within each article and networkx to build the graph. I then exported the graph to GEXF and opened it in Gephi to filter out small connections (they added too much noise and made it look like one huge clump) and lay the nodes out. Full writeup and source code incoming!
Have you not been following the Rust community? There's Debian, Fedora, and Arch packagers that are integrating Rust software into their respective platforms. Arch's the quickest to adapt and thus already offers ripgrep in the official software repository.
Nothing wrong with having cargo feature the ability to install applications outside of your package manager. If your distribution wants a Rust application then it can pick up your Rust application and package it. Otherwise, it's easier to try out Rust software and get Rust software installed on unsupported platforms via cargo.
There is no final decision on the matter yet, and I would expect Arch to drop i686 support rather sooner than later. If I had to guess, i686 support will likely end around December 2017.
Even today, i686 packages are built, but barely tested, if they are tested at all.
Well, you need to remember that Arch did the switch a long time ago (5 years). At that time there was no recommendation of which version of Python /usr/bin/python should match, and the fact that /usr/bin/python3 was actually Python 3 was more something that every distro was doing instead of a recommendation from Python developers.
PEP0394, that recommends everything I said above, was only released 6 months later (https://www.python.org/dev/peps/pep-0394/). So this more a fault of Arch Linux than anything, but I can understand why Arch developers did this.
Update regularly, subscribe to https://www.archlinux.org/news/, and keep an eye out for anything that requires user intervention. This helps you avoid instances where multiple updates break your install and you don't know which to fix first.
Stay out of [testing].
If you pull from [core], quickly check the news feed before following through.
Learn how to pacman -U for previously working packages and how to --ignore the package until another version is out (which most likely contains the fix).
Update whenever you can spare 5 minutes once a week.
This is my process, never failed me in over 2 years.
This is an example of the web site that is helpful both for newcomers and current users.
It has package search right there. I use it all the time. For haskell though i always have to go to a dozen of different web sites. hoogle, hayoo, fpcomplete.
It has installation instructions. I use it from time to time when i need to install new machine. Because i forget things.
It has prominent news section right in the middle.
It has easy access to forums. For questions and general discussions on haskell i have to again go to a dozen of different places: reddit, google groups, stackoverflow etc.
It has the best and most useful wiki i have ever seen. Even users of other linux distros routinely refer to it. For haskell know-how i have to again scour the internet: LYAH, realworld haskell, wikibooks, stackoverflow, google groups, various blogs.
Pacman now verifies package signatures by default. But your new /dev/random isn't going to have enough entropy to create Pacman's keyring in any reasonable amount of time. haveged is the quickest way to get more entropy faster. Download the package to a flash drive or enable the community repository on the ISO and install it then.
Run sudo pacman -Syu or yay (which is an alias for yay -Syu) regularly.
Don't do partial upgrades.
Install https://aur.archlinux.org/packages/informant/ to be notified about Arch Linux news before updating packages.
Use pacdiff from time to time to identify newer config files of packages installed (installed via https://www.archlinux.org/packages/community/x86_64/pacman-contrib/).
Regularly check your explicitly installed packages with pacman -Qe and uninstall what you don't need anymore.
Only install from the AUR what you really need. These packages can be listed with pacman -Qe --foreign.
All these measures should make your Arch even more stable than it already is.
The one reason to not use -Syu with every upgrade is that you could miss something from https://www.archlinux.org/news/. It's a good idea to check for news before -Syu, which can be automated.
> I cant find the default fonts.conf that comes with arch linux.
For next time:
$ pacman -Qo /etc/fonts/fonts.conf /etc/fonts/fonts.conf is owned by fontconfig 2:2.13.1+12+g5f5ec56-1
And if you want to manually get original fonts.conf, then simply download fontconfig package from mirrors and unpack it.
From a quick look (Go to https://www.archlinux.org/packages/?q=deepin --> Pick random package --> Source files --> PKGBUILD --> Download the files in 'sources=...' --> Examine contents --> Repeat), it looks like they are built from the source code on GitHub, not simply repackaged binaries.
I use mopidy (a clone of MPD) with the mopidy-spotify extension.
libspotify, the main Spotify dependency, is supposedly no longer supported, but it still works well for me.
Not sure what you mean. The CUDA package now depends on gcc7 instead. See:
- https://www.archlinux.org/packages/community/x86_64/cuda/
- https://lists.archlinux.org/pipermail/arch-dev-public/2018-May/029254.html
If you really need gcc6, it's in the AUR.
always read Arch Linux news prior to upgrading. this removes about 90% of any issues. the other 10% is just is individual packages break because the developers of them did something.
Arch linux: https://www.archlinux.org/packages/community/x86_64/sway/
I used it for a while and it was quite nice. I came back to i3 because I missed polybar, and because I had a few clipboard issues between xwayland and wayland apps, but that's hardly Sway's fault.
Linux Mint. Ubuntu is a bit wobbly, I agree.
Pick the cinnamon edition, it's really stable and nice. You'll like it.
EDIT: Gentoo is pretty cool but you spend a lot of time compiling. Maybe you'd want to take a look at Arch
This has been happening in the archlinux community for a number of years now (starting on IRC). I think alucard isn't over-reacting here.
Florian Pritz is not a troll, he is a TU.
Yep, even Arch is actively trying to get rid of GCC-5. https://www.archlinux.org/todo/gcc5-removal/
No need when 6 and 7 have already rolled around.
EDIT: Comment above me originally said "6" ;P
gcc-libs-multilib 7.1.1 is now on the [multilib] repository (not on testing anymore).
https://www.archlinux.org/packages/multilib/x86_64/gcc-libs-multilib/
There is a hardened kernel package on arch for those who want to give it a go!
I was hoping something would replace thestinger's linux-grsec package and it looks like he's done it himself!
You do know these releases happen usually in the according distribution repository, right? (e.g arch)
And its very easy to compile it yourself on Linux, so there's really no point in complaining about that.
> Sweet, let's hope this kicks off the trend for other distros.
Arch has been defaulting to python 3 since 2010, let's see if the Red Hat momentum can finally get others moving :-)
Well, it kind of is, for example the linux package requires mkinitcpio which in turn requires systemd for some reason. You cannot run arch without systemd.