| View previous topic :: View next topic |
| Author |
Message |
miket
Guru
Joined: 28 Apr 2007
Posts: 488
Location: Gainesville, FL, USA
|
 Posted: Sat Aug 01, 2015 7:58 pm Post subject: |
 |
|
| Naib wrote: | | miket wrote: |
If they want systemd features, why don't they just use systemd? |
It depends if the features of systemd are worthwhile. I am not saying this is one of them or any of them, just to dismiss a concept just because it is systemd in origin is a oneTrueScotman stance |
The main reason I wrote that was that, as disussion of the point earlier in this thread illustrates, that the concept of making up new units--or rather cooking up a new unit system from whole cloth that openrc had not had before--is a unneeded case of adding extra, untested complexity into a system that is working pretty well already. In the discussion in the mailing list, there seemed to quite a flow of wild new ideas, including a truly dangerous one: if an idea or some bit of code happens to have been in place for some years, it is "legacy" and therefore outmoded and must be replaced. These are very dangerous currents. It happens that much of the thrust of systemd is based on such premises.
The commenters in the mailing list seemed to be pushing for radical things, but maybe yes, they see systemd in all its vast horror as too big a pill to swallow. If that should be the case, everyone might be happier with one idea I mentioned in my post: a module to add to the openrc startup which would do the unit-based startup of file systems.
Yes, a module from a second package that uses well-defined interfaces. That kind of transparency is quite contrary to another part of systemd philosophy. |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Aug 02, 2015 11:34 am Post subject: |
|
|
| Naib wrote: | | It depends if the features of systemd are worthwhile. I am not saying this is one of them or any of them, just to dismiss a concept just because it is systemd in origin is a oneTrueScotman stance |
And this is just playing devil's advocate.
Step up with the use-case first, which you should not even need to do, because many admins have been asking for the capability on your mailing-list, and all over the web.
Or y'know, stop wasting our time with nonsense. You might get paid to waste our time, but we, and our businesses just lose. |
|
| Back to top |
|
|
miket
Guru
Joined: 28 Apr 2007
Posts: 488
Location: Gainesville, FL, USA
|
| Posted: Wed Aug 05, 2015 6:41 pm Post subject: |
|
|
Behind all the back-and-forth of who is insulting whom is an elephant-in-the-room issue that saellaven raised last Friday: the proposal to bring in systemd-type mounting to openrc with the possible elimination of /etc/fstab entirely. This is the alarming thing. It would seem from the course of the mailing-list threads that the openrc maintainer is all too eager to make radical changes on the basis of what only six correspondents had discussed: | Quote: | | it seems that we have mostly agreed that this proposal is a good one, so I want to focus the discussion on the specific behaviour of localmount and netmount. |
(http://article.gmane.org/gmane.linux.gentoo.devel/96530)
For such a critical part of the Gentoo infrastructure, that's a mighty big set of changes with so little consultation with the wider community. There do seem to be valid concerns raised in those mailing-list threads, but way too little coverage of a wide variety of usage cases or of possible alternate solutions.
This comes back to the issue of competence, namely the competence of any single developer to resolve such weighty issues himself. The larger community must be able to weigh in. There can be experiments, but in no way should we have something this big spring upon us without having buy-in from the Many Eyes of the community.
There should be a separate thread in this forum for the topic. |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 646
|
| Posted: Wed Aug 05, 2015 7:23 pm Post subject: |
|
|
| miket wrote: | Behind all the back-and-forth of who is insulting whom is an elephant-in-the-room issue that saellaven raised last Friday: the proposal to bring in systemd-type mounting to openrc with the possible elimination of /etc/fstab entirely. This is the alarming thing. It would seem from the course of the mailing-list threads that the openrc maintainer is all too eager to make radical changes on the basis of what only six correspondents had discussed: | Quote: | | it seems that we have mostly agreed that this proposal is a good one, so I want to focus the discussion on the specific behaviour of localmount and netmount. |
(http://article.gmane.org/gmane.linux.gentoo.devel/96530)
For such a critical part of the Gentoo infrastructure, that's a mighty big set of changes with so little consultation with the wider community. There do seem to be valid concerns raised in those mailing-list threads, but way too little coverage of a wide variety of usage cases or of possible alternate solutions.
This comes back to the issue of competence, namely the competence of any single developer to resolve such weighty issues himself. The larger community must be able to weigh in. There can be experiments, but in no way should we have something this big spring upon us without having buy-in from the Many Eyes of the community.
There should be a separate thread in this forum for the topic. |
In his latest post, williamh says that fstab isn't going anywhere any time soon, he's just adding functionality that can be ignored if you don't want it (IMO, "for now")... meanwhile, the systemd people are chiming in that this functionality must be added to everything else, even though they don't intend to use anything other than systemd itself.
Also, from what I gather, williamh has some type of disability that precludes him from using the forums, though there is no requirement for devs to participate here at all anyway (and the council can't be arsed to look here even when making a large sweeping decision). Anyway, if you want to have a discussion that he (or any other dev) is sure to see, you want the dev mailing list or bugzilla, though I find neither all that conducive to getting things done as a mere mortal (user), so I don't participate there (nor does SteveL or some others). |
|
| Back to top |
|
|
Ottre
Tux's lil' helper
Joined: 23 Dec 2012
Posts: 129
|
| Posted: Wed Aug 05, 2015 7:28 pm Post subject: |
|
|
| miket wrote: | | There do seem to be valid concerns raised in those mailing-list threads, but way too little coverage of a wide variety of usage cases or of possible alternate solutions. |
True. They're discussing the pros and cons of systemd-style mount units, without considering things like /etc/vfstab from Solaris.
Having an "automount=yes" or "automount=no" column is simpler than passing the "auto" or "noauto" option, wouldn't you say?
And it's much simpler than systemd.automount, where automount means "mount on first access" rather than "mount on boot".
Similarly, we could have a "usermount=yes" or "usermount=no" column, like the "sysctl vfs.usermount=1" setting in FreeBSD, which is simpler than passing the "user" option. What is the opposite of "user" anyway, is it "nouser" or "superuser"?
| Quote: | | This comes back to the issue of competence, namely the competence of any single developer to resolve such weighty issues himself. The larger community must be able to weigh in. |
The maintainer of the mount program is collaborating with the systemd developers, there's no reason to think he wouldn't collaborate with the OpenRC developers as well. Somebody should send him a link to the thread.
As a side note, OpenRC is using mount -n in 14 different places:
| Code: |
~/openrc/sh/init.sh.Linux.in: mount -n -t "$procfs" -o noexec,nosuid,nodev proc /proc
~/openrc/sh/init.sh.Linux.in: mount -n -t xenfs xenfs /proc/xen -o nosuid,nodev,noexec
~/openrc/init.d/devfs.in: mount -n -t $devfstype -o $mountopts dev /dev
~/openrc/init.d/devfs.in: mount -n -t $1 -o noexec,nosuid$4 $5 $2
~/openrc/init.d/root.in: mount -n -o remount,rw /
~/openrc/init.d/sysfs.in: mount -n -t sysfs -o ${sysfs_opts} sysfs /sys
~/openrc/init.d/sysfs.in: mount -n -t securityfs -o ${sysfs_opts} \
~/openrc/init.d/sysfs.in: mount -n -t debugfs -o ${sysfs_opts} debugfs /sys/kernel/debug
~/openrc/init.d/sysfs.in: mount -n -t configfs -o ${sysfs_opts} configfs /sys/kernel/config
~/openrc/init.d/sysfs.in: mount -n -t tmpfs -o ${opts} cgroup_root /sys/fs/cgroup
~/openrc/init.d/sysfs.in: mount -n -t fusectl -o ${sysfs_opts} \
~/openrc/init.d/sysfs.in: mount -n -t efivarfs -o ${sysfs_opts} \
~/openrc/init.d/sysfs.in: mount -n -t cgroup \
~/openrc/init.d/sysfs.in: mount -n -t cgroup -o ${sysfs_opts},${name} \
|
|
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Wed Aug 05, 2015 7:56 pm Post subject: |
|
|
| saellaven wrote: |
In his latest post, williamh says that fstab isn't going anywhere any time soon, he's just adding functionality that can be ignored if you don't want it (IMO, "for now")... meanwhile, the systemd people are chiming in that this functionality must be added to everything else, even though they don't intend to use anything other than systemd itself. |
The problem itself is that openrc is not gentoorc, it's openrc, adding functionally that can only works the way gentoo handle its system (ie: the no fstab), will void the "open" in it. I think the project should be taken away from hubbs hands, because he is not driving it the way it should. I won't say he is incompetent to avoid getting mv getting green and angry again, but he seriously made me regret the project isn't anymore handle by Roy Marples.
Hubbs will never goes here, just because no devs in the ml will told him what users could tell him, if a dev disagree he will just shutup.
That's how we endup with /usr in seperate partition ; and that's the purpose of this non discussion thread in their list : an excuse to tell it was spoken.
See it's already to a "it seems that we have mostly agreed that this proposal is a good one" level.
Sorry, but when i see:
| Quote: | The sys admin would have to configure
which mounts are local vs network using settings in
/etc/conf.d/{local,net}mount. |
It's enough for me to disagree and ask: isn't what all linux sysadmins are doing with fstab already? |
|
| Back to top |
|
|
Ottre
Tux's lil' helper
Joined: 23 Dec 2012
Posts: 129
|
| Posted: Wed Aug 05, 2015 8:30 pm Post subject: |
|
|
| krinn wrote: | | It's enough for me to disagree and ask: isn't what all linux sysadmins are doing with fstab already? |
Configuring fstab is not a pleasant experience. I don't agree with splitting it into multiple files, but there are improvements to be made.
Case in point, how many people finetune the way their system boots?
Most people configure fstab to the point where the system boots, and then just leave it alone. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Thu Aug 06, 2015 1:52 am Post subject: |
|
|
| miket wrote: | Behind all the back-and-forth of who is insulting whom is an elephant-in-the-room issue that saellaven raised last Friday: the proposal to bring in systemd-type mounting to openrc with the possible elimination of /etc/fstab entirely. This is the alarming thing. It would seem from the course of the mailing-list threads that the openrc maintainer is all too eager to make radical changes on the basis of what only six correspondents had discussed: | Quote: | | it seems that we have mostly agreed that this proposal is a good one, so I want to focus the discussion on the specific behaviour of localmount and netmount. |
(http://article.gmane.org/gmane.linux.gentoo.devel/96530)
For such a critical part of the Gentoo infrastructure, that's a mighty big set of changes with so little consultation with the wider community. There do seem to be valid concerns raised in those mailing-list threads, but way too little coverage of a wide variety of usage cases or of possible alternate solutions.
This comes back to the issue of competence, namely the competence of any single developer to resolve such weighty issues himself. The larger community must be able to weigh in. There can be experiments, but in no way should we have something this big spring upon us without having buy-in from the Many Eyes of the community.
There should be a separate thread in this forum for the topic. |
The death knell for OpenRC. |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Fri Aug 07, 2015 1:29 am Post subject: |
|
|
I do not have much experience about williamh, perhaps except for an argument in bug #551644.
Nevertheless, I really do not agree with his attitude toward technical problems ("sweeping dirt under the carpet") as shown in above-mentioned argument.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
desultory
Bodhisattva
Joined: 04 Nov 2005
Posts: 9410
|
|
| Back to top |
|
|
miket
Guru
Joined: 28 Apr 2007
Posts: 488
Location: Gainesville, FL, USA
|
| Posted: Fri Aug 07, 2015 5:56 am Post subject: |
|
|
I am disheartened to see the splitting off of some of the posts in the current topic into a second topic. Even with the unproductive unpleasantness and hard feelings in some of the posts, there was even in many of them some material germane to the topic at hand. The topic's title, after all, is itself a clue into its contentiousness: The politics of systemd.
There are important issues here to confront; squashing the discussion is not helpful. The context of the split-off messages, as well as that of the source discussion becomes harder to follow. As I said in my previous post--which took me well over an hour to compose and made me late to work this morning--we can all work on ways to be civil yet speak honestly to the issues, including the intensely vital issues of how one of our core packages is to be maintained. I found the breaking of the topic to be unhelpful; I wish it had not happened. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Aug 07, 2015 9:51 am Post subject: |
|
|
| krinn wrote: | | It's enough for me to disagree and ask: isn't what all linux sysadmins are doing with fstab already? |
Agreed.
| Ottre wrote: | Configuring fstab is not a pleasant experience. I don't agree with splitting it into multiple files, but there are improvements to be made.
Case in point, how many people finetune the way their system boots?
Most people configure fstab to the point where the system boots, and then just leave it alone. |
Hmm thanks for the link to solaris' vsftab, but I don't see that as much of an improvement. (Also, I'd tend to use 'users' over 'user'.)
It seems to me you're confusing the underlying file format, with a tool to configure it, which can be written in any language (that's the beauty of a simple line-based plaintext config.)
eg: it's common for an installation program to provide a method of setting fstab parms, certainly in every bindist I've used, and we've done the same for a gentoo installer (whether we need one distributed is another topic) in bash, so it's not a real issue (in format terms.)
Ultimately people configure their fstab as much, or as little as they like.
Nowadays people are told just to use one big rootfs in any case, so I don't see that we need to change anything for the "non-admin" end-user. If everyone else is dumbing-down, there's no need for us to complexify. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Fri Aug 07, 2015 11:01 am Post subject: |
|
|
| Tony0945 wrote: | | miket wrote: | Behind all the back-and-forth of who is insulting whom is an elephant-in-the-room issue that saellaven raised last Friday: the proposal to bring in systemd-type mounting to openrc with the possible elimination of /etc/fstab entirely. This is the alarming thing. It would seem from the course of the mailing-list threads that the openrc maintainer is all too eager to make radical changes on the basis of what only six correspondents had discussed: | Quote: | | it seems that we have mostly agreed that this proposal is a good one, so I want to focus the discussion on the specific behaviour of localmount and netmount. |
(http://article.gmane.org/gmane.linux.gentoo.devel/96530)
For such a critical part of the Gentoo infrastructure, that's a mighty big set of changes with so little consultation with the wider community. There do seem to be valid concerns raised in those mailing-list threads, but way too little coverage of a wide variety of usage cases or of possible alternate solutions.
This comes back to the issue of competence, namely the competence of any single developer to resolve such weighty issues himself. The larger community must be able to weigh in. There can be experiments, but in no way should we have something this big spring upon us without having buy-in from the Many Eyes of the community.
There should be a separate thread in this forum for the topic. |
The death knell for OpenRC. |
Or the birth of a fork of openrc, one where hubbs and others of his ilk won't be able to ruin it so that systemd is the only choice.. 
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Fri Aug 07, 2015 3:26 pm Post subject: |
|
|
| Anon-E-moose wrote: |
Or the birth of a fork of openrc, one where hubbs and others of his ilk won't be able to ruin it so that systemd is the only choice.. |
It might be worthwhile. I've been looking into openrc, more specifically how it interacts with devfs, mdev, and udev. They are a mess and openrc itself could use some cleanup. Not a ground up re-write to stoke someone's ego with "a new direction and concept", but a code cleaning, re-documentation and removal of obsolete parts. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri Aug 07, 2015 4:26 pm Post subject: |
|
|
| Tony0945 wrote: | | openrc [...] code cleaning, re-documentation and removal of obsolete parts |
Documentation is almost nonexistent |
|
| Back to top |
|
|
EmaRsk
Apprentice
Joined: 07 Sep 2004
Posts: 158
Location: Italy
|
| Posted: Thu Aug 20, 2015 1:48 pm Post subject: |
|
|
| Ottre wrote: | | Having an "automount=yes" or "automount=no" column is simpler than passing the "auto" or "noauto" option, wouldn't you say? |
Actually, no, I fail to see how having a separate column for "automount" is different than having an "automount" option (the same goes for "user", of course).
| Ottre wrote: | | Configuring fstab is not a pleasant experience. |
What's so hard about it? It does one simple thing and has a simple and documented syntax, with tons of examples on the web.
| Ottre wrote: | Case in point, how many people finetune the way their system boots?
Most people configure fstab to the point where the system boots, and then just leave it alone. |
I'm sure there are specific names for these fallacies. Nobody knows the answer for the question (but I bet it's not "0") and there's no evidence to support the claim.
Even if the claim was correct,
- "most people" is not everyone. The answer for the question is not much relevant, unless the number is REALLY small.
- the fact that most people don't fine tune fstab doesn't imply a fstab inadequateness. (Actually, it could even imply the opposite.)
_________________
Please, avoid some common spelling errors:
http://theoatmeal.com/comics/misspelling |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2284
Location: Adendorf, Germany
|
| Posted: Fri Aug 21, 2015 9:11 am Post subject: |
|
|
| EmaRsk wrote: | | Ottre wrote: | Case in point, how many people finetune the way their system boots?
Most people configure fstab to the point where the system boots, and then just leave it alone. |
I'm sure there are specific names for these fallacies. Nobody knows the answer for the question (but I bet it's not "0") and there's no evidence to support the claim.
Even if the claim was correct,
- "most people" is not everyone. The answer for the question is not much relevant, unless the number is REALLY small.
- the fact that most people don't fine tune fstab doesn't imply a fstab inadequateness. (Actually, it could even imply the opposite.)
|
I do not finetune but change my fstab on several machines a few times per month. Like adding project relevant server shares or NAS filer paths, removing them when they are gone.
And on our server, all NFS shares for active projects get entries in the servers fstab, which every now and so often gets cleaned up.
The fstab is a handy tool that is *extremely* easy to handle. All you have to do is to invest about 15-30 Minutes to read some documentation, and you must know that there are man pages for every mount.* command you use.
There is absolutely nothing about fstab that could be improved.
_________________
Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Aug 21, 2015 6:37 pm Post subject: |
|
|
| Ottre wrote: | Case in point, how many people finetune the way their system boots?
Most people configure fstab to the point where the system boots, and then just leave it alone. |
Still not sure how this is a criticism. Is something only good if we're tweaking how it does things every week, or what?
Where I come from, fire-and-forget (until you actually need to change something) is much more fun, because it's much more useful, and much less hassle.
| EmaRsk wrote: | Even if the claim was correct,
- "most people" is not everyone. The answer for the question is not much relevant, unless the number is REALLY small.
- the fact that most people don't fine tune fstab doesn't imply a fstab inadequateness. (Actually, it could even imply the opposite.)
|
| Yamakuzure wrote: | I do not finetune but change my fstab on several machines a few times per month. Like adding project relevant server shares or NAS filer paths, removing them when they are gone.
And on our server, all NFS shares for active projects get entries in the servers fstab, which every now and so often gets cleaned up. |
So we have attestation from someone who does actually use fstab fairly "dynamically" on a regular basis.
No doubt the fact that you're not a newb is somehow going to be a criticism, but that's what utilities (console and GUI tools) are for, if it's really an issue.
| Quote: | The fstab is a handy tool that is *extremely* easy to handle. All you have to do is to invest about 15-30 Minutes to read some documentation, and you must know that there are man pages for every mount.* command you use.
There is absolutely nothing about fstab that could be improved. |
(emphasised)
++
It's a doddle to write a tool to configure it (I know, I've done it), should that really be needed.
As usual, it's a solushun looking for a problem, done "because we can" ("hey look, we can do this, and wouldn't it be neat if.."), not because admins and/or end-users have been bugging the developers for this ill-thought-through (because not thought-through at all) facility.
Another month, another wacky idea from the systemdiots. Entertainment, right? Right? ;)
Personally, I'm much more interested in what admins want, than lame-brained ideas from the wacky end of poeterring's rather deranged thought-process; end-users can soon learn, or use simple tools, given a format admins are happy with (which always means line-based plaintext, unless you have a damn good reason otherwise, which admins asked you for.) |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Fri Aug 21, 2015 11:40 pm Post subject: |
|
|
| steveL wrote: | As usual, it's a solushun looking for a problem, done "because we can" ("hey look, we can do this, and wouldn't it be neat if.."), not because admins and/or end-users have been bugging the developers for this ill-thought-through (because not thought-through at all) facility.
Another month, another wacky idea from the systemdiots. Entertainment, right? Right? 
Personally, I'm much more interested in what admins want, than lame-brained ideas from the wacky end of poeterring's rather deranged thought-process; end-users can soon learn, or use simple tools, given a format admins are happy with (which always means line-based plaintext, unless you have a damn good reason otherwise, which admins asked you for.) |
Exactly...and if there was a compelling reason at all to improve on fstab or replace it, there are countless plain text file formats that could define any functionality imaginable...but no...we have to turn everything into black-box-binary-Windows hell.
Like I keep saying...if it's simple there must be something wrong with it right? Amazing. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Aug 22, 2015 9:09 am Post subject: |
|
|
| tld wrote: | | Like I keep saying...if it's simple there must be something wrong with it right? Amazing. |
Lol, indeed.
I'm a great believer in: | Mikhail Kalashnikov wrote: | | To make something simple, is a thousand times harder than making something complicated. |
Work that's come before is deceptively simple; you can try and redo the whole thing from scratch, which always takes you down a complex route on the second iteration, but you will simply end up reinventing the whole thing, and you're very likely to do so badly, especially if you think you're somehow special by comparison to coders of the past.
An example would be eschewing shell, and then ending up using javascript (of all things) to effect evaluation.
The problem is ego getting in the way of admitting mistake, which means you cannot backtrack, or can only do so dishonestly, eg: by quietly having a Damascene conversion to POSIX, which never gets mentioned despite (because of) all the prior diatribes against POSIX.
This ofc leads to more obfuscation, rather than transparent craft.
I have no respect whatsoever for this approach; it's totally counter-productive in the longer-term.
However it's important to realise that a good result for us, is not what this is about; it's all about "business strategy" and "cornering a market" in order to cream off more profit from users: exploitation iow.
The make-work brigade are much the same; middlemen seeking to enforce their slice of the pie, by making it so only "certified admins" can be "trusted" to administer a Linux box.
Personally I find the idea of an admin who needs a certificate to show experience and ability, to be quite alarming.
Not saying I wouldn't understand that someone had taken such, early on in their career; it just wouldn't have any relevance to the decision to hire, or not.
If they were continually taking certificates to show "continuing education" I'd be much more dubious, and far less likely to recommend them: they should be way past that level in their daily work already, and that should be obvious in discussion and interview.
Certificates would be irrelevant to that conversation, or it's an amateur playing at competent, and I'd heed the Peter Principle when it came to dismissing their current position as a factor. |
|
| Back to top |
|
|
gwr
Apprentice
Joined: 19 Nov 2014
Posts: 194
|
| Posted: Sun Aug 30, 2015 12:11 am Post subject: |
|
|
So, the tactic of declaring stuff broken so you can be the hero and fix it just went too far...
http://m.slashdot.org/story/298759 |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Sun Aug 30, 2015 10:06 am Post subject: |
|
|
Not really kdbus related but interesting none the less (prob best moved to the sysd thread)
Why they think it is better to rewrite than submit patches is mindbogglingly.. The main concerns are about not all variables are set.
Besides arbitrarily defining some reference point, dismissing some tool against this referencing point (never justifying that reference point) and declaring a full rewrite is the only solution, with links to libsysd
Wait till vi gets absorbed for POSIX compliance
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54236
Location: 56N 3W
|
| Posted: Sun Aug 30, 2015 10:28 am Post subject: |
|
|
Naib,
Embrace ... Extend ... Extinguish ...
Its just Red Hat following the already discredited Microsoft Path.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
davidm
Guru
Joined: 26 Apr 2009
Posts: 557
Location: US
|
| Posted: Sun Aug 30, 2015 11:08 am Post subject: |
|
|
To be fair here is the other side of the story - not that I agree or disagree (from the link above)
| Quote: |
by phantomfive (622387) on Saturday August 29, 2015 @01:55PM (#50416559) Journal
ok, I just spent my morning researching the problem, and why the feature got built, starting from here [github.com] (linked to in the article). Essentially, the timeline goes like this:
1) On Linux, the su command uses PAM to manage logins (that's probably ok).
2) systemd wrote their own version of PAM (because containers)
3) Unlike normal su, the systemd-pam su doesn't transfer over all environment variables, which led to:
4) A bug filed by a user, that the XDG_RUNTIME_DIR variable wasn't being maintained when su was run.
5) Lennart said that's because su is confusing, and he wouldn't fix it.
6) The user asked for a feature request to be added to machinectl, that would retain that environment variable
7) Lennart said, "sure, no problem." (Which shows why systemd is gaining usage, when people want a feature, he adds it)
It's important to note that there isn't a conspiracy here to destroy su. The process would more accurately be called "design by feature accretion," which doesn't really make you feel better, but it's not malice.
|
|
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sun Aug 30, 2015 11:15 am Post subject: |
|
|
| Naib wrote: | | Why they think it is better to rewrite than submit patches is mindbogglingly.. |
Patching progX made by M.Z (and friends), will endup with progX faith under M.Z
Doing your own, you have its faith under your hands, sure someone might fork it, but until (easier to say than to do), everyone using it must accept what YOU decide, and even if anyone submit patch, YOU will accept them (or not!).
What next systemd, kdbus "funny" feature will be add, set mandatory... on a distro that is not own by RedHat, is under the hands of RedHat.
That's the state of debian & other distros now, their future is under RH's hands. And for me that's not even future, i consider that even today, many debian users flee from it, they flee to gentoo, bsd... But if tomorrow they wish comes back into a systemd driven release, it should be clear for them that the logical best distro for that would be RH and not the old one they left that don't own systemd ; so most users they lost, may comes back but not to them, for the distro that is the top with systemd, and this distro is RH.
Big companies generally react to that by creating consortium and ask the "stuff" or a new "stuff" put under its control, preventing any of the companies from it to takes the control of "stuff" (see the w3c, pci express, open document...). Even companies not from it benefits from it, they have no control themselves on "stuff", but the companies from the consortium are blocking each other from eating the project, and this equilibrium of forces prevent one company from it to attack companies not from it ; this until the consortium decide to act as one against them (like vhs, blueray...).
Any distro falling into systemd/kdbus... should put forces into controlling it, else they are just giving nails to RH that is building their coffin.
(maybe this all su's systemd should be moved to systemd politics thread, where it is already discuss there and su is not a kdbus feature) |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
