Announcement
Collapse
No announcement yet.
Debian May Be Leaning Towards Systemd Over Upstart
Collapse
X
-
Yes the first thing is you must learn actually what is the problem behind the reason the find solution or need to support from other.
-
sry if i came on too hard in last post
just i don't see a big problem with using standard tools and kernel provided things
edit: i see a problem
cat can be killed with a couple char's in buffer
solution, dd if=/that/fifo of=/that/log bs=1Last edited by gens; 22 January 2014, 09:48 AM.
Leave a comment:
-
Originally posted by bkor View PostThat's not the same functionality. If you redirect the output to a file, it will forever go to that file. So good luck with logrotate and so on. Obviously you could add yet another program inbetween to solve that. But at one point it is better to just see that the way to solve it is by handling this in the init system and all other solutions might work, but are just hacks/unreliable.
I have the following issue: I have an application, which continuously produces output to stderr and stdout. The output of this application is captured in a logfile (the app is redirected as: &...
dosen't seem unreliable to me
you see something that could break ?
i think maybe it could be done without cat
maybe "it is better to just see"
thinking hurtsLast edited by gens; 22 January 2014, 09:13 AM.
Leave a comment:
-
Originally posted by peppepz View PostThe subshell is just an example to show that even something as dumb as a bash shell can capture the standard error of a daemon and save it to a file. So saying that this is a "real problem that can only be solved by putting code in PID 1" is simply not true. Which does not mean that putting code in PID 1 is wrong. What is wrong is stating it as inevitable.
Leave a comment:
-
Originally posted by Ericg View PostYou can rip out the logind requirement, the developers specifically not (see the other user's post like 1 or 2 above me). MORE specifically though... Gnome doesn't actually require -LOGIND- what it requires are the dbus interfaces that currently only logind provides.
During development you need something to be aligned with. Systemd maintainers you can work with. You know the roadmap, plans, objections, etc. So you can explain your needs and they'll work on it. For Upstart option, the answer basically is "we maintain the fork". So what'll happen in practice is that GNOME will continue to work with systemd developers. Then we have no other option than to assume that Upstart option duplicates whatever has been done within the systemd project.
Above sounds like a totally insane way to work IMO. Way easier for Debian to use systemd. Choosing Upstart means consciously choosing to be behind in the latest developments. And this is not due to forcing, it is due to the lack of cooperation and development in Upstart. Further, it is not really needed, loads of people (distributions, systemd developers, developers from other projects, low level stack developers) are already working together under the systemd name.
Leave a comment:
-
Originally posted by JX8p View PostSystemd as Debian's new init-system of choice has probably just been dealt its fatal blow as upstart is preliminarily working with kFreeBSD. Given the immature refusal of Poettering to even accept any patches allowing systemd to run on other platforms, which is vulgarly defiant of Debian's stated aims, one assumes they will be leaning towards upstart once more.
Basically, all the committee are accepting of the idea that while the continued existence of the BSD and Hurd variants is important, it's of secondary importance to doing the right thing on Linux, even if that means having different default init systems on Linux and other. It's increasingly looking like their decision will be to go with Systemd on Linux, and Upstart on the other two...
Leave a comment:
-
Originally posted by Siuoq View PostGNOME requires logind for some reason, therefore they requires systemd as PID 1 well. systemd is the bug you mentioned.
Thats the beauty of it, you don't depend specifically upon logind, you depend upon the dbus interfaces it provides. Then if something else wants to provide them and do it in a non-breaking manner, then its just a drop-in replacement
Leave a comment:
-
Originally posted by Siuoq View PostGNOME requires logind for some reason, therefore they requires systemd as PID 1 well. systemd is the bug you mentioned.
In addition: https://wiki.gnome.org/ThreePointEle...emdUserSession
Originally posted by Colin WaltersIt's important to note that with these patches, we still support non-systemd systems (as well as older systemd). How far into the future we do so is an open question, but it should not be too difficult to leave non-systemd systems with the previous model over the next few cycles.
Leave a comment:
-
Originally posted by GreatEmerald View PostNice, I'm glad to hear that the technical committee are making technical choices.
technical means, they should decide in technical question. Obviously they should find the solution what is the best for Debian Project, and not, which program is technically better
Originally posted by AdamW View PostYou...really can't simplify things that much.
It's not like there is a single systemd process running which does init, and journalling, and everything else. Just because the functions are part of one *project* doesn't mean they're part of one *code path*. It's not like a bug in systemd's journalling code will inevitably break your init sequence. Functions can be isolated from each other without being part of completely different development projects.
Leave a comment:
Leave a comment: