Re: [gentoo-user] Re: Steam downloading extremely

[Danny YUE]

Hi Kai,

Oops, fixed?

I just updated my system and tried to randomly download another game
and it looks fine...

Weird.

Anyway, thanks for you guys.
May the good code be with you.

Danny


On 2017-03-19 19:11, Kai Krakow  wrote:
> Am Thu, 16 Mar 2017 14:04:14 +0800
> schrieb Danny YUE :
>
>> 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".
>
> This has been fixed with the March 9th 2017 Update. It's in the current
> stable client.
>
>> 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.
>
> Well, it still can be if there's a lot of data backlogged and the
> writeback cache of the kernel is saturated.
>
>> I suspect it is related to Linux client because Steam Windows client
>> on my machine downloads at the normal speed...
>
> This makes sense... However, here the linux client is downloading at 48
> mbytes/s which is pretty much the maximum of my 400 mbit link.
>
> So, if it is still slow for you, there seem to be other issues.
>
>> Well, I am not that familiar with network tuning things...so I will
>> definitely check the methods you mentioned.
>
> Feel free to ask.
>
>> 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 :
>> >>  
>>  [...]  
>> >>
>> >> 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.  
>> 
>> 

Re: [gentoo-user] Shell echo missing after ctrl+c

[Dale]

Walter Dnes wrote:
> On Sun, Mar 19, 2017 at 09:49:50AM +0100, Kai Krakow wrote
>> Hello!
>>
>> More and more of my Gentoo systems are exhibiting the following
>> strange and unexpected behavior:
>>
>> After ctrl+c'ing out of programs like tailf, SSH password prompts, in
>> the middle of a shell scripts, the shell echo is not restored - that
>> is: If I type characters I no longer see the characters (but they are
>> received and can be executed by "enter"). If experiencing this, I have
>> to ctrl+c again to discard what I was typing, the blindly type "reset"
>> to reset the terminal, then echo is enabled again.
>   "It's not a bug; it's a feature".  It's caused by some programs.  See
> http://askubuntu.com/questions/171449/shell-does-not-show-typed-in-commands-reset-works-but-what-happened
> for a detailed explanation.  Executive summary... some programs, e.g.
> vim, can be run from the command line, and they accept certain control
> characters (CTRL-V, CTRL-I, etc) as valid input.  These characters would
> normally be echo'd back to the user's terminal by the kernel's tty
> subsystem.  This would foul up the application's screen display.  To
> avoid that, the application turns off echoing to the tty when it starts
> up.  It also restores echoing ***IF IT EXITS PROPERLY***.  This also
> applies to when a program issues a password prompt, where you obviously
> want echoing turned off.  If killed with CTRL-C or "kill -9" or "kill
> -15", it doesn't have a chance to restore echoing, and you get the
> situation you described.
>


So, it was intentional.  Why am I not surprised.  It's still annoying. 
I can see why they did it based on your post but it's still annoying. 

Dale

:-)  :-) 

Re: [gentoo-user] Shell echo missing after ctrl+c

[Walter Dnes]

On Sun, Mar 19, 2017 at 09:49:50AM +0100, Kai Krakow wrote
> Hello!
> 
> More and more of my Gentoo systems are exhibiting the following
> strange and unexpected behavior:
> 
> After ctrl+c'ing out of programs like tailf, SSH password prompts, in
> the middle of a shell scripts, the shell echo is not restored - that
> is: If I type characters I no longer see the characters (but they are
> received and can be executed by "enter"). If experiencing this, I have
> to ctrl+c again to discard what I was typing, the blindly type "reset"
> to reset the terminal, then echo is enabled again.

  "It's not a bug; it's a feature".  It's caused by some programs.  See
http://askubuntu.com/questions/171449/shell-does-not-show-typed-in-commands-reset-works-but-what-happened
for a detailed explanation.  Executive summary... some programs, e.g.
vim, can be run from the command line, and they accept certain control
characters (CTRL-V, CTRL-I, etc) as valid input.  These characters would
normally be echo'd back to the user's terminal by the kernel's tty
subsystem.  This would foul up the application's screen display.  To
avoid that, the application turns off echoing to the tty when it starts
up.  It also restores echoing ***IF IT EXITS PROPERLY***.  This also
applies to when a program issues a password prompt, where you obviously
want echoing turned off.  If killed with CTRL-C or "kill -9" or "kill
-15", it doesn't have a chance to restore echoing, and you get the
situation you described.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

[gentoo-user] Re: Re: Flashing hardware via WINE ?

[Jörg Schaible]

tu...@posteo.de wrote:

[snip]

> Hi Kai (that's a rhyme! :)
> 
> I have installed Virtualbox already and use the Linux Image I
> installed there for banking purposes only. Feels more secure.
> 
> I would prefer the WIndows-in-a-(virtual)box-solution) as you
> do -- if I would own a Windows installation disc. But do not.

You might give ReactOS a try: https://www.reactos.org/
Works for me in a VBox, but I have no idea if serial ports are supported.

[snip]

Cheers,
Jörg

Re: [gentoo-user] mpv startup times...is this guy waiting for soemthing ?

[Stroller]

> On 18 Mar 2017, at 18:44, tu...@posteo.de wrote:
> 
> Starting mpv as root "fixes" the problem...so it is 
> a permission problem (see my second mail).

Can't find your second mail, but a different user has a different 
_environment_, as well as different permissions.

Stroller.

[gentoo-user] Re: Steam downloading extremely

[Kai Krakow]

Am Thu, 16 Mar 2017 14:04:14 +0800
schrieb Danny YUE :

> 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".

This has been fixed with the March 9th 2017 Update. It's in the current
stable client.

> 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.

Well, it still can be if there's a lot of data backlogged and the
writeback cache of the kernel is saturated.

> I suspect it is related to Linux client because Steam Windows client
> on my machine downloads at the normal speed...

This makes sense... However, here the linux client is downloading at 48
mbytes/s which is pretty much the maximum of my 400 mbit link.

So, if it is still slow for you, there seem to be other issues.

> Well, I am not that familiar with network tuning things...so I will
> definitely check the methods you mentioned.

Feel free to ask.

> 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 :
> >>  
>  [...]  
> >>
> >> 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: Shell echo missing after ctrl+c

[Kai Krakow]

Am Sun, 19 Mar 2017 14:50:14 +
schrieb Peter Humphrey :

> On Sunday 19 Mar 2017 10:59:45 Mick wrote:
> 
> > Not sure this will help, but none of my systems have this problem.
> > urxvt, xterm, konsole, terminology, all display anything I enter in
> > the keyboard after I have pressed Ctrl+c.  I run enlightenment, or
> > fluxbox, I have not tried with the plasma DE yet.  
> 
> I'm using plasma and I don't have any problem with CTRL-C. Well,
> unless I'm interrupting something so deeply nested in the call stack
> that there's no way back out all the way to the command line, as
> happens sometimes when emerging -j . Then I have to kill
> Konsole and start it again.

I thought this was fixed by emerge using cgroups?

-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: Shell echo missing after ctrl+c

[Neil Bothwick]

On Sun, 19 Mar 2017 16:37:50 +, Peter Humphrey wrote:

> > > I'm using plasma and I don't have any problem with CTRL-C. Well,
> > > unless I'm interrupting something so deeply nested in the call
> > > stack that there's no way back out all the way to the command line,
> > > as happens sometimes when emerging -j . Then I have to kill
> > > Konsole and start it again.  
> > 
> > kill -9 works for me in that situation.  
> 
> Yes, that's what I meant. Sometimes I can pick out the process holding 
> things up, other times I can't reliably and kill the konsole containing
> it, preferring not to resort to guesswork with such a sharp knife.  :8

pgrep --full --list-full emerge

works for emerge processes. So far, I haven't killed the wrong process...
so far.


-- 
Neil Bothwick

Theory is when you know everything, but nothing works.
Reality is when everything works, but you don't know why.
However, usually theory and reality are mixed together :
Nothing works, and nobody knows why not.


pgpDde5octlvk.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Shell echo missing after ctrl+c

[Peter Humphrey]

On Sunday 19 Mar 2017 16:23:34 Neil Bothwick wrote:
> On Sun, 19 Mar 2017 14:50:14 +, Peter Humphrey wrote:
> > I'm using plasma and I don't have any problem with CTRL-C. Well, unless
> > I'm interrupting something so deeply nested in the call stack that
> > there's no way back out all the way to the command line, as happens
> > sometimes when emerging -j . Then I have to kill Konsole and
> > start it again.
> 
> kill -9 works for me in that situation.

Yes, that's what I meant. Sometimes I can pick out the process holding 
things up, other times I can't reliably and kill the konsole containing it, 
preferring not to resort to guesswork with such a sharp knife.  :8

> I also don't see the behaviour described by the others.

-- 
Regards
Peter

Re: [gentoo-user] Re: Shell echo missing after ctrl+c

[Neil Bothwick]

On Sun, 19 Mar 2017 14:50:14 +, Peter Humphrey wrote:

> I'm using plasma and I don't have any problem with CTRL-C. Well, unless
> I'm interrupting something so deeply nested in the call stack that
> there's no way back out all the way to the command line, as happens
> sometimes when emerging -j . Then I have to kill Konsole and
> start it again.

kill -9 works for me in that situation.

I also don't see the behaviour described by the others.


-- 
Neil Bothwick

Get your grubby hands off my tagline! I stole it first!


pgp14D_Y_Uug_.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Shell echo missing after ctrl+c

[Daniel Frey]

On 03/19/2017 04:37 AM, Alan Mackenzie wrote:
> Hello, Kai.
> 
> On Sun, Mar 19, 2017 at 09:49:50 +0100, Kai Krakow wrote:
>> Hello!
> 
>> More and more of my Gentoo systems are exhibiting the following
>> strange and unexpected behavior:
> 
>> After ctrl+c'ing out of programs like tailf, SSH password prompts, in
>> the middle of a shell scripts, the shell echo is not restored - that
>> is: If I type characters I no longer see the characters (but they are
>> received and can be executed by "enter"). If experiencing this, I have
>> to ctrl+c again to discard what I was typing, the blindly type "reset"
>> to reset the terminal, then echo is enabled again.
> 
>> I'm not sure which update or configuration is causing this. It started
>> out on our Gentoo servers some years ago (which I'm only SSH'ed into,
>> no physical access), now since a few weeks, also my desktop machines are
>> affected. I have no explanation for this.
> 
>> But maybe anyone?
> 
>> BTW: I know from the old times (some 15-20 years ago) that ctrl+c out
>> of a program (i.e. rsync) that starts a subshell (i.e. ssh) that in
>> turn shows a password prompt, will leave you with an echoless shell.
>> But it shows up on almost any occasion now.
> 
> It's been happening to me increasingly often in the last few
> months/years.  I don't like it.
> 
> Here is a recipe for reproducing the phenomenon.  A typical way of
> invoking patch is by supplying the patch file to standard input:
> 
> $ patch --dry-run < some-patch-file.diff
> 
> .  However if you accidentally omit the "<", like this:
> 
> $ patch --dry-run some-patch-file.diff
> 
> , the terminal will await you typing in the patch file.  Instead, do a
> ctrl-c.  This leaves the terminal not echoing keystrokes.
> 
> By the way, thanks for educating me about the existence of the command
> `reset'.  :-)
> 

`stty echo` will probably fix it as well.

I haven't seen this problem but I can reproduce it. It seems to rely on
programs/scripts interrupting break and setting the terminal settings
back the way they were. If a program/script does not do this properly,
and it changes the tty echo state, it leaves echo off as well.

When it happens, if you run `stty -a` do you see "-echo" in the results?
If you do, whatever you ran turned echo off and didn't restore it on abort.

If you want you can turn it off yourself using `stty -echo` for testing.

The question is, is this the responsibility of bash itself after a
script terminates?

Dan

Re: [gentoo-user] Re: Shell echo missing after ctrl+c

[Peter Humphrey]

On Sunday 19 Mar 2017 10:59:45 Mick wrote:

> Not sure this will help, but none of my systems have this problem.  urxvt,
> xterm, konsole, terminology, all display anything I enter in the keyboard
> after I have pressed Ctrl+c.  I run enlightenment, or fluxbox, I have not
> tried with the plasma DE yet.

I'm using plasma and I don't have any problem with CTRL-C. Well, unless I'm 
interrupting something so deeply nested in the call stack that there's no 
way back out all the way to the command line, as happens sometimes when
emerging -j . Then I have to kill Konsole and start it again.

-- 
Regards
Peter

[gentoo-user] Re: Flashing hardware via WINE ?

[Grant Edwards]

On 2017-03-19, tu...@posteo.de  wrote:

> yes...no chance.
> Linux is insecure...you know.
> It makes it possible to spy the firmware and decrypt it on
> the way to the charger.
>
> Windows is much more secure.

Wow.  It's actually much easier to grab serial data on Windows (using
sysinternals 'portmon') than it is on Linux (you can do it with
strace, but it's not easy).

> Earth is flat and there was no landing on the moon.
>
> I believe in Santa Claus.

-- 
Grant

[gentoo-user] Re: Shell echo missing after ctrl+c

[Kai Krakow]

Am Sun, 19 Mar 2017 10:17:02 +0100
schrieb Matthias Hanft :

> Kai Krakow wrote:
> > 
> > After ctrl+c'ing out of programs like tailf, SSH password prompts,
> > in the middle of a shell scripts, the shell echo is not restored  
> 
> Not here, but something similar: Immediately after ctrl+c'ing, no
> shell prompt is displayed (in fact, *nothing* is displayed) - but
> it's just the display; I can enter a shell command (with echo, too)
> which will be executed properly. Or just press the RETURN key on the
> empty line to get the shell prompt again.
> 
> This happens just on a single of my Gentoo systems (and not always,
> but very often).
> 
> Any idea?

Yes, this can sneak upon you if you ctrl+c a program with child
processes, and part of the teardown is that a child displays a line
after control has already been returned to the shell.

What happens now is: Your shell displays the prompt, the child process
echos a carriage return and echos text, overwriting your prompt,
and putting a newline, child now also exits. If your prompt was long
enough, you may still see the rest of it. You end up with a sole
blinking cursor on an empty line. Hitting enter produces a new shell
prompt.

There's no way to work around it except by maybe putting a sleep inside
the PS1 variable. But I'm sure you don't want that. ;-)

Tho, thinking about this, your case may have the same underlying bug in
common: delayed termination of child processes.

-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: Shell echo missing after ctrl+c

[Dale]

Kai Krakow wrote:
> Am Sun, 19 Mar 2017 06:27:15 -0500
> schrieb Dale :
>
>
>
> Here is mine:
>
> root@fireball / # uname -r
> 4.5.2-gentoo
> root@fireball / #
>
> As far as I know, I use bash.  If you are talking about what I think
> you are talking about. 
> Yes, that's what I was talking about.
>
> Run ps, it should tell you the processes running in your current shell,
> including the shell itself:
>
> # ps
>   PID TTY  TIME CMD
>  1256 pts/200:00:00 ps
> 32059 pts/200:00:00 bash
>
> And you can see your default shell this way:
>
> # realpath /bin/sh
> /bin/dash
>
> Yes, dash for me, because it spawns much faster than bash, at least
> when running scripts. This can make a big difference with openrc.
> Meanwhile, I'm using systemd.

root@fireball / # ps | grep bash
 8515 pts/000:00:00 bash
root@fireball / # realpath /bin/sh
/bin/bash
root@fireball / #

Looks like bash for me. 


>> [IP-] [  ] app-shells/bash-4.3_p48-r1:0
> Here, too:
>
> # equery list bash
> [IP-] [  ] app-shells/bash-4.3_p48-r1:0
>
>> Given the age of your kernel, maybe it is above that level anyway.  I
>> don't update my kernel often either. 
>>
>> I'm going to be watching this thread tho.  If I can share info which
>> may help narrow things down, I'll do that for sure. 
> The problem is that this bug is totally non-deterministic... It fails
> once, next try it works as it should.
>
> If you can work out a way to reliably reproduce this bug, let me know.
> Then I'll try to work out what the problem is. 
>


I think our other Alan posted a way to reproduce it.  I see you replied
so maybe his post will help and I'll read your reply next.  Maybe if we
share enough between several of us, we can at least rule out some stuff
and narrow it down a bit. 

Dale

:-)  :-) 

[gentoo-user] Re: modules-load restart

[Kai Krakow]

Am Thu, 16 Mar 2017 18:11:33 -0600
schrieb the...@sys-concept.com:

> On 03/16/2017 12:51 PM, Alan McKinnon wrote:
> > On 16/03/2017 20:04, the...@sys-concept.com wrote:  
> >> I compiled as module: it87
> >> run:
> >> make
> >> make modules_prepare
> >> make modules_install
> >> ...
> >> INSTALL drivers/hwmon/it87.ko
> >>
> >> add "it87" to modules.conf
> >>
> >> but running: /etc/init.d/modules-load restart
> >> does not restart the module.
> >>
> >> Do I need to restart the box, this procedure work on a different
> >> box without restart.
> >>  
> > 
> > 
> > What is the correct module name? It does not have to match the file
> > name.  
> 
> I compile this as module:
> 
> CONFIG_SENSORS_IT87=m
> 
> I did the same on my other computer, add to: /etc/conf.d/modules
> it87
> 
> and modules-load restart worked.

You need to fix two things on the affected system:

First, changes to /etc/conf.d/modules affect /etc/init.d/modules but
not /etc/init.d/modules-load.

Then, fix your syntax: You're overwriting the modules= assignment with
each line.

Your changes have no effect because you are confusing yourself (and
even others here):

1. There a module autoloader and depmod, modules may be autoloaded
2. There's modules-load and modules
3. Each have their own config file and init script
4. Use the correct pair of config/init script when doing changes

-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: modules-load restart

[Kai Krakow]

Am Sat, 18 Mar 2017 22:31:44 +
schrieb Neil Bothwick :

> On Fri, 17 Mar 2017 17:28:27 +, David W Noon wrote:
> 
> > > cat /etc/conf.d/modules 
> > > modules="vboxdrv vboxnetflt vboxnetadp vboxpci"
> > > modules="it87"
> > 
> > The above syntax is incorrect.
> > 
> > To use multiple lines, you need to re-interpolate the modules
> > variable, thus:
> > 
> > modules="vboxdrv vboxnetflt vboxnetadp vboxpci"
> > modules="${modules} it87"
> > 
> > Otherwise the second assignment deletes the module list from the
> > first assignment.  
> 
> If that were true, it87 would be the only module loaded, not the only
> module not loaded.

This is only a wrong assumption... His reload command is using a
different configuration file.

> The comments in the file show multiple module definitions without
> explicitly adding the previous values.


-- 
Regards,
Kai

Replies to list-only preferred.


pgpMRwVfTNz9h.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-user] Re: Shell echo missing after ctrl+c

[Kai Krakow]

Am Sun, 19 Mar 2017 11:37:56 +
schrieb Alan Mackenzie :

> Hello, Kai.
> 
> On Sun, Mar 19, 2017 at 09:49:50 +0100, Kai Krakow wrote:
> > Hello!  
> 
> > More and more of my Gentoo systems are exhibiting the following
> > strange and unexpected behavior:  
> 
> > After ctrl+c'ing out of programs like tailf, SSH password prompts,
> > in the middle of a shell scripts, the shell echo is not restored -
> > that is: If I type characters I no longer see the characters (but
> > they are received and can be executed by "enter"). If experiencing
> > this, I have to ctrl+c again to discard what I was typing, the
> > blindly type "reset" to reset the terminal, then echo is enabled
> > again.  
> 
> > I'm not sure which update or configuration is causing this. It
> > started out on our Gentoo servers some years ago (which I'm only
> > SSH'ed into, no physical access), now since a few weeks, also my
> > desktop machines are affected. I have no explanation for this.  
> 
> > But maybe anyone?  
> 
> > BTW: I know from the old times (some 15-20 years ago) that ctrl+c
> > out of a program (i.e. rsync) that starts a subshell (i.e. ssh)
> > that in turn shows a password prompt, will leave you with an
> > echoless shell. But it shows up on almost any occasion now.  
> 
> It's been happening to me increasingly often in the last few
> months/years.  I don't like it.

Me neither, getting on my nerves.

> Here is a recipe for reproducing the phenomenon.  A typical way of
> invoking patch is by supplying the patch file to standard input:
> 
> $ patch --dry-run < some-patch-file.diff
> 
> .  However if you accidentally omit the "<", like this:
> 
> $ patch --dry-run some-patch-file.diff
> 
> , the terminal will await you typing in the patch file.  Instead, do a
> ctrl-c.  This leaves the terminal not echoing keystrokes.

The "funny" nature of this bug is its "reproducibility": On my system,
your test doesn't work for me: I currently always get echo back. Tho,
next reboot that may have changed.
 
> By the way, thanks for educating me about the existence of the command
> `reset'.  :-)

Enjoy. :-)

There's a maybe related problem: On some system I see that tailf
doesn't detect new file data - sometimes never, sometimes it stop after
a while, and I checked: The file wasn't rotated or truncated. That also
affects apachetop which reliably never works on this system. Fun fact:
Only one user was affected by this, now also my own user is affected.

-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: Shell echo missing after ctrl+c

[Kai Krakow]

Am Sun, 19 Mar 2017 06:27:15 -0500
schrieb Dale :

> Kai Krakow wrote:
> > Am Sun, 19 Mar 2017 05:40:09 -0500
> > schrieb Dale :
> >  
> >> Kai Krakow wrote:  
>  [...]  
>  [...]  
> >>  [...]
>  [...]  
>  [...]  
> >> I've likely had it happen on a regular console too.  I have just
> >> got so used to it, I don't pay it any attention.  I suspect this
> >> is a deep issue somewhere.  Maybe even as low level as the kernel
> >> somehow or close to it. 
> >>
> >> It will be interesting to see what it is tho.  Given how long it
> >> has been doing it here at least, it's going to be a old
> >> commit/change which may be difficult to track back.  
> > Well, I shouldn't say that probably, but some affected servers are
> > still running on 3.0 or 3.2 kernels. Only the rest of the system was
> > upgraded (mostly "glsa-check -f affected" only). So, I suspected an
> > issue because of old kernel but new user space tools.
> >
> > But since some time ago my desktop machines are also affected (and
> > those are almost bleeding edge, with ~amd64 gentoo-sources).
> >
> > So, more likely it's something in bash... Which is what I use. Which
> > shell do you use? I could try using zsh tho I absolutely hate how it
> > tries to be smarter about tab-completion and always steals trailing
> > "/" away - which especially with rsync and mv can do some serious
> > damage or at least unexpected results.
> >  
> 
> 
> Here is mine:
> 
> root@fireball / # uname -r
> 4.5.2-gentoo
> root@fireball / #
> 
> As far as I know, I use bash.  If you are talking about what I think
> you are talking about. 

Yes, that's what I was talking about.

Run ps, it should tell you the processes running in your current shell,
including the shell itself:

# ps
  PID TTY  TIME CMD
 1256 pts/200:00:00 ps
32059 pts/200:00:00 bash

And you can see your default shell this way:

# realpath /bin/sh
/bin/dash

Yes, dash for me, because it spawns much faster than bash, at least
when running scripts. This can make a big difference with openrc.
Meanwhile, I'm using systemd.

> [IP-] [  ] app-shells/bash-4.3_p48-r1:0

Here, too:

# equery list bash
[IP-] [  ] app-shells/bash-4.3_p48-r1:0

> Given the age of your kernel, maybe it is above that level anyway.  I
> don't update my kernel often either. 
> 
> I'm going to be watching this thread tho.  If I can share info which
> may help narrow things down, I'll do that for sure. 

The problem is that this bug is totally non-deterministic... It fails
once, next try it works as it should.

If you can work out a way to reliably reproduce this bug, let me know.
Then I'll try to work out what the problem is. 

-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Shell echo missing after ctrl+c

[Alan Mackenzie]

Hello, Kai.

On Sun, Mar 19, 2017 at 09:49:50 +0100, Kai Krakow wrote:
> Hello!

> More and more of my Gentoo systems are exhibiting the following
> strange and unexpected behavior:

> After ctrl+c'ing out of programs like tailf, SSH password prompts, in
> the middle of a shell scripts, the shell echo is not restored - that
> is: If I type characters I no longer see the characters (but they are
> received and can be executed by "enter"). If experiencing this, I have
> to ctrl+c again to discard what I was typing, the blindly type "reset"
> to reset the terminal, then echo is enabled again.

> I'm not sure which update or configuration is causing this. It started
> out on our Gentoo servers some years ago (which I'm only SSH'ed into,
> no physical access), now since a few weeks, also my desktop machines are
> affected. I have no explanation for this.

> But maybe anyone?

> BTW: I know from the old times (some 15-20 years ago) that ctrl+c out
> of a program (i.e. rsync) that starts a subshell (i.e. ssh) that in
> turn shows a password prompt, will leave you with an echoless shell.
> But it shows up on almost any occasion now.

It's been happening to me increasingly often in the last few
months/years.  I don't like it.

Here is a recipe for reproducing the phenomenon.  A typical way of
invoking patch is by supplying the patch file to standard input:

$ patch --dry-run < some-patch-file.diff

.  However if you accidentally omit the "<", like this:

$ patch --dry-run some-patch-file.diff

, the terminal will await you typing in the patch file.  Instead, do a
ctrl-c.  This leaves the terminal not echoing keystrokes.

By the way, thanks for educating me about the existence of the command
`reset'.  :-)

> -- 
> Regards,
> Kai

> Replies to list-only preferred.

-- 
Alan Mackenzie (Nuremberg, Germany).

[gentoo-user] Re: Flashing hardware via WINE ?

[Kai Krakow]

Am Sun, 19 Mar 2017 11:38:56 +0100
schrieb tu...@posteo.de:

> On 03/19 10:27, Neil Bothwick wrote:
> > On Sun, 19 Mar 2017 09:09:51 +0100, tu...@posteo.de wrote:
> >   
> > > I have a smart NiMH-charger with serial port (normally used to
> > > dump chargeing curves to the PC).
> > > The chargers firmware can bei flashed with a flashtool provided
> > > by the vendor. The communication is via serial port. I have
> > > a PCI=>serial.ports-card installed in my PC.
> > > 
> > > The command
> > > 
> > > file 
> > > 
> > > results in this information
> > > 
> > > PE32 executable (GUI) Intel 80386, for MS Windows
> > > 
> > > . As Linux user by heart I have no Windows.  
> > 
> > Have you tried contacting the manufacturer to see if flashing from
> > Linux is possible?
> > 
> > 
> > -- 
> > Neil Bothwick
> > 
> > I am MODERATOR of BORG. Follow the rules or be assimilated.  
> 
> Hi Neil,
> 
> yes...no chance.
> Linux is insecure...you know.
> It makes it possible to spy the firmware and decrypt it on
> the way to the charger.
> 
> Windows is much more secyre.
> 
> Earth is flat and there was no landing on the moon.
> 
> I believe in Santa Claus.

And then there is Wireshark in Windows, with libpcap for USB... It can
easily decode and record all USB frames. I successfully used it some
time ago to debug a custom made USB board and found bugs in the
firmware, which I had access to that way. In the end, there was a bug
in the interrupt handler: a race condition overwriting the USB
communication buffer too early and thus sending back wrong data in the
USB HID frames back to the PC (part old data, part new data). The bug
was uncovered by our implementation using a highly optimized threaded
implementation to use the maximum bandwidth the device could provide.
It wasn't possible to convince the firmware programmer about the bug
(which was really expensive for our customer) and the project was
eventually stopped. Strangely, they later provided a firmware without
this failing behavior, much later. Project still paused. But the
preliminary implementation now runs and show very high time resolution
of measurement data (it's an electrochemical spectrometer, just if
you're curious).

Just that in Linux tools are available more easily doesn't mean that
Windows is more "secure". ;-)

Choose your partners wisely.

-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: Shell echo missing after ctrl+c

[Dale]

Mick wrote:
> On Sunday 19 Mar 2017 05:40:09 Dale wrote:
>>
>> I've likely had it happen on a regular console too.  I have just got so
>> used to it, I don't pay it any attention.  I suspect this is a deep
>> issue somewhere.  Maybe even as low level as the kernel somehow or close
>> to it.
>>
>> It will be interesting to see what it is tho.  Given how long it has
>> been doing it here at least, it's going to be a old commit/change which
>> may be difficult to track back.
>>
>> Dale
>>
>> :-)  :-)
> Not sure this will help, but none of my systems have this problem.  urxvt, 
> xterm, konsole, terminology, all display anything I enter in the keyboard 
> after I have pressed Ctrl+c.  I run enlightenment, or fluxbox, I have not 
> tried with the plasma DE yet.

Be interesting to see what happens when you try that.  I have KDE for my
main desktop.  I do have others, Fluxbox etc, for backup usage tho. 

If we keep posting what we use and what is affected, or not, maybe we
can find something common that points to the problem.  Maybe.

Dale

:-)  :-) 

Re: [gentoo-user] Re: Shell echo missing after ctrl+c

[Dale]

Kai Krakow wrote:
> Am Sun, 19 Mar 2017 05:40:09 -0500
> schrieb Dale :
>
>> Kai Krakow wrote:
>>> Am Sun, 19 Mar 2017 04:12:38 -0500
>>> schrieb Dale :
>>>  
 Kai Krakow wrote:  
>>  [...]  
 I don't have a solution but wanted to reply to say that this
 happens to me too.  I have a regular desktop running KDE.  I use
 Konsole for most of my command line activity.  I've noticed that
 this happens with a lot of programs.  It has been happening so
 long, I thought maybe it was the new way things are done.  It is
 aggravating and confusing at times. 

 You are not alone on this.  I'm hoping someone will post a fix.   
>>> KDE with konsole here, too... But I don't think that's the common
>>> denominator. It's also happening from PuTTY in Windows.
>>>  
>> I've likely had it happen on a regular console too.  I have just got
>> so used to it, I don't pay it any attention.  I suspect this is a deep
>> issue somewhere.  Maybe even as low level as the kernel somehow or
>> close to it. 
>>
>> It will be interesting to see what it is tho.  Given how long it has
>> been doing it here at least, it's going to be a old commit/change
>> which may be difficult to track back.
> Well, I shouldn't say that probably, but some affected servers are
> still running on 3.0 or 3.2 kernels. Only the rest of the system was
> upgraded (mostly "glsa-check -f affected" only). So, I suspected an
> issue because of old kernel but new user space tools.
>
> But since some time ago my desktop machines are also affected (and those
> are almost bleeding edge, with ~amd64 gentoo-sources).
>
> So, more likely it's something in bash... Which is what I use. Which
> shell do you use? I could try using zsh tho I absolutely hate how it
> tries to be smarter about tab-completion and always steals trailing "/"
> away - which especially with rsync and mv can do some serious damage or
> at least unexpected results.
>


Here is mine:

root@fireball / # uname -r
4.5.2-gentoo
root@fireball / #

As far as I know, I use bash.  If you are talking about what I think you
are talking about. 

[IP-] [  ] app-shells/bash-4.3_p48-r1:0

Given the age of your kernel, maybe it is above that level anyway.  I
don't update my kernel often either. 

I'm going to be watching this thread tho.  If I can share info which may
help narrow things down, I'll do that for sure. 

Dale

:-)  :-) 

[gentoo-user] Re: Shell echo missing after ctrl+c

[Kai Krakow]

Am Sun, 19 Mar 2017 05:40:09 -0500
schrieb Dale :

> Kai Krakow wrote:
> > Am Sun, 19 Mar 2017 04:12:38 -0500
> > schrieb Dale :
> >  
> >> Kai Krakow wrote:  
>  [...]  
> >> I don't have a solution but wanted to reply to say that this
> >> happens to me too.  I have a regular desktop running KDE.  I use
> >> Konsole for most of my command line activity.  I've noticed that
> >> this happens with a lot of programs.  It has been happening so
> >> long, I thought maybe it was the new way things are done.  It is
> >> aggravating and confusing at times. 
> >>
> >> You are not alone on this.  I'm hoping someone will post a fix.   
> > KDE with konsole here, too... But I don't think that's the common
> > denominator. It's also happening from PuTTY in Windows.
> >  
> 
> I've likely had it happen on a regular console too.  I have just got
> so used to it, I don't pay it any attention.  I suspect this is a deep
> issue somewhere.  Maybe even as low level as the kernel somehow or
> close to it. 
> 
> It will be interesting to see what it is tho.  Given how long it has
> been doing it here at least, it's going to be a old commit/change
> which may be difficult to track back.

Well, I shouldn't say that probably, but some affected servers are
still running on 3.0 or 3.2 kernels. Only the rest of the system was
upgraded (mostly "glsa-check -f affected" only). So, I suspected an
issue because of old kernel but new user space tools.

But since some time ago my desktop machines are also affected (and those
are almost bleeding edge, with ~amd64 gentoo-sources).

So, more likely it's something in bash... Which is what I use. Which
shell do you use? I could try using zsh tho I absolutely hate how it
tries to be smarter about tab-completion and always steals trailing "/"
away - which especially with rsync and mv can do some serious damage or
at least unexpected results.

-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: Shell echo missing after ctrl+c

[Mick]

On Sunday 19 Mar 2017 05:40:09 Dale wrote:
> Kai Krakow wrote:
> > Am Sun, 19 Mar 2017 04:12:38 -0500
> > 
> > schrieb Dale :
> >> Kai Krakow wrote:
> >>> Hello!
> >>> 
> >>> More and more of my Gentoo systems are exhibiting the following
> >>> strange and unexpected behavior:
> >>> 
> >>> After ctrl+c'ing out of programs like tailf, SSH password prompts,
> >>> in the middle of a shell scripts, the shell echo is not restored -
> >>> that is: If I type characters I no longer see the characters (but
> >>> they are received and can be executed by "enter"). If experiencing
> >>> this, I have to ctrl+c again to discard what I was typing, the
> >>> blindly type "reset" to reset the terminal, then echo is enabled
> >>> again.
> >>> 
> >>> I'm not sure which update or configuration is causing this. It
> >>> started out on our Gentoo servers some years ago (which I'm only
> >>> SSH'ed into, no physical access), now since a few weeks, also my
> >>> desktop machines are affected. I have no explanation for this.
> >>> 
> >>> But maybe anyone?
> >>> 
> >>> BTW: I know from the old times (some 15-20 years ago) that ctrl+c
> >>> out of a program (i.e. rsync) that starts a subshell (i.e. ssh)
> >>> that in turn shows a password prompt, will leave you with an
> >>> echoless shell. But it shows up on almost any occasion now.
> >> 
> >> I don't have a solution but wanted to reply to say that this happens
> >> to me too.  I have a regular desktop running KDE.  I use Konsole for
> >> most of my command line activity.  I've noticed that this happens
> >> with a lot of programs.  It has been happening so long, I thought
> >> maybe it was the new way things are done.  It is aggravating and
> >> confusing at times.
> >> 
> >> You are not alone on this.  I'm hoping someone will post a fix.
> > 
> > KDE with konsole here, too... But I don't think that's the common
> > denominator. It's also happening from PuTTY in Windows.
> 
> I've likely had it happen on a regular console too.  I have just got so
> used to it, I don't pay it any attention.  I suspect this is a deep
> issue somewhere.  Maybe even as low level as the kernel somehow or close
> to it.
> 
> It will be interesting to see what it is tho.  Given how long it has
> been doing it here at least, it's going to be a old commit/change which
> may be difficult to track back.
> 
> Dale
> 
> :-)  :-)

Not sure this will help, but none of my systems have this problem.  urxvt, 
xterm, konsole, terminology, all display anything I enter in the keyboard 
after I have pressed Ctrl+c.  I run enlightenment, or fluxbox, I have not 
tried with the plasma DE yet.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Slightly OT - My new SSD.

[Alan Mackenzie]

Hello, Adam.

Thanks for the reply.

On Sun, Mar 19, 2017 at 11:45:34 +1100, Adam Carter wrote:
> On Sun, Mar 19, 2017 at 3:36 AM, Alan Mackenzie  wrote:

> > I've just bought myself a Samsung NVMe 960 EVO M.2 SSD.
> > 
> > Some timings:
> >
> > An emerge -puND @world (when there's nothing to merge) took 38.5s.  With
> > my mirrored HDDs, this took 45.6s.  (Though usually it takes nearer a
> > minute.)
> >
> > An emerge of Firefox took 34m23s, compared with 37m34s with the HDDs.
> > The lack of the sound of the HDD heads moving was either disconcerting
> > or a bit of a relief, I'm not sure which.
> >
> > Copying my email spool file (~110,000 entries, ~1.4 GB) from SSD -> SSD
> > took 6.1s.  From HDD RAID -> HDD RAID it took 30.0s.
> >
> > 
> >

> I was also hoping for more speed up when i got mine, but of course it only
> helps with the system is IO bound. Its great for loading VMs.

> It may be mandatory with NVM, but you can check multiqueue is setup/working
> with;
> # cat /proc/interrupts | egrep '(CPU|nvm)'
> CPU0   CPU1   CPU2   CPU3   CPU4   CPU5   
> CPU6   CPU7
>   30:  21596  0  0  0  0  0   
>0  0   PCI-MSI 1572864-edge  nvme0q0, nvme0q1
>   40:  0  12195  0  0  0  0   
>0  0   PCI-MSI 1572865-edge  nvme0q2
>   41:  0  0  12188  0  0  0   
>0  0   PCI-MSI 1572866-edge  nvme0q3
>   42:  0  0  0  13696  0  0   
>0  0   PCI-MSI 1572867-edge  nvme0q4
>   43:  0  0  0  0  11698  0   
>0  0   PCI-MSI 1572868-edge  nvme0q5
>   44:  0  0  0  0  0  45820   
>0  0   PCI-MSI 1572869-edge  nvme0q6
>   45:  0  0  0  0  0  0  
> 10917  0   PCI-MSI 1572870-edge  nvme0q7
>   46:  0  0  0  0  0  0   
>0  12865   PCI-MSI 1572871-edge  nvme0q8

> If its not setup there'll be just a single IRQ/core handling all the IO.

That, indeed, seems to to be the case.  When I do cat /proc/interrupts |
egrep '(CPU/nvm)', I get just the header line with one data line:

   CPU0   CPU1   CPU2   CPU3
 17:  0  0 15  14605   IO-APIC 17-fasteoi   
ehci_hcd:usb1, nvme0q0, nvme0q1

I'm kind of feeling a bit out of my depth here.  What are the nvme0q0,
etc.?  "Queues" of some kind?  You appear to have nine of these things,
I've just got two.  I'm sure there's a fine manual I ought to be
reading.  Do you know where I might find this manual?

When I look at the entire /proc/interrupts, there are just 30 lines
listed, and I suspect there are no more than 32 interrupt numbers
available.  Is there any way I can configure Linux to give my SSD more
than one interrupt line to work with?

> FWIW
> # hdparm -tT /dev/nvme0n1

> /dev/nvme0n1:
>  Timing cached reads:   9884 MB in  2.00 seconds = 4945.35 MB/sec
>  Timing buffered disk reads: 4506 MB in  3.00 seconds = 1501.84 MB/sec

I get:

/dev/nvme0n1:
 Timing cached reads:   4248 MB in  2.00 seconds = 2124.01 MB/sec
 Timing buffered disk reads: 1214 MB in  3.00 seconds = 404.51 MB/sec

So my "cached reads" speed is (a little under) half of yours.  This is
to be expected, since my PCIe lanes are only version 2 (and yours are
probably version 3).  But the "buffered disk read" are much slower.  Is
this just the age of my PC, or might I have something suboptimally
configured?

-- 
Alan Mackenzie (Nuremberg, Germany).

[gentoo-user] Re: Flashing hardware via WINE ?

[Kai Krakow]

Am Sun, 19 Mar 2017 11:35:44 +0100
schrieb tu...@posteo.de:

> On 03/19 11:20, Kai Krakow wrote:
> > Am Sun, 19 Mar 2017 09:57:22 +0100
> > schrieb tu...@posteo.de:
> >   
> > > On 03/19 09:37, Kai Krakow wrote:  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
> > > 
> > > Hi Kai (that's a rhyme! :)  
> > 
> > Yeah, I know that one... If you are from Germany, you'll also get
> > why my former nick (some years ago) was "Shark" :-)
> >   
> > > I have installed Virtualbox already and use the Linux Image I
> > > installed there for banking purposes only. Feels more secure.  
> > 
> > So something like application virtualization... You could maybe run
> > in an isolated container, only exposing the xserver or run inside a
> > nested xserver. It would probably greatly reduce startup times and
> > not waste a complete image.
> >   
> > > I would prefer the WIndows-in-a-(virtual)box-solution) as you
> > > do -- if I would own a Windows installation disc. But do not.  
> > 
> > Well, you can easily get an image from MS using a Linux browser.
> > Just go to the Windows 10 download page. It will show a selection
> > form to choose the ISO instead of the nasty downloader they present
> > to Windows browsers. Then install this inside the VM. Even if not
> > activated, it runs for 1-2 hours before shutting down which should
> > be enough for most purposes you'll need it for.
> > 
> > If you already activated a Windows installation with your MS
> > account, with some luck your Win10 VM may even become digitally
> > activated (this happened to me). No cracks involved. Should be
> > legal enough. ;-) 
> > > But it is good to know, that the wine-workaround would either
> > > work or fail too early to damage anything.  
> > 
> > I tried some, and all failed because they didn't even find the
> > device. The ones that worked where either network based (flashing
> > via IP protocol) or using other simple interfaces (COM or LPT).
> >   
> > > Is there anything important to know before doing an emerge
> > > of wine (need I more than app-emulation/wine?) -- I have
> > > literally no experience with this emulator - the flashing
> > > tool is a 32bit gui application...) ???  
> > 
> > Wine = wine is no emulater ;-)
> > 
> > Actually, it's the Windows API implemented as .so files plus an EXE
> > loader to enable the kernel to run PE binaries (instead of ELF). So
> > nothing is emulated, it's running native. There's also a thin layer
> > of drivers implemented to transform API calls to native kernel
> > interfaces, like HID (for input devices). So everything connecting
> > to simple HID-USB should also work (some custom USB hardware just
> > implement a HID interface, it's simple and cheap).
> > 
> > If your applications work depends on if the required parts of the
> > API had been implemented (including the bugs that exists between
> > different versions of Windows).
> > 
> > So, with this knowledge, you simply emerge wine with the useflags
> > that look useful to you. If you don't need graphics (DirectX) or
> > don't want to apply your linux GUI theme to Windows apps, you can
> > ignore the staging useflag. Wine can be compiled with both 64bit
> > and 32bit support.
> > 
> > After installation, get familiar with the winecfg utility. It allows
> > mapping unix path to Windows drive letters. And it allows to set
> > Windows version per EXE you run (to expose different API bugs and
> > behavior to your application). Also, you can set DDL overrides
> > (which is what Windows itself uses when you run applications in
> > compatibility mode, or when you put DLL overrides manually in the
> > registry). Tho, here you can decide between native (native DLL on
> > filesystem) or builtin (*.dll.so file from Wine), and the order in
> > which they are tried.
> > 
> > You may also run with different WINEDEBUG settings if you want to
> > work out problems. There are fixme lines which usually show stub
> > implementations of API calls (functions that do nothing, and are
> > there just to return success or fail). You can use it like this:
> > 
> > # WINEDEBUG=-all wine your-exe-file.exe
> > 
> > If you'd like to easily manage different Wine prefixes, I'd
> > recommend using PlayOnLinux - it's not only useful to games. It
> > also has a long list of scripted installers for installing popular
> > Windows extensions that you may need (fonts, VB runtimes, C
> > runtimes) in different versions.
> > 
> > And then, maybe you want to use winetricks, tho it may be a bit
> > tricky to run this with PlayOnLinux because it will default to the
> > non-PlayOnLinux wine prefix. Easy work-around: Launch a commandline
> > shell from within PlayOnLinux and run winetricks there.
> > 
> > With PlayOnLinux you can easily reset or discard wine prefixes if
> > you messed up. Also, you can see each prefix as some sort of
> > compatibility profile you individually crafted per Windows
> > application you are running.
> > 
> > -- 
> > Regards,
> > Kai
> > 
> > Replies 

Re: [gentoo-user] Re: Shell echo missing after ctrl+c

[Dale]

Kai Krakow wrote:
> Am Sun, 19 Mar 2017 04:12:38 -0500
> schrieb Dale :
>
>> Kai Krakow wrote:
>>> Hello!
>>>
>>> More and more of my Gentoo systems are exhibiting the following
>>> strange and unexpected behavior:
>>>
>>> After ctrl+c'ing out of programs like tailf, SSH password prompts,
>>> in the middle of a shell scripts, the shell echo is not restored -
>>> that is: If I type characters I no longer see the characters (but
>>> they are received and can be executed by "enter"). If experiencing
>>> this, I have to ctrl+c again to discard what I was typing, the
>>> blindly type "reset" to reset the terminal, then echo is enabled
>>> again.
>>>
>>> I'm not sure which update or configuration is causing this. It
>>> started out on our Gentoo servers some years ago (which I'm only
>>> SSH'ed into, no physical access), now since a few weeks, also my
>>> desktop machines are affected. I have no explanation for this.
>>>
>>> But maybe anyone?
>>>
>>> BTW: I know from the old times (some 15-20 years ago) that ctrl+c
>>> out of a program (i.e. rsync) that starts a subshell (i.e. ssh)
>>> that in turn shows a password prompt, will leave you with an
>>> echoless shell. But it shows up on almost any occasion now.
>>>  
>> I don't have a solution but wanted to reply to say that this happens
>> to me too.  I have a regular desktop running KDE.  I use Konsole for
>> most of my command line activity.  I've noticed that this happens
>> with a lot of programs.  It has been happening so long, I thought
>> maybe it was the new way things are done.  It is aggravating and
>> confusing at times. 
>>
>> You are not alone on this.  I'm hoping someone will post a fix. 
> KDE with konsole here, too... But I don't think that's the common
> denominator. It's also happening from PuTTY in Windows.
>

I've likely had it happen on a regular console too.  I have just got so
used to it, I don't pay it any attention.  I suspect this is a deep
issue somewhere.  Maybe even as low level as the kernel somehow or close
to it. 

It will be interesting to see what it is tho.  Given how long it has
been doing it here at least, it's going to be a old commit/change which
may be difficult to track back. 

Dale

:-)  :-) 

Re: [gentoo-user] Flashing hardware via WINE ?

[tuxic]

On 03/19 10:27, Neil Bothwick wrote:
> On Sun, 19 Mar 2017 09:09:51 +0100, tu...@posteo.de wrote:
> 
> > I have a smart NiMH-charger with serial port (normally used to
> > dump chargeing curves to the PC).
> > The chargers firmware can bei flashed with a flashtool provided
> > by the vendor. The communication is via serial port. I have
> > a PCI=>serial.ports-card installed in my PC.
> > 
> > The command
> > 
> > file 
> > 
> > results in this information
> > 
> > PE32 executable (GUI) Intel 80386, for MS Windows
> > 
> > . As Linux user by heart I have no Windows.
> 
> Have you tried contacting the manufacturer to see if flashing from Linux
> is possible?
> 
> 
> -- 
> Neil Bothwick
> 
> I am MODERATOR of BORG. Follow the rules or be assimilated.

Hi Neil,

yes...no chance.
Linux is insecure...you know.
It makes it possible to spy the firmware and decrypt it on
the way to the charger.

Windows is much more secyre.

Earth is flat and there was no landing on the moon.

I believe in Santa Claus.

Cheers
Meino

Re: [gentoo-user] Re: Flashing hardware via WINE ?

[tuxic]

On 03/19 11:20, Kai Krakow wrote:
> Am Sun, 19 Mar 2017 09:57:22 +0100
> schrieb tu...@posteo.de:
> 
> > On 03/19 09:37, Kai Krakow wrote:
> > > Am Sun, 19 Mar 2017 09:09:51 +0100
> > > schrieb tu...@posteo.de:
> > >   
> > > > Hi,
> > > > 
> > > > I have a smart NiMH-charger with serial port (normally used to
> > > > dump chargeing curves to the PC).
> > > > The chargers firmware can bei flashed with a flashtool provided
> > > > by the vendor. The communication is via serial port. I have
> > > > a PCI=>serial.ports-card installed in my PC.
> > > > 
> > > > The command
> > > > 
> > > > file 
> > > > 
> > > > results in this information
> > > > 
> > > > PE32 executable (GUI) Intel 80386, for MS Windows
> > > > 
> > > > . As Linux user by heart I have no Windows.
> > > > 
> > > > May the attempt to install wine and use it for this purpose
> > > > a thinkable way or are the precoditions that way, that it
> > > > is due to those a NO-NO...?  
> > > 
> > > Flashing via serial port should be no problem from within Wine. It
> > > requires no special driver implementation.
> > > 
> > > However, if the hardware implements its own driver behind the serial
> > > port, it won't work anyways because on the Wine side there will be
> > > no such driver.
> > > 
> > > So I think, it should either work or fail early without doing
> > > damage. 
> > > 
> > >   
> > > > Does anyone have experience with such an attempt?  
> > > 
> > > I'm usually doing such things from VirtualBox by passing through the
> > > hardware (usually USB, that's easily done from within the GUI).
> > > 
> > > VirtualBox can also pass COM ports to the VM. You may want to try
> > > that as a second chance.
> > > 
> > > 
> > > -- 
> > > Regards,
> > > Kai
> > > 
> > > Replies to list-only preferred.  
> > 
> > Hi Kai (that's a rhyme! :)
> 
> Yeah, I know that one... If you are from Germany, you'll also get why
> my former nick (some years ago) was "Shark" :-)
> 
> > I have installed Virtualbox already and use the Linux Image I
> > installed there for banking purposes only. Feels more secure.
> 
> So something like application virtualization... You could maybe run in
> an isolated container, only exposing the xserver or run inside a nested
> xserver. It would probably greatly reduce startup times and not waste a
> complete image.
> 
> > I would prefer the WIndows-in-a-(virtual)box-solution) as you
> > do -- if I would own a Windows installation disc. But do not.
> 
> Well, you can easily get an image from MS using a Linux browser. Just
> go to the Windows 10 download page. It will show a selection form to
> choose the ISO instead of the nasty downloader they present to Windows
> browsers. Then install this inside the VM. Even if not activated, it
> runs for 1-2 hours before shutting down which should be enough for most
> purposes you'll need it for.
> 
> If you already activated a Windows installation with your MS account,
> with some luck your Win10 VM may even become digitally activated (this
> happened to me). No cracks involved. Should be legal enough. ;-)
> 
> > But it is good to know, that the wine-workaround would either
> > work or fail too early to damage anything.
> 
> I tried some, and all failed because they didn't even find the device.
> The ones that worked where either network based (flashing via IP
> protocol) or using other simple interfaces (COM or LPT).
> 
> > Is there anything important to know before doing an emerge
> > of wine (need I more than app-emulation/wine?) -- I have
> > literally no experience with this emulator - the flashing
> > tool is a 32bit gui application...) ???
> 
> Wine = wine is no emulater ;-)
> 
> Actually, it's the Windows API implemented as .so files plus an EXE
> loader to enable the kernel to run PE binaries (instead of ELF). So
> nothing is emulated, it's running native. There's also a thin layer of
> drivers implemented to transform API calls to native kernel interfaces,
> like HID (for input devices). So everything connecting to simple
> HID-USB should also work (some custom USB hardware just implement a HID
> interface, it's simple and cheap).
> 
> If your applications work depends on if the required parts of the API
> had been implemented (including the bugs that exists between different
> versions of Windows).
> 
> So, with this knowledge, you simply emerge wine with the useflags that
> look useful to you. If you don't need graphics (DirectX) or don't want
> to apply your linux GUI theme to Windows apps, you can ignore the
> staging useflag. Wine can be compiled with both 64bit and 32bit support.
> 
> After installation, get familiar with the winecfg utility. It allows
> mapping unix path to Windows drive letters. And it allows to set
> Windows version per EXE you run (to expose different API bugs and
> behavior to your application). Also, you can set DDL overrides (which
> is what Windows itself uses when you run applications in compatibility
> mode, or when you put DLL overrides manually 

Re: [gentoo-user] Flashing hardware via WINE ?

[Neil Bothwick]

On Sun, 19 Mar 2017 09:09:51 +0100, tu...@posteo.de wrote:

> I have a smart NiMH-charger with serial port (normally used to
> dump chargeing curves to the PC).
> The chargers firmware can bei flashed with a flashtool provided
> by the vendor. The communication is via serial port. I have
> a PCI=>serial.ports-card installed in my PC.
> 
> The command
> 
> file 
> 
> results in this information
> 
> PE32 executable (GUI) Intel 80386, for MS Windows
> 
> . As Linux user by heart I have no Windows.

Have you tried contacting the manufacturer to see if flashing from Linux
is possible?


-- 
Neil Bothwick

I am MODERATOR of BORG. Follow the rules or be assimilated.


pgpfRJtZtP5Ut.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: Shell echo missing after ctrl+c

[Kai Krakow]

Am Sun, 19 Mar 2017 04:12:38 -0500
schrieb Dale :

> Kai Krakow wrote:
> > Hello!
> >
> > More and more of my Gentoo systems are exhibiting the following
> > strange and unexpected behavior:
> >
> > After ctrl+c'ing out of programs like tailf, SSH password prompts,
> > in the middle of a shell scripts, the shell echo is not restored -
> > that is: If I type characters I no longer see the characters (but
> > they are received and can be executed by "enter"). If experiencing
> > this, I have to ctrl+c again to discard what I was typing, the
> > blindly type "reset" to reset the terminal, then echo is enabled
> > again.
> >
> > I'm not sure which update or configuration is causing this. It
> > started out on our Gentoo servers some years ago (which I'm only
> > SSH'ed into, no physical access), now since a few weeks, also my
> > desktop machines are affected. I have no explanation for this.
> >
> > But maybe anyone?
> >
> > BTW: I know from the old times (some 15-20 years ago) that ctrl+c
> > out of a program (i.e. rsync) that starts a subshell (i.e. ssh)
> > that in turn shows a password prompt, will leave you with an
> > echoless shell. But it shows up on almost any occasion now.
> >  
> 
> I don't have a solution but wanted to reply to say that this happens
> to me too.  I have a regular desktop running KDE.  I use Konsole for
> most of my command line activity.  I've noticed that this happens
> with a lot of programs.  It has been happening so long, I thought
> maybe it was the new way things are done.  It is aggravating and
> confusing at times. 
> 
> You are not alone on this.  I'm hoping someone will post a fix. 

KDE with konsole here, too... But I don't think that's the common
denominator. It's also happening from PuTTY in Windows.

-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: Flashing hardware via WINE ?

[Kai Krakow]

Am Sun, 19 Mar 2017 09:57:22 +0100
schrieb tu...@posteo.de:

> On 03/19 09:37, Kai Krakow wrote:
> > Am Sun, 19 Mar 2017 09:09:51 +0100
> > schrieb tu...@posteo.de:
> >   
> > > Hi,
> > > 
> > > I have a smart NiMH-charger with serial port (normally used to
> > > dump chargeing curves to the PC).
> > > The chargers firmware can bei flashed with a flashtool provided
> > > by the vendor. The communication is via serial port. I have
> > > a PCI=>serial.ports-card installed in my PC.
> > > 
> > > The command
> > > 
> > > file 
> > > 
> > > results in this information
> > > 
> > > PE32 executable (GUI) Intel 80386, for MS Windows
> > > 
> > > . As Linux user by heart I have no Windows.
> > > 
> > > May the attempt to install wine and use it for this purpose
> > > a thinkable way or are the precoditions that way, that it
> > > is due to those a NO-NO...?  
> > 
> > Flashing via serial port should be no problem from within Wine. It
> > requires no special driver implementation.
> > 
> > However, if the hardware implements its own driver behind the serial
> > port, it won't work anyways because on the Wine side there will be
> > no such driver.
> > 
> > So I think, it should either work or fail early without doing
> > damage. 
> > 
> >   
> > > Does anyone have experience with such an attempt?  
> > 
> > I'm usually doing such things from VirtualBox by passing through the
> > hardware (usually USB, that's easily done from within the GUI).
> > 
> > VirtualBox can also pass COM ports to the VM. You may want to try
> > that as a second chance.
> > 
> > 
> > -- 
> > Regards,
> > Kai
> > 
> > Replies to list-only preferred.  
> 
> Hi Kai (that's a rhyme! :)

Yeah, I know that one... If you are from Germany, you'll also get why
my former nick (some years ago) was "Shark" :-)

> I have installed Virtualbox already and use the Linux Image I
> installed there for banking purposes only. Feels more secure.

So something like application virtualization... You could maybe run in
an isolated container, only exposing the xserver or run inside a nested
xserver. It would probably greatly reduce startup times and not waste a
complete image.

> I would prefer the WIndows-in-a-(virtual)box-solution) as you
> do -- if I would own a Windows installation disc. But do not.

Well, you can easily get an image from MS using a Linux browser. Just
go to the Windows 10 download page. It will show a selection form to
choose the ISO instead of the nasty downloader they present to Windows
browsers. Then install this inside the VM. Even if not activated, it
runs for 1-2 hours before shutting down which should be enough for most
purposes you'll need it for.

If you already activated a Windows installation with your MS account,
with some luck your Win10 VM may even become digitally activated (this
happened to me). No cracks involved. Should be legal enough. ;-)

> But it is good to know, that the wine-workaround would either
> work or fail too early to damage anything.

I tried some, and all failed because they didn't even find the device.
The ones that worked where either network based (flashing via IP
protocol) or using other simple interfaces (COM or LPT).

> Is there anything important to know before doing an emerge
> of wine (need I more than app-emulation/wine?) -- I have
> literally no experience with this emulator - the flashing
> tool is a 32bit gui application...) ???

Wine = wine is no emulater ;-)

Actually, it's the Windows API implemented as .so files plus an EXE
loader to enable the kernel to run PE binaries (instead of ELF). So
nothing is emulated, it's running native. There's also a thin layer of
drivers implemented to transform API calls to native kernel interfaces,
like HID (for input devices). So everything connecting to simple
HID-USB should also work (some custom USB hardware just implement a HID
interface, it's simple and cheap).

If your applications work depends on if the required parts of the API
had been implemented (including the bugs that exists between different
versions of Windows).

So, with this knowledge, you simply emerge wine with the useflags that
look useful to you. If you don't need graphics (DirectX) or don't want
to apply your linux GUI theme to Windows apps, you can ignore the
staging useflag. Wine can be compiled with both 64bit and 32bit support.

After installation, get familiar with the winecfg utility. It allows
mapping unix path to Windows drive letters. And it allows to set
Windows version per EXE you run (to expose different API bugs and
behavior to your application). Also, you can set DDL overrides (which
is what Windows itself uses when you run applications in compatibility
mode, or when you put DLL overrides manually in the registry). Tho,
here you can decide between native (native DLL on filesystem) or builtin
(*.dll.so file from Wine), and the order in which they are tried.

You may also run with different WINEDEBUG settings if you want to work
out problems. There are fixme lines 

Re: [gentoo-user] Shell echo missing after ctrl+c

[tuxic]

On 03/19 10:17, Matthias Hanft wrote:
> Kai Krakow wrote:
> > 
> > After ctrl+c'ing out of programs like tailf, SSH password prompts, in
> > the middle of a shell scripts, the shell echo is not restored
> 
> Not here, but something similar: Immediately after ctrl+c'ing, no shell
> prompt is displayed (in fact, *nothing* is displayed) - but it's just
> the display; I can enter a shell command (with echo, too) which will
> be executed properly. Or just press the RETURN key on the empty line
> to get the shell prompt again.
> 
> This happens just on a single of my Gentoo systems (and not always,
> but very often).
> 
> Any idea?
> 
> -Matt
> 
> 
Hi,

I haven't experienced this yet...but  the command

'reset'

will reset (hence the name... ;) the terminal to
normal. This also helps, if the terminal got confused
after accidentally cat'ing a binary...

Cheers
Meino

Re: [gentoo-user] Shell echo missing after ctrl+c

[Matthias Hanft]

Kai Krakow wrote:
> 
> After ctrl+c'ing out of programs like tailf, SSH password prompts, in
> the middle of a shell scripts, the shell echo is not restored

Not here, but something similar: Immediately after ctrl+c'ing, no shell
prompt is displayed (in fact, *nothing* is displayed) - but it's just
the display; I can enter a shell command (with echo, too) which will
be executed properly. Or just press the RETURN key on the empty line
to get the shell prompt again.

This happens just on a single of my Gentoo systems (and not always,
but very often).

Any idea?

-Matt

Re: [gentoo-user] Shell echo missing after ctrl+c

[Dale]

Kai Krakow wrote:
> Hello!
>
> More and more of my Gentoo systems are exhibiting the following
> strange and unexpected behavior:
>
> After ctrl+c'ing out of programs like tailf, SSH password prompts, in
> the middle of a shell scripts, the shell echo is not restored - that
> is: If I type characters I no longer see the characters (but they are
> received and can be executed by "enter"). If experiencing this, I have
> to ctrl+c again to discard what I was typing, the blindly type "reset"
> to reset the terminal, then echo is enabled again.
>
> I'm not sure which update or configuration is causing this. It started
> out on our Gentoo servers some years ago (which I'm only SSH'ed into,
> no physical access), now since a few weeks, also my desktop machines are
> affected. I have no explanation for this.
>
> But maybe anyone?
>
> BTW: I know from the old times (some 15-20 years ago) that ctrl+c out
> of a program (i.e. rsync) that starts a subshell (i.e. ssh) that in
> turn shows a password prompt, will leave you with an echoless shell.
> But it shows up on almost any occasion now.
>

I don't have a solution but wanted to reply to say that this happens to
me too.  I have a regular desktop running KDE.  I use Konsole for most
of my command line activity.  I've noticed that this happens with a lot
of programs.  It has been happening so long, I thought maybe it was the
new way things are done.  It is aggravating and confusing at times. 

You are not alone on this.  I'm hoping someone will post a fix. 

Dale

:-)  :-) 

Re: [gentoo-user] Re: Flashing hardware via WINE ?

[tuxic]

On 03/19 09:37, Kai Krakow wrote:
> Am Sun, 19 Mar 2017 09:09:51 +0100
> schrieb tu...@posteo.de:
> 
> > Hi,
> > 
> > I have a smart NiMH-charger with serial port (normally used to
> > dump chargeing curves to the PC).
> > The chargers firmware can bei flashed with a flashtool provided
> > by the vendor. The communication is via serial port. I have
> > a PCI=>serial.ports-card installed in my PC.
> > 
> > The command
> > 
> > file 
> > 
> > results in this information
> > 
> > PE32 executable (GUI) Intel 80386, for MS Windows
> > 
> > . As Linux user by heart I have no Windows.
> > 
> > May the attempt to install wine and use it for this purpose
> > a thinkable way or are the precoditions that way, that it
> > is due to those a NO-NO...?
> 
> Flashing via serial port should be no problem from within Wine. It
> requires no special driver implementation.
> 
> However, if the hardware implements its own driver behind the serial
> port, it won't work anyways because on the Wine side there will be no
> such driver.
> 
> So I think, it should either work or fail early without doing damage. 
> 
> 
> > Does anyone have experience with such an attempt?
> 
> I'm usually doing such things from VirtualBox by passing through the
> hardware (usually USB, that's easily done from within the GUI).
> 
> VirtualBox can also pass COM ports to the VM. You may want to try that
> as a second chance.
> 
> 
> -- 
> Regards,
> Kai
> 
> Replies to list-only preferred.

Hi Kai (that's a rhyme! :)

I have installed Virtualbox already and use the Linux Image I
installed there for banking purposes only. Feels more secure.

I would prefer the WIndows-in-a-(virtual)box-solution) as you
do -- if I would own a Windows installation disc. But do not.

But it is good to know, that the wine-workaround would either
work or fail too early to damage anything.

Is there anything important to know before doing an emerge
of wine (need I more than app-emulation/wine?) -- I have
literally no experience with this emulator - the flashing
tool is a 32bit gui application...) ???

Cheers
Meino

[gentoo-user] Shell echo missing after ctrl+c

[Kai Krakow]

Hello!

More and more of my Gentoo systems are exhibiting the following
strange and unexpected behavior:

After ctrl+c'ing out of programs like tailf, SSH password prompts, in
the middle of a shell scripts, the shell echo is not restored - that
is: If I type characters I no longer see the characters (but they are
received and can be executed by "enter"). If experiencing this, I have
to ctrl+c again to discard what I was typing, the blindly type "reset"
to reset the terminal, then echo is enabled again.

I'm not sure which update or configuration is causing this. It started
out on our Gentoo servers some years ago (which I'm only SSH'ed into,
no physical access), now since a few weeks, also my desktop machines are
affected. I have no explanation for this.

But maybe anyone?

BTW: I know from the old times (some 15-20 years ago) that ctrl+c out
of a program (i.e. rsync) that starts a subshell (i.e. ssh) that in
turn shows a password prompt, will leave you with an echoless shell.
But it shows up on almost any occasion now.

-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: Flashing hardware via WINE ?

[Kai Krakow]

Am Sun, 19 Mar 2017 09:09:51 +0100
schrieb tu...@posteo.de:

> Hi,
> 
> I have a smart NiMH-charger with serial port (normally used to
> dump chargeing curves to the PC).
> The chargers firmware can bei flashed with a flashtool provided
> by the vendor. The communication is via serial port. I have
> a PCI=>serial.ports-card installed in my PC.
> 
> The command
> 
> file 
> 
> results in this information
> 
> PE32 executable (GUI) Intel 80386, for MS Windows
> 
> . As Linux user by heart I have no Windows.
> 
> May the attempt to install wine and use it for this purpose
> a thinkable way or are the precoditions that way, that it
> is due to those a NO-NO...?

Flashing via serial port should be no problem from within Wine. It
requires no special driver implementation.

However, if the hardware implements its own driver behind the serial
port, it won't work anyways because on the Wine side there will be no
such driver.

So I think, it should either work or fail early without doing damage. 


> Does anyone have experience with such an attempt?

I'm usually doing such things from VirtualBox by passing through the
hardware (usually USB, that's easily done from within the GUI).

VirtualBox can also pass COM ports to the VM. You may want to try that
as a second chance.


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Flashing hardware via WINE ?

[tuxic]

Hi,

I have a smart NiMH-charger with serial port (normally used to
dump chargeing curves to the PC).
The chargers firmware can bei flashed with a flashtool provided
by the vendor. The communication is via serial port. I have
a PCI=>serial.ports-card installed in my PC.

The command

file 

results in this information

PE32 executable (GUI) Intel 80386, for MS Windows

. As Linux user by heart I have no Windows.

May the attempt to install wine and use it for this purpose
a thinkable way or are the precoditions that way, that it
is due to those a NO-NO...?

Does anyone have experience with such an attempt?

Cheers
Meino

Re: [gentoo-user] Diskless nodes

[thelma]

On 03/18/2017 05:33 AM, Rich Freeman wrote:
> On Sat, Mar 18, 2017 at 4:25 AM, Ural  wrote:
>> Rich Freeman:
>>> On Thu, Mar 16, 2017 at 11:12 PM,   wrote:

 So, instead of getting into trouble of making disk-less node I figure it 
 out my Atom (small box) can access Main server via X2GO.  I tested it on 
 my local network and speed wise it works OK.  Buy my computer is much 
 faster than the Atom.  So after upgrade I'll see how it will run. All 
 boxes have gigabit network cards.

>>>
>>> While this would certainly work, you should also consider using a
>>> windows technology like rdp/citrix to connect directly from the client
>>> to the VM guest.  That might actually give you better performance.
>>>
>>> It is analogous to running a linux VM in a window and typing into its
>>> console, vs running a linux VM headless and using ssh to connect to
>>> it.  Ssh is probably going to give you a more integrated experience
>>> and better performance, because you're not virtualizing a console with
>>> minimal support for stuff like the clipboard/etc.
>>>
>>
>> Try using Nomachine.com NX. It is fastest remote connection, but it is
>> proprietary. There is open source client available for Linux
>>
> 
> x2go is based on NX.  I doubt that NX + VM console window is faster
> than Citrix for accessing a Windows machine.  NX was largely inspired
> by Citrix.
> 
> Both approaches have their pros and cons.  NX is the right solution
> for accessing a linux X11 server.  rdp/citrix is probably the right
> solution for accessing a windows console.  So, the question is whether
> you want to be accessing the VM console running on Linux, or directly
> accessing the windows console running inside the VM.  I suspect that
> the latter is going to be a bit cleaner when you consider things like
> clipboard support and such.  But, if you want to be able to start/stop
> the VM and such then obviously you can't do that from the windows
> console.

OK, I've maxed the RAM on Linux server that will be running two
VM-Windows7 with 32GB of RAM and it has SSD so it should handle the load
(8-core AMD).
One VM-Windows7 run a program as a server the other VM-Windows7 acts as
a client, run by another user. Another user will log to the his account
on a sever via X2GO and start VM-Windows7 (run the same program but in a
client mode).

I've NX as well, but they have closed the source.  X2GO was easier to
install as well.

The rdp might work.  It would be best if I could by-pass the switch,
since both VM's are running on the same Linux server.

--
Thelma