«FS#24259 - [kernel26] AUFS2 is against "The Arch Way"». Or not?

metre · 2011-05-13 20:15:08

I noticed that interesting point of view. What do you think about it? (https://bugs.archlinux.org/task/24259?p … &sort=desc)
As you can see (http://mailman.archlinux.org/pipermail/ … 19080.html) this is kinda annoying for the developer.
So, I think that you (we?) can drop it

Last edited by metre (2011-05-13 20:16:27)

karol · 2011-05-13 21:32:12

As usual, the people that do the work should decide i.e. the devs.

ConnorBehan · 2011-05-15 14:41:28

IMO that bug report is pretty stupid. Last time I checked, the patch also had code related to unionfs and squashfs... should we take those out too? The Arch Way is not simply an anti-patch doctrine. Arch applies patches to firefox, xorg-server, mesa, gtk2, qt and lots of other major packages. However, the patches are applied responsibly because the developer has taken the time to study exactly what effect the patch will have on the code.

What (I've always thought) the Arch Way is trying to say is that the decision to apply a patch should not be taken lightly because even if a patch works perfectly RIGHT NOW, applying it represents a big commitment on the part of the package maintainer to make sure it keeps working with future versions. The maintainer of kernel26 has evidently decided that this commitment is worth it. Unless the patch breaks something, it is pretty stupid to cite a policy that encourages users to solve their own problems as a reason for removing it.

Last edited by ConnorBehan (2011-05-15 14:43:27)

jnguyen · 2011-05-15 15:18:29

ConnorBehan wrote:

IMO that bug report is pretty stupid. Last time I checked, the patch also had code related to unionfs and squashfs... should we take those out too? The Arch Way is not simply an anti-patch doctrine. Arch applies patches to firefox, xorg-server, mesa, gtk2, qt and lots of other major packages. However, the patches are applied responsibly because the developer has taken the time to study exactly what effect the patch will have on the code.

I think you misunderstand entirely what my point was I didn't claim that the developers are applying patches irresponsibly, or that they do not know the effects of these patches.

The maintainer of kernel26 has evidently decided that this commitment is worth it.

If you read the Mailing List link that I posted in the bug report, you might notice that tpowa (one of the kernel devs) said that he is "getting tired of building aufs2 into the standard kernel" and asked "Can we ditch aufs2 support?". brain0 (the other kernel dev) said that "We could maintain an extra kernel only for the live CD if that is easier." Perhaps they have changed their minds since then, but it doesn't seem like the two kernel devs are huge fans of aufs2. I couldn't find any further public communication regarding this matter, so I opened this bug report.

Unless the patch breaks something, it is pretty stupid to cite a policy that encourages users to solve their own problems as a reason for removing it.

Perhaps you should read the bug report and comments again you will realise I am not talking about patches that fix known bugs. That is perfectly acceptable. However, the kernel builds fine and functions perfectly without the aufs2 patches. Those patches do not fix bugs or regressions. If we are to follow your line of logic, perhaps then we should include the kernel26-ck patches... after all, we wouldn't want to encourage users to solve their own desktop responsiveness problems, right? The TOMOYO Linux 1.x branch is undoubtedly better than the current in-kernel 2.x branch. Perhaps we should include that as well. The BFQ I/O scheduler is considered by some to be better than CFQ. Perhaps we should include that as well... in fact the BFQ patches don't even really change anything unless you set "elevator=bfq" in GRUB. So, uhh, where do you draw the line. See my point? The answer is that none of these should be in the kernel, since the Arch philosophy as I see it is for minimal patching and keeping things as vanilla as is reasonable to do.

The main reason for the aufs2 patches at the moment is for the installation media. brain0 already suggested one of the alternative options (separate kernel only for live CD), while djgera suggested the use of union-fuse. If the kernel devs and releng team see one of these alternatives as viable, then we no longer need to patch the kernel with the aufs2 patches. I am still awaiting more input from tpowa, brain0 and the releng team, as it is still unclear what their opinions are. They of course have the final say, and of course may have different opinions than myself on what "The Arch Way" really means.

Last edited by jnguyen (2011-05-15 15:24:01)

ANOKNUSA · 2011-05-15 17:30:49

I'd like to throw in my two cents here, just for the sake of anyone who might read this later. I'm not looking to criticize anyone personally--I'm just afraid I know where this conversation might go. Now, if you look around online you'll find that, quite often, people who criticize both the Arch community and Arch as a distro rhetorically use "The Arch Way" to make their points. These criticisms typically fall roughly into four categories:

1) People who just don't get Arch (misunderstanding of "Simplicity," "Lightweight," "Freedom," etc.).
2) People who complain for ideological reasons (usually about kernel components that they see as toeing/crossing the line, such as certain drivers).
3) People who can't understand the fact that every highly popular distro is distinct, hence its popularity (fanboys/fangirls complaining that "Feature x" should be present 'cuz that's how "Distro y" does it; we all know the types).
4) People who want what they want for whatever reason and dammit, they want it now!

Whatever the case may be here, starting an argument off with "It's against 'The Arch Way'" isn't going to push a discussion anywhere. I've seen this come up with regard to scheduling patches, the AIF, wifi drivers, the AUR, pacman (especially GUIs) and the like, and the answer is always the same: "The Arch Way" is a multi-faceted philosophy that extends beyond whatever bits precisely conform to any individual user's outlook. Those components of Arch people complain about are typically the one's they don't need for their systems, and they seem to easily forget that there's a hell of a lot of diversity among PCs requiring a balance of the aforementioned components of "The Arch Way" in order to make Arch accessible to many other people. Asking the devs to focus on one component of "The Arch Way" (Simplicity) at the expense of another (Liberty) simply because one's own definition of "Simplicity" doesn't fully jibe with others' isn't just inconsiderate, it's also insulting to the devs--who I would guess have given more thoughts to this than the complainant.

Yes, ask for explanations; if they aren't quite satisfactory, go ahead and state your point, and leave the devs to ponder it and do what they will. The explanation of the actual substance of the patch seems adequate to me; fact is, this may be a simple issue of someone not wanting to spend time building two extra kernels separately, and it's clear that a similar component is necessary even if aufs specifically isn't (which means that replacing it raises logistical issues as well). At the same time, the other dev's desire to remove aufs for similar reasons is understandable. What will suffice for all you readers here is: "The Arch Way" isn't black-and-white, and isn't an ideological weapon that one can use to get one's own way. And as karol pointed out: complain all you want, but you ain't doing the work, and chances are the folks who have been doing this for years thought this through before you dropped your complaints at their feet. The question is raised: Where does one draw the line? The fact is, sitting here and discussing that isn't going to answer the question in the same way real-world practice would, and the devs are dealing with the latter.

jnguyen · 2011-05-15 19:28:30

ANOKNUSA wrote:

starting an argument off with "It's against 'The Arch Way'" isn't going to push a discussion anywhere.

I would like to emphasize (which I also did in the bug report) that my intention was not to start a flamewar. I found a certain decision made by the devs to be different to how I would have done it, and so tried to present my argument in a polite and constructive manner. My intention was thus to offer my opinion and to start a friendly discussion. metre said above: "I noticed that interesting point of view. What do you think about it?" and that was the atmosphere I intended for the discussion. I do admit that I forgot to include a very important tidbit (the alternative solutions to the installation media if aufs2 patches are removed), which did lead to a misunderstanding with wonder and brain0, but I did later mention that omission in the comments.

Asking the devs to focus on one component of "The Arch Way" (Simplicity) at the expense of another (Liberty) simply because one's own definition of "Simplicity" doesn't fully jibe with others' isn't just inconsiderate, it's also insulting to the devs--who I would guess have given more thoughts to this than the complainant.

I would like to defend myself here, as I presented my opinions politely. Bringing up philosophical discussion is not insulting. I engage in heated religious debates all the time, but nobody leaves feeling insulted. Recently, I presented a criticism to the minister of a church I attend. He acknowledged my complaint and respectfully disagreed with my viewpoint. Nobody left that discussion feeling insulted. If the devs do in fact feel insulted then they can say so, and I will apologize

The fact is, sitting here and discussing that isn't going to answer the question in the same way real-world practice would, and the devs are dealing with the latter.

You are right that discussing isn't going to answer my question, because the only input I care about is that of Thomas, Tobias and the releng team (whose opinions I am still awaiting). That is why I avoided the forum, but it appears that this discussion has overflowed from the bug tracker

I personally value user feedback, whether positive or negative, as long as it is done politely, is constructive, and is presented with sufficient evidence and information. I feel I have done this, and I also believe that all development teams value constructive input from their users. As I already mentioned in the bug report, this issue is not a big deal, and if the devs do not agree with my viewpoint then I will happily sit back and forever hold my peace.

Last edited by jnguyen (2011-05-15 19:49:50)

Inxsible · 2011-05-15 20:27:36

I don't believe there is anything wrong with starting a bug report, if a user feels that something in the software should be different/fixed. It, atleast, gets the discussion started. Once the bug/issue report is opened, its up to the devs (in this case the kernel devs) to decide if they want to spend the time fixing said issue or just put it down as "Won't Fix" - which will be the end of that.

If however, they do decide to fix it, then they still can set a priority on it anywhere from Low --> Immediate depending upon the impact of the said bug and its potential fix.

So the discussion has been started already and the devs will come to a decision sooner or later after they do their deliberations. Until then, (generally) people are welcome to provide fixes so that they devs can simply accept those if they do decide to fix it.

ConnorBehan · 2011-05-16 16:15:22

jnguyen wrote:

If you read the Mailing List link that I posted in the bug report, you might notice that tpowa (one of the kernel devs) said that he is "getting tired of building aufs2 into the standard kernel" and asked "Can we ditch aufs2 support?". brain0 (the other kernel dev) said that "We could maintain an extra kernel only for the live CD if that is easier." Perhaps they have changed their minds since then, but it doesn't seem like the two kernel devs are huge fans of aufs2. I couldn't find any further public communication regarding this matter, so I opened this bug report.

Originally I just assumed that the mailing list post was written by the same person as the bug report -- I didn't notice that it was by Tpowa. That certainly gives more weight to your argument. And it makes mine look trollish because I said that the kernel devs find the aufs2 patch to be worthwhile when that is actually not the case.

If we are to follow your line of logic, perhaps then we should include the kernel26-ck patches... after all, we wouldn't want to encourage users to solve their own desktop responsiveness problems, right? The TOMOYO Linux 1.x branch is undoubtedly better than the current in-kernel 2.x branch. Perhaps we should include that as well. The BFQ I/O scheduler is considered by some to be better than CFQ. Perhaps we should include that as well... in fact the BFQ patches don't even really change anything unless you set "elevator=bfq" in GRUB. So, uhh, where do you draw the line. See my point? The answer is that none of these should be in the kernel, since the Arch philosophy as I see it is for minimal patching and keeping things as vanilla as is reasonable to do.

And now, you in turn misunderstand my point. I'm not saying that every hack ever written should be applied to the kernel. In a perfect world I would expect the Arch kernel to include every patch that is a) well-tested and known not to cause any bugs no matter how the features are used and b) universally beneficial to the Arch community so that 100% of Arch users gain a more functional system whether they run a desktop, laptop or server.

In the real world, it is very hard to satisfy such a diverse user base and very hard to do that much testing and debugging in all possible cases so there are a few schools of thought on the topic of which patches to include. Many distros decide to focus only on particular users e.g. "we have mostly desktop users so lets include -ck". Other distros decide to make their releases few and far between so they can offer lots of patches and possibly multiple kernel packages. Then there's The Arch Way whose priority is having quick releases and not telling users what category they fall into. This lends itself to a vanilla kernel but if the developer thinks he can still make a quick schedule by applying patch X and making sure it is free of bugs, then I'd say patch X is compatible with The Arch Way as long as every user's performance is either improved by it or left the same.

Judging by Tpowa's post, the presence of aufs2 *is* affecting his ability to do releases so the safest thing to do may very well be to drop it in favour of your solution. The convenient side-effect of this is that if someone still wants aufs2 for whatever reason, he or she will be forced to compile kernel26 and hopefully learn a thing or two about Linux along the way. i.e. The Arch Way makes users solve their own problems which is something we *do* want to encourage. So you might be right in this case but I don't think the aufs2 patch is automatically wrong because it's "not vanilla" and doesn't fix an explicit bug. If you think so then I guess we just interpret The Arch Way differently.

Last edited by ConnorBehan (2011-05-16 17:07:35)

jnguyen · 2011-05-16 21:56:53

ConnorBehan wrote:

If you think so then I guess we just interpret The Arch Way differently.

Thanks for your input. I enjoy philosophical discussions, and I enjoy hearing different views from different people. Wouldn't it be so boring if everyone had the same opinion?

metre · 2011-05-20 09:32:08

News:
http://projects.archlinux.org/linux-2.6-ARCH.git/
"remove aufs for now, it's not working with .39 kernel"

http://projects.archlinux.org/linux-2.6 … 68f7fcec85

+ # according to:
+ # http://sourceforge.net/mailarchive/message.php?msg_id=27437647
+ # it's really unclear when .39 support will happen!

Last edited by metre (2011-05-20 09:33:02)

Awebb · 2011-05-20 09:48:18

So if aufs is needed to build the iso and the newer kernel does not support aufs, we won't see another iso unless the devs decide on which alternative they want to use? Hah! I like when the core elements of a discussion become obsolete all of the sudden... all this unsolved tension :-D

jnguyen · 2011-05-20 17:21:37

Well that was unexpected

Calimero · 2011-06-18 00:54:30

I don't agree with people who want to remove a patch, if this patch is needed for features we can't live without.
Well, maybe they don't make live-CDs, but I do. (dm-snapshot just won't do it for my livecd)

Thus, I'm maintaining a working AUFS2 package on AUR. Enjoy!

You need to rebuild kernel26 with those patches (they export the symbols needed by the aufs module):
http://sprunge.us/EaWg
http://sprunge.us/jMiW

Or use the kernel26-aufs_friendly package I'm also maintaining on AUR. It does this.

I strongly hope that Arch will suport AUFS again. In the meantime I'm maintaining the PKGBUILDs on AUR for those who need them.

PS: of course, in order to follow the Arch way, upstream should merge AUFS in the kernel's tree. That would be great.

Last edited by Calimero (2011-06-18 00:58:37)

archpastor · 2011-06-18 12:26:33

Thanks Calimero for maintaining the aufs2 package. Agreed on hoping Arch will resolve the aufs2 situation so we can make live-CDs again. Frustrating today trying to make an .iso on larch and poison-livecd-creator today and running into the aufs2 problem.

Arch Linux

#1 2011-05-13 20:15:08

«FS#24259 - [kernel26] AUFS2 is against "The Arch Way"». Or not?

#2 2011-05-13 21:32:12

Re: «FS#24259 - [kernel26] AUFS2 is against "The Arch Way"». Or not?

#3 2011-05-15 14:41:28

Re: «FS#24259 - [kernel26] AUFS2 is against "The Arch Way"». Or not?

#4 2011-05-15 15:18:29

Re: «FS#24259 - [kernel26] AUFS2 is against "The Arch Way"». Or not?

#5 2011-05-15 17:30:49

Re: «FS#24259 - [kernel26] AUFS2 is against "The Arch Way"». Or not?

#6 2011-05-15 19:28:30

Re: «FS#24259 - [kernel26] AUFS2 is against "The Arch Way"». Or not?

#7 2011-05-15 20:27:36

Re: «FS#24259 - [kernel26] AUFS2 is against "The Arch Way"». Or not?

#8 2011-05-16 16:15:22

Re: «FS#24259 - [kernel26] AUFS2 is against "The Arch Way"». Or not?

#9 2011-05-16 21:56:53

Re: «FS#24259 - [kernel26] AUFS2 is against "The Arch Way"». Or not?

#10 2011-05-20 09:32:08

Re: «FS#24259 - [kernel26] AUFS2 is against "The Arch Way"». Or not?

#11 2011-05-20 09:48:18

Re: «FS#24259 - [kernel26] AUFS2 is against "The Arch Way"». Or not?

#12 2011-05-20 17:21:37

Re: «FS#24259 - [kernel26] AUFS2 is against "The Arch Way"». Or not?

#13 2011-06-18 00:54:30

Re: «FS#24259 - [kernel26] AUFS2 is against "The Arch Way"». Or not?

#14 2011-06-18 12:26:33

Re: «FS#24259 - [kernel26] AUFS2 is against "The Arch Way"». Or not?

Board footer