| View previous topic :: View next topic |
| Author |
Message |
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
 Posted: Mon Nov 10, 2014 10:18 pm Post subject: |
 |
|
| depontius wrote: |
Or a local overlay to make it switchable. There's a bug on this, and the person who filed the bug already verified that it builds and works without avahi. |
What I'm saying is that the Synergy code has zeroconf code in the gui with no way to turn it off.
So to have >1.6* will require the avahi dns_sd lib.
It's not a matter of the ebuild.
Edit to add: I did download the 1.6.1 tarball, and the above response is based on what I saw in it.
Edit to add 2: To clarify, you can't separate out the zeroconf code from the gui code. (See later post by me)
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Last edited by Anon-E-moose on Tue Nov 11, 2014 12:41 pm; edited 1 time in total |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Nov 11, 2014 12:09 pm Post subject: |
|
|
| depontius wrote: | | Or a local overlay to make it switchable. There's a bug on this, and the person who filed the bug already verified that it builds and works without avahi. |
| Anon-E-moose wrote: | What I'm saying is that the Synergy code has zeroconf code in the gui with no way to turn it off.
So to have >1.6* will require the avahi dns_sd lib.
It's not a matter of the ebuild.
Edit to add: I did download the 1.6.1 tarball, and the above response is based on what I saw in it. |
Well both of these statements can't be true.. can they? |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Tue Nov 11, 2014 12:29 pm Post subject: |
|
|
An addendum, it will compile without avahi if you don't use the qt4 use flag.
Because the zeroconf stuff is down in the gui code.
Of course I'm not sure if you even get a gui without qt4.
Edit to add: So the ebuild should make avahi contingent upon the qt4 flag
_________________
PRIME x570-pro, 3700x, 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 Nov 11, 2014 12:47 pm Post subject: |
|
|
| Anon-E-moose wrote: | An addendum, it will compile without avahi if you don't use the qt4 use flag.
Because the zeroconf stuff is down in the gui code.
Of course I'm not sure if you even get a gui without qt4.
Edit to add: So the ebuild should make avahi contingent upon the qt4 flag |
Odd, as Raziel's post showed no USE flags on synergy:
| Code: | | [ebuild U ~] x11-misc/synergy-1.6.1 [1.5.1_p2398] |
It was avahi which had qt4; but I see the earlier ebuilds have qt4 and test, and clearly synergy uses Qt for its GUI. (Never heard of it before this post.)
| Code: | if use qt4 ; then
cd src/gui || die
qt4-r2_src_compile
fi |
Still, if it can build and compile without avahi, then there's hope, including that it's not central to its functionality, since earlier versions didn't use it.
edit: From the bug report, devs have already followed your suggestion. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Tue Nov 11, 2014 1:22 pm Post subject: |
|
|
| steveL wrote: | It was avahi which had qt4; but I see the earlier ebuilds have qt4 and test, and clearly synergy uses Qt for its GUI. (Never heard of it before this post.)
| Code: | if use qt4 ; then
cd src/gui || die
qt4-r2_src_compile
fi |
Still, if it can build and compile without avahi, then there's hope, including that it's not central to its functionality, since earlier versions didn't use it. |
Synergy should work fine without the gui. Might have to hand edit the config files though.
Whether avahi/zeroconf can be pulled out of the gui is left as an exercise for the reader. 
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Tue Nov 11, 2014 1:59 pm Post subject: |
|
|
We need a strategy...
The fire-of-the-moment is synergy, but there have been others and there will be more. The problem is that currently meaningless systemd encumbrances are being added to packages willy-nilly. At the moment they really are generally meaningless, but it may not remain so forever. There is a set of responses:
1 - Update ebuilds to remove meaningless dependencies, like this synergy problem. It's obviously entangled with the GUI, but functional without. (I know the problem is really avaha, it's a little conscious L.P. conflation.)
2 - Patch - with minimal learning it may be possible to patch things to run without encumbrances. I suspect synergy would be an obvious example, but it takes someone to step up to the job. Gentoo is well-set for such patching.
3 - Shims, like the bsd systemd-shim stuff.
4 - Fork.
So far there have been lots of tactical responses and discussion, and some strategic talk. The really sad thing here is that none of us really trust those who hold the keys to Gentoo to do the right thing. It's even sadder that I just wrote that sentence, and that I don't think anyone here will deny it.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
RazielFMX
l33t
Joined: 23 Apr 2005
Posts: 835
Location: NY, USA
|
| Posted: Tue Nov 11, 2014 2:16 pm Post subject: |
|
|
| depontius wrote: | We need a strategy...
The fire-of-the-moment is synergy, but there have been others and there will be more. The problem is that currently meaningless systemd encumbrances are being added to packages willy-nilly. At the moment they really are generally meaningless, but it may not remain so forever. There is a set of responses:
1 - Update ebuilds to remove meaningless dependencies, like this synergy problem. It's obviously entangled with the GUI, but functional without. (I know the problem is really avaha, it's a little conscious L.P. conflation.)
2 - Patch - with minimal learning it may be possible to patch things to run without encumbrances. I suspect synergy would be an obvious example, but it takes someone to step up to the job. Gentoo is well-set for such patching.
3 - Shims, like the bsd systemd-shim stuff.
4 - Fork.
So far there have been lots of tactical responses and discussion, and some strategic talk. The really sad thing here is that none of us really trust those who hold the keys to Gentoo to do the right thing. It's even sadder that I just wrote that sentence, and that I don't think anyone here will deny it. |
To your last point, how do we fix it? Gentoo is a distribution but it is also a community. How do we ensure that those with the keys listen to that community, or, that the keys are moved into the hands of those that care? I really don't understand/know the Gentoo governance structure; I am not trying to be difficult.
_________________
I am not anti-systemd; I am pro-choice. If being the latter makes you feel that I am the former, then so be it. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Tue Nov 11, 2014 2:34 pm Post subject: |
|
|
I dislike #3 as it gives a partial nod to systemd.
Patching or forking would let them know that we're not rolling over for a sysd overlord but working around it without any acknowledgment.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Tue Nov 11, 2014 6:02 pm Post subject: |
|
|
| Anon-E-moose wrote: | I dislike #3 as it gives a partial nod to systemd.
Patching or forking would let them know that we're not rolling over for a sysd overlord but working around it without any acknowledgment. |
+10^100 on this! I don't want systemd interfaces that walk or talk like a systemduck any more than I want systemd itself. Seems sort of like putting duct tape over a hole your neighbor drilled in your fucking wall  |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Nov 11, 2014 6:58 pm Post subject: |
|
|
| depontius wrote: | We need a strategy...
The fire-of-the-moment is synergy, but there have been others and there will be more. The problem is that currently meaningless systemd encumbrances are being added to packages willy-nilly. At the moment they really are generally meaningless, but it may not remain so forever. There is a set of responses:
1 - Update ebuilds to remove meaningless dependencies, like this synergy problem. It's obviously entangled with the GUI, but functional without. (I know the problem is really avaha, it's a little conscious L.P. conflation.)
2 - Patch - with minimal learning it may be possible to patch things to run without encumbrances. I suspect synergy would be an obvious example, but it takes someone to step up to the job. Gentoo is well-set for such patching.
3 - Shims, like the bsd systemd-shim stuff.
4 - Fork.
So far there have been lots of tactical responses and discussion, and some strategic talk. |
Yes, but: an inappropriate strategy is worse than none at all. ATM simply putting out fires as they appear, allows us to carry on without getting side-tracked into major political wars, which really do sap effort and go nowhere.
I agree with Anon, that 3 is a stupid idea, since all it does is cede the design ground to known-bad ideas.
That's not to say someone who's less technically-minded can't take on the political battles: but they should do that via the right medium; the mailing-list.
Technically speaking, a strategic move would be to setup a website to reclaim the projects coopted and then crippled by systemd. pci and usb hw dbs would be the first to address in that context; though aren't they incorporated in eudev now?
And then to rework the desktops so that there is no single desktop bus, but rather a domain-specific API for each area such as email-notification which uses the underlying POSIX API supplied with libc. That would be similar in form and intent to LADSPA, which is a classic example of how to do this right (in design terms).
| Quote: | | The really sad thing here is that none of us really trust those who hold the keys to Gentoo to do the right thing. It's even sadder that I just wrote that sentence, and that I don't think anyone here will deny it. |
I still don't think they're dumb enough to add a load of work to releng's shoulders, simply to get a much less capable and flexible end-product, that comes out much less frequently and is not as reliable a base from which to build a Gentoo install, for everyone concerned.
At that level, we should be pushing to change the default to eudev, imo, since one developer tilting at windmills is irrelevant when the upstream has explicitly warned us on several occasions that they think our usage of udev is broken, and that they consider it unsupported. Even more so as time goes on, and udev becomes more and more enmeshed with systemdiocy.
After all, as soon as you select your profile and emerge world, you're already going to have the systemd package (assuming you chose that route) and along with it udev as part of the bundle, so whom exactly does this "default" of openrc with an unsupported udev serve?
AFAICT its only purpose is to provide a political cloak for the other shenanigans, by appealing to the Council's desire that everything is fine with the default (and that udev/systemdbug is not in fact a stalking-horse designed to lock Linux into RH.)
But that's a political war I personally have no desire to fight; though I'd ofc support anyone else looking to lead that charge on the lists.
Quite apart from anything else, I don't have that great a rep with the "developers" as a collective, and ofc that feeling is mutual. ;-)
| tld wrote: | | I don't want systemd interfaces that walk or talk like a systemduck any more than I want systemd itself. Seems sort of like putting duct tape over a hole your neighbor drilled in your fscking wall ;) |
Lol; language please ;) |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Tue Nov 11, 2014 9:43 pm Post subject: |
|
|
Given the "submission of kdbus by GKH" it might be wise to pay attention to this
Note the date and note that with udev-217 firmware loading is removed.
| Quote: | Lennart Poettering lennart at poettering.net
Sat May 31 22:45:17 PDT 2014
On Fri, 30.05.14 04:32, Michael Biebl (mbiebl at gmail.com) wrote:
>
> 2014-05-30 4:26 GMT+02:00 Greg KH <gregkh at linuxfoundation.org>:
>
> > You update systemd but you don't update the kernel? How does that make
> > any sense?
>
> There might be very valid reasons why you need to stick with the old
> kernel. As said, one example could be that the new one simply doesn't
> boot. Requiring lock-step upgrades makes the system less
> fault-tolerant.
> So where possible this should be avoided.
To make this clear, we expect that systemd and kernels are updated in
lockstep. We explicitly do not support really old kernels with really
new systemd. So far we had the focus to support up to 2y old kernels
(which means 3.4 right now), but even that should be taken with a grain
of salt, as we already made clear that soon after kdbus is merged into
the kernel we'll probably make a hard requirement on it from the systemd
side.
I am tempted to say that we should merge the firmware loader removal
patch at the same time as the kdbus requirement is made. As that would
be a clean cut anyway...
Also note that at that point we intend to move udev onto kdbus as
transport, and get rid of the userspace-to-userspace netlink-based
tranport udev used so far. Unless the systemd-haters prepare another
kdbus userspace until then this will effectively also mean that we will
not support non-systemd systems with udev anymore starting at that
point. Gentoo folks, this is your wakeup call.
Lennart
--
Lennart Poettering, Red Hat |
Hmmm
Edit to add: on a side note it sure is interesting that a couple of devs that used to reply us non-stop about sysd seem to have disappeared off the posting map. hmmmmm
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Tue Nov 11, 2014 10:01 pm Post subject: |
|
|
| steveL wrote: | | Technically speaking, a strategic move would be to setup a website to reclaim the projects coopted and then crippled by systemd. pci and usb hw dbs would be the first to address in that context; though aren't they incorporated in eudev now? |
Just remember to stick to *nix tradition, and make the domain name a clever jab at both parts of freedesktop.org (now that it's lost its focus on either...) |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Tue Nov 11, 2014 10:03 pm Post subject: |
|
|
| Anon-E-moose wrote: | Given the "submission of kdbus by GKH" it might be wise to pay attention to this
Note the date and note that with udev-217 firmware loading is removed.
| Quote: | Lennart Poettering lennart at poettering.net
Sat May 31 22:45:17 PDT 2014
On Fri, 30.05.14 04:32, Michael Biebl (mbiebl at gmail.com) wrote:
>
> 2014-05-30 4:26 GMT+02:00 Greg KH <gregkh at linuxfoundation.org>:
>
> > You update systemd but you don't update the kernel? How does that make
> > any sense?
>
> There might be very valid reasons why you need to stick with the old
> kernel. As said, one example could be that the new one simply doesn't
> boot. Requiring lock-step upgrades makes the system less
> fault-tolerant.
> So where possible this should be avoided.
To make this clear, we expect that systemd and kernels are updated in
lockstep. We explicitly do not support really old kernels with really
new systemd. So far we had the focus to support up to 2y old kernels
(which means 3.4 right now), but even that should be taken with a grain
of salt, as we already made clear that soon after kdbus is merged into
the kernel we'll probably make a hard requirement on it from the systemd
side.
I am tempted to say that we should merge the firmware loader removal
patch at the same time as the kdbus requirement is made. As that would
be a clean cut anyway...
Also note that at that point we intend to move udev onto kdbus as
transport, and get rid of the userspace-to-userspace netlink-based
tranport udev used so far. Unless the systemd-haters prepare another
kdbus userspace until then this will effectively also mean that we will
not support non-systemd systems with udev anymore starting at that
point. Gentoo folks, this is your wakeup call.
Lennart
--
Lennart Poettering, Red Hat |
Hmmm |
Does anyone else think that this is something really funny coming from RedHat? I'm at home now, but my system at work, with the newest service-level or RHEL6.5 kernel says something like 2.6.32-431, or some such. I know I'm not at the newest RHEL6.6, let along RHEL7, but you know, that's industry for you. It's going to be really fun watching acceptance of RHEL7.x with an update attitude like this. Something is going to have to give, either the attitude or RHEL market share. But then again, if ALL Linux runs with systemd and this attitude, I suspect the real winner will be MacOS and Windows for desktops, and *BSD for servers. Anyone know if Oracle's Linux has adopted systemd?
In a more real sense, what firmware loader is L.P. planning on removing? Is it confined to udev, kmod itself, or does he actually think he's going to futz around inside the kernel? (Break userspace, unbootable?)
| Anon-E-moose wrote: |
Edit to add: on a side note it sure is interesting that a couple of devs that used to reply us non-stop about sysd seem to have disappeared off the posting map. hmmmmm |
I presume your "couple of devs" are (EDIT - incomplete sentence) some of the systemd proponents?
_________________
.sigs waste space and bandwidth
Last edited by depontius on Tue Nov 11, 2014 10:43 pm; edited 1 time in total |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Tue Nov 11, 2014 10:10 pm Post subject: |
|
|
| depontius wrote: | | In a more real sense, what firmware loader is L.P. planning on removing? Is it confined to udev, kmod itself, or does he actually think he's going to futz around inside the kernel? (Break userspace, unbootable?) |
As of udev 217 firmware loading (by way of udev) has been dropped.
He was only talking about udev, as that's all he controls.
It's almost as if he expected kdbus to sail on smoothly into the kernel, especially after his screed about Linus and the kernel devs a month or so ago.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Jerry_McBride
n00b
Joined: 23 Mar 2004
Posts: 10
|
| Posted: Tue Nov 11, 2014 10:21 pm Post subject: |
|
|
The arrogance of Lennart is breath taking. "Gentoo folks wakeup".
Nothing personal, but screw him.
That's my two cents worth. |
|
| Back to top |
|
|
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Tue Nov 11, 2014 10:25 pm Post subject: |
|
|
| depontius wrote: |
Does anyone else think that this is something really funny coming from RedHat?
|
Absolutely, but so is Fedora coming from RH, in a way, so I guess it kinda figures. I mean who cares, right? RH will have the biggest (beta) testing platform the planet has ever seen as all the distros, millions of users, will be subject to one and the same code. I already see the scenes of human farms from Matrix and all those myriads of bug reports flowing upstream to the Core... |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Tue Nov 11, 2014 10:50 pm Post subject: |
|
|
| GrueXYZ wrote: | | depontius wrote: |
Does anyone else think that this is something really funny coming from RedHat?
|
Absolutely, but so is Fedora coming from RH, in a way, so I guess it kinda figures. I mean who cares, right? RH will have the biggest (beta) testing platform the planet has ever seen as all the distros, millions of users, will be subject to one and the same code. I already see the scenes of human farms from Matrix and all those myriads of bug reports flowing upstream to the Core... |
Fedora is consistent - that's their experimentation platform, the playpen. RHEL isn't. It eventually gets content from Fedora, but eventually can be a long time. Then beyond delays from Fedora into RHEL, there are delays on uptake by industry. Our "leading edge" is currently RHEL6.5, there are a lot of legacy machines still running RHEL5.6, and new machines being deployed with RHEL6.4. Looking at what the CAD tool vendors offer, we're not that far ahead or behind the rest of the industry.
I own some Python code at work, and figured I'd probably be retired before I had to worry about porting it to Python-3.x, and still think that. I may also be retired, or close to it, before company-deployed systemd lands on my desktop.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Tue Nov 11, 2014 11:32 pm Post subject: |
|
|
| GrueXYZ wrote: |
Absolutely, but so is Fedora coming from RH, in a way, so I guess it kinda figures. I mean who cares, right? RH will have the biggest (beta) testing platform the planet has ever seen as all the distros, millions of users, will be subject to one and the same code. I already see the scenes of human farms from Matrix and all those myriads of bug reports flowing upstream to the Core... |
The fun part of all the bugs being directed up to RH, they either get ignored till next patch then mass closed as unsupported or marked as NOT A BUG. RH has a fun thing, that unless it is bleeding edge, it's an unsupported software (thus thrown away and forgotten about). It will be interesting for the hardened team (since I usually don't ever see bleeding edge ever being in hardened). |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Wed Nov 12, 2014 6:21 am Post subject: |
|
|
| steveL wrote: | | And then to rework the desktops so that there is no single desktop bus, but rather a domain-specific API for each area such as email-notification which uses the underlying POSIX API supplied with libc. That would be similar in form and intent to LADSPA, which is a classic example of how to do this right (in design terms). |
Perhaps I'm no expert in system/architecture design when compared to you guys, but I really think this idea sounds promising.
Judging from s6 and other projects of Laurent, he really seems to be following a much saner (at least when compared to LP & Co.) approach in design and implementation of software.
I have seen this discussion and there indeed exists divergence in opinions between him (@skarnet) and the openrc developers.
IMO, his ideas might not be identical to ours, but can at least provide a decent reference.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Wed Nov 12, 2014 6:45 am Post subject: |
|
|
| depontius wrote: | | Anyone know if Oracle's Linux has adopted systemd? |
Even if they have, there will exist companies that sign contracts with them saying "don't install systemd on our machines" 
http://linux.slashdot.org/comments.pl?sid=5802033&cid=48104407
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
Ottre
Tux's lil' helper
Joined: 23 Dec 2012
Posts: 129
|
| Posted: Wed Nov 12, 2014 7:06 am Post subject: |
|
|
Lennart has made a bunch of commits this week to the systemd TODO file.
| Quote: |
merge ~/.local/share and ~/.local/lib into one similar /usr/lib and /usr/share….
when we detect low battery and no AC on boot, show pretty splash and refuse boot
refuse boot if /etc/os-release is missing or /etc/machine-id cannot be set up
|
Don't you think that's a lot of policy decisions for an init system to be making?
Also, check out this line:
| Quote: |
rename "userspace" to "core-os"
|
An init system should be mostly concerned with "early userspace". It shouldn't encompass all of userspace and it certainly shouldn't encompass the "core" of the OS. |
|
| Back to top |
|
|
mayak
n00b
Joined: 16 Jul 2013
Posts: 26
|
|
| Back to top |
|
|
MrFluffy
n00b
Joined: 01 Mar 2011
Posts: 6
|
| Posted: Wed Nov 12, 2014 8:30 am Post subject: |
|
|
I doubt that to be honest, contracts are done by the HR and sales people in organizations large enough to have some financial clout to get bespoke contracts negotiated, the sort of people who know enough about a system at a low enough level for this to be an talking point for are not involved, until the ink has dried and we get handed the turd to polish as best they can, bitter experience as a professional turd polisher suggests. If you know of a large bluechip that operates differently, are they recruiting? can you pm me the name so I can get in ahead of the rush? 
I've done some due diligence as part of my boring corporate whoring, and lets just say slightly political ethical rantings will be absolutely minute compared to the issues this is going to create at an enterprise level, with corporate policies needing rewrites, automated logging systems porting, alarming systems needing end to end retesting, dual journald and syslog solutions on boxes to keep compatibility, leaning on vendors that supply 3rd party tools which hook into syslog (I have visions of lots of "sorry that version is obsolete, we're not supporting it, please buy our upgraded systemd compatible version ") etc. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Wed Nov 12, 2014 11:01 am Post subject: |
|
|
| Ottre wrote: | | An init system should be mostly concerned with "early userspace". It shouldn't encompass all of userspace and it certainly shouldn't encompass the "core" of the OS. |
It's long quit trying to be just an init system.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Wed Nov 12, 2014 11:09 am Post subject: |
|
|
| MrFluffy wrote: |
I doubt that to be honest, contracts are done by the HR and sales people in organizations large enough to have some financial clout to get bespoke contracts negotiated, the sort of people who know enough about a system at a low enough level for this to be an talking point for are not involved, until the ink has dried and we get handed the turd to polish as best they can, bitter experience as a professional turd polisher suggests. If you know of a large bluechip that operates differently, are they recruiting? can you pm me the name so I can get in ahead of the rush?
I've done some due diligence as part of my boring corporate whoring, and lets just say slightly political ethical rantings will be absolutely minute compared to the issues this is going to create at an enterprise level, with corporate policies needing rewrites, automated logging systems porting, alarming systems needing end to end retesting, dual journald and syslog solutions on boxes to keep compatibility, leaning on vendors that supply 3rd party tools which hook into syslog (I have visions of lots of "sorry that version is obsolete, we're not supporting it, please buy our upgraded systemd compatible version ") etc. |
Until the question comes, "Tell me again why did serviceability dropped from six 9's to three?" Think "Task Force", then think blamestorming, then think that this will be done by old-schoolers who had this rammed down their throats. The only way to stop the conclusion is if an executive first gets his ego behind systemd, which as you say is unlikely.
_________________
.sigs waste space and bandwidth |
|
| 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
