| View previous topic :: View next topic |
| Author |
Message |
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
 Posted: Wed Mar 04, 2015 12:52 pm Post subject: |
 |
|
| depontius wrote: | | Naib wrote: | | depontius wrote: | | arnvidr wrote: | | mrsteven wrote: | | I still wonder why any program needs "support" for a particular logger in the first place. |
My thoughts exactly. Not that I particularly care to find out why, but still. |
Because VLC is a desktop program, and probably feels that they need to work with the "new Linux desktop". Behind that, there has been a perfectly functional logging scheme that has worked for Linux and Unix for 30 or 40 years, and of course systemd does logging its own way. |
but why not have its own log file? its not like vlc is a system daemon where logging centrally would make sense. |
I would say again, systemd. VLC doesn't log to syslog today, but I'm guessing that the systemd way is to make more use of systemd, hence logging to systemd.
Has anyone else here ever read "Whipping Star" by Frank Herbert? The resolution at the end of the book reminds me of systemd. |
Its a rhetorical question I guess. It itself has no need to log to the system daemon so why all of a sudden adding support for it, especially as VLC is "cross platform" (linux,windows, android, osx, bsd...) and suddenly they have added in something that VERY platform specific and won't really be duplicated on other systems.
Its not like platform specific interaction "we need to open a file on windows like X but like Y on linux" this is "on linux we will log to the main system logger but on everything else we won't"
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
 |
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Thu Mar 05, 2015 1:24 am Post subject: |
|
|
As for VLC logging to systemd, I'm absolutely certain that the systemd people are very happy to see things like this happen. Makes you wonder if there was a beer involved, real or virtual.
Off to another topic...
From what I understand, CGROUPS in the kernel have always been a bit messy. There has been an effort to clean things up, bringing them back under control. Not content with kdbus, the systemd folks are into the discussion, with the position that of course there should be one master controller for cgroups, and of course it should be systemd, which of course plays well according to its own rules that they've published.
Two interesting pointers into the lkml discussion:
https://lkml.org/lkml/2013/6/22/111
https://lkml.org/lkml/2013/7/2/572
Since I don't choose to run systemd, which makes me a "systemd-hater", I've chosen posts by Tim Hockin of Google and Thomas Gleixner, and old kernel guy.
Funny, I don't think my wife, friends, or even acquaintances would consider me to be a hateful person.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Mar 05, 2015 7:45 am Post subject: |
|
|
| depontius wrote: | | From what I understand, CGROUPS in the kernel have always been a bit messy. There has been an effort to clean things up, bringing them back under control. |
I don't really buy that argument; cgroups are as messy as the admin wants them to be.
| Quote: | | Not content with kdbus, the systemd folks are into the discussion, with the position that of course there should be one master controller for cgroups, and of course it should be systemd, which of course plays well according to its own rules that they've published. |
Which to me just reads as: "crippling cgroups for any other usage, just like we crippled userland projects" such as udisks, upower, udev, hwids..
Thanks; I found this post to sum it up.
| James Bottomley wrote: | Where we are is that the current APIs may be messy, but they support all use cases and all container structure policies.
If anyone, systemd included, wants to do a new API, it must support all use cases as well.
Ideally, it should be agreed to and in the kernel as well rather than having some userspace filter.
|
From where I'm sitting, cgroups as-is are fine. What would be good is a "delete-on-empty" and a "delete-and-notify" semantic, in addition to "notify-on-empty" which is more in line with their original exposure to kernel-code, and not so useful for userland.
However instead of that simple change being made, which would be useful under any init-system, we instead get more politicking by RedHat and the systemdidiots (Sievers: cos bitchiness always works.)
| Quote: | Since I don't choose to run systemd, which makes me a "systemd-hater", I've chosen posts by Tim Hockin of Google and Thomas Gleixner, and old kernel guy.
Funny, I don't think my wife, friends, or even acquaintances would consider me to be a hateful person. |
Well, we're in lala-land, where even Alice wouldn't know how to cope.. ;)
edit: s/delete-on-notify/delete-on-empty/
Last edited by steveL on Thu Mar 05, 2015 12:00 pm; edited 1 time in total |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Thu Mar 05, 2015 10:53 am Post subject: |
|
|
My understanding of cgroups re the kernel (admittedly shallow as I don't even have them enabled and don't follow them in depth)
is that the old way was going to stay, too much breakage (and we know Linus' view on that) but that a new cgroup system (api or whatever)
would be put in alongside it. Call them versions 1 and 2 or whatever.
_________________
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: Thu Mar 05, 2015 11:53 am Post subject: |
|
|
| Anon-E-moose wrote: | My understanding of cgroups re the kernel (admittedly shallow as I don't even have them enabled and don't follow them in depth)
is that the old way was going to stay, too much breakage (and we know Linus' view on that) but that a new cgroup system (api or whatever)
would be put in alongside it. Call them versions 1 and 2 or whatever. |
I rather like the old way, since it simply exposes the knobs and leaves it to root to tweak them.
As such, any "convenience" API really belongs in userland, as one of N methods to tweak the kernel, not the One True Master NSA Control Method shipped with the kernel sources.
Especially when one considers the myriad uses the existing kernel ABI is already being put to, it just doesn't make sense to "fix" what ain't broken, just to support vendor lock-in, which is hardly the Linux style.
Sure, it makes sense to support a sane convenience ABI in userland; but that would necessarily be a different project to systemdbug. It would be more along the lines of LADSPA, than that mess.
The only thing it could possibly require from kernel-side, is "delete-on-empty", mainly as a basis for "delete-and-exec" (for notification) to close the possibility of races. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Thu Mar 05, 2015 12:13 pm Post subject: |
|
|
Having just read all the back and forth on the mailing list, the main point for changing is that "too many" knobs are exposed
to non root processes, even if root starts the ball rolling.
I've heard it said in the past that the whole cgroup code was thrown together by people who weren't kernel devs
and the kernel devs were too busy with other things at the time to properly vet the code and all the ramifications
and thus some of the problems (from a kernel perspective) in enhancing/changing the existing code.
But it was brought out that the existing interface would be around "for years" so any changes would not be immediate.
And as far as sysd being the one true ruler, there's google and others who aren't buying into that whole argument.
So I doubt very seriously that it will happen the way the cabal thinks it will, which IMO also applies to kdbus.
Anyway thanks (to whoever) for the original links, it was an interesting read.
_________________
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
|
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Fri Mar 06, 2015 12:05 pm Post subject: |
|
|
Anyone that doesn't know how to write portable code isn't a coder IMO.
Any section of code that needs to be specific whether sysv, linux, bsd, windows should be factored out into it's own area
then one ifdef will select what's needed.
One of the earliest projects was in converting proprietary code for a company to run on what we would call standard unix.
I very carefully separated out areas, like the database stuff (oracle at the time) so that it could be replaced by any other
database if you simply used the interfaces that I put in place.
Very much how linux is done, the published external interface stays the same, the internals could be changed.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Fri Mar 06, 2015 12:17 pm Post subject: |
|
|
| Quote: |
I am not making things difficult: you are yourself making things
difficult. Debian kFreeBSD is a toy OS. About 10 people on this earth
use it. About 0.4 of those probably run GNOME on it. Of that half a
person only about 0.2 probably expect it to work properly.
I am not sure why you ask me to care about your interest into toy
OSes. I am not sure why you think that your interest in toy OSes should
set the agenda for GNOME. |
lol
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Mar 06, 2015 2:19 pm Post subject: |
|
|
| Anon-E-moose wrote: | Having just read all the back and forth on the mailing list, the main point for changing is that "too many" knobs are exposed
to non root processes, even if root starts the ball rolling. |
I don't understand; that sounds like a permissions problem, ie userland policy, rather than anything else.
| Quote: | I've heard it said in the past that the whole cgroup code was thrown together by people who weren't kernel devs
and the kernel devs were too busy with other things at the time to properly vet the code and all the ramifications
and thus some of the problems (from a kernel perspective) in enhancing/changing the existing code. |
I see it a bit like dtrace or kprobes; if you don't know what you're doing, you can screw your machine. But that's always been the Unix way: if you have permission, it doesn't stop you doing stupid things, since that would stop you doing clever things.
I can't speak to "changes to existing code", since I don't know the kernel code, nor where the changes would take place.
It just seems to me that the objections are more to do with usage, than mechanism, and amount to shielding root from oneself, which is never a good path to take. The base functionality of a meta-session that a process cannot escape, is relatively solid and a simple notion, and the semantics of resource usage are already ingrained into the kernel (or accounting could never happen, nor indeed scheduling.) |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Mar 07, 2015 2:02 pm Post subject: |
|
|
WRT cgroups being "bolted-on" to the kernel, here's a decent article on it.
If we take a look at one example, it's clear firstly that it wasn't done very well, but also that the necessary changes have been made, in that subsystem (one of the most critical) at least.
As Corbet says in that latter piece: | Jonathan Corbet wrote: | | In the real world, removing control groups is an increasingly difficult thing to do, so it makes sense to consider the alternative: fixing them. |
In the former, we see the reasoning behind munging the useful existing functionality (a step which I think would be a regression):
| Quote: | | The real complaint with multiple hierarchies, though, is that few developers seem to see the feature as being useful in actual, deployed systems. |
The reason I think this is a bad idea, is that developers are not users, and coders are typically awful at seeing all the myriad uses that people get up to. By all means discuss use-cases, and how best to implement them, but sometimes you just have to bite the bullet and deliver what people actually want:
| Cyberax wrote: | I'm using multiple control groups and I like it. For example, it makes perfect sense to categorize processes based on network policy (i.e. processes that can create connections, that can create listening sockets, etc.) with completely parallel tree maintained by systemd.
That's a great feature and I'd be disappointed if it went away. |
| cmccabe wrote: | | Removing multiple-hierarchy support would be an amazingly bad idea. It would force system administrators to put all their tasks into one giant rigid hierarchy, removing all flexibility. It would also make a lot of configurations impossible. |
Essentially what it amounts to is not fulfilling the actual use-case that cgroups were invented for, imo: allowing the admin to partition parts of the process tree, in line with policy configuration, which is not our place to either question, nor dictate: only provide mechanism to implement.
| Quote: | | The block I/O controller, for example, only finished the job with hierarchical support last year; others still have not done it. Making the system work properly, Tejun said, requires getting all of the controllers to treat the hierarchy in the same way. |
To my mind, the only proper response is to get on and do it; in the interim Linux admins are a bit like Gentoo users: much more in touch with the upstream codebase than the norm. So it's on them not to mess up their own machines (no change there, then) and also to provide the feedback and QA which are why FLOSS works so well.
edit:
| Poeterring wrote: | In the long run there's only going to be a single kernel cgroup hierarchy.. This hierarchy becomes private property of systemd. systemd will set it up. Systemd will maintain it. Systemd will rearrange it. Other software that wants to make use of cgroups can do so only through systemd's APIs.
We will take away the ability for the admin to set low-level attributes, to arrange things in cgroup trees or to enable controllers for a service. |
[removed value-laden "arbitrary"]
*facepalm* Talk about delusions of grandeur, and the Master Control Program agenda.. |
|
| Back to top |
|
|
truekaiser
l33t
Joined: 05 Mar 2004
Posts: 801
|
| Posted: Sat Mar 07, 2015 7:24 pm Post subject: |
|
|
Wait, let me get this straight. VLC, a media playing application, wants to hook itself into the SYSTEM logger for systemD?
Is logging to an error file in your home dir not enough? or just plain /var/log ?? |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Sat Mar 07, 2015 7:55 pm Post subject: |
|
|
| truekaiser wrote: | Wait, let me get this straight. VLC, a media playing application, wants to hook itself into the SYSTEM logger for systemD?
Is logging to an error file in your home dir not enough? or just plain /var/log ?? |
I suspect more to the point, the SYSTEM logger for systemD wants VLC to hook itself into it. That way, VLC will work best with systemD - a previously stated desire by the systemD folk.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Sat Mar 07, 2015 8:36 pm Post subject: |
|
|
| depontius wrote: | | truekaiser wrote: | Wait, let me get this straight. VLC, a media playing application, wants to hook itself into the SYSTEM logger for systemD?
Is logging to an error file in your home dir not enough? or just plain /var/log ?? |
I suspect more to the point, the SYSTEM logger for systemD wants VLC to hook itself into it. That way, VLC will work best with systemD - a previously stated desire by the systemD folk. |
And it will probably he heavily used as propaganda material "the popular cross-platform media player VLC makes extensive use of systemd's advanced logging capability to ensure atomic commits and clarity to assist in faultfinding"
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Sun Mar 08, 2015 1:32 pm Post subject: |
|
|
| truekaiser wrote: | Wait, let me get this straight. VLC, a media playing application, wants to hook itself into the SYSTEM logger for systemD?
Is logging to an error file in your home dir not enough? or just plain /var/log ?? |
I'm not sure I'd want a video player program to log anywhere. I can see it with a complex system like MythTV, but a stand alone player??....and doing so by utilizing one of the most ill-designed, broken features of systemd no less??...and they announce it like I'm supposed to be impressed...
The open source community has just lost it collective mind...I swear. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Sun Mar 08, 2015 1:48 pm Post subject: |
|
|
| tld wrote: |
The open source community has just lost it collective mind...I swear. |
Keep in mind my pet hypothesis that what we're seeing here is a mass influx of Windows users and developers. The "collective mind" has just been overwhelmed by people out of their comfort zone, and bringing the Windows comforts with them.
Be careful what you ask for, you may get it.
Linux has been asking for years for a bigger market share. without thinking of the unintended consequences.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Sun Mar 08, 2015 3:09 pm Post subject: |
|
|
Out of curiosity, where does VLC log its messages in the case of Windows? Does it use Windows' Applications and Services Logs, viewable using Windows' Event Viewer? Because that would be analogous to using systemd's Journal in Linux.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3136
|
| Posted: Sun Mar 08, 2015 3:27 pm Post subject: |
|
|
Uhm.... Where does notepad log it's messages?
Considering it's an interactive, single user application that loses it's purpose when user is not present, why would it need anything else than standard error (terminal) or big-ugly-message-box-with-OK-button stating that something-bad-happened-check-manual-for-errorcode-XXX?
Oh, and what about portable version which should not leave any trace in the system temporarly running it? |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Sun Mar 08, 2015 3:34 pm Post subject: |
|
|
| Fitzcarraldo wrote: | | Out of curiosity, where does VLC log its messages in the case of Windows? Does it use Windows' Applications and Services Logs, viewable using Windows' Event Viewer? Because that would be analogous to using systemd's Journal in Linux. |
it doesn't, because a general user should not have access to the system logs. So if VLC logged to the windows event service, the user would not be able to debug...
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Sun Mar 08, 2015 3:40 pm Post subject: |
|
|
| Fitzcarraldo wrote: | | Out of curiosity, where does VLC log its messages in the case of Windows? Does it use Windows' Applications and Services Logs, viewable using Windows' Event Viewer? Because that would be analogous to using systemd's Journal in Linux. |
I've just checked VLC in Windows, to answer my own question. Tools > Messages takes the user to a dialogue window where it is possible to select the verbosity (0 = errors; 1 = warning; 2 = debug) and specify the log file name (with a .log or .txt suffix). So in Windows VLC does not use the operating system's event logger. In which case I wonder why the VLC developers felt the need to do it in Linux.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Sun Mar 08, 2015 3:46 pm Post subject: |
|
|
| Naib wrote: | | Fitzcarraldo wrote: | | Out of curiosity, where does VLC log its messages in the case of Windows? Does it use Windows' Applications and Services Logs, viewable using Windows' Event Viewer? Because that would be analogous to using systemd's Journal in Linux. |
it doesn't, because a general user should not have access to the system logs. So if VLC logged to the windows event service, the user would not be able to debug... |
I've just checked in Windows 8.1 and a user who is not an administrator does have access to Windows' Applications and Services Logs via Windows' Event Viewer.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Sun Mar 08, 2015 6:31 pm Post subject: |
|
|
| szatox wrote: | Uhm.... Where does notepad log it's messages?
Considering it's an interactive, single user application that loses it's purpose when user is not present, why would it need anything else than standard error (terminal) or big-ugly-message-box-with-OK-button stating that something-bad-happened-check-manual-for-errorcode-XXX?
Oh, and what about portable version which should not leave any trace in the system temporarly running it? |
VLC can be used as an unattended streaming server (see e.g. http://www.videolan.org/vlc/streaming.html), so I can see why logging debugging and/or warning and/or error messages to a log file would be useful. But that, in itself, does not mean it has to log it to the operating system's log. It could use its own log file.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Sun Mar 08, 2015 7:59 pm Post subject: |
|
|
| Fitzcarraldo wrote: | | So in Windows VLC does not use the operating system's event logger. In which case I wonder why the VLC developers felt the need to do it in Linux. |
Again, I'm sure that there was encouragement to do this from the systemd developers - to make sure that systemd was the best platform for VLC.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Sun Mar 08, 2015 9:11 pm Post subject: |
|
|
| depontius wrote: | | Linux has been asking for years for a bigger market share. without thinking of the unintended consequences. |
I've wondered for a long time just exactly who it is, other than commercial interests, who actually cares how many people adopt Linux. For those of us who actually care about the real quality of the OS, the concern should be around how many developers it attracts. Somehow turning Linux into Wiindows doesn't seem like a plan to promote that if you ask me. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Mar 09, 2015 5:27 am Post subject: |
|
|
| tld wrote: | | I've wondered for a long time just exactly who it is, other than commercial interests, who actually cares how many people adopt Linux. For those of us who actually care about the real quality of the OS, the concern should be around how many developers it attracts. Somehow turning Linux into Wiindows doesn't seem like a plan to promote that if you ask me. |
IDK, I think you want programmers and users, both. "Developers" seems to be FLOSS-speek for "Enterprise Consultants" in the business world, aka new graduates (many of whom think they're going to be the next Bill Gates, so it doesn't matter that they didn't actually do any CS at all.)
End-users don't tend to be the ones getting us into trouble, from what I've seen. Nor do admins (which is essentially the skill-level of most Gentoo users, certainly the ones maintaining it on real hardware.)
As someone pointed out to me, it's all okay though, since:
"The most powerful force in the universe is free labour, wearing your corporate tee-shirt, and singing along." |
|
| 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
