Re: [DNG] Multiple chromium mystery processes
Quoting goli...@dyne.org (goli...@dyne.org): > I just noticed that chromium has started spawning multiple PIDs that > start with this string: > > PID chromium --type=renderer --field-trial-handle=1 > --primordial-pipe-token= and on and on including lots of number > sequences. [...] > I searched a bit, and gather that this is phoning home with who > knows what information about my habits. That can't be a good thing. > Does anyone know how to kill it? Is there something comparable to > about:config in chromium? Possibly you've already seen http://raeknowler.com/wtf-chromium . That doesn't have a solution, exactly, but does provide more detail. Also, https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/6V-OhvCMxJE/EZR_jpPFCAAJ says: While I believe you cannot disable field trials altogether, you can at least identify them by going to chrome://net-internals/#capture and clicking on "Stop". The "Active Field Trial Groups" shows their names. Then, I believe you can disable them one by one (or create a script that takes the names and creates a command line disabling all of them) using some command flag. (Of course, in case it does not list all of the available (not necessarily enabled) field trials, then some field trial may be added the next time you launch Chrome. Wash, rinse, repeat) 'T'would be nice if the De??an package maintainer performed an experimentecetomy. Seems like there's an 'ungoogled-chromium' fork that has this covered: https://github.com/Eloston/ungoogled-chromium/blob/master/patches/bromite/disable-fetching-field-trials.patch https://github.com/Eloston/ungoogled-chromium They claim to have functional builds for Stretch and Buster. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Multiple chromium mystery processes
Sent from ProtonMail, encrypted email based in Switzerland. ‐‐‐ Original Message ‐‐‐ On Wednesday, 19 December 2018 22:30, wrote: > I just noticed that chromium has started spawning multiple PIDs that > start with this string: > > PID chromium --type=renderer --field-trial-handle=1 > --primordial-pipe-token= and on and on including lots of number > sequences. > > The complete string goes on for several page widths of my rather large > monitor. For every PID I kill, another one (or two) pops up. I > currently have about 15 with this prefix running and they all seem to be > sleeping. But I have had them peg out a core to 100%. > > I searched a bit, and gather that this is phoning home with who knows > what information about my habits. That can't be a good thing. Does > anyone know how to kill it? Is there something comparable to > about:config in chromium? > > Version 57.0.2987.98 Built on 8.7 > > Thanks, > > golinux > > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng about:about will show a list of config pages. Where you go from there, I've no idea. Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Multiple chromium mystery processes
I just noticed that chromium has started spawning multiple PIDs that start with this string: PID chromium --type=renderer --field-trial-handle=1 --primordial-pipe-token= and on and on including lots of number sequences. The complete string goes on for several page widths of my rather large monitor. For every PID I kill, another one (or two) pops up. I currently have about 15 with this prefix running and they all seem to be sleeping. But I have had them peg out a core to 100%. I searched a bit, and gather that this is phoning home with who knows what information about my habits. That can't be a good thing. Does anyone know how to kill it? Is there something comparable to about:config in chromium? Version 57.0.2987.98 Built on 8.7 Thanks, golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Drive-by critique
Quoting Steve Litt (sl...@troubleshooters.com): > I agree. The more GNU/Linux blows off prospective users by making them > jump through hoops, the more Linux becomes a niche. The nichier Linux > becomes, the more the hardware manufacturers ignore it. Let GNU/Linux > get up to 25% on the desktop, and the manufacturers will provide good > drivers for everything they make. I hope you won't mind my differing strongly with the premise of this line of reasoning -- and also with its conclusion. First (as to the conclusion), empirically I find that Linux support for hardware is quite good, and on balance better than it was in olden days. But that's the lesser point I wanted to make: The larger is that you're ignoring a huge difference between proprietary and open-source operating systems, and also a unique advantage that Microsoft Corporation enjoys (control of the OEMs via coop marketing) for its OSes. Microsoft offers to hardware manufacturers (as does Apple and the other surviving proprietary Unix companies) the huge advantage of them furnishing (generally buggy, poorly documented, difficult or impossible to maintain) driver code with the source provided, if at all, under NDA. This is a motivator because hardware manufacturers tend to regard detailed information about their hardware, such as would be exposed by source-available drivers, as a closely held trade secret. (Moreover, it's known that some such manufacturers outsource driver authorship to other firms as one-off contract work, and end up lacking expertise -- and sometimes lacking source code.) Linux _could_ offer the same attraction -- through the tiny little ;-> change of abandoning open source. Absent that abandonment of our founding principles, a sizeable percentage of Linux hardware drivers get created using reverse-engineering with little or no manufacturer cooperation. The number of Linux desktop users has no effect on this dynamic. The unique advantage Microsoft has is its 'coop marketing' program: favoured OEMs' advertising costs are very heavily subsidised by Microsoft Corporation, forming a very significant percentage of revenues of goods sold. This perpetuate the preload monopoly, and ensures that hardware manufacturers are motivated to keep hurling driver code over the transom to stay in the game (even though the resulting code usually sucks) without Microsoft needing to do any work. And, again, desktop headcount has zero effect on this dynamic. I can hazard a guess about why I keep hearing this 'desktop mindshare' argument with no recognition of the vital differences that make it pretty much inapplicable: It's a leftover, reflexive proprietary-OS way of thinking (or, to be blunt, of not thinking). Free your mind, Steve. ;-> ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ifstat.eth0 on Boot [SOLVED]
Le 18/12/2018 à 14:06, Michael K. a écrit : !Ola outra vez! and: sorry for delay ... (to be ill) Am 10.12.18 um 16:26 schrieb Didier Kryn: don't ask me why, I don't know, but it works. OK, *Big Thanks* for Help and the Script. *Yes! it work's for me* Happy Hollyday's @all (whatever you celebrate) Seems it can only work for one user because now it doesn't work for me any more (~: In the mean time I've made some changes to control what I was writing and it seems I can't restore a working config. Must be pretty touchy. I'm now wildly hacking my interfaces file and slightly the startup script. My eth0 gets sometimes configured, plus an additional eth0.avahi even when there's no cable plugged in and my wlan0 configured with wpa-roam doesn't come up anymore. I have now changed my wlan0 interface config to be completely manual - experimenting... I hope I can reach some better understanding and report it. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Trouble with .onion addresses?
I'm all of a sudden having trouble using the .onion addresses. They've worked fine for me for months. I'm getting "could not connect to devuanfwojg73k6r.onion (0.0.0.0:0) due to: Host unreachable (6)" Is anyone else having this trouble? Thanks! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Installing without rebooting
There is this notion of "kexec boot"; I've never tried it, but it's documentation claims "kexec is a system call that enables you to load and boot into another kernel from the currently running kernel." Maybe it comes with too many ifs and buts to be a viable approach. Ralph. k...@aspodata.se wrote on 20/12/18 00:36: > Hendrik: >> On Wed, Dec 19, 2018 at 12:09:29AM -0500, Steve Litt wrote: >>> On Tue, 18 Dec 2018 23:33:30 +0100 (CET) >>> k...@aspodata.se wrote: >>> With all this discussion about installing procedures, why do we need to reboot during reboot ? > I meant: to reboot during install ? Couldn't one boot the install media like an initram thing and then pivot_root (or what is used today) the real system and continuing from there... > ... >> It's not possible to pivot_root away from the install USB to the >> installed root system on rotating rust (or whatever permannt storage >> the computer has? > > Ok. > >> Does this have anything to do with initramfs? > > Possibly not, but initramfs/initrd does that all the times, i.e. > during boot, do something and then switch to installed system. > >> It would probably constrain the installer to use the same kernel as the >> installee, though. Which means lots of installer versions. > > Yes, but this was meant as a "research" project, is it possible and if > so, what are the consequences. > > /// > > One possible way to test this could be to have a greatly simplified > installer in an initramfs/initrd, which basically does a "precompiled" > install to a known system, and then switches to it and possible > continues from that. > > Regards, > /Karl Hammar > > --- > Aspö Data > Lilla Aspö 148 > S-742 94 Östhammar > Sweden > > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Installing without rebooting
Hendrik: > On Wed, Dec 19, 2018 at 12:09:29AM -0500, Steve Litt wrote: > > On Tue, 18 Dec 2018 23:33:30 +0100 (CET) > > k...@aspodata.se wrote: > > > > > With all this discussion about installing procedures, why do we need > > > to reboot during reboot ? I meant: to reboot during install ? > > > Couldn't one boot the install media like an initram thing and then > > > pivot_root (or what is used today) the real system and continuing > > > from there... ... > It's not possible to pivot_root away from the install USB to the > installed root system on rotating rust (or whatever permannt storage > the computer has? Ok. > Does this have anything to do with initramfs? Possibly not, but initramfs/initrd does that all the times, i.e. during boot, do something and then switch to installed system. > It would probably constrain the installer to use the same kernel as the > installee, though. Which means lots of installer versions. Yes, but this was meant as a "research" project, is it possible and if so, what are the consequences. /// One possible way to test this could be to have a greatly simplified installer in an initramfs/initrd, which basically does a "precompiled" install to a known system, and then switches to it and possible continues from that. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Installing without rebooting
On Wed, Dec 19, 2018 at 12:09:29AM -0500, Steve Litt wrote: > On Tue, 18 Dec 2018 23:33:30 +0100 (CET) > k...@aspodata.se wrote: > > > With all this discussion about installing procedures, why do we need > > to reboot during reboot ? > > > > Couldn't one boot the install media like an initram thing and then > > pivot_root (or what is used today) the real system and continuing > > from there... > > I don't ever want to encourage use of initramfs. Down that road lies > Redhat. It's not possible to pivot_root away from the install USB to the installed root system on rotating rust (or whatever permannt storage the computer has? Does this have anything to do with initramfs? It would probably constrain the installer to use the same kernel as the installee, though. Which means lots of installer versions. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Installing without rebooting
Bruce Perens: > Because you're not necessarily installing the same API. And by API, you mean the system calls that the used kernel make available and the clib used ? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Installing without rebooting
Steve Litt: ... > I don't ever want to encourage use of initramfs. Down that road lies > Redhat. ... It's a tool in the toolbox, useful sometimes and not necessary sometimes. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] No dependency packages in ASCII repo for nvidia's xorg-video-driver.
On Wed, Dec 19, 2018 at 04:35:39PM +0700, Андрей via Dng wrote: > Приветствую. > > > How to solve problem of installing nvidia xorg-video-driver, when > aptitude says that in ASCII repo no one of: > > nvidia-installer-cleanup > nvidia-support > glx-alternative-nvidia > > packages? Thank you for advice. > Please use https://pkginfo.devuan.org: https://pkginfo.devuan.org/stage/ascii/ascii/nvidia-installer-cleanup_20151021+4.html You need to add "contrib" and "non-free" to your sources.list. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] No dependency packages in ASCII repo for nvidia's xorg-video-driver.
Приветствую. How to solve problem of installing nvidia xorg-video-driver, when aptitude says that in ASCII repo no one of: nvidia-installer-cleanup nvidia-support glx-alternative-nvidia packages? Thank you for advice. Андрей. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
