The downsides of Arch ?

lloeki · 2007-04-23 08:09:14

I always use man. I never use info. other docs (e.g DEs help pages) I sometimes refer to, some others (JDK javadocs, used by eclipse for e.g javadoc tooltipping over classlibs methods) I absolutely require. optional doc packages are a must have, it does not even require 'suggested' packages and such: just build e.g grub-docs (as said before) so that grub+grub-docs = same as abs grub with keepdocs. it wouldn't even take redundant space. what about a 'onlydocs' ?
plus 'stfw' flat out doesn't work: I don't have a persistent internet connection: I dev on a laptop and am often on the move. yes, people do are offline sometimes. surprise surprise.

my system does not boot faster with upstart (that's a ~15s even match between arch and ubuntu) but it does (did, was with gentoo) boot much faster with einit (~2s to init 3, ~5-7s to init 5).

Last edited by lloeki (2007-04-23 08:14:01)

Jacek Poplawski · 2007-04-23 09:04:25

Arch is still best Linux distro I found but it has downsides:

- package dependences, while pacman is a good (perfect?) tool, it's very often diffucult to make a package update without full system update (I will repeat same example: openssl, update it and forget about your servers), solution? spend more time when making critical packages

- package maintainers, when someone will make PKGBUILD and put it into AUR, someone else can take it away from him and put it community, it is OK as long as he has time to mainain this package, but outdated packages exist and we, as users, can't do anything with it, only wait, solution? create repository for unofficial builds, or at least give some server space for unofficial PKGBUILDs ("proposed updates"?)

- votes and unsupported -> community, there are good packages in community, they are voted high, but they still require compilation from AUR, solution? give server space for unsupported binary packages or look at votes and move packages to community (but only if you are willing to mainain this package, look previous point)

- removed info - year ago I though that it's a good idea, but it happened at least few times when I needed info, I found it on another computer or on the website

About user community - Arch Linux has probably most friendly community, you can't even compare it with Gentoo or Ubuntu. Just read forums or newsgroups. This distro has so many advantages that I can't even count them.

hybrid · 2007-04-26 01:19:22

stonecrest wrote:

My criticisms of Arch are its ridiculous stance on stripping docs (not that I would use them often, but to save me 50mb? come on) and the fact that it installs openoffice, firefox, acroread, and similar programs to /opt. I personally think only GNOME, KDE, and Xfce should be installed to /opt, and I'd even be okay with nothing being installed there.

@stonecrest: I have /opt symlinked to /usr/opt. I agree that Arch stores too much in opt. I kinda had to laugh about the "gnome moves from opt to usr" news. Well anyhow.
I also agree that it is a preposterous philosophy to strip those very few KB of sometimes valuable information for what? Disk space can't be a reason considering today's harddisks (I recently saw a 500GB HDD for less than 150USD/~130Euro). Arch requires a good internet connection; so users with a sufficient connection I'm sure won't care about those extra kb and if one's internet connection is not that great, believe me, searching the net for that missing piece of information is not great or quick either (take my word for it, I'm stuck with a 64kbit line for the next couple months).
Example: I needed the kernel documentation and guess what: it wasn't there. :> So I ended up downloading the whole kernel-tarball _just_to_get_the_documentation_that_I_needed - and that with the internet connection I mentioned earlier. That wasn't only nerve wrecking and wasting time, but also cost me money (don't have a flatrate either). That one tarball is probably bigger than the stripped documentation to all the packages on my harddisk.

Coming from a Slackware I miss the clean cut, simple but effective design. Sometimes find things unorganized, it sometimes seems like things are all over the place. Example firefox: Instead of putting a symlink pointing to the firefox-binary "/opt/mozilla/bin" is added to $PATH. (Why would anyone do it that way, by the way?) Other example openoffice: openoffice is linked to /usr/bin instead of added to $PATH. That just seems inconsistent and unorganized to me, I can't see a greater idea behind this. Talking about $PATH: What is /usr/X11R6/bin doing in path? Still there for compatibility reasons? Or are some packages still using that path? If so, why don't those packages set that up themselves instead of having one of the xorg-core packages set it up when no xorg-core package uses or even creates that directory?

Other than that I am still really happy with "my" Arch and I am enjoying pacman, pacman resolving dependencies for me, the nice Arch community and much more. :>

KerowynM · 2007-05-07 03:28:22

I miss the documentation. It always bothered me that it was missing, it was just one of the things I "Sucked up" when moving to arch.

From the tar man page:

The  GNU  folks, in general, abhor man pages, and create info documents instead.  The maintainer of tar falls into this
       category.  This man page is neither complete, nor current, and was included  in  the  Debian  Linux  packaging  of  tar
       entirely  to  reduce the frequency with which the lack of a man page gets reported as a bug in our defect tracking sys-
       tem.

       If you really want to understand tar, then you should run info and read the tar info pages, or use  the  info  mode  in
       emacs.

Simply deciding that one set of doc's is more important then the other leaves users which may not be as knowledgeable at a disadvantage. Not to mention the size of a couple text files by today's standards is trivial.

I'm one of those people that really wants to understand tar!

hybrid wrote:

Example: I needed the kernel documentation and guess what: it wasn't there. :> So I ended up downloading the whole kernel-tarball _just_to_get_the_documentation_that_I_needed - and that with the internet connection I mentioned earlier. That wasn't only nerve wrecking and wasting time, but also cost me money (don't have a flatrate either). That one tarball is probably bigger than the stripped documentation to all the packages on my harddisk.

QFT

Edit: And while I am aware that there is far more information online then could ever be found in a couple info pages, the times in which I might really need the info pages are likely the times things have gone horribly wrong, and if things are going horribly wrong then internet access is hardly guaranteed.

Edit2: If this wasn't a i686+ distro then stripping small text files by default might make more sense. My old 486 might not have the disk space. I can't say I've ever seen a pc that could run Arch that didn't have a disk big enough for info pages. Of course in those instances, which seem rarer to me, one can just strip the offending files manually.

Last edited by KerowynM (2007-05-07 03:54:18)

lloeki · 2007-05-07 09:54:50

I think the main concern of stripping docs is not space on the target, but bandwidth at source (and, only to some extend, at target). stripping 50 megs is a net save of 50 gig bandwidth for 1000 users (and I expect Arch has more that 1000 users), and that translates directly into added costs.

Secondly, it seems info pages not being included is like 32bit multilib in 64bit not being included, that is, pushing to the use of a common doc format throughout the system, the Arch chosen one being man. that said, foo-doc packages could very well be part of community or the AUR, just like lib32-foo ones are.

I understand hte frustration, but sincerely, 'man tar' is vastly sufficient in an 'emergency' case, and you honestly have to 'understand tar' once or twice, and then refer to the man page.

Last edited by lloeki (2007-05-07 09:56:25)

KerowynM · 2007-05-07 13:09:53

Well, obviously tar is a somewhat trivial example, but I found they summed up the problem quite well. Moving to a unified documentation format is an ideal that I agree with, but not at the cost of simply tossing out documentation that doesn't fit a chosen standard. I myself often wonder why people would choose to spread documentation across different implementations like that, but it's the situation we have. Given a choice between supporting 2 standards and throwing away valuable information, I for one will suffer with 2 standards.

I don't remove gzip just because I have bzip2, because I need to support both standards.

Edit: I wouldn't mind having separate packages with documentation, I am just not seeing it happen. The devs would have to maintain twice as many packages (Or less, any package with no info pages is excused.) I myself don't have the time to go thru and figure out which packages have info pages and make PKGBUILDs for them, let alone attempt to maintain them. I have keepdocs set in my makepkg.conf, so any package I build gives me the info I desire, but I left Gentoo, I don't want to have to compile most of my distro just because I care about documentation.

Last edited by KerowynM (2007-05-07 13:46:22)

KerowynM · 2007-05-07 17:23:00

Not sure how long it is considered proper before writing a new post instead of editing the last one, but its been a few hours so...

If there was a list of packages in the repo's that had info pages removed, that would go a long way to solving the problem. I could either set them all to build from source, or even start writing PKGBUILDs for them. As things stand it would be quite a task. Does there happen to be a list floating about? Or possibly a way to make makepkg report it so as the dev team builds packages and strips the info, the package name gets added to the list so somebody can get crackin' on making the required PKGBUILDs? That way us documentation freaks can take the burden off of those who could care less. It may not be that hard to add a few lines to makepkg that logs removal of documentation, extracts the package name, and checks it against the list to see if it has already been flagged. If it has already been flagged, then check to see if an info package has already been built. Something along the lines of: (pardon the psudo code, I dont know what makepkg is written in...)

if stripdocs == 1 then
  if pkgname != onlist then
    if pkgname == info-built
  return 0;
  else
  addlist pkgname
return 0;

A few lines of code and this problem could slowly fade into the distance and never plague anyone again.

Edit: The more I think about it, this seems to be the perfect solution. AUR packages don't need to be listed, because keepdocs can be set in makepkg. binutils, coreutils, and gcc have already been done, and if there were a list of others that needed written users could begin populating AUR with whatever info pages were deemed necessary. The actions in makepkg that logged info removal could be set with a flag, so users building their own packages wouldn't be making a list they don't need, and developers could set the flag in makepkg.conf and never have to think about info pages again. Also, as packages were moved from unsupported to community, as a dev built them their name would be added to the list, as they used a flagged makepkg to build them, and users then know the status of the info pages. Packages in AUR don't have the bandwith issues associated with repo packages, as they download the sources from whatever site hosts the sources. Disk space issues disappear as well, as you still only install what you want/need. Heck, were this the case it wouldn't even be that hard to write a script that would check all installed packages and see if there was an info package that corresponded to it, so long as everybody honored the pkgname-info convention.

Edit2: The code in makepkg wouldn't necessarily have to check if an info package had been built, so long as it didn't upset whether or not the built flag was set.

Edit3: Working on patching in a few lines to makepkg, I didn't realize it was just a bash script.

And an apology for my repeated editing, my brain works in spurts as I'm going about my day, and new concepts just "pop in in there."

Last edited by KerowynM (2007-05-07 20:34:10)

KerowynM · 2007-05-07 20:17:54

Hehe, that wasn't hard at all really.

My patch doesn't do anything fancy like checking if an info package already exsist, but it will check for info pages, if they exist it will check against the list to see if there is an entry, and then put the name on the list if it needs to be there:

--- /usr/bin/makepkg    2007-05-07 16:12:52.000000000 -0400
+++ makepkg     2007-05-07 16:12:30.000000000 -0400
@@ -42,6 +42,7 @@
 NOEXTRACT=0
 NOSTRIP=0
 RMDEPS=0
+INFOLIST=0

 PACMAN_OPTS=

@@ -644,6 +645,18 @@
        # remove info/doc files
        msg "Removing info/doc files..."
        cd $startdir
+        # check if package has been flagged as stripped
+         if [ ! "$INFOLIST" = "0" ]; then
+          if [ -d pkg/usr/info ] || [ -d pkg/usr/share/info ] || [ -d pkg/usr/doc ] || [ -d pkg/usr/share/doc ] || [ -d pkg/usr/share/gtk-doc ] || [ -d pkg/opt/gnome/share/gtk-doc ]; then
+           grep -x $pkgname ~/infostripped.log $1 $2 &> /dev/null
+           if [ ! $? = 0 ]; then
+            echo $pkgname >> ~/infostripped.log
+            msg "Adding package name to infostripped.log..."
+            else
+             msg "Already in infostripped.log..."
+           fi
+          fi
+         fi
        rm -rf pkg/usr/info pkg/usr/share/info
        rm -rf pkg/usr/doc pkg/usr/share/doc
        rm -rf pkg/{usr,opt/gnome}/share/gtk-doc

Any chance we could see something like this go live?

Edit: Somewhat self explanatory, but you need to set INFOLIST = 1 in makepkg.conf

Last edited by KerowynM (2007-05-07 22:56:50)

Romashka · 2007-05-07 20:33:44

Nice. Having more possibilities is not bad.

KerowynM wrote:

Any chance we could see something like this go live?

Post this patch to pacman-dev ML and file Feature Request on Flyspray so it won't get lost.

.:B:. · 2007-05-08 06:49:41

lloeki wrote:

I think the main concern of stripping docs is not space on the target, but bandwidth at source (and, only to some extend, at target). stripping 50 megs is a net save of 50 gig bandwidth for 1000 users (and I expect Arch has more that 1000 users), and that translates directly into added costs.

There is an easy and elegant workaround: instead of gzip, switch to bzip2 or (even better) lzma. Lzma has fabolous compression, takes slightly longer to decompress than gzip, but still better than bzip2. However it seems the developers are a bit reluctant to integrate it into pacman.

Tar is easily patched to support lzma. I've done that myself quite a few times already. I'm not sure how tricky it would be to have Arch's pacman handle lzma (I don't want Frugal's ). Heck, I'm not even sure if pacman needs to be able to handle lzma... If it just calls onto tar to handle it, it's even easier.

lloeki · 2007-05-08 11:17:26

Tar is easily patched to support lzma

no need for any patch. tar j and z options are merely convenience. pipe tar output into 7z:

# compress:
tar cf - ${files} | 7z a -si ${archive}.tar.7z
# uncompress:
7z x -so ${archive}.tar.7z | tar xf -

whatever, this is no workaround, it's entirely another solution for another problem: whatever the compression, stripping docs saves bandwidth.

KerowynM · 2007-05-08 14:47:15

There is a patched tar in AUR already (Hehe it's one of my packages, along with lzma )

LZMA is great. At its lowest settings it's often faster then bzip2, while giving comparable compression. If you crank it up it gets slow but gives amazing compression. Luckily the speed loss is mostly compression time, decompression doesn't take nearly as long.

Last edited by KerowynM (2007-05-08 14:52:35)

randomshinichi · 2007-05-18 16:35:22

SIDENOTE: I used to use Mandrake Linux here, and whenever I wanted to install the program I'd manually scour the internet for RPMs.

Now that I've learnt more about Linux in general, I'll just say that Gentoo is awesome, and Arch is like Gentoo but without the compiling. The only bad thing I can come up with about Arch is that Gentoo would never, ever, install esd if all I had to do was install eog. What does an audio mixer have in common with an image viewer anyway?

Jacek Poplawski · 2007-05-19 16:05:21

I think esd dependancy is gnome design problem, not arch problem.

.:B:. · 2007-05-19 17:13:32

randomshinichi wrote:

The only bad thing I can come up with about Arch is that Gentoo would never, ever, install esd if all I had to do was install eog. What does an audio mixer have in common with an image viewer anyway?

That's the drawback of binary distros: you're stuck with their dependencies as they see fit. Of course you won't have to install esd for eog on Gentoo, if the Gnome base you build it on has not been compiled with support for esd. You cannot make that choice yourself on distros like Arch, unless you rebuild packages.

archville · 2007-05-28 00:09:43

Only two downsides so far:

1) I don't want anything on /opt, or at least i prefer the system to ask me if i want, before installing.
2) I like /usr/local, AUR does not.

By the way the main downside i could see is if anything changes the actual way things are done in Archlinux.
For example, i don't understand why all distros seem to like adding Apache or Mysql to init when i install them. I love Arch doesn't. Same about Pacman asking about wheter i want to upgrade a package with the same version i have installed or not.

About stripping docs... i find man pages sufficient for everyday use.
Simple and lightweight... ¿ remember ? I need nothing more, if i want it
i can install it later.

F · 2007-05-28 07:38:23

(1) its awesome.

(2) too awesome for most people

these are the only downsides.

deficite · 2007-05-28 15:53:53

I personally love /opt, and I don't think Arch puts enough stuff in /opt. I don't know how you can have "too much" in /opt. It's not like Tux is going to smack you with his wing and then peck the crap out of you until you cry "/usr"

Whatever. It doesn't matter a whole lot to me, I just have to wade through unrelated crap to find what I want if I don't know it's name off the top of my head, that's all . I also don't have all the config files for a particular set of programs in one uniform place for easy finding. Bummer. We can't all agree on one thing I guess.

Last edited by deficite (2007-05-28 15:54:12)

noamsml · 2007-06-04 21:15:12

Downsides:

1. Takes lots of time to configure initially. Also, there's always some package I forget to install
2. Default font rendering for X sucks when compared with Ubuntu, and using cleartype packages can be problematic at times.
3. Usage of /opt for stuff works well from a login shell but breaks-ish if you use SLiM, where the path must be update manually
4. Some instability

oli · 2007-06-05 07:41:34

>1. Takes lots of time to configure initially.

Around 10 minutes.

>4. Some instability

Don't use any binary blobs and you will have a nice stability.

>Default font rendering for X sucks when compared with Ubuntu

It's KISS, some people are using antialiasing other people don't.

I don't see a real downside within most of the postings in this thread, because if you go with Arch you should already know it - it's the Arch way of doing things. There is KISS in Arch and e.g. some kind of "dicatorship" for beginners in Ubuntu/Fedora/Suse ...

chaosgeisterchen · 2007-06-05 08:06:03

Where to find a HowTo for people who - in fact - like to have font rendering just as nice as Ubuntu provides it?

Jacek Poplawski · 2007-06-05 08:49:08

About downsides - we are waiting another week for new Blender package, and really can't do anything. I can't make a PKGBUILD in AUR, because duplicating packages is forbidden. I can't flag package out of date because it is out of date for few weeks. I can't takeover package because I am not TU. I can only wait, that's sad.

mitsoko · 2007-06-05 09:37:07

/var/abs/extra/multimedia/blender
http://wiki.archlinux.org/index.php/XOr … figuration

[raeven@Lux32  ~]# telldepends esd
A list of all Arch packages that depends on : esd
--------------------------------------

community/basilisk-1.0-4
community/cinelerra-cv-1005-1
community/kvirc-3.2.6-3
community/musepack-tools-1.15v-1
community/rusxmms-1.2.10_csa31-2
community/xmms-1.2.10-9
current/libao-0.8.6-2
current/madplay-0.15.2b-1
current/xine-lib-1.1.6-2
current/xmms-1.2.10-8
current/enlightenment-0.16.8.8-1
extra/alsaplayer-0.99.79-1
extra/arts-1.5.7-1
extra/bmp-0.9.7.1-4
extra/d4x-2.5.7.1-1
extra/dopewars-1.5.12-1
extra/epplet-base-0.5-4
extra/freeciv-2.0.9-1
extra/sawfish-1.3-3
extra/sdl_net-1.2.6-1
extra/synaesthesia-2.4-1
extra/tuxtype-1.0.3-6
extra/vice-1.21-1
extra/gstreamer0.10-esd-0.10.5-1
extra/libvisual-plugins-0.4.0-1
unstable/mplayer-svn-22979-1

rebuild em without esd .... or pacman -Rd esd, and hope nothing tries to uses esd; btw, i don't see what harm esd is doign here ...
if disk usage is the issue here then i can so only one thing 178.2 KB z0m9 :-0 ..

EOR

KerowynM · 2007-06-06 04:12:30

Jacek Poplawski wrote:

About downsides - we are waiting another week for new Blender package, and really can't do anything. I can't make a PKGBUILD in AUR, because duplicating packages is forbidden. I can't flag package out of date because it is out of date for few weeks. I can't takeover package because I am not TU. I can only wait, that's sad.

You can always update your own version of the package, no need to wait for someone else to. Just because you can't upload it to AUR doesn't mean you can't save yourself.

Jacek Poplawski · 2007-06-06 09:52:16

Sure, I can do it myself, I can even download a binary version from Blender website. The point is that packages are not really created by community but by one person who maintains this package. Will it change in future?

Arch Linux

#76 2007-04-23 08:09:14

Re: The downsides of Arch ?

#77 2007-04-23 09:04:25

Re: The downsides of Arch ?

#78 2007-04-26 01:19:22

Re: The downsides of Arch ?

#79 2007-05-07 03:28:22

Re: The downsides of Arch ?

#80 2007-05-07 09:54:50

Re: The downsides of Arch ?

#81 2007-05-07 13:09:53

Re: The downsides of Arch ?

#82 2007-05-07 17:23:00

Re: The downsides of Arch ?

#83 2007-05-07 20:17:54

Re: The downsides of Arch ?

#84 2007-05-07 20:33:44

Re: The downsides of Arch ?

#85 2007-05-08 06:49:41

Re: The downsides of Arch ?

#86 2007-05-08 11:17:26

Re: The downsides of Arch ?

#87 2007-05-08 14:47:15

Re: The downsides of Arch ?

#88 2007-05-18 16:35:22

Re: The downsides of Arch ?

#89 2007-05-19 16:05:21

Re: The downsides of Arch ?

#90 2007-05-19 17:13:32

Re: The downsides of Arch ?

#91 2007-05-28 00:09:43

Re: The downsides of Arch ?

#92 2007-05-28 07:38:23

Re: The downsides of Arch ?

#93 2007-05-28 15:53:53

Re: The downsides of Arch ?

#94 2007-06-04 21:15:12

Re: The downsides of Arch ?

#95 2007-06-05 07:41:34

Re: The downsides of Arch ?

#96 2007-06-05 08:06:03

Re: The downsides of Arch ?

#97 2007-06-05 08:49:08

Re: The downsides of Arch ?

#98 2007-06-05 09:37:07

Re: The downsides of Arch ?

#99 2007-06-06 04:12:30

Re: The downsides of Arch ?

#100 2007-06-06 09:52:16

Re: The downsides of Arch ?

Board footer