| View previous topic :: View next topic |
| Author |
Message |
schorsch_76
Guru
Joined: 19 Jun 2012
Posts: 452
|
 Posted: Wed Oct 07, 2015 6:59 am Post subject: |
 |
|
| Naib wrote: | 1st mainstream "fork" of the kernel under the guise of the SJW has occurred. Just need sysd throwing their weight behind this and we'll.
I guess I need to start looking at windows again |
Wo is SJW? 
_________________
// valid again: I forgot about the git access. Now 1.2GB big. Start: 2015-06-25
git daily portage tree
Web: https://github.com/schorsch1976/portage
git clone https://github.com/schorsch1976/portage |
|
| Back to top |
|
 |
gwr
Apprentice
Joined: 19 Nov 2014
Posts: 194
|
| Posted: Wed Oct 07, 2015 7:04 am Post subject: |
|
|
| schorsch_76 wrote: | | Naib wrote: | 1st mainstream "fork" of the kernel under the guise of the SJW has occurred. Just need sysd throwing their weight behind this and we'll.
I guess I need to start looking at windows again |
Wo is SJW? :?: |
Social Justice Warrior
http://www.urbandictionary.com/define.php?term=social+justice+warrior |
|
| Back to top |
|
|
augustin
Guru
Joined: 23 Feb 2015
Posts: 318
|
| Posted: Sun Oct 11, 2015 2:34 am Post subject: |
|
|
Laughing under Loud?? |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Oct 11, 2015 11:50 am Post subject: |
|
|
| khayyam wrote: | | Systemd is an innovation in the way that we communicate, legacy communication is broken ... stop spreading FUDGE! ;) |
"Communication is broken: people keep misunderstanding us, but it's not because we keep talking rubbish. (No-no-no): it's because people expect reasoning to make sense.
Nu-Speek™ is an innovation in the way that we communicate; legacy communication is broken. Nu-Speek™[1] is just the messenger.
[1] pka: Bulshytt™-2.0" |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Oct 11, 2015 12:03 pm Post subject: |
|
|
| saellaven wrote: | | how long before they apply the newly adopted code of conduct against key kernel devs like Linus via the Linux Foundation to try to pry it away from him? If Linus continues to maintain a branch, he will likely win*, but I can see Linus giving a big middle finger to everyone and walking away from the kernel to do something else at some point. |
It's a much longer-game than that: Torvalds will retire at some point, and then it's open-season on the codebase, as far as the corporate stooges are concerned.
They'll act in concert, as they do now, since de-facto cartel is the stable-point for crony capitalism.
The groundwork has already been laid, and the process of placing agents is well-established, and accepted in the community they're stealing from.
| gwr wrote: | | That would be the writing on the wall for open source software. It would no longer be a meritocracy of technical skills, but a bureaucracy of political correctness. |
Indeed: it's already happened in debilian, and to an extent Gentoo.
Though in both cases the ornery nature of users and smarter developers is a counter-weight, the apparatchiks are all about leverage (which is why "representative democracy" is all we ever get: much easier to coopt a few, than all. After all, you can fool some people all of the time.)
If we want to avoid it, then we have to fight the apparatchiks now, or later it will be a fait-accompli:
"No-one said anything back then, why are you kicking up a fuss now? Who are you anyhow?" (let's deflect into that, quite nastily, instead of the substantive issue.) |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3522
|
| Posted: Sun Oct 11, 2015 12:14 pm Post subject: |
|
|
| gwr wrote: | | It would no longer be a meritocracy of technical skills, but a buracracy of political correctness. |
"Political correctness" is not the goal for "them", it's just a tool for getting there. Once it serves no further purpose, it'll be cast aside.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
gwr
Apprentice
Joined: 19 Nov 2014
Posts: 194
|
| Posted: Mon Oct 12, 2015 5:24 am Post subject: |
|
|
| steveL wrote: |
Though in both cases the ornery nature of users and smarter developers is a counter-weight, the apparatchiks are all about leverage (which is why "representative democracy" is all we ever get: much easier to coopt a few, than all. After all, you can fool some people all of the time.)
|
| Quote: | | The apparatchik's aim in life is to out-ass-kiss, out-maneuver, out-threaten, out-lie and ultimately out-fight his or her way to the top of the pyramid-any pyramid. |
Nice!
But it doesn't seem like the few fighting are having any real effect. |
|
| Back to top |
|
|
arnvidr
l33t
Joined: 19 Aug 2004
Posts: 629
Location: Oslo, Norway
|
| Posted: Mon Oct 12, 2015 10:20 am Post subject: |
|
|
Going back to something discussed a few months ago.
| 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") |
Seems you're forced to do the opposite of ignoring it with openrc 0.18 according to the latest news after latest sync. It seems like I now have to add "nofail" too all my mount entries to make sure functionality does not change? Seems backwards. I don't know how serious it is if localmount/netmount fails to start, but it seems similar to the idiocy in systemd?
_________________
|
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6147
Location: Dallas area
|
| Posted: Mon Oct 12, 2015 12:54 pm Post subject: |
|
|
I locked my openrc at 13.11 just because I saw the potential for stupidity from the openrc dev back then.
Haven't seen anything that doesn't work with that version.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Mon Oct 12, 2015 1:32 pm Post subject: |
|
|
| Anon-E-moose wrote: | | I locked my openrc at 13.11 just because I saw the potential for stupidity from the openrc dev back then. Haven't seen anything that doesn't work with that version. |
similarly, I'm at =sys-apps/openrc-0.12.4 ... but have had to mask the following:
/etc/portage/package.mask
| Code: | >=sys-apps/openrc-0.13.7
>=sys-apps/kmod-19
>=net-fs/nfs-utils-1.3.1-r1 |
best ... khay |
|
| Back to top |
|
|
gwr
Apprentice
Joined: 19 Nov 2014
Posts: 194
|
| Posted: Mon Oct 12, 2015 6:00 pm Post subject: |
|
|
| I am sorry, but this is what it comes to? Locking the very app that makes Gentoo what it is on a specific version? That is insane. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Mon Oct 12, 2015 7:07 pm Post subject: |
|
|
| gwr wrote: | | I am sorry, but this is what it comes to? Locking the very app that makes Gentoo what it is on a specific version? That is insane. |
gwr ... that wouldn't be the only package from the tree I maintain in a local repo for one reason or other ...
| Code: | # print ${#$(print -rl ~pkg/local/**/*.ebuild(.))}
39 |
Anyhow, I masked openrc when I saw the likes of 'runscript > openrc-run' effectively breaking working setups in order to fix cornner cases ... I can live without that.
best ... khay |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1845
|
| Posted: Mon Oct 12, 2015 9:29 pm Post subject: |
|
|
| arnvidr wrote: | Going back to something discussed a few months ago.
| 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") |
Seems you're forced to do the opposite of ignoring it with openrc 0.18 according to the latest news after latest sync. It seems like I now have to add "nofail" too all my mount entries to make sure functionality does not change? Seems backwards. I don't know how serious it is if localmount/netmount fails to start, but it seems similar to the idiocy in systemd? |
Yea, that sort of pissed me off too. You could argue that possibly that should have been the default behavior to begin with, but it wasn't, and changing it like that is a total systemd move for sure. |
|
| Back to top |
|
|
arnvidr
l33t
Joined: 19 Aug 2004
Posts: 629
Location: Oslo, Norway
|
| Posted: Tue Oct 13, 2015 6:54 am Post subject: |
|
|
| tld wrote: | | arnvidr wrote: | Going back to something discussed a few months ago.
| 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") |
Seems you're forced to do the opposite of ignoring it with openrc 0.18 according to the latest news after latest sync. It seems like I now have to add "nofail" too all my mount entries to make sure functionality does not change? Seems backwards. I don't know how serious it is if localmount/netmount fails to start, but it seems similar to the idiocy in systemd? |
Yea, that sort of pissed me off too. You could argue that possibly that should have been the default behavior to begin with, but it wasn't, and changing it like that is a total systemd move for sure. |
What are the arguments for having that as default? If this is as terminal as in systemd, leading to a failed boot, that seems like nothing but lazy programming, not wanting to handle errors.
_________________
|
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3522
|
| Posted: Tue Oct 13, 2015 7:07 am Post subject: |
|
|
| arnvidr wrote: | | Yea, that sort of pissed me off too. You could argue that possibly that should have been the default behavior to begin with, but it wasn't, and changing it like that is a total systemd move for sure. |
What are the arguments for having that as default? If this is as terminal as in systemd, leading to a failed boot, that seems like nothing but lazy programming, not wanting to handle errors.[/quote]
Let's look at this differently. If something out of localmount/netmount fails under the old way, what have you got? An improperly booted system that hopefully lets you get in as root and diagnose. If something fails under the new way, what happens? Can you diagnose, or is it SystemRescueCD time?
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6147
Location: Dallas area
|
| Posted: Tue Oct 13, 2015 9:08 am Post subject: |
|
|
| arnvidr wrote: | Going back to something discussed a few months ago.
| 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") |
Seems you're forced to do the opposite of ignoring it with openrc 0.18 according to the latest news after latest sync. It seems like I now have to add "nofail" too all my mount entries to make sure functionality does not change? Seems backwards. I don't know how serious it is if localmount/netmount fails to start, but it seems similar to the idiocy in systemd? |
And why add "nofail", there is no valid reason for a disk not to automount
other than hardware error or someone wiped a disk of partitions/filesystems
and in that case trying to get it to boot to a normal desktop, by ignoring the error, is supremely foolish.
In any event I think that Hubbs, IMO, has got to be one of the stupidest people to ever claim to be a developer.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2179
|
| Posted: Tue Oct 13, 2015 9:38 am Post subject: |
|
|
| Anon-E-moose wrote: | ...
And why add "nofail", there is no valid reason for a disk not to automount
other than hardware error or someone wiped a disk of partitions/filesystems
and in that case trying to get it to boot to a normal desktop, by ignoring the error, is supremely foolish.
In any event I think that Hubbs, IMO, has got to be one of the stupidest people to ever claim to be a developer. |
Can you help me understand this? IIUC the old versions of localmount and netmount always claim to have started successfully whether or not they'd mounted all the disks. That sounds to me like a noob programmer error - not trapping errors. The new versions now fail if there's a duff disk, unless you explicitly flag it as "nofail" in fstab. That appears to me to be a sensible fix - it no longer lets init continue blindly in ignorance of a failed drive unless you've told it that you don't need said drive. It's not as if "nofail" is new, or Gentoo-specific; openrc should have respected it all along.
So why does that elect Hubbs to such an exalted minority? Arguing to retain broken behaviour for historical consistency is ridiculous - appling that to (say) security would require that all exposures remain unpached.
_________________
Greybeard |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6147
Location: Dallas area
|
| Posted: Tue Oct 13, 2015 10:27 am Post subject: |
|
|
| Goverp wrote: | | So why does that elect Hubbs to such an exalted minority? |
My view of wh's incompetence isn't based on what he's done with openrc this time, but his general history with gentoo software
openrc should have indeed checked for failure from localmount all along (any init pkg should have done the same)
Edit to add: in my own scripts, that mount disks I check the return code and only continue with two conditions (successful mount or it's already mounted).
It ain't rocket science.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Oct 13, 2015 11:29 am Post subject: |
|
|
| Anon-E-moose wrote: | ...
And why add "nofail", there is no valid reason for a disk not to automount
other than hardware error or someone wiped a disk of partitions/filesystems
and in that case trying to get it to boot to a normal desktop, by ignoring the error, is supremely foolish.
In any event I think that Hubbs, IMO, has got to be one of the stupidest people to ever claim to be a developer. |
| Goverp wrote: | | Can you help me understand this? IIUC the old versions of localmount and netmount always claim to have started successfully whether or not they'd mounted all the disks. |
The first problem is the confusion between netmount and localmount; just because you may wish to do something different for network-mounted filesystems, is no reason to start complexifying localmount too.
That is the "noob error" that keeps on cropping up: "let's make everything the same as what I'm thinking about now."
| Quote: | | That sounds to me like a noob programmer error - not trapping errors. The new versions now fail if there's a duff disk, unless you explicitly flag it as "nofail" in fstab. That appears to me to be a sensible fix - it no longer lets init continue blindly in ignorance of a failed drive unless you've told it that you don't need said drive. It's not as if "nofail" is new, or Gentoo-specific; openrc should have respected it all along. |
Well, that sounds good: "respecting it all along"; the problem is that it misses the point. Which is simply that localmount must succeed; it's a different thing to most services, and secondly that we use "noauto" to tell mount not to worry about certain drives.
| Quote: | | Arguing to retain broken behaviour for historical consistency is ridiculous - appling that to (say) security would require that all exposures remain unpached. |
It's not about "historical consistency", though there is never a good reason to break a perfectly sane, simple setup, in order to make a complex one on another installation half-work (or even work: it's simply bad thinking.)
I for one am perfectly happy to change things around in openrc, but only when you understand why they are the way they are in the first place; not from ignorance. For instance, I'd personally change localmount from being a standard service, to being a staging-runlevel if that makes sense, in the same way I'd treat network. And allow one to depend on the other, or not.
I would do this, and separate early-init out properly, so we can deal with udev or equivalent requiring localmount before full-startup properly, rather than papering over the issue and leaving it down to every end-user to sort out on their own.
See: we're not against change. We just want it to be sane, reasoned, and based on knowledge and experience of UNIX and the existing toolset.
Not on some nub's delusional ramblings this week, which amount to nothing more than "I can see this from here: let's change it as well." coupled with "see then we could do all this kewl stuff no-one ever asked for."
In this case, it's not about "retaining broken behaviour" which you must concede is a rather loaded statement. It's about recognising that if a "local" mount fails, someone is going to have to deal with it, and to do that they need to log in.
edit: s/netmount/network/
Last edited by steveL on Tue Oct 13, 2015 1:02 pm; edited 1 time in total |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6147
Location: Dallas area
|
| Posted: Tue Oct 13, 2015 11:52 am Post subject: |
|
|
I can see localmount continuing on even if a disk should fail to mount
although it should scream to the heavens  about it and thus someone can look at any problem(s).
Though I think that going to a full desktop (just so that someone can ssh in and find out there is a hardware problem) isn't an optimal solution either.
I have 2 entries for each kernel version that I keep, regular (full desktop) and single (root only mount)
I use the single entry for problems in booting (whatever they may be) it doesn't try to do localmount or indeed any of the normal services.
Bottom line, per this latest change to openrc, if disks fail to mount there is a problem.
As to whether a disk is necessary for full functionality of the system re: logging in, that will vary from user to user and setup to setup.
Sometime it would be appropriate to continue to full system functionality other times not.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Oct 13, 2015 1:07 pm Post subject: |
|
|
| Anon-E-moose wrote: | I can see localmount continuing on even if a disk should fail to mount
although it should scream to the heavens :) about it and thus someone can look at any problem(s). |
which is what happens.
| Quote: | | Though I think that going to a full desktop (just so that someone can ssh in and find out there is a hardware problem) isn't an optimal solution either. |
IDK, I see this as the equivalent of "socket activation"; if it has the filesystems it needs to start, it starts; if not, it bails.
Where's the problem? We're only talking about the occasional times where there's an error, not the usual case for partitions on the same drive as your rootfs and /boot, and hopefully not for more esoteric setups either (or they need to sort out the bigger problems, first.)
Meantime you can indeed ssh in, because the init-manager hasn't had a hissy-fit since it thinks it knows better than you.
| Quote: | As to whether a disk is necessary for full functionality of the system re: logging in, that will vary from user to user and setup to setup.
Sometime it would be appropriate to continue to full system functionality other times not. |
Again, just make a best-effort and let the admin sort it out, seems much cleaner and more elegant to me.
If anyone is talking about automating VM clouds (for the borg? ;) then they should address that use-case separately afaic, same as LTSP is a much better option than all this "modern" crap that doesn't know what it's doing. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6147
Location: Dallas area
|
| Posted: Tue Oct 13, 2015 1:34 pm Post subject: |
|
|
| steveL wrote: | | Again, just make a best-effort and let the admin sort it out, seems much cleaner and more elegant to me. |
I agree, I know about my system and how it should behave and what's necessary and what's not.
I can't say the same for some clueless dev (whether openrc or sysd) trying to decide about my system.
Given this from the man page
| Code: | | nofail Do not report errors for this device if it does not exist. |
I'm not sure if covers hardware that has a problem vs simple non-existence of hardware.
| Code: | mount has the following return codes (the bits can be ORed):
0 success
1 incorrect invocation or permissions
2 system error (out of memory, cannot fork, no more loop devices)
4 internal mount bug
8 user interrupt
16 problems writing or locking /etc/mtab
32 mount failure
64 some mount succeeded
The command mount -a returns 0 (all succeeded), 32 (all failed), or 64 (some failed, some succeeded). |
It would be easy enough to check inside localmount for mount problems instead of just blindly adding "nofail" to fstab
and alerting the relevant user (admin, etc)
This is hardly optimal, though (from /etc/init.d/localmount)
| Code: | ebegin "Mounting local filesystems"
mount -at "$types" $no_netdev
eend $? "Some local filesystem failed to mount" |
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
gwr
Apprentice
Joined: 19 Nov 2014
Posts: 194
|
| Posted: Tue Oct 13, 2015 4:06 pm Post subject: |
|
|
Does nofail even make sense?
If it is a critical OS drive and it fails, then the nofail specifier is meaningless. You are stuck no matter what.
If it is a noncritical drive and it fails, then it was noncritical and you don't care immediately anyway and it will be reported in logs, anyway.
So that leaves the case when it was a non OS drive and you want to specify it as nofail, but what does that mean for init?
Also, this seems ass-backwards from the expected default behaviour. I would only put a drive in a config file if I wanted explicit behaviour for it, so why would the default be do ignore mounting behaviour that I have explicitly stated? Seems like nofail should be the default and canfail should be the optional. |
|
| Back to top |
|
|
digi_owl
n00b
Joined: 04 Oct 2015
Posts: 9
|
| Posted: Tue Oct 13, 2015 4:23 pm Post subject: |
|
|
Nofail just suppress the errorcode on a failed mount command.
Thing is that previous inits have basically ignored mount error codes unless explicitly told otherwise.
Thing is that / is mounted earlier than most, so of it fails you will not even get into the general mount step of the init sequence.
While /bin and /sbin are directories on /, as long as / mounts the rest can be recovered from within the live system.
But now there is a push to move /(s)bin into /usr, perhaps even punt /usr onto NAS or SAN.
current low level user space developers only see two kinds of computers. Desktops/laptops and container/VM farms.
On the former, any failed mount is to be fixed with a livecd or similar. On the latter you reboot until it comes up, or you use the host OS to fix the container/VM (or depend on the likes of Intel VPro or HP ILO). Anything else do not enter into the equation.
Then again it all seems to come down to being able to take automated action upon the appearance of a new storage device in /dev. to me at least that sounds like autorun on steroids... |
|
| Back to top |
|
|
gwr
Apprentice
Joined: 19 Nov 2014
Posts: 194
|
| Posted: Tue Oct 13, 2015 5:59 pm Post subject: |
|
|
| digi_owl wrote: | Nofail just suppress the errorcode on a failed mount command.
Thing is that previous inits have basically ignored mount error codes unless explicitly told otherwise.
|
This seems like the saner behaviour to me. |
|
| 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
