Re: [gentoo-user] Recommended CDR-Burning-frontend without QT and without KDE?
tu...@posteo.de wrote: is it possible to run xcdroast without root ( i.e. user root or suid )? The first time you need to run it as root to enable non-root mode, it sets suid on some files (or asks you to, I don't remember), afterwards you can run as regular user. So the answer to your question is yes and no. raffaele
Re: [gentoo-user] SOLVED Building mongodb-3.4.2 scons error
On 03/12/17 19:12, Dick Middleton wrote: It turns out that the error is caused by ABI incompatibilities in the object code generated by different versions of gcc compiler. I thought I'd fixed this earlier by running revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc before emerging mongodb. It seems that wasn't the case and some mongodb dependencies were overlooked. I ran the command again and mongodb compile completed without errors. Dick
Re: [gentoo-user] Recommended CDR-Burning-frontend without QT and without KDE?
wrote: > is it possible to run xcdroast without root ( i.e. user root or suid > )? Unfortunately xcdroast did miss that Linux finally implemented working support for fine grained privileges 4 years ago. In theory, you should be able to convert the suid wrapper it installs into a no-op wrapper to make it happy and use cdrtools-binaries that are installed via "setcap". Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
[gentoo-user] Re: How am I supposed to block the KDE update?
On 03/15/2017 07:38 AM, J. Roeleveld wrote: On March 14, 2017 6:05:17 PM GMT+01:00, Nikos Chantziaras wrote: (The issue was that hovering over icons or other items would highlight them but they would stay highlighted forever even after the mouse moved somewhere else or even if you click somewhere else. So everything would be full of highlighted icons.) I have seen this happen on MS Windows machines. (Customer supplied ones) I think it is related to some accessibility thing that accidentally gets enabled. (I simply reboot Windows as I prefer not to fight my way through a stupidly locked down system) Could be a similar cause with your KDE/Plasma issue? Nope. It was a bug that indeed got fixed in the plasma-5.32.0-r1 revbump.
[gentoo-user] Steam downloading extremely
Hi guys, I just got Steam installed and running successfully on my machine, and tried to get CS:GO running smoothly, which made me really happy :-D However when Steam is downloading games, the speed is extremely slow, down to several KB/s, even some bytes/s. I have already installed dnsmasq and it *was* good during downloading CS:GO (~4MB/s), but became slow again with Civilization V. I googled a lot but all point to installing dnsmasq, which I don't think is really helpful since I already have done that... Also I'm sure downloading region is correct. Anybody experienced the same issue with dnsmasq installed? Any clue is welcome and thanks in advance. Danny
Re: [gentoo-user] Steam downloading extremely
Hi guy, Am Mittwoch, 15. März 2017, 14:24:10 CET schrieb Danny YUE: > Hi guys, > > I just got Steam installed and running successfully on my machine, > and tried to get CS:GO running smoothly, which made me really happy :-D nice to hear, have fun with that! > However when Steam is downloading games, the speed is extremely slow, > down to several KB/s, even some bytes/s. > I have already installed dnsmasq and it *was* good during downloading > CS:GO (~4MB/s), but became slow again with Civilization V. > > I googled a lot but all point to installing dnsmasq, which I don't think > is really helpful since I already have done that... Just installing dnsmasq doesn’t change anything, and just starting it does neither. I *assume* you did set it up as a local DNS cache, but please provide some information about it: - the source of the information, i.e. link to the page - your setup: * dnsmasq config * /etc/resolv.conf * other configs you think that matter here > Also I'm sure downloading region is correct. > > Anybody experienced the same issue with dnsmasq installed? > Any clue is welcome and thanks in advance. > > > Danny Nils -- GPG fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B' Nils Freydank signature.asc Description: This is a digitally signed message part.
[gentoo-user] Latest LLVM wants to pollute my machine with VIM stuff.....
Hi all, I'm still trying to come to grips with understanding ebuilds so please bear with me if this is a simple question. I've just sync'd and then done an emerge --ask -NuD world I have LLVM/clang installed and upon browsing the updates saw app-vim/llvm-vim. This is some sort of syntax highlighting thingy for Vim. I don't have Vim installed so went into the llvm-4.0.0 ebuild and saw the line PDEPEND="app-vim/llvm-vim My understanding is that PDEPEND means that something, in this case llvm-vim, will be installed after the update of llvm - correct? If so, I can't see any way of "turning this off" as I don't want even more junk installed on my machine. Have I understood the ebuild correctly and it could do with a "fiddle" so that it doesn't force this install? Regards, Andrew
[gentoo-user] locate can not find a file
Yes, I run as root: updatedb But when run: locate consent_extraction* It only list one file: /home/fd/consent_extraction1.pdf (this is a link file) /home/fd/business/forms/consent_extraction1.pdf It can not find: "consent_extraction.pdf" both files are in same directory ll business/forms/ total 688 ... -rw-r--r-- 1 fd fd 63032 Mar 15 08:52 consent_extraction1.pdf -rw-r--r-- 1 fd fd 397649 Mar 14 20:05 consent_extraction.pdf I observe the same behaviour on my local machine and remote machine. Running "find" finds both files find . -name '*consent_extraction*' ./business/forms/consent_extraction.pdf ./business/forms/consent_extraction1.pdf ./consent_extraction1.pdf Why? -- Thelma
Re: [gentoo-user] Latest LLVM wants to pollute my machine with VIM stuff.....
On Wed, 15 Mar 2017 22:33:10 +0800, Andrew Lowe wrote: > I have LLVM/clang installed and upon browsing the updates saw > app-vim/llvm-vim. This is some sort of syntax highlighting thingy for > Vim. I don't have Vim installed so went into the llvm-4.0.0 ebuild and > saw the line > > PDEPEND="app-vim/llvm-vim > > My understanding is that PDEPEND means that something, in this case > llvm-vim, will be installed after the update of llvm - correct? That's right. > If so, > I can't see any way of "turning this off" as I don't want even more > junk installed on my machine. It is a fixed dependency, so the ebuild maintainer considers it compulsory. > Have I understood the ebuild correctly and it could do with a > "fiddle" so that it doesn't force this install? You can remove the dependency from the ebuild and recreate the manifest, then one of the following may happen. It will fail to build It will build but fail to run It will build and run successfully One or more kittens/puppies will die If only option 3 happens, copy the modified ebuild to a local overlay to prevent the dependency being reinstated when you next sync. Then file a bug asking for this to be controlled by a USE flag. -- Neil Bothwick Forget the Joneses...I can't keep up with The Simpsons. pgpN0Ati910CS.pgp Description: OpenPGP digital signature
Re: [gentoo-user] locate can not find a file
On mer. 15 mars 09:10:26 2017, the...@sys-concept.com wrote: > Yes, I run as root: updatedb > But when run: > locate consent_extraction* > > It only list one file: > /home/fd/consent_extraction1.pdf (this is a link file) > /home/fd/business/forms/consent_extraction1.pdf > > It can not find: "consent_extraction.pdf" both files are in same directory > > ll business/forms/ > total 688 > ... > -rw-r--r-- 1 fd fd 63032 Mar 15 08:52 consent_extraction1.pdf > -rw-r--r-- 1 fd fd 397649 Mar 14 20:05 consent_extraction.pdf > > I observe the same behaviour on my local machine and remote machine. > > Running "find" finds both files > > find . -name '*consent_extraction*' > ./business/forms/consent_extraction.pdf > ./business/forms/consent_extraction1.pdf > ./consent_extraction1.pdf > > Why? Hi, Do you have file consent_extraction1.pdf in your working directory? In that case, your shell will begin by expending your asterisk and you will really look for consent_extraction1.pdf. -- alarig signature.asc Description: PGP signature
Re: [gentoo-user] locate can not find a file
On 03/15/2017 09:31 AM, Alarig Le Lay wrote: > On mer. 15 mars 09:10:26 2017, the...@sys-concept.com wrote: >> Yes, I run as root: updatedb >> But when run: >> locate consent_extraction* >> >> It only list one file: >> /home/fd/consent_extraction1.pdf (this is a link file) >> /home/fd/business/forms/consent_extraction1.pdf >> >> It can not find: "consent_extraction.pdf" both files are in same directory >> >> ll business/forms/ >> total 688 >> ... >> -rw-r--r-- 1 fd fd 63032 Mar 15 08:52 consent_extraction1.pdf >> -rw-r--r-- 1 fd fd 397649 Mar 14 20:05 consent_extraction.pdf >> >> I observe the same behaviour on my local machine and remote machine. >> >> Running "find" finds both files >> >> find . -name '*consent_extraction*' >> ./business/forms/consent_extraction.pdf >> ./business/forms/consent_extraction1.pdf >> ./consent_extraction1.pdf >> >> Why? > > Hi, > > Do you have file consent_extraction1.pdf in your working directory? In > that case, your shell will begin by expending your asterisk and you will > really look for consent_extraction1.pdf. It is a strange behaviour :-/ Yes, I had a link "consent_extraction1.pdf" in a working directory and locate could only locate: consent_extraction1.pdf It could not find: consent_extraction.pdf When I removed "consent_extraction.pdf" from my working directory. run "updatedb" and "locate *consent_extraction*" found both files "locate consent_extraction" found both files "locate consent_extraction*" didn't find any files The "*" is is messing up the search. I was under impression the "*" will match any character including extensions. -- Thelma
Re: [gentoo-user] locate can not find a file
On 03/15/2017 09:51 AM, the...@sys-concept.com wrote: [snip] >> >> Do you have file consent_extraction1.pdf in your working directory? In >> that case, your shell will begin by expending your asterisk and you will >> really look for consent_extraction1.pdf. > > It is a strange behaviour :-/ > Yes, I had a link "consent_extraction1.pdf" in a working directory and > locate could only locate: consent_extraction1.pdf > It could not find: consent_extraction.pdf > > When I removed "consent_extraction.pdf" from my working directory. > run "updatedb" and > "locate *consent_extraction*" found both files > "locate consent_extraction" found both files > "locate consent_extraction*" didn't find any files > > The "*" is is messing up the search. I was under impression the "*" will > match any character including extensions. > > -- > Thelma Sometimes reading the "man" files helps :-/ ...If --regex is not specified, PATTERNs can contain globbing characters. If any PATTERN contains no globbing characters, locate behaves as if the pattern were *PATTERN*. -- Thelma
Re: [gentoo-user] locate can not find a file
On Wed, 15 Mar 2017 09:10:26 -0600, the...@sys-concept.com wrote: > Yes, I run as root: updatedb > But when run: > locate consent_extraction* > > It only list one file: > /home/fd/consent_extraction1.pdf (this is a link file) > /home/fd/business/forms/consent_extraction1.pdf The wildcard is being expanded by your shell, so the command you are actually running is locate consent_extraction1.pdf If you want to pass the * to locate, you need to escape or quote it. -- Neil Bothwick Downloading - A quick way of catching a virus from anywhere in the world. pgpoVentnElkh.pgp Description: OpenPGP digital signature
Re: [gentoo-user] locate can not find a file
On 03/15/2017 10:16 AM, Neil Bothwick wrote: > On Wed, 15 Mar 2017 09:10:26 -0600, the...@sys-concept.com wrote: > >> Yes, I run as root: updatedb >> But when run: >> locate consent_extraction* >> >> It only list one file: >> /home/fd/consent_extraction1.pdf (this is a link file) >> /home/fd/business/forms/consent_extraction1.pdf > > The wildcard is being expanded by your shell, so the command you are > actually running is > > locate consent_extraction1.pdf > > If you want to pass the * to locate, you need to escape or quote it. locate consent_extraction\* - didn't find anything locate "consent_extraction*" - didn't find anything locate "*consent_extraction*" - found both files locate *consent_extraction* - found both files I guess I have to erase my memory of DOS -- Thelma
[gentoo-user] Re: Latest LLVM wants to pollute my machine with VIM stuff.....
On Wed, 15 Mar 2017 22:33:10 +0800, Andrew Lowe wrote: > Hi all, > I'm still trying to come to grips with understanding ebuilds so please > bear with me if this is a simple question. I've just sync'd and then > done an > > emerge --ask -NuD world > > I have LLVM/clang installed and upon browsing the updates saw > app-vim/llvm-vim. This is some sort of syntax highlighting thingy for > Vim. I don't have Vim installed so went into the llvm-4.0.0 ebuild and > saw the line > > PDEPEND="app-vim/llvm-vim > > My understanding is that PDEPEND means that something, in this case > llvm-vim, will be installed after the update of llvm - correct? If so, I > can't see any way of "turning this off" as I don't want even more junk > installed on my machine. > > Have I understood the ebuild correctly and it could do with a "fiddle" > so that it doesn't force this install? Yes, it could - I wondered the same thing. File an enhancement request in bugzilla so that vim support can be optional via the already existing "vim" USE flag. In the meantime try: $echo "app-vim/llvm-vim-" >> /etc/portage/profile/package.provided This tells portage that the package is installed as version , so any future llvm/clang updates won't try to update it. -h
Re: [gentoo-user] locate can not find a file
On Wed, 15 Mar 2017 10:24:27 -0600, the...@sys-concept.com wrote: > > The wildcard is being expanded by your shell, so the command you are > > actually running is > > > > locate consent_extraction1.pdf > > > > If you want to pass the * to locate, you need to escape or quote it. > > locate consent_extraction\* - didn't find anything > locate "consent_extraction*" - didn't find anything > > locate "*consent_extraction*" - found both files > locate *consent_extraction* - found both files Or you could simply use locate consent_extraction because a substring match is the default behaviour. -- Neil Bothwick Q-Tip: When an omnipotent alien gives you advice. pgp1HPGKsj5iu.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Latest LLVM wants to pollute my machine with VIM stuff.....
On 16/03/17 02:32, Holger Hoffstätte wrote: On Wed, 15 Mar 2017 22:33:10 +0800, Andrew Lowe wrote: Hi all, I'm still trying to come to grips with understanding ebuilds so please bear with me if this is a simple question. I've just sync'd and then done an emerge --ask -NuD world I have LLVM/clang installed and upon browsing the updates saw app-vim/llvm-vim. This is some sort of syntax highlighting thingy for Vim. I don't have Vim installed so went into the llvm-4.0.0 ebuild and saw the line PDEPEND="app-vim/llvm-vim My understanding is that PDEPEND means that something, in this case llvm-vim, will be installed after the update of llvm - correct? If so, I can't see any way of "turning this off" as I don't want even more junk installed on my machine. Have I understood the ebuild correctly and it could do with a "fiddle" so that it doesn't force this install? Yes, it could - I wondered the same thing. File an enhancement request in bugzilla so that vim support can be optional via the already existing "vim" USE flag. In the meantime try: $echo "app-vim/llvm-vim-" >> /etc/portage/profile/package.provided This tells portage that the package is installed as version , so any future llvm/clang updates won't try to update it. -h Neil & Holger, Thanks for the thoughts, I will file the request. Andrew
Re: [gentoo-user] Latest LLVM wants to pollute my machine with VIM stuff.....
Am Mittwoch, 15. März 2017, 15:33:10 CET schrieb Andrew Lowe: > Hi all, Hi, > I'm still trying to come to grips with understanding ebuilds so please > bear with me if this is a simple question. I've just sync'd and then > done an > > emerge --ask -NuD world > > I have LLVM/clang installed and upon browsing the updates saw > app-vim/llvm-vim. This is some sort of syntax highlighting thingy for > Vim. I don't have Vim installed so went into the llvm-4.0.0 ebuild and > saw the line > > PDEPEND="app-vim/llvm-vim > > My understanding is that PDEPEND means that something, in this case > llvm-vim, will be installed after the update of llvm - correct? If so, I > can't see any way of "turning this off" as I don't want even more junk > installed on my machine. > > Have I understood the ebuild correctly and it could do with a "fiddle" > so that it doesn't force this install? > > Regards, > Andrew well, I just asked in IRC on Freenode about that and a dev pointed out, that the new dep for vim files is actually putting files *outside* the package to avoid file collisions with slotted packages. So I took a look myself with clang < 4.0 (needed on my system anyways thanks to rust): % equery f llvm|grep vim /usr/share/vim /usr/share/vim/vimfiles /usr/share/vim/vimfiles/llvm-lit.vim /usr/share/vim/vimfiles/llvm.vim /usr/share/vim/vimfiles/tablegen.vim % du -ch $(equery f llvm|grep vim) 2> /dev/null 4,0K/usr/share/vim/vimfiles/llvm-lit.vim 8,0K/usr/share/vim/vimfiles/llvm.vim 4,0K/usr/share/vim/vimfiles/tablegen.vim 16K total So well, 16KB in sum. Funny to see the “outsourced“ ebuild is exactly the same size. All in all I consider that way a bit ugly, but for this size I agree it’s really wasted energy [and as the mentioned dev pointed out, discussing this matter takes way more space than the issue itself]. Greetings, -- GPG fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B' Nils Freydank signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: Steam downloading extremely
Am Wed, 15 Mar 2017 21:24:10 +0800 schrieb Danny YUE : > Hi guys, > > I just got Steam installed and running successfully on my machine, > and tried to get CS:GO running smoothly, which made me really > happy :-D > > However when Steam is downloading games, the speed is extremely slow, > down to several KB/s, even some bytes/s. > I have already installed dnsmasq and it *was* good during downloading > CS:GO (~4MB/s), but became slow again with Civilization V. > > I googled a lot but all point to installing dnsmasq, which I don't > think is really helpful since I already have done that... > > Also I'm sure downloading region is correct. > > Anybody experienced the same issue with dnsmasq installed? > Any clue is welcome and thanks in advance. Here, it's downloading with peak bandwidths of 48 mbytes/s but usually it's around 38 mbytes/s. However, I sometimes see slowdowns, too. I guess that games are downloaded file by file, and when a lot of small files are left in the queue, it just cannot get good bandwidth. But I only see such slowdowns mostly short before the last few megabytes of a game. Could you check if your downloaded games consist of many smallish files? Then that could be the explanation. You could try activating fq_codel and tcp fastopen: In /proc/sys/net/ipv4/tcp_fastopen it should say 1. In /proc/sys/net/core/default_qdisc it should say fq_codel. Also, you may want to try out bbr congestion control: In /proc/sys/net/ipv4/tcp_congestion_control it should say bbr. By recompiling the kernel, you can reconfigure the defaults for this (and enable support). Some of these need modern kernels. Additionally, many small tcp request need a good portion of your upload bandwidth and are very dependent on good round trip times. Traditional DSL lines with ping times of 50-60ms can really slow down requests of small files a lot due to three-way tcp handshaking, that is, you could request only one smallish file per 100-120ms. This can totally destroy the usable bandwidth. Maybe watch a running ping while the downloads are running. If the ping times increase while the download slows down, your bottleneck is the upload. But also keep in mind that traditional spinning disks may not keep up with the bandwidth if confronted with many small files. If you're using SSD all should be fine. I'm running on bcache with writeback caching which gives a really good performance boost by adding a small SSD to one or more big HDDs. -- Regards, Kai Replies to list-only preferred.
[gentoo-user] Re: Steam downloading extremely
Am Wed, 15 Mar 2017 21:53:44 +0100 schrieb Kai Krakow : > Am Wed, 15 Mar 2017 21:24:10 +0800 > schrieb Danny YUE : > > > Hi guys, > > > > I just got Steam installed and running successfully on my machine, > > and tried to get CS:GO running smoothly, which made me really > > happy :-D > > > > However when Steam is downloading games, the speed is extremely > > slow, down to several KB/s, even some bytes/s. > > I have already installed dnsmasq and it *was* good during > > downloading CS:GO (~4MB/s), but became slow again with Civilization > > V. > > > > I googled a lot but all point to installing dnsmasq, which I don't > > think is really helpful since I already have done that... > > > > Also I'm sure downloading region is correct. > > > > Anybody experienced the same issue with dnsmasq installed? > > Any clue is welcome and thanks in advance. > > Here, it's downloading with peak bandwidths of 48 mbytes/s but usually > it's around 38 mbytes/s. However, I sometimes see slowdowns, too. I > guess that games are downloaded file by file, and when a lot of small > files are left in the queue, it just cannot get good bandwidth. > > But I only see such slowdowns mostly short before the last few > megabytes of a game. > > Could you check if your downloaded games consist of many smallish > files? Then that could be the explanation. > > You could try activating fq_codel and tcp fastopen: > > In /proc/sys/net/ipv4/tcp_fastopen it should say 1. > In /proc/sys/net/core/default_qdisc it should say fq_codel. > > Also, you may want to try out bbr congestion control: > > In /proc/sys/net/ipv4/tcp_congestion_control it should say bbr. > > By recompiling the kernel, you can reconfigure the defaults for this > (and enable support). Some of these need modern kernels. > > Additionally, many small tcp request need a good portion of your > upload bandwidth and are very dependent on good round trip times. > Traditional DSL lines with ping times of 50-60ms can really slow down > requests of small files a lot due to three-way tcp handshaking, that > is, you could request only one smallish file per 100-120ms. This can > totally destroy the usable bandwidth. Maybe watch a running ping > while the downloads are running. If the ping times increase while the > download slows down, your bottleneck is the upload. > > But also keep in mind that traditional spinning disks may not keep up > with the bandwidth if confronted with many small files. If you're > using SSD all should be fine. I'm running on bcache with writeback > caching which gives a really good performance boost by adding a small > SSD to one or more big HDDs. BTW: I don't see how dnsmasq could help you here... It can do nothing about bandwidth. It only acts as a DNS cache which helps keeping latency of the DNS resolver down. But this doesn't matter here because during download, steam won't do many DNS requests. As already stated, part of the problem may be the upload, and/or bad queue handling within your broadband router. You can work around it with a traffic shaper and throttling upload below what's physically possible with your internet line, thus keeping the queue in front of the broadband router. That way, a traffic shaper could handle it and work around bad queue handling. To resolve the issue it is important to sophistically test the suggestions one step at a time, starting with the easy ones, and do your measurements. -- Regards, Kai Replies to list-only preferred.
[gentoo-user] Re: locate can not find a file
Am Wed, 15 Mar 2017 16:31:58 +0100 schrieb Alarig Le Lay : > On mer. 15 mars 09:10:26 2017, the...@sys-concept.com wrote: > > Yes, I run as root: updatedb > > But when run: > > locate consent_extraction* > > > > It only list one file: > > /home/fd/consent_extraction1.pdf (this is a link file) > > /home/fd/business/forms/consent_extraction1.pdf > > > > It can not find: "consent_extraction.pdf" both files are in same > > directory > > > > ll business/forms/ > > total 688 > > ... > > -rw-r--r-- 1 fd fd 63032 Mar 15 08:52 consent_extraction1.pdf > > -rw-r--r-- 1 fd fd 397649 Mar 14 20:05 consent_extraction.pdf > > > > I observe the same behaviour on my local machine and remote machine. > > > > Running "find" finds both files > > > > find . -name '*consent_extraction*' > > ./business/forms/consent_extraction.pdf > > ./business/forms/consent_extraction1.pdf > > ./consent_extraction1.pdf > > > > Why? > > Hi, > > Do you have file consent_extraction1.pdf in your working directory? In > that case, your shell will begin by expending your asterisk and you > will really look for consent_extraction1.pdf. This is a concept many people cannot or don't want to grasp. Easy fix is to put quotation marks around the search term: # locate "consent_extraction*" Especially people coming from Windows or DOS have problems with this feature. In the MS world, globbing expansion is done by the command itself: it will see the * literally in the parameters. In the GNU world, globbing expansion is done by the shell before handing parameters over to the command: The command won't see the * but instead sees what the shell made from it. To work around this behavior, you simply put quotation marks around it (which will be removed before handed over to the command, so even consent_extraction"*" would work). Thus, simply always put quotation marks if you don't want to become fooled by unwillingly letting the shell do its job. Missing to do so can even have some negative effects, i.e. dangerous, like overwriting files during mv by moving all files into the same filename. -- Regards, Kai Replies to list-only preferred. pgphDhknqNGIY.pgp Description: Digitale Signatur von OpenPGP
[gentoo-user] Re: locate can not find a file
On 2017-03-15, Kai Krakow wrote: > Especially people coming from Windows or DOS have problems with this > feature. In the MS world, globbing expansion is done by the command > itself: it will see the * literally in the parameters. Well, technically, that depends on what shell you're running. That's true with the command.com and cmd.exe shells. It's not true with some others. When back when I ran DOS (and when I run Windows), the globbing is done by the shell: the way god intended. ;) -- Grant Edwards grant.b.edwardsYow! HELLO KITTY gang at terrorizes town, family gmail.comSTICKERED to death!
[gentoo-user] Re: DNS from dialup or wifi for broadband connection?
Am Sun, 12 Mar 2017 03:18:59 -0400 schrieb "Walter Dnes" : > Starting a separate topic, rather than hijack the main thread... > > On Fri, Mar 10, 2017 at 01:50:26PM -0600, Corbin Bird wrote > > > > 6 # : ISP is starting to filter customers web access. The ISP is > > deciding what sites customers are allowed to see. ( look up the > > practice called "ransom" ). > > Does this consist of grabbing outbound traffic to port 53? If so, I > wonder if the following is possible... > > * Can a POTS dialup or a wifi connection co-exist with a broadband > connection? It would make the network config and route config more > complex. Complex? Not really. Just put static DNS IPs into your resolver config, and add a static route for these destinations: for tunnel devices like ppp: # route add 8.8.4.4 dev ppp-interface or for LAN router: # route add 8.8.4.4 gw ip-of-your-dialup-router And then do not let the dialup line set a default route. > * If yes, can iptables be used to redirect only outbound-to-port-53 > traffic to the dialup/wifi connection, with everything else going to > the broadband connection? You could but this becomes more complicated. I think this would have to go into the pre-routing chain. But I don't recommend fiddling around with that. > * Another option, if you know the alternate DNS server address in > advance, set up routing of the /32 (for the alternate DNS server) > to ppp0 or wlan0 with higher priority than the default route. This > doesn't require any iptables magic. As stated above... And you don't need to set higher priority. The best matching rules are always tried before routing rules with lower matching destinations, that means /32 destination rules are matched before /24 destination rules, and so forth. The default gateway is matching IP destination 0/0. The priority is only considered when multiple equally matching rules are found. Just remove the default route via the ppp route to ensure nothing else will go over the slow link. > * Can the standard linux network stack handle this properly, and use > incoming DNS responses from the dialup/wifi connection for the IP > addresses of websites, etc to be accessed via broadband? I don't see problems here. DNS is one request, HTTP is another. As long as your broadband DNS doesn't resolve to some proxy IPs all should be fine. > DNS traffic is low volume, usually fitting into 1 packet. So it > would be feasible to divert DNS requests to a lower-speed connection. > The broadband ISP would handle all the highspeed website, etc, traffic > but it would not see any DNS traffic, and would not be able to > intercept it. Yes. -- Regards, Kai Replies to list-only preferred.
Re: [gentoo-user] Re: locate can not find a file
On 03/15/2017 03:36 PM, Kai Krakow wrote: > Am Wed, 15 Mar 2017 16:31:58 +0100 > schrieb Alarig Le Lay : > >> On mer. 15 mars 09:10:26 2017, the...@sys-concept.com wrote: >>> Yes, I run as root: updatedb >>> But when run: >>> locate consent_extraction* >>> >>> It only list one file: >>> /home/fd/consent_extraction1.pdf (this is a link file) >>> /home/fd/business/forms/consent_extraction1.pdf >>> >>> It can not find: "consent_extraction.pdf" both files are in same >>> directory >>> >>> ll business/forms/ >>> total 688 >>> ... >>> -rw-r--r-- 1 fd fd 63032 Mar 15 08:52 consent_extraction1.pdf >>> -rw-r--r-- 1 fd fd 397649 Mar 14 20:05 consent_extraction.pdf >>> >>> I observe the same behaviour on my local machine and remote machine. >>> >>> Running "find" finds both files >>> >>> find . -name '*consent_extraction*' >>> ./business/forms/consent_extraction.pdf >>> ./business/forms/consent_extraction1.pdf >>> ./consent_extraction1.pdf >>> >>> Why? >> >> Hi, >> >> Do you have file consent_extraction1.pdf in your working directory? In >> that case, your shell will begin by expending your asterisk and you >> will really look for consent_extraction1.pdf. > > This is a concept many people cannot or don't want to grasp. Easy fix > is to put quotation marks around the search term: > > # locate "consent_extraction*" > > Especially people coming from Windows or DOS have problems with this > feature. In the MS world, globbing expansion is done by the command > itself: it will see the * literally in the parameters. > > In the GNU world, globbing expansion is done by the shell before > handing parameters over to the command: The command won't see the * but > instead sees what the shell made from it. To work around this behavior, > you simply put quotation marks around it (which will be removed before > handed over to the command, so even consent_extraction"*" would work). > > Thus, simply always put quotation marks if you don't want to become > fooled by unwillingly letting the shell do its job. Missing to do so > can even have some negative effects, i.e. dangerous, like overwriting > files during mv by moving all files into the same filename. locate "consent_extraction*" - didn't find anything I think, by default "locate" wants to enclose the search location between two "*.*" stars. So if you will not put anything locate will put them for you. If you put only one star it will not find anything. -- Thelma
Re: [gentoo-user] Re: locate can not find a file
On Wed, 15 Mar 2017 15:52:53 -0600, the...@sys-concept.com wrote: > I think, by default "locate" wants to enclose the search location > between two "*.*" stars. So if you will not put anything locate > will put them for you. If you put only one star it will not find > anything. No need to think or suppose, the man page explains it clearly: If --regex is not specified, PATTERNs can contain globbing characters. If any PATTERN contains no globbing characters, locate behaves as if the pattern were *PATTERN*. -- Neil Bothwick And on the seventh day God said :wq and then make pgpf1psSdFep3.pgp Description: OpenPGP digital signature
[gentoo-user] Re: locate can not find a file
Am Wed, 15 Mar 2017 21:41:41 + (UTC) schrieb Grant Edwards : > On 2017-03-15, Kai Krakow wrote: > > > Especially people coming from Windows or DOS have problems with this > > feature. In the MS world, globbing expansion is done by the command > > itself: it will see the * literally in the parameters. > > Well, technically, that depends on what shell you're running. That's > true with the command.com and cmd.exe shells. It's not true with some > others. > > When back when I ran DOS (and when I run Windows), the globbing is > done by the shell: the way god intended. ;) Hell yeah! :-) Tho I'd expect that globbing done by the shell won't play well with most traditional DOS commands. I guess those shells also brought their own built-in commands? -- Regards, Kai Replies to list-only preferred.
[gentoo-user] Re: locate can not find a file
Am Wed, 15 Mar 2017 15:52:53 -0600 schrieb the...@sys-concept.com: > On 03/15/2017 03:36 PM, Kai Krakow wrote: > > Am Wed, 15 Mar 2017 16:31:58 +0100 > > schrieb Alarig Le Lay : > > > >> On mer. 15 mars 09:10:26 2017, the...@sys-concept.com wrote: > [...] > >> > >> Hi, > >> > >> Do you have file consent_extraction1.pdf in your working > >> directory? In that case, your shell will begin by expending your > >> asterisk and you will really look for consent_extraction1.pdf. > > > > This is a concept many people cannot or don't want to grasp. Easy > > fix is to put quotation marks around the search term: > > > > # locate "consent_extraction*" > > > > Especially people coming from Windows or DOS have problems with this > > feature. In the MS world, globbing expansion is done by the command > > itself: it will see the * literally in the parameters. > > > > In the GNU world, globbing expansion is done by the shell before > > handing parameters over to the command: The command won't see the * > > but instead sees what the shell made from it. To work around this > > behavior, you simply put quotation marks around it (which will be > > removed before handed over to the command, so even > > consent_extraction"*" would work). > > > > Thus, simply always put quotation marks if you don't want to become > > fooled by unwillingly letting the shell do its job. Missing to do so > > can even have some negative effects, i.e. dangerous, like > > overwriting files during mv by moving all files into the same > > filename. > > locate "consent_extraction*" - didn't find anything > > I think, by default "locate" wants to enclose the search location > between two "*.*" stars. So if you will not put anything locate > will put them for you. If you put only one star it will not find > anything. Not true... But it seems globbing is working different in locate (well, technically speaking, it works different as expected): The star always matches against the complete path, not only one path fragment. That is why it doesn't work for you. Use the following and it should work: # locate $(pwd)/"consent_extraction*" If you put a star in front, it will also match the $(pwd) component. On the shell, omitting the star in the front only works because you are already in that directory. The shell omits this part of the path when matching. To make this clear, doing: # cd .. # ls consent_extraction* wouldn't find your file, too. But using: # cd .. # ls */consent_extraction* would. As does locate... -- Regards, Kai Replies to list-only preferred.
[gentoo-user] Re: some capital B blockers in world update
Am Tue, 14 Mar 2017 13:00:17 -0400
schrieb allan gottlieb :
> On Tue, Mar 14 2017, Alan McKinnon wrote:
>
> > On 14/03/2017 16:43, allan gottlieb wrote:
> >> I update roughly twice a week. On one machine (full output below)
> >> I was told that libinput and evdev are blocking xorg-drivers
> >>
> >> [blocks B ] >> (" >> x11-base/xorg-drivers-1.19)
> >> [blocks B ] >> (" >> x11-base/xorg-drivers-1.19)
> >>
> >> However the merge does propose to update xorg-drivers
> >> [ebuild U ] x11-base/xorg-drivers-1.19 [1.18-r1] VIDEO_CARDS="-ark%
> >> -i915% -i965% (-newport) -sis%"
> >>
> >> It also proposes to update libinput and evdev
> >> [ebuild U ] x11-drivers/xf86-input-libinput-0.24.0 [0.19.0]
> >> [ebuild U ] x11-drivers/xf86-input-evdev-2.10.5 [2.10.3]
> >>
> >> I do see that the versions of libinput and evdev to be used are
> >> higher than the versions that would block xorg-drivers. I am
> >> wondering why in this case emerge is telling me about the block
> >> (in red with a capital B) and more importantly would appreciate
> >> confirmation that I should let the emerge proceed.
> >
> >
> > Portage found a solution that satisfies all constraints, so you
> > should let it proceed.
> >
> > Did you run emerge with -v to get the above?
> > That looks like portage is doing it's usual -v thing which is to
> > core dump to your console in the hope that maybe you can figure it
> > out and you are willing to play the game called "let's find out
> > what portage thinks it means today!"
> >
> > I don't understand why those blockers are marked hard, as portage
> > found a solution. The blocker lines are really telling you why
> > portage wants to upgrade your libinput and evdev drivers - the
> > current ones won't work with your current drivers.
> >
> > Which is all totally pointless, as newer versions of everything are
> > available and you want a full update. There's very little point in
> > software going to great lengths to tell you why it won't keep old
> > versions when you explicitly told it to not keep old versions :-)
>
> Thank you for the confirmation! I also doubt the use of B when b
> would be appropriated. No this was not a --verbose run. I would
> guess that output would be even less illuminating.
Portage usually has such problems when it needs to resolve blockers
involving package rebuilds involving a subslot upgrade. It would be
nice to see the output below the build list which usually gives hints
how to manually resolve this.
The two package blocking each other could then be first upgraded using
# emerge -1a package1 package2
where one of those is the package which needs a subslot rebuild.
This usually then pulls in the rest of the upgrades, at least
partially. A subsequent "emerge -DNua world" then should work as
expected.
I think this is a bug in the dependency resolver.
--
Regards,
Kai
Replies to list-only preferred.
[gentoo-user] Diskless nodes
Is anybody running Diskless machine, booting over network? How is the speed? I have a Gentoo machine running Windows7 via VM. I need to network another PC and connect to that VM so I was thinking setting up Diskless node but never done it before. Would there be a problem with upgrades? I know all the node files have to reside on Sever from which the node is booting. Or is is easier to just get one of those ThinkCentre Lenovo unit -- Thelma
Re: [gentoo-user] Steam downloading extremely
Thanks for your fast reply, and sorry for my late response. The original is described as: Steam starts with a fast download speed, and eventually goes down, even to 0 (which is probably caused by a bug in Steam Linux client). >From this link: http://steamcommunity.com/app/221410/discussions/2/616189106498372437/ Just installing dnsmasq *does* solve the problem. And it did on my side. Also this link https://wiki.gentoo.org/wiki/Steam/Client_troubleshooting mentioned the same method. (See section "Slow download speeds"). However, my current problem is that when downloading Civilization V the problem comes back (unstable speed, sometimes down to 0 KB/s), while downloading CS:GO is acceptable high speed 4MB/s. (Yes, ISP here is rather slow...My bandwidth is only 30 or 50 Mbit I don't remember.) dnsmasq is up, and downloading from other sources (browser, emerge etc) is definitely fast. I suspect it is a problem of Steam client... Danny On 2017-03-15 13:48, Nils Freydank wrote: > Hi guy, > > Am Mittwoch, 15. März 2017, 14:24:10 CET schrieb Danny YUE: >> Hi guys, >> >> I just got Steam installed and running successfully on my machine, >> and tried to get CS:GO running smoothly, which made me really happy :-D > nice to hear, have fun with that! > >> However when Steam is downloading games, the speed is extremely slow, >> down to several KB/s, even some bytes/s. >> I have already installed dnsmasq and it *was* good during downloading >> CS:GO (~4MB/s), but became slow again with Civilization V. >> >> I googled a lot but all point to installing dnsmasq, which I don't think >> is really helpful since I already have done that... > Just installing dnsmasq doesn’t change anything, and just starting it does > neither. I *assume* you did set it up as a local DNS cache, but please provide > some information about it: > - the source of the information, i.e. link to the page > - your setup: > * dnsmasq config > * /etc/resolv.conf > * other configs you think that matter here > >> Also I'm sure downloading region is correct. >> >> Anybody experienced the same issue with dnsmasq installed? >> Any clue is welcome and thanks in advance. >> >> >> Danny > > Nils
Re: [gentoo-user] Re: Steam downloading extremely
Hi Kai, Thanks for your help :-) Code here: /usr/share/info $ cat /proc/sys/net/ipv4/tcp_fastopen 1 /usr/share/info $ cat /proc/sys/net/core/default_qdisc pfifo_fast /usr/share/info $ cat /proc/sys/net/ipv4/tcp_congestion_control cubic dnsmasq may help because...if my understanding is correct, Steam Linux client has a bug that it tries to query the DNS too often during downloading, then its request got throttled. Please see https://wiki.gentoo.org/wiki/Steam/Client_troubleshooting Section "Slow download speeds". For disk, I don't think it fits my case because for a downloading speed of 100KB/s, disk write should not be a bottleneck. I suspect it is related to Linux client because Steam Windows client on my machine downloads at the normal speed... Well, I am not that familiar with network tuning things...so I will definitely check the methods you mentioned. Thanks, Danny On 2017-03-15 21:07, Kai Krakow wrote: > Am Wed, 15 Mar 2017 21:53:44 +0100 > schrieb Kai Krakow : > >> Am Wed, 15 Mar 2017 21:24:10 +0800 >> schrieb Danny YUE : >> >> > Hi guys, >> > >> > I just got Steam installed and running successfully on my machine, >> > and tried to get CS:GO running smoothly, which made me really >> > happy :-D >> > >> > However when Steam is downloading games, the speed is extremely >> > slow, down to several KB/s, even some bytes/s. >> > I have already installed dnsmasq and it *was* good during >> > downloading CS:GO (~4MB/s), but became slow again with Civilization >> > V. >> > >> > I googled a lot but all point to installing dnsmasq, which I don't >> > think is really helpful since I already have done that... >> > >> > Also I'm sure downloading region is correct. >> > >> > Anybody experienced the same issue with dnsmasq installed? >> > Any clue is welcome and thanks in advance. >> >> Here, it's downloading with peak bandwidths of 48 mbytes/s but usually >> it's around 38 mbytes/s. However, I sometimes see slowdowns, too. I >> guess that games are downloaded file by file, and when a lot of small >> files are left in the queue, it just cannot get good bandwidth. >> >> But I only see such slowdowns mostly short before the last few >> megabytes of a game. >> >> Could you check if your downloaded games consist of many smallish >> files? Then that could be the explanation. >> >> You could try activating fq_codel and tcp fastopen: >> >> In /proc/sys/net/ipv4/tcp_fastopen it should say 1. >> In /proc/sys/net/core/default_qdisc it should say fq_codel. >> >> Also, you may want to try out bbr congestion control: >> >> In /proc/sys/net/ipv4/tcp_congestion_control it should say bbr. >> >> By recompiling the kernel, you can reconfigure the defaults for this >> (and enable support). Some of these need modern kernels. >> >> Additionally, many small tcp request need a good portion of your >> upload bandwidth and are very dependent on good round trip times. >> Traditional DSL lines with ping times of 50-60ms can really slow down >> requests of small files a lot due to three-way tcp handshaking, that >> is, you could request only one smallish file per 100-120ms. This can >> totally destroy the usable bandwidth. Maybe watch a running ping >> while the downloads are running. If the ping times increase while the >> download slows down, your bottleneck is the upload. >> >> But also keep in mind that traditional spinning disks may not keep up >> with the bandwidth if confronted with many small files. If you're >> using SSD all should be fine. I'm running on bcache with writeback >> caching which gives a really good performance boost by adding a small >> SSD to one or more big HDDs. > > BTW: I don't see how dnsmasq could help you here... It can do nothing > about bandwidth. It only acts as a DNS cache which helps keeping > latency of the DNS resolver down. But this doesn't matter here because > during download, steam won't do many DNS requests. > > As already stated, part of the problem may be the upload, and/or bad > queue handling within your broadband router. You can work around it > with a traffic shaper and throttling upload below what's physically > possible with your internet line, thus keeping the queue in front of the > broadband router. That way, a traffic shaper could handle it and work > around bad queue handling. > > To resolve the issue it is important to sophistically test the > suggestions one step at a time, starting with the easy ones, and do > your measurements.
