Re: Debian 7.8 sand KDE4: Problem with konsole (and gnome-terminal)
Hi Trent, thanks for the answer.
for the last few weeks I have problems with unresponsive konsoles (and gnome-terminals as well, I tried) under KDE with Debian 7.8.
Please not: I meant konsole, the KDE terminal, not the text console of a Debian system. I may have confused you here, sorry.
They seem to be extremely slow (I have to wait for 10 seconds after entering a simple command) and I believe it happens only when I am running commands with large output in other windows (e.g. a ssh session to a FreeBSD server and "make buildworld")
When this happens, check loadavg (it should be below N, where N is the number of CPU cores); check for procs in D state; check iostat; check free.
My problem is not the "make" on the FreeBSD server, it is the graphical terminal(KDE's konsole or gnome-terminal)
In my experience with fbcon, large output (e.g. dmesg or cat /var/log/syslog) will slow the entire system noticably, but switching to another vt (Ctrl+Alt+F2) "fixes" it.
I also noticed it running scren inside xterm, but it was MUCH MUCH MUCH faster to recover -- it's the main reason I start X by default these days.
Until now I have not seen it inside xterm. It seems to be the terminal application itself, konsole or gnome-terminal, which holds all terminals in one application. It means, KDE's konsole becomes unresponsive. I can switch to IceWeazel (e.g.) but the drawing of another konsole window takes a long long time.
Are you running screen / tmux?
When this happens, is the "lots of output" window onscreen? Try minimizing it (konsole) and switching window or detaching (screen), so that fewer layers are trying to render the "lots of output".
I am running things sometimes in screen but I am not sure whether it was always the case when I experienced the problem. Sometimes the "large output" window is a hidden tab or in a different workspace. So the actual rendering does not seem to be the problem. The problem appeared only recently.. so I wonder what kind of change could have triggered it. I also run KDE's konsole on a much less powerful laptop running PC-BSD + Fluxbox. I have not seen the problem there at all. I actually like the KDE but I always seem to get to a point where some things are becoming unstable. So at the end I usually return to other X11 environments which are lite. I am just installing Fluxbox.. I do not want to worry about my own desktop. I want to concentrate on the servers I look after.. Regards Peter
On Wed, Apr 08, 2015 at 12:37:23PM +1000, Peter Ross wrote:
In my experience with fbcon, large output (e.g. dmesg or cat /var/log/syslog) will slow the entire system noticably, but switching to another vt (Ctrl+Alt+F2) "fixes" it.
I also noticed it running scren inside xterm, but it was MUCH MUCH MUCH faster to recover -- it's the main reason I start X by default these days.
Until now I have not seen it inside xterm.
It seems to be the terminal application itself, konsole or gnome-terminal, which holds all terminals in one application.
It means, KDE's konsole becomes unresponsive. I can switch to IceWeazel (e.g.) but the drawing of another konsole window takes a long long time.
xterm is much faster than gnome-terminal (or anything else that depends on libvte)...that's mostly because libvte is horribly slow (partly because it does more complicated things, like unicode) e.g. try running 'time ls -lR /' in xterm, gnome-terminal, and konsole. xterm will finish much faster than the other two. mrxvt (my previous favourite terminal) is also much faster than any libvte-based terminal, about as fast as plain old xterm. unfortunately, it doesn't support unicode so i finally gave up using it a couple of years ago (i switched to roxterm which is, IMO, the least crappy of the libvte-based terminals - i tried them all when i reluctantly accepted that i'd have to give up mrxvt) i have no idea about Konsole because I don't use it...but i suspect that if it does fancy modern stuff like unicode then it's probably also slow like libvte. craig -- craig sanders <cas@taz.net.au>
Craig Sanders <cas@taz.net.au> writes:
mrxvt (my previous favourite terminal) is also much faster than any libvte-based terminal, about as fast as plain old xterm. unfortunately, it doesn't support unicode so i finally gave up using it a couple of years ago (i switched to roxterm which is, IMO, the least crappy of the libvte-based terminals - i tried them all when i reluctantly accepted that i'd have to give up mrxvt)
Obligatory mention of urxvt (rxvt-unicode) if you just need CJKV, and (IIRC) mlterm if you need bidi. I can heartily recommend urxvt. I've never tried mlterm seriously. I don't know how they compare to libvte for m18n support, because libvte didn't exist last time I cared about such things. Also nitpick: xterm *does* support unicode, it just doesn't support non-latin/cyrillic/greek orthographies very well. Obs. xterm -u8 / uxterm.
On Thu, Apr 09, 2015 at 11:53:18AM +1000, Trent W. Buck wrote:
Craig Sanders <cas@taz.net.au> writes:
mrxvt (my previous favourite terminal) is also much faster than any libvte-based terminal, about as fast as plain old xterm. unfortunately, it doesn't support unicode so i finally gave up using it a couple of years ago (i switched to roxterm which is, IMO, the least crappy of the libvte-based terminals - i tried them all when i reluctantly accepted that i'd have to give up mrxvt)
Obligatory mention of urxvt (rxvt-unicode) if you just need CJKV, and (IIRC) mlterm if you need bidi.
i tried urxvt, didn't like it. it might have started from the same base code as mrxvt long ago, but it forked in a wildly different direction. i disliked urxvt enough that even libvte-based terms are preferable. mostly i need unicode so that i don't get '?' characters all over the screen when viewing text created on unicode systems, e.g. email or viewing web pages in links or lynx. and so that the terminal accounts for line-width and characters-displayed-per-line correctly. i've come to accept roxterm as 'good enough'...i've got used to its quirks just as i got used to mrxvt's quirks.
Also nitpick: xterm *does* support unicode, it just doesn't support non-latin/cyrillic/greek orthographies very well. Obs. xterm -u8 / uxterm.
i've ignored xterm for years because it doesn't do tabs and resizing for readable fonts on high-resolution displays is a PITA. craig -- craig sanders <cas@taz.net.au>
On Thu, 9 Apr 2015, Craig Sanders wrote:
On Thu, Apr 09, 2015 at 11:53:18AM +1000, Trent W. Buck wrote:
Craig Sanders <cas@taz.net.au> writes:
mrxvt (my previous favourite terminal) is also much faster than any libvte-based terminal, about as fast as plain old xterm. unfortunately, it doesn't support unicode so i finally gave up using it a couple of years ago (i switched to roxterm which is, IMO, the least crappy of the libvte-based terminals - i tried them all when i reluctantly accepted that i'd have to give up mrxvt)
Obligatory mention of urxvt (rxvt-unicode) if you just need CJKV, and (IIRC) mlterm if you need bidi.
i tried urxvt, didn't like it. it might have started from the same base code as mrxvt long ago, but it forked in a wildly different direction.
i disliked urxvt enough that even libvte-based terms are preferable.
Heh. My biggest problems were all of the menu options removed. And it just didn't seem to work so well.
mostly i need unicode so that i don't get '?' characters all over the screen when viewing text created on unicode systems, e.g. email or viewing web pages in links or lynx. and so that the terminal accounts for line-width and characters-displayed-per-line correctly.
xterm satisfies this well.
i've come to accept roxterm as 'good enough'...i've got used to its quirks just as i got used to mrxvt's quirks.
Also nitpick: xterm *does* support unicode, it just doesn't support non-latin/cyrillic/greek orthographies very well. Obs. xterm -u8 / uxterm.
i've ignored xterm for years because it doesn't do tabs and resizing for readable fonts on high-resolution displays is a PITA.
meh, set and forget. These look like my relevent settings: !to get meta characters to be able to be input in bash and emacs in an xterm: !http://www.leonerd.org.uk/hacks/hints/xterm-8bit.html XTerm*VT100.utf8: 1 XTerm*VT100.eightBitInput: false XTerm*VT100.eightBitControl: false XTerm*VT100.eightBitOutput: true !http://www.leonerd.org.uk/hacks/hints/xterm-sensible.html !When using xft fonts (facename below), these below just set the relative scalings and where the default font size fits in relative to the other font sizes XTerm*VT100.faceName: DejaVu Sans Mono XTerm*VT100.boldFont: DejaVu Sans Mono:style=Bold XTerm*VT100.faceSize: 9 XTerm*VT100.faceSize1: 1 XTerm*VT100.faceSize2: 5 XTerm*VT100.faceSize3: 7 XTerm*VT100.faceSize4: 11 XTerm*VT100.faceSize5: 14 XTerm*VT100.faceSize6: 17 XTerm*VT100.Font2: -*-dejavu sans mono-medium-r-*-*-8-*-*-*-*-*-iso10646-1 XTerm*VT100.Font3: -*-dejavu sans mono-medium-r-*-*-10-*-*-*-*-*-iso10646-1 XTerm*VT100.Font: -*-dejavu sans mono-medium-r-*-*-14-*-*-*-*-*-iso10646-1 XTerm*VT100.Font4: -*-dejavu sans mono-medium-r-*-*-18-*-*-*-*-*-iso10646-1 XTerm*VT100.Font5: -*-dejavu sans mono-medium-r-*-*-20-*-*-*-*-*-iso10646-1 XTerm*VT100.Font6: -*-dejavu sans mono-medium-r-*-*-24-*-*-*-*-*-iso10646-1 -- Tim Connors
On Mon, Apr 13, 2015 at 10:35:10AM +1000, Tim Connors wrote:
i've ignored xterm for years because it doesn't do tabs and resizing for readable fonts on high-resolution displays is a PITA.
meh, set and forget. These look like my relevent settings:
so xterm supports multiple tabs now? (as in tabbed windows, not the tab character or tab-stop settings) AFAIK, it doesn't - and it's a feature i consider to be essential. craig -- craig sanders <cas@taz.net.au>
On Mon, 13 Apr 2015 19:33 Craig Sanders <cas@taz.net.au> wrote: so xterm supports multiple tabs now? With screen or tmux (preferred) it does :-)
2015-04-13 12:26 GMT+02:00 Brian May <brian@microcomaustralia.com.au>:
On Mon, 13 Apr 2015 19:33 Craig Sanders <cas@taz.net.au> wrote:
so xterm supports multiple tabs now?
With screen or tmux (preferred) it does :-)
I red that even FluxBox window manager can group a set of windows in a tab-view, but I haven't tried yet.
-- Mick
2015-04-13 12:26 GMT+02:00 Brian May <brian@microcomaustralia.com.au>: On Mon, 13 Apr 2015 19:33 Craig Sanders <cas@taz.net.au> wrote:
so xterm supports multiple tabs now?
With screen or tmux (preferred) it does :-)
http://fluxbox.org/features/ -- Mick
On Mon, Apr 13, 2015 at 10:26:22AM +0000, Brian May wrote:
On Mon, 13 Apr 2015 19:33 Craig Sanders <cas@taz.net.au> wrote:
so xterm supports multiple tabs now?
With screen or tmux (preferred) it does :-)
no, it doesnt. they're not the same thing, not even similar. i run screen inside tabbed termninals, usually over ssh with one tab per remote host. one of the things i use screen for is so that i can attach to my screen sessions from whatever machine i happen to be physically at - including my desktop, my mythtv machine, the machine in my dialysis room(*), and hopefully in the not too distant future at work again (when i fully recover from my recent surgery in a few weeks, i'll be well enough to have at least a part-time job again...if i can find one, part-time sysadmin jobs are hard to find). (*) where i am right now - being a part time cyborg - so my typing is slow and error prone. this machine also doubles as another myth box because TV passes the time very quickly while stuck in this chair. craig -- craig sanders <cas@taz.net.au>
Craig Sanders <cas@taz.net.au> writes:
On Mon, Apr 13, 2015 at 10:26:22AM +0000, Brian May wrote:
On Mon, 13 Apr 2015 19:33 Craig Sanders <cas@taz.net.au> wrote:
so xterm supports multiple tabs now?
With screen or tmux (preferred) it does :-)
no, it doesnt. they're not the same thing, not even similar.
i run screen inside tabbed termninals, usually over ssh with one tab per remote host. one of the things i use screen for is so that i can attach to my screen sessions from whatever machine i happen to be physically at - including my desktop
Uh, you just nest screen sessions. The outer one is local, the inner ones are on the far end of SSHs. If you have :caption always or :hardstatus alwayslastline, the window titles are effectively tabs. You can't "click" on them, but you can ^A1 or ^A' or ^A" to jump to a specific one by number or name, or ^A^A/^ASPC/^A^H to jump around. If you're only using screen as dtach, you're missing most of its functionality.
On Tue, Apr 14, 2015 at 12:45:51PM +1000, Trent W. Buck wrote:
Craig Sanders <cas@taz.net.au> writes:
On Mon, Apr 13, 2015 at 10:26:22AM +0000, Brian May wrote:
On Mon, 13 Apr 2015 19:33 Craig Sanders <cas@taz.net.au> wrote:
so xterm supports multiple tabs now?
With screen or tmux (preferred) it does :-)
no, it doesnt. they're not the same thing, not even similar.
i run screen inside tabbed termninals, usually over ssh with one tab per remote host. one of the things i use screen for is so that i can attach to my screen sessions from whatever machine i happen to be physically at - including my desktop
Uh, you just nest screen sessions. The outer one is local, the inner ones are on the far end of SSHs.
uh, no. i run multiple and sometimes even nested screen sessions but nested screens really don't work for me as a substitute for tabs.
You can't "click" on them, but you can ^A1 or ^A' or ^A" to jump to a specific one by number or name, or ^A^A/^ASPC/^A^H to jump around.
i redefine the escape key to be ^K becausee ^A is just far too useful on the bash command line to sacrifice, whereas ^K isn't used for anything at all (at least, nothing that matters to me)
If you're only using screen as dtach, you're missing most of its functionality.
that's not all i use it for, but my two main uses are detach/attach and having multiple shells available on the one ssh session. and sometimes i use the cut and paste abilities of screen's backscroll buffer. craig -- craig sanders <cas@taz.net.au>
2015-04-14 5:44 GMT+02:00 Craig Sanders <cas@taz.net.au>:
You can't "click" on them, but you can ^A1 or ^A' or ^A" to jump to a specific one by number or name, or ^A^A/^ASPC/^A^H to jump around.
i redefine the escape key to be ^K becausee ^A is just far too useful on the bash command line to sacrifice, whereas ^K isn't used for anything at all (at least, nothing that matters to me)
Of course, if you use the cut&past features of screen, you don't need the emacs-like kill&yank feature of the bash command line. ^K kills characters from the cursor to the end of the line. I've been using it for lots of years just to delete the line, and I realize only later that such deleted characters can be yanked. Personally I find the ^A-A keybinding quick enough; the problem rises whenever I frequently switch between using and not using screen, thus I confuse ^A whith ^A-A :-D -- Mick
Craig Sanders <cas@taz.net.au> writes:
i've ignored xterm for years because it doesn't do tabs
http://tools.suckless.org/tabbed/ Or: "why reinvent tabs separately in each app?" :-) I've never tried it myself; I use screen for this.
and resizing for readable fonts on high-resolution displays is a PITA.
If you still have a numeric keypad, Alt+Shift+KP_Plus (IIRC). Doesn't work if you manually set a size, e.g. xterm -fa Monospace # works xterm -fa Monospace-8 # does not work xterm -fa Monospace:pixelsize=6 # does not work For urxvt, long ago I had these: ! Bind C-0, C-+ and C-= to activate medium, big, & small font size respectively. URxvt.font: xft:Monospace-7 URxvt.keysym.C-minus: command:\033]710;xft:Monospace-7\007 URxvt.keysym.C-0: command:\033]710;xft:Monospace\007 URxvt.keysym.C-equal: command:\033]710;xft:Monospace-19\007
Quoting Trent W. Buck (trentbuck@gmail.com):
Also nitpick: xterm *does* support unicode, it just doesn't support non-latin/cyrillic/greek orthographies very well. Obs. xterm -u8 / uxterm.
It supports us weirdo Scandihoovians with our 'Latin-plus' alphabets well, FWIW. (Those aren't diacriticals you see in Scandinavian words, but rather distinct letters.[1] They have spots in alphabetical order following the letter zed. More at: https://www.youtube.com/watch?v=f488uJAQgmw ) [1] Comedian Garrison Keillor, who had long residence in Denmark, once observed that the letter that looks like an 'o' with a diagonal line through it means 'This word cannot be pronounced by Americans.'
Rick Moen <rick@linuxmafia.com> writes:
Quoting Trent W. Buck (trentbuck@gmail.com):
Also nitpick: xterm *does* support unicode, it just doesn't support non-latin/cyrillic/greek orthographies very well. Obs. xterm -u8 / uxterm.
It supports us weirdo Scandihoovians with our 'Latin-plus' alphabets well, FWIW. (Those aren't diacriticals you see in Scandinavian words, but rather distinct letters.[1] They have spots in alphabetical order following the letter zed.
I was imlicitly including those under "Latin orthography" --- just like "U" and "W" and lowercase letters ;-) Hm, let's do a quick and misrepresentative test. $ xterm -fa Monospace -e emacs -Q -f view-hello-file -f follow-mode -f split-window-right $ urxvt -fn xft:Monospace -e emacs -Q -f view-hello-file -f follow-mode -f split-window-right $ mlterm -type xft -fg white -bg black -e emacs -Q -f view-hello-file -f follow-mode -f split-window-right I tried mrxvt, but the output was copletely buggered - it interpreted output from Emacs as ISO-8859-1 instead of UTF-8. I couldn't find anything relevant in the manual except -km, and guessing how to use that didn't work. I didn't bother to manually define fontsets, but all those orthographies (except maybe Han) definitely have working fontconfig aliases set up already. Terminals emulators using fontconfig (not just xft) should've Just Worked for all the fonts below. I *do not* have any i18n fonts installed for the X font system (the old bitmap stuff), which is probably why mlterm is so broken. bash4$ lsb_release -d Description: Debian GNU/Linux 8.0 (jessie) $ aptitude search --disable-columns -F '%p %v' ~i~sfont | column -t culmus 0.130-1 fontconfig 2.11.0-6.1 fontconfig-config 2.11.0-6.1 fonts-arabeyes 2.1-3 fonts-croscore 1.23.0-1 fonts-crosextra-caladea 20130214-1 fonts-crosextra-carlito 20130920-1 fonts-dejavu-core 2.34-1 fonts-droid 1:4.4.4r2-4 fonts-dzongkha 0.3-8 fonts-farsiweb 0.4.dfsg-12 fonts-ipafont 00303-12 fonts-ipafont-gothic 00303-12 fonts-ipafont-mincho 00303-12 fonts-kacst 2.01+mry-10 fonts-kacst-one 5.0+svn11846-7 fonts-khmeros 5.0-7 fonts-liberation 1.07.4-1 fonts-linuxlibertine 5.3.0-2 fonts-lklug-sinhala 0.6-3 fonts-lohit-beng-assamese 2.5.3-1 fonts-lohit-beng-bengali 2.5.3-1 fonts-lohit-deva 2.5.3-1 fonts-lohit-gujr 2.5.3-1 fonts-lohit-guru 2.5.3-2 fonts-lohit-knda 2.5.3-1 fonts-lohit-mlym 2.5.4-1 fonts-lohit-orya 2.5.4.1-1 fonts-lohit-taml 2.5.3-1 fonts-lohit-telu 2.5.3-1 fonts-nanum 20140930-1 fonts-nanum-coding 2.0-10 fonts-noto 2013-04-11-2 fonts-sil-abyssinica 1.500-1 fonts-sil-padauk 2.80-2 fonts-sil-zaghawa-beria 1.000-3 fonts-tibetan-machine 1.901b-5 fonts-tlwg-kinnari 1:0.6.1-2 fonts-tlwg-typo 1:0.6.1-2 fonts-tlwg-waree 1:0.6.1-2 gsfonts 1:8.11+urwcyr1.0.7~pre44-4.2 texlive-fonts-recommended 2014.20141024-1 toilet-fonts 0.3-1 xfonts-encodings 1:1.0.4-2 xfonts-terminus 4.39-1
[1] Comedian Garrison Keillor, who had long residence in Denmark, once observed that the letter that looks like an 'o' with a diagonal line through it means 'This word cannot be pronounced by Americans.'
Duh, that's pronounced "ZE-RO"!
duck<
On Wed, 8 Apr 2015, Craig Sanders wrote:
On Wed, Apr 08, 2015 at 12:37:23PM +1000, Peter Ross wrote:
In my experience with fbcon, large output (e.g. dmesg or cat /var/log/syslog) will slow the entire system noticably, but switching to another vt (Ctrl+Alt+F2) "fixes" it.
I also noticed it running scren inside xterm, but it was MUCH MUCH MUCH faster to recover -- it's the main reason I start X by default these days.
Until now I have not seen it inside xterm.
It seems to be the terminal application itself, konsole or gnome-terminal, which holds all terminals in one application.
It means, KDE's konsole becomes unresponsive. I can switch to IceWeazel (e.g.) but the drawing of another konsole window takes a long long time.
xterm is much faster than gnome-terminal (or anything else that depends on libvte)...that's mostly because libvte is horribly slow (partly because it does more complicated things, like unicode)
e.g. try running 'time ls -lR /' in xterm, gnome-terminal, and konsole. xterm will finish much faster than the other two.
xterm support unicode just fine. For instance, this pine session is in an xterm, and a møøse bit my sister ønce. That's not what slows down a crappy terminal implementation. xterm has forever done things like not redraw every single scroll - and when I last got subjected to gnome-term, it didn't appear to redraw immediately, but it'd sit there and hold up output while it did redraw. But you know the best bit about xterm? Whoever invented tite was a moron, but fortunately we have settings for that: ! This resource specifies whether or not to ignore the 'alternate screen' ! of applications such as vi. When it is on, these applications will restore ! the contents of the screen when they are exited to what they were before ! they were started. When it is off, the contents of vi will remain on the ! screen after the program is quit (seriously, who do I shoot to make sure ! that this ridiculous concept never appears again?) XTerm.VT100.titeInhibit: true !and then allow an extra screenfull of scroll when screen "alternated" XTerm.VT100.tiXtraScroll: true The other terms don't appear to have this for the most part. -- Tim Connors
On Mon, 13 Apr 2015 at 10:30 Tim Connors <tim.w.connors@gmail.com> wrote:
xterm support unicode just fine.
I have found in the past that xterm UTF support deteriorates badly (compared with say rxvt) with bold fonts (ie can't disable certain random UTF characters properly). I ended up disabling bold fonts as a result: ~/.Xresources contains some lines including: *vt100*boldMode: off I think this was with Debian/wheezy, I really should test this out in case it has changed in Debian/Jessie.
2015-04-13 2:29 GMT+02:00 Tim Connors <tim.w.connors@gmail.com>:
But you know the best bit about xterm? Whoever invented tite was a moron, but fortunately we have settings for that:
What's "tite"? -- Mick
On Mon, 13 Apr 2015, Michele Bert wrote:
2015-04-13 2:29 GMT+02:00 Tim Connors <tim.w.connors@gmail.com>:
But you know the best bit about xterm? Whoever invented tite was a moron, but fortunately we have settings for that:
What's "tite"?
xterm(1): titeInhibit (class TiteInhibit) Specifies whether or not xterm should remove ti and te termcap entries (used to switch between alternate screens on startup of many screen-oriented programs) from the TERMCAP string. If set, xterm also ignores the escape sequence to switch to the alternate screen. Xterm supports terminfo in a different way, supporting composite control sequences (also known as private modes) 1047, 1048 and 1049 which have the same effect as the original 47 control sequence. The default for this resource is “false”. -- Tim Connors
On 13/04/15 10:29, Tim Connors wrote:
Whoever invented tite was a moron
Well, it dates back to those days when our computers didn't have heaps of ram to waste on a display buffer, so we used the display memory in the terminals (sure beat line based editing). Some of the fancier terminals had extra ram, which enabled multipage displays; the ti/te escape sequences allowed access to a second display page. Now that we have multiple virtual terminals and plenty of scroll memory, it does feel like it is time to move on! Glenn -- sks-keyservers.net 0x6d656d65
Tim Connors <tim.w.connors@gmail.com> writes:
But you know the best bit about xterm? Whoever invented tite was a moron, but fortunately we have settings for that:
! This resource specifies whether or not to ignore the 'alternate screen' ! of applications such as vi. When it is on, these applications will restore ! the contents of the screen when they are exited to what they were before ! they were started. When it is off, the contents of vi will remain on the ! screen after the program is quit (seriously, who do I shoot to make sure ! that this ridiculous concept never appears again?) XTerm.VT100.titeInhibit: true !and then allow an extra screenfull of scroll when screen "alternated" XTerm.VT100.tiXtraScroll: true
The other terms don't appear to have this for the most part.
I've never noticed because I do the equivalent in .screenrc: altscreen on # GUIs don't clobber scrollback ## This makes screen leak about 100MB of memory per day :-( # defscrollback 32767
participants (8)
-
Brian May -
Craig Sanders -
Glenn McIntosh -
Michele Bert -
Peter Ross -
Rick Moen -
Tim Connors -
trentbuck＠gmail.com