
My Arch Linux Setup with Plasma 5 - sadanand4singh
https://sadanand-singh.github.io/posts/CompleteSetupArchPlasma/#.WTdRfvp5QQQ.hackernews
======
roadbeats
Arch Linux is so powerful thanks to its amazing community. You got access to
over 70k packages with one command (stable: pacman, community: yaourt).
Whatever you're looking for, it's there.

I run the same setup for almost 7 years without any issues, and it's always
fast, always reliable and productive. I prefer Xmonad over pretty stuff like
KDE though, just like many Arch users. It's not beautiful and there is a
learning curve, but once you got used to it, you can use it for years, just
like me and lots of other people. And it'll give you a stability that lasts
years.

Recently I created a distro based on Arch, to attract more pragmatic
developers to use Arch. My distro is called Happy Hacking Linux and unlike
Arch, it comes with a ready-to-use desktop. It's a niche distro made just for
pragmatic developers, so its installation wizard starts with asking where your
dotfiles are located, and sets up a system that you can immediately start
building stuff. Last January, I converted my dad's old desktop pc to my
personal development workspace within 30 minutes. And that useless machine was
running my workspace as fast as a brand new Mac with bloated OSX.

If you're curious, check it out; [http://kodfabrik.com/happy-hacking-
linux](http://kodfabrik.com/happy-hacking-linux)

~~~
makepanic
If you like yaourt, check out pacaur.

There are other alternative aur wrappers that have more features:
[https://wiki.archlinux.org/index.php/AUR_helpers#Comparison_...](https://wiki.archlinux.org/index.php/AUR_helpers#Comparison_table)

~~~
roadbeats
I'll try it, looks neat. Cower is not building due to PGP errors at this point
though.

~~~
makepanic
you have to import the teams gpg key

------
tuxxy
When you overwrite the disk, you say you should use dd if=/dev/random, but the
reason why this is much slower is because /dev/random blocks. Use /dev/urandom
because it doesn't block -- Before you ask, yes this is still secure.

Or you can use dm-crypt and create a temporary container with a random key to
wipe it. This will be a bit faster than the above. See the Arch wiki for
details[1]

[1] - [https://wiki.archlinux.org/index.php/Dm-
crypt/Drive_preparat...](https://wiki.archlinux.org/index.php/Dm-
crypt/Drive_preparation#dm-crypt_specific_methods)

~~~
noinsight
Or, you can use the (S)ATA Secure Erase[1] command which was designed from the
start to securely wipe a hard disk and should handle wiping reserve space etc.
properly.

[1]
[https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase](https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase)

~~~
Nauxuron
Apparently, this is not always implemented correctly on SSDs. It should take
quite some time, but if it finishes after a few seconds, it probably didn't
really wipe your SSD securely.

~~~
oxplot
Most SSDs should be encrypted by default and all secure erase would do is to
wipe the encryption key and generate a new one which takes no time and does
effectively and securely wipe the entire disk.

------
Hydraulix989
Arch is just too much time for me doing sysadmin and keeping up with breaking
changes (it's a rolling distro, so all kinds of system configurations are
possible, many are untested or just bleeding edge).

If you like using an unstable bleeding edge system where you have to configure
everything yourself by hand with absolutely zero tolerance for user error, use
Arch.

If I'm on a tight schedule with doing mission critical projects on my work
computer where there are hard deadlines and Murphy's Law involved, forget it.

If you're curious, I'm currently using Mint with Cinnamon.

~~~
RealityVoid
I thought the same thing but I set up arch on my main machine a couple of
months ago and apart from the setup pain, it has been a much smaller hassle
than I anticipated. It's pretty stable, didn't have any breakage until now. I
love it!

But I do admit the initial setup was pretty intense, I loved the learning
experience.

I'm also using Cinnamon, on Arch. It's quite clean and nice. :)

~~~
Zancarius
> I thought the same thing but I set up arch on my main machine a couple of
> months ago and apart from the setup pain, it has been a much smaller hassle
> than I anticipated. It's pretty stable, didn't have any breakage until now.
> I love it!

As an Arch user of ~5-6 years, I do have some advice outside the obvious realm
of "keep regular (working) backups" that can help minimize future headaches
(not necessarily for you since you've likely already encountered these points;
mostly for others who may be interested in dabbling with Arch):

1) Update often (at least once every 1-2 months; try not to let it get more
than 6 months out of date), and keep a close eye on the news items--or, better
yet, subscribe to the arch-announce mailing list. You'll get a heads up on
anything that could be a potentially breaking change. When breaking changes
come down the turnpike, don't panic--the Arch maintainers post upgrade
instructions walking you through the process along with the appropriate news
entry and it's usually fairly straightforward. There's also the forums if you
get into a bind, and there's tons of great people willing to help (but search
first!).

2) Keep your configurations up to date (either with `yaourt -C` or examining
the _.pacnew files by hand with vimdiff or similar). This isn 't really Arch-
specific, but because Arch _is* a rolling release distribution, sometimes new
versions of things come out fast enough that existing configurations can fall
out of date and present unique challenges. But it all very much depends on the
upgrade policy of upstream packages. _Usually_ this isn't a problem unless.

Fortunately, the lion's share of "breaking" changes you'll encounter will be
minor. The most recent one you've probably encountered by now may have been
the certificate path issue with ca-certificates existing already. I suspect
most of the major architectural changes are in the past at this point (mostly
due to the disruption caused by systemd), but keeping your system relatively
up to date is a great way to inoculate it against unnecessary future effort.
It's always possible to upgrade ancient installs if you let them lapse (I
should know!), but it's better to avoid that if possible.

I hope you continue to enjoy Arch for many years to come!

~~~
eikenberry
One concern I've had with Arch was how they would handle the big C/C++ library
ABI changes. It only seems to happen about once a decade, but when it does it
is a giant pain. Last time this happened while I was using Debian testing you
had to pin a ton of packages for many months while everything moved over to
the new ABI. How does Arch manage these core library ABI changes?

~~~
pritambaral
Arch is currently transitioning to GCC 7 and OpenSSL 1.1.0 (yes, both).

The GCC transition is a straight up replacement of packages, gcc and those
built with the new gcc. Some AUR packages may need to be rebuilt, but the
community of users agrees in some measure that that's something a user of AUR
must know already.

The OpenSSL transition is keeping both versions around for a while, shunting
the older version from package `openssl` to `openssl-1.0`, which will
eventually go away too.

I guess the GCC 6 to 7 transition was not a big deal, but that could be partly
because Arch tries to stick with upstream code and doesn't add patches of its
own much.

~~~
Zancarius
> The OpenSSL transition is keeping both versions around for a while, shunting
> the older version from package `openssl` to `openssl-1.0`, which will
> eventually go away too.

In my experience, this hasn't been a terribly unsettling transition and has
gone quite smoothly except for a few individuals unlucky enough to update
during a mirror turnover (or so I gathered from the forums as their problems
often went away after updating again a short time later).

Mostly, insofar as OpenSSL 1.1.x is concerned vs. openssl-1.0, I've only had
problems with projects that make heavy use of cmake as there's no easy
workaround outside either a) creating/linking a few directories that cmake
expects to find OpenSSL 1.0 in, or b) (my preferred approach because it avoids
polluting the file system) patching the FindOpenSSL macro. But, I don't think
this is a problem Arch needs to resolve as this is most certainly an upstream
issue and only affects AUR packages (which, as you said, users of the AUR
should already have some experience in this area anyway!).

You're absolutely spot on with that last statement--one of the reasons I love
Arch is because package maintainers keep things as close to upstream as
possible and GCC updates have largely been painless. Certainly more so than I
recall under Gentoo.

Now that I think about it, the few pain points I've encountered with less
frequently updated Arch installations have almost always involved multiple
incompatible changes to core/filesystem layered with pacman updates. There are
others, sure, but those ones seem to stick out in my mind the most. It's
better to avoid them entirely by updating regularly, of course, but it
happens.

------
SteveBash
For me the rolling release model of Arch makes it not the most suitable distro
for development, lately I had to fight with the openssl upgrade to 1.1.0
because some rust libs I used no longer worked. Downgrading is not an option
for pacman, so I had to resort to compiling on docker containers and that's
not the most comfortable dev environment. I'm gonna migrate to NixOS or GuixSD
this weekend, the package managers they have are really a breakthrough to
package management.

------
grumph
I used to install Arch by hand, then I discovered ArchFI and ArchDI scripts.
They do every basic step of the install wiki, and if you need you can do some
things manually from another console. With those, I go from an empty machine
to a fully functional system with total control/feedback on what is installed
(Arch way) in about one hour (most of the time is waiting for packages to
download and install).

[https://github.com/MatMoul/archfi](https://github.com/MatMoul/archfi)

------
rvdavis
Why on God's green Earth would you pollute Arch with KDE?! :)

~~~
kellyjprice
What happened to the time when KDE was respected as a beautiful DE?

~~~
nice_byte
KDE 4 happened

~~~
bhrgunatha
To be fair KDE4 _was_ a disaster when it was released but in time it came to
be as stable and usable as the much loved KDE3. The path to plasma was also
somewhat rocky (but nowhere near as bad as the KDE3 - KDE4 transition).

I used to enjoy using KDE but I feel they lost their way and are overly
attracted by "shiny new things" like workspaces, activities, or semantic
desktop - virtually everything being dependent on strigi then akonadi then
nepomuk then baloo or ... The real bugbear is that every time they ditch
everything for a new metaphor - so much of the previously working and reliable
software is also ditched or obsolete.

It doesn't suit my needs to have to keep re-configuring my computer and
software and workflow so I stopped using it.

I do think it's great and valuable that it's there as an option though.

~~~
majewsky
Akonadi was the main reason why I ditched KMail for Thunderbird six years ago.
I recently went back, and it's marginally better. But it's still pretty
outrageous that a service that only gives one user-visible extra feature (mail
checking and calendar reminders as a background service) costs 330 megabytes
of RAM. Most of that for the MySQL instance that it's using; no idea why they
have to use anything else than SQLite for a mailbox with maybe 100 mails.
Stopping Akonadi is a thing that I just have to do before launching Minecraft
on my notebook.

    
    
      $ free; akonadictl stop; sleep 15; free
                    total        used        free      shared  buff/cache   available
      Mem:        3934720     1227872     1296492      253868     1410356     2203068
      Swap:             0           0           0
                    total        used        free      shared  buff/cache   available
      Mem:        3934720      897308     1626924      249452     1410488     2538072
      Swap:             0           0           0
    

I'm still sticking with KMail for now, though. The UI is a bit nicer (esp.
w.r.t. GPG), and mail checking as a background service _is_ nice.

------
vondur
I've taken a liking to KDE lately. Looks nice and the file manager is top
notch. I cheated and used Antergros to install Arch.

~~~
Zancarius
I have to admit, this is one of the things I miss most whenever I boot to
Windows. Explorer lacks an awful lot of the conveniences present in Dolphin.

Dolphin _can_ be a bit unstable and has some UI warts, but tabs/tab views, the
drag-and-drop copy/move/link dialog, and tree view in the file list pane are
some of my favorites. Right-click copy to/move to are also hugely useful.

~~~
aruggirello
Dolphin rocks! Double panel, tabs, filter, and F4 for the built-in shell which
is kept in sync with the current folder... and then there are the additional
columns in table view, where you can see image resolution (OK Explorer has it
too) or number of lines for text files...

BTW there's also the additional information during long file operations (like
bandwidth used, etc), and (I believe) it's the only system I know of, where I
can _pause_ a file transfer operation, and resume it later...

~~~
Zancarius
> BTW there's also the additional information during long file operations
> (like bandwidth used, etc), and (I believe) it's the only system I know of,
> where I can pause a file transfer operation, and resume it later...

I think Explorer does that too (bandwidth; don't remember about pause--I think
it has that feature), but Dolphin certainly had it first. The task tray
integration for background copying is also quite nice and useful if you're on
a different virtual desktop (to me, anyway!).

You're absolutely right: Almost everything else is anemic compared to Dolphin!

------
microwavecamera
Question for all the Arch peeps, what's the goal/purpose of Arch? As an
outside observer it seems needlessly complicated and most of the complexity
being specific to Arch. Why not just run Slack or Debian if you want a
barebones full distro? Slack and BSD's are closer to old school UNIX. Arch is
after my time, am I missing something?

~~~
viraptor
Debian is not kept as up to date as arch. There's also no AUR equivalent. AUR
had Steam for Linux packaged for example about 2h after the official release,
with people adding the missed dependencies very shortly.

Also not having many prescribed defaults is sometimes nice. I want KDE with
that display manager / lockscreen. And I can have it without uninstalling some
metapackage which will make updates harder in the future. (like gnome-desktop
on Ubuntu)

I haven't used slack for over a decade, so can't really comment.

Also until recently it was one of the few distros with nicely integrated grsec
kernel. :-(

~~~
Tomte
So Arch community packages are "released" without even cursory testing whether
it works (missing dependencies)?

And you feel that's a good thing?

~~~
viraptor
Mixing names. Community repo is different from AUR. The first has rules, the
second one is a free for all.

AUR steam was missing dependencies in a way that specific installed apps
weren't functioning right, but that's not something you could figure out from
the binary itself. For example Portal depended on texture compression which
wasn't included by default. Without buying everything in the Steam store you
wouldn't know that.

The good thing was that it was corrected within a day. How long does a typical
distro bug report take, before it's even looked at?

~~~
majewsky
This is also Arch, but I just yesterday reported a bug to the distro
maintainers because the upgrade to Perl 5.26 broke my monitoring. A fixed
package was published into the repo within 3 hours:
[https://bugs.archlinux.org/task/54322](https://bugs.archlinux.org/task/54322)

I guess I got lucky though. A turnaround time that short for community
projects also depends on whether the contributor in question happens to be at
his desk at that point.

------
paines
Almost agree 100%, but why would you encrypt the whole disk? There is no need
for that. It's 100% free software availabe for anyone. Encrypt your home
directory. And this has Ubuntu figured out quite nicely IMHO.

~~~
mxvzr
Encrypting the home directory ensures the privacy of your data should someone
get his hands on your machine. Under the same scenario, full disk encryption
would also gives you the guarantee the system hasn't been tampered with.

~~~
klodolph
That's profoundly incorrect: full disk encryption provides no guarantees that
your system has not been tampered with. I don't see how that would even be
possible.

~~~
mxvzr
If the machine is turned off and only the home directory is encrypted, I am at
liberty to patch the kernel or binaries, update your package manager or dns
settings, or anything in between really. I can do none of that with FDE
(assuming I don't already know the key of course).

What am I missing here?

~~~
eikenberry
Once "they" have your machine you have to assume it is compromised. If they
have the ability to install kernel patches or custom binaries, they most
certainly have the ability to install monitoring hardware and/or modify your
bios. That is, no matter what you encrypt your machine is compromised and your
only recourse is to recover the encrypted data and move on to a new system.
Here "they" is someone who would take your machine, modify it, and get it back
to you maybe without your knowing.

If you are just concerned with identity thieves and basic asset protection
then as long as that stuff is encrypted you are fine, whether that is whole
system, home directory, ~/Private directory, or just those specific files.

