
Windows Terminal Preview 0.9 - lelf
https://devblogs.microsoft.com/commandline/windows-terminal-preview-v0-9-release/
======
rstat1
So this release is exciting for me, because it contains my first ever open
source contribution, in the form of a setting that allows one to disable that
annoying dialog box that pops up when you close a window with multiple open
tabs.

~~~
lostmsu
What's the setting?

~~~
mkl
It's described in the article:

> set "confirmCloseAllTabs" to true at the top of your profiles.json file

~~~
KORraN
Is it just me or it should be the other way around - set it to "false" so
confirmation is not required?

~~~
breakingcups
The name is somewhat ambiguous. Does it mean to ask the user to
"confirmCloseAllTabs"? Or does it mean the act of the user setting the value
of this setting to true means to "confirmCloseAllTabs"?

I find your interpretation slightly preferable over what was actually
implemented in this case.

~~~
KORraN
It turns out that description in this blog post is wrong. Profiles.json
Documentation from rstat1's commit
([https://github.com/rstat1/terminal/blob/58f442dfd2a476de5552...](https://github.com/rstat1/terminal/blob/58f442dfd2a476de5552249535668fd9c185467b/doc/cascadia/SettingsSchema.md))
describes new setting this way:

"When set to true closing a window with multiple tabs open WILL require
confirmation. When set to false closing a window with multiple tabs open WILL
NOT require confirmation."

I just checked it and indeed setting it to "false" turns off confirmation.

------
tony
It's faster than any Bash terminal I've tried so far on WSL. Tried ConEmu and
Hyper.

ConEmu glitches out for me on tmux. Hyper can be a bit slow, but is most
accurate for me.

I'm doing tmux + vim with 256 colors. So a lot of stuff has to come together
and "just work"

Windows Terminal over the past months fixed glitches. It's update-able via
Windows Store.

Oh, and the font "Cascadia Code" is one of my favorites. Very clean. Actually,
I'm using it on Linux now in my terminal [1].

The other thing is Windows Terminal works great on a huge monitor, too. No lag
when rendering. Feels lite. I compare its snappiness to rxvt-unicode. Faster
than iTerm2.

Just my perception, never benchmarked.

And this goes along with WSL 2, which is worth reinstalling Win 10 for if you
left because of WSL 1 problems. This stuff is fast. I can throw multiple
multiple beefy node projects, python flask/django apps, building C++ projects,
importing postgres DB (4gB import with a lot of indexes), all at the same
time.

[1] I dual boot still. There is a shortcut on Windows 10 minimizes all windows
that I can't disable easily. It loses my workspace positioning and isn't
recoverable. I hope this gets changed - it'd be a dream.

~~~
khalilravanna
Would you recommend WSL 2? I updated it and regretted it immediately due to a
bug where accessing the Windows filesystem through the ubtuntu shell is
something like 10-100x slower. Running ‘git status’ takes > 10 seconds to
return. Do you stick exclusively to the Linux filesystem?

~~~
chrismorgan
Linux accessing Windows is indeed _way_ slower under WSL 2, and I get the
impression from what I’ve heard that this is unlikely to ever be improved
much. But working the other way round is a bit faster than it used to be, if I
recall correctly, and working purely within ext4 is _enormously_ faster than
under WSL 1.

Combined with the steady improvements to being able to access the Linux side
from Windows (under \\\wsl$\ _machine-name_ ), and being able to mount that to
a drive letter (I have my ~/.zprofile run `/mnt/c/WINDOWS/system32/subst.exe
A: '\\\wsl$\arch' > /dev/null`, which delays subsequent login shell startups
by 30–40ms, but that’s not too bad), shifting all your relevant stuff onto the
Linux side and still working with Windows tools where desirable is quite
feasible.

I moved all my files (including a >700MB Git repository) from C: to A: after
upgrading to WSL 2. _Well_ worth it. I do most of my work in a terminal (the
Linux side) or in gVim (the Windows side).

~~~
khalilravanna
Interesting. Is it possible to use something like Visual Studio Code (my main
editor due to a lot of TypeScript focused work) with the Linux filesystem? I
think I tried this and couldn't get it to work but I can't remember and maybe
I did it wrong and am just incompetent.

~~~
peschkaj
The "Remote - WSL" extension allows you to open a folder inside WSL but keep
writing code inside VS Code running as a Windows process. It's available at
[https://github.com/Microsoft/vscode-remote-
release.git](https://github.com/Microsoft/vscode-remote-release.git)

------
russellbeattie
I've read all of the blog posts about the Windows Command Line [1] and the
following posts and it still boggles my mind how long it's taking Microsoft to
overhaul their command line and create a decent terminal emulator. They're on
year 6 of this effort, if you didn't know. I don't think people at MS are
stupid or anything - I obviously have no idea of the real complexity
underpinning this stuff. But holy cow. This is a problem that's long been
solved on other platforms and it just seems ludicrous.

1\. [https://devblogs.microsoft.com/commandline/windows-
command-l...](https://devblogs.microsoft.com/commandline/windows-command-line-
backgrounder/)

~~~
OptionX
The team on it is rather small. I think M$ takes it as a side project more
than a new feature for the OS. But I agree with you, should've been done ages
ago. When they first put out powershell, for example, would've made sense.

~~~
austdi
The team is incredibly small compared to other teams. 2-4 devs at a time,
roughly a tenth of those on powershell. Much of the difficulty of the project
came from the lack of resources yes, but also the age of the codebase. It was
originally written in the 1980s (before most of the dev team was born) and the
original authors had long since left the company by the time the mothballs
were dusted off. The team also owned other codebases that time had to be split
between.

Maintaining compatibility and performance were two of the main unbreakable
tenets of the team (and Windows in general). This made it difficult to move
quickly with features right out of the gate. A few of those years were spent
understanding the system and modernizing the code from crufty C to C++17,
while still managing to add features.

One of the first dev tasks I heard about when I became exposed to the project
was of a dev mapping out all of the PVOIDs in the codebase so they could be
eventually replaced with better abstractions. Another fun one was a different
dev that refactored the GDI rendering, as a side project squeezed in around
other tasks. The new renderer ended up being much faster and ~7000 lines
shorter, if I remember right. We also took CJK language support quite
seriously, which was difficult as none of the devs could read one of those
languages day to day to catch bugs quickly.

~~~
dboreham
1980s? For some reason I always assumed cmd was re-written for NT in around
1991.

~~~
bitcrazed
Hi. PM on Windows Command-Line here:

A couple of things:

1\. You're confusing Cmd (the command-line shell) with Console (the terminal
UX you see and interact with on-screen) 2\. Development for NT started in Oct
1989 and the first version of NT shipped in 1993

You might find it interesting to read my series of posts on the evolution of
the Windows Command Line: [https://devblogs.microsoft.com/commandline/windows-
command-l...](https://devblogs.microsoft.com/commandline/windows-command-line-
backgrounder/)

HTH.

------
nickjj
Mouse events still don't pass through to tmux which makes it unusable in every
day usage. In other words, if you use tmux and have Vim open and try to click
into Vim or any tmux window, nothing happens. This also happens without tmux
too if you're just using terminal Vim. It's like the event gets absorbed and
thrown out.

I highly recommend to check out WSLtty if you're interested in a good WSL
terminal: [https://github.com/mintty/wsltty](https://github.com/mintty/wsltty)

It has equally as low input latency, really good keyboard shortcut support,
clickable URLs, tmux works perfectly (with and without the mouse), it's rock
solid, uses almost no resources, has smaller / less distracting window borders
vs MS' terminal and it has lots of themes. I've been using it for full time
development with tmux + terminal Vim for almost a year now and it hasn't
failed me yet.

~~~
zamadatix
They just started working on this
[https://github.com/microsoft/terminal/issues/376](https://github.com/microsoft/terminal/issues/376)
I don't think it'll make it for 1.0 as they are doing a new feature freeze.

~~~
nickjj
That's unfortunate because it was reported many many preview versions ago by
multiple people and that issue you linked is from a year ago.

I wish they would hire the dude who makes WSLtty. It feels like the MS team
doesn't want to address the really important things that make a terminal
optimal for full time development. It's like they spent 3 years creating a
tabbed interface and supporting icon emojis but ignored other critical
features for so long (for the longest time you couldn't even zoom in and out
with a hotkey).

~~~
austdi
With respect, emoji support and tabs were the most requested features for
years according to the uservoice page that tracked the public feature
requests.

I no longer work on the project but that team is filled with some of the most
passionate and dedicated people you could find to shepherd the console from
where it was to now. We collectively lived and breathed the console, yet the
team was always understaffed and almost always had at least one dev that was
pulled off by management to work on what was believed to be a higher priority
project.

Implementing the emoji support took me years and that doesn't even count the
rendering of them, just the ability to shuttle them through the internals and
back. Tabs as well required quite a bit of work behind the scenes, there was
an entire blog series written on the work that led up to tabs being possible.

~~~
rcarmo
There is a substantial difference between random (but massive) user feedback
and expert user feedback. UserVoice fails utterly at capturing the latter,
because very specific (and critical) user feedback gets buried under “nice”
things that fall outside the 80% of what users actually _need_.

As a former Marketing guy (reformed) I’ve seen this time and again, and really
wish features were prioritized differently—not to diss on what you did, since
I’ve had plenty of pains with encodings, code points, etc. over the years-but
considering the target audience for a terminal, I would definitely have
prioritized mouse reporting over it, because it would make non-Windows users
happier and more likely to adopt Windows/WSL as their primary development
platform.

~~~
bitcrazed
PM for Windows Command-Line here.

Appreciate your feedback, but we solicited and received feedback from many,
MANY sources. UserVoice, Stack Overflow, Github Issues, customer interviews,
email, Twitter, comments after speaking at events, comments from customers at
booths at OSCON, Build, Ignite, JSConf, PyCon, etc. to name just a few.

We received an OVERWHELMING number of asks for unicode text support. Emoji are
simply one class of unicode glyph but they're pretty important for those
working with tools/scripts that use emoji to indicate the state or outcome of
an operation.

Further, many users speak non-Latin languages which require non-ASCII glyphs,
some of which can be quite challenging to support in a grid-based display
format (e.g. Arabic, Hebrew).

This whole class of asks around "Unicode Support" required not just a brand
new renderer that could actually draw the correct glyph in the correct cell,
but also a whole new way of storing, iterating, and navigating variable-width
code-points qucikly and efficiently.

These asks (and many others like them) vastly outnumbered asks for mouse
support.

------
emmanueloga_
I've been using the new terminal for a while now. I was missing emacs key
bindings I thought it was because of the terminal. It turned out it just
wasn't enabled on powershell:

    
    
        Set-PSReadLineOption -EditMode Emacs
    

1: [https://stackoverflow.com/questions/43295639/update-
powershe...](https://stackoverflow.com/questions/43295639/update-powershell-
keyboard-bindings-to-be-emacs-style-like-bash-shell)

~~~
lukeschlather
This is what I do to make my bash muscle memory happy:

    
    
        if ($host.Name -eq 'ConsoleHost')
        {
            Import-Module PSReadLine
            Set-PSReadLineOption -EditMode Emacs
            Set-PSReadLineKeyHandler -Key 'Ctrl+V' -Function Paste
            Set-PSReadLineKeyHandler -Key 'Ctrl+v' -Function Paste
            Set-PSReadLineKeyHandler -Key 'Ctrl+/' -Function Undo
            Set-PSReadLineKeyHandler -Key 'Ctrl+Backspace' -Function BackwardKillWord
            Set-PSReadLineKeyHandler -Key 'Ctrl+LeftArrow' -Function BackwardWord
            Set-PSReadLineKeyHandler -Key 'Ctrl+RightArrow' -Function ForwardWord
        }

------
tbolt
Other than some pains to get it all setup, it’s actually a fairly pleasant
experience doing web development on Windows now. Edge (chromium), VSCode, WSL
(Ubuntu), and Windows Terminal all feel pretty good.

Plus this was setup on my otherwise dedicated “gaming pc” with an i7 9700k and
fast ram/storage so it’s nice being able to use all that power

~~~
alexdumitru
I've started using hyper yesterday and it seems much more polished than this.

~~~
cercatrova
Hyper is quite slow, isn't it? It definitely was when I tried it.

~~~
kingosticks
It's really slow if you spool a lot of output. It's unusable for me for that
reason.

------
kingosticks
It been using this for about 3 months now and I'm actively looking for
something else now. I ssh into beefy server machines to run all my actual
jobs.

* The biggest issue for me is that it's crashed 8 or 9 times. Most times when this happens I lose some long-running process I forgot to nohup. This is the first terminal I've had crash so regularly. There's also some link to the crashing and accessing it from remote desktop but I can't figure out the trigger.

* The memory usage seems to really jump up sometimes, I have over 2GB being used right now between my usual 5 or 6 tabs ssh'ed into other machines.

* It can get in a state where it pegs my cpu at 30%. I think this happens when it's spooling text faster than it can be output and it's trying to catch up. It doesn't happen all the time.

* copying text. The option to automatic copy on selection (similar to what I'm used to from gnome-terminal) is frustrating. If you select text, change window focus and copy something else, then refocus the terminal it'll re-copy the originally selected text!

~~~
Sammi
Git for Windows comes with the best terminal for Windows that I've found:
[https://gitforwindows.org/](https://gitforwindows.org/)

I've tried ConEmu, Cmder, Cygwin, and Alacritty.

~~~
kingosticks
Which I presume is just Mintty
([http://mintty.github.io/](http://mintty.github.io/)) ?

------
LennyWhiteJr
Bravo. Aside from WSL, Windows Terminal is probably the best developer tool
Microsoft has come out with in quite a while.

I've finally been able to retire my Cmder installation.

~~~
airstrike
Can't retire cmder until I can hide tabs and have some padding around the
edges...

[https://i.stack.imgur.com/ASKAX.png](https://i.stack.imgur.com/ASKAX.png)

~~~
fuzzmz
Can you share your config for that?

~~~
airstrike
Sure, here you go:
[https://pastebin.com/qJBRFb3V](https://pastebin.com/qJBRFb3V)

Let me know if it works. Probably has a bunch of junk you won't need (like
various custom color palettes I played around with). I may or may not have
edited other .cmd files outside of the ConEmu.xml realm so that may warrant
some tweaking too

And you'll need the Monaco Font (and Ubuntu Mono for the lambda) for it to
look exactly the same

------
btgeekboy
I’ve recently taken to trying an Ubuntu Hyper-V VM, VS Code, and the new
Terminal preview as an experimentation platform for use with Expo. It’s solid.
The hardware (Ryzen 3700X+32G) was relatively cheap, and it’s working quite
well. If I was Apple, I’d be concerned - I was going to upgrade my 2012 Mac
Mini, but I now don’t see the rush.

~~~
bitcrazed
As a matter of interest, have you tried WSL? It's a much more integrated
experience than the isolated VM approach.

~~~
btgeekboy
WSL 1 and Expo don’t play nice with each other; Expo was causing ephemeral
port exhaustion and making both Windows and Linux unusable. WSL 2 should fix,
but I don’t want to jump to an insider build quite yet.

[https://github.com/Microsoft/WSL/issues/2913](https://github.com/Microsoft/WSL/issues/2913)

------
apetresc
> A new global setting has been created that allows you to always hide the
> “Close All Tabs” confirmation dialog. You can set "confirmCloseAllTabs" to
> true at the top of your profiles.json file and you’ll never see that popup
> again!

Did they just phrase this backwards or is that the total opposite of what
you'd expect?

~~~
cercatrova
Sounds right to me. "I confirm that I always want to close all tabs."

~~~
hi41
I am glad I scrolled this far. I too had the same question in my mind and
thought the config variable was confusing. But the way you phrased it made it
clear. I originally read it as “show confirm-close-all-tabs dialog box”.

------
xvilka
I hope they will add a proper BiDirectional[1] text support for languages like
Arabic, Hebrew, etc. There is a prominent new standard for terminals[2] that
should unify the support in the terminals and terminal programs. See the
corresponding issue[3] in the Windows Terminal repository.

[1]
[https://gist.github.com/XVilka/a0e49e1c65370ba11c17](https://gist.github.com/XVilka/a0e49e1c65370ba11c17)

[2] [https://terminal-wg.pages.freedesktop.org/bidi/](https://terminal-
wg.pages.freedesktop.org/bidi/)

[3]
[https://github.com/microsoft/terminal/issues/538](https://github.com/microsoft/terminal/issues/538)

------
recursive
Maybe someone here can help. I have a major usability problem with this. It
actually seems to be a regression from cmd.exe.

I often like to run `cls; build -with -long -output;`. And then I scroll to
the top to see the first build error. With this, when you issue a clear, it
only blanks the visible viewport, and you can still scroll back through all
the old stuff.

[https://github.com/microsoft/terminal/issues/1305](https://github.com/microsoft/terminal/issues/1305)

There's a lot of information here that's over my head about how this actually
isn't a bug, and different pieces of trivia and history. But I still can't use
it for my use case, which is a thing I do often.

~~~
jiggawatts
Yeah, this is the canary in the coal mine for me.

The Windows behaviour is correct, the Linux behaviour is inconsistent and was
kept for historical reasons only.

Microsoft has been overrun with developers who think that whenever there's a
conflict between the Windows and Linux ways of doing things, then
automatically the Linux way is correct, because of a 60-year old UNIX legacy
that _must be preserved forever and ever_. Even on different operating
systems. Even in green-fields codebases being developed in 2020. Even if it
makes no sense at all. Even if it's a regression compared to what Windows does
now.

This is not the only example. Mark my words, it's just a matter of time until
junior Microsoft devs reintroduce all of the stupidities from Linux that have
no place in any sane operating system:

* Button action occurs on mouse-down instead of mouse-up, making misclicks uncancellable.

* No delete key support to match Linux backspace-only behaviour: [https://unix.stackexchange.com/questions/66434/delete-key-do...](https://unix.stackexchange.com/questions/66434/delete-key-doesnt-work-on-command-line)

* Cursor key support is removed in favour of vim-style hjkl movement keys that make sense only on ADM-3A terminals from the 70s: [https://superuser.com/a/599152](https://superuser.com/a/599152)

* Selection copies instantly, wiping out your clipboard whether you like it or not.

* All output becomes text, because strong typing is for soft people that haven't mastered sed/awk.

* PowerShell is replaced by bash, because why would anyone need consistent naming, readable scripts, and pervasive tab-complete? We want to save precious bytes on our 300 baud SSH connections!

* SSH for Windows instead of WinRM, which has been included for a decade.

~~~
rswail
I doubt "junior Microsoft devs" reintroduce what you think is somehow related
to Linux.

And a "sane" operating system is independent of shells (whether *sh or
PowerShell or cmd) and is also independent of the GUI running on it.

Button action is related to the GUI you're running, not Linux.

Delete key actions are related to termcap which indeed is historical. However,
any sane GUI terminal handles that. How many people actually operate a windows
machine via a serial port?

Cursor key support: I used terminals in the 70s and 80s. Many of them had
arrow keys that were supported. See termcap above that was specifically to
handle these sorts of issues.

Multiple clipboards, again, are dependent on your GUI, it has nothing to do
with the terminal or the PTTY underneath it in Linux/Unix.

All output becomes text, is actually a misnomer. It is that all output (by
default) comes out of stdout and is an octet stream.

SSH didn't exist when there were 300 (or 110) baud connections. TTYs did and
devices like the VT-52 that supported certain escape sequences to do things
that were relevant to a screen as opposed to a printer with keyboard attached.

SSH vs WinRM. Neither were around when the Unix TTY/PTTY/line drivers etc were
established. In fact, telnet and rlogin weren't around either. They're not
even comparable. SSH establishes an encrypted tunnel between processes, WinRM
is a SOAP API client/server protocol for performing remote admin.

But hey, tell us what you think about systemd.

~~~
jiggawatts
> And a "sane" operating system is independent of shells (whether sh or
> PowerShell or cmd) and is also independent of the GUI running on it.

No, it is not. An operating system is not just a kernel. It's a collection of
components, of which the kernel is just a tiny part. Windows is the
combination of Win32, WMI, DCOM+, Active Directory, Registry, NTFS, GDI+,
DirectX, and so on. Take away even a couple of those, and you no longer have
Windows.

Applications are programmed _not_ against the bare kernel API, but shims like
Win32. Similarly, applications are programmed against the standard operating
system shells. A Linux install script that requires "sh" will not "Just Work"
on Windows. A program that requires CMD.EXE batch files will not "Just Work"
on Linux, even if it could otherwise, such as a Java app.

That's just the APIs and shell languages. The GUIs are the same. That's the
_human_ interface to the OS. An Apple OSX app ported as-is to Windows
(preserving the look & feel) would feel horribly out of place.

Other than the GUI, the only other human interface is the text shell. It's
_important_. It's a significant chunk of the experience for advanced users.
Directly porting Linux-isms to Windows is just as out-of-place as directly
porting a Mac app to Windows.

> Button action is related to the GUI you're running, not Linux.

Switchable GUIs are an X-Windows thing. Most other operating systems, such as
OSX and Windows have _consistent_ GUI toolkits. Linux doesn't. Its arbitrary
button click behaviour is insane. When your learned habit is to depress
buttons for a second while thinking twice about potentially harmful actions,
knowing that you can cancel by moving the cursor off and releasing, the
outlier Linux behaviour is shocking in its indifference to 99% of the
installed GUI base that existed at the time.

> Delete key actions are related to termcap which indeed is historical.

I still can't use the del key like... 50% of the time I interact with non-
Windows operating systems, particularly over SSH. How is this still a problem
in 2020!? Please explain why this has been simply _unsolvable_ for all of this
time. The 101-key layout has been out for 30 years. That's three decades.
THREE!

> Cursor key support

I was being sarcastic at this point. However, you will still find people
arguing with a straight face that ijkl movement is "superior", which is just
hilarious.

> Multiple clipboards

Windows has one primary clipboard. One. It now has clipboard history, but I'm
willing to bet that 99% of its user base is unaware of this feature. The
standard for 99.99% of its apps is to _not_ overwrite the clipboard on select,
yet I've seen apps ported from Linux introduce this behaviour to have that
"Linux feel".

This is just as wrong as porting the Mac OSX look and feel to Windows.

> All output becomes text, is actually a misnomer. It is that all output (by
> default) comes out of stdout and is an octet stream.

That's splitting hairs. Practically all Windows APIs are Object Oriented,
especially the ones used for scripting, such a WMI. They're not text-based.
The notion that what Windows is "really missing" is a bunch of text-oriented
Linux shell tools is just nuts. It already has native shells that are better
suited to it, such as PowerShell.

Meanwhile I don't particularly recommend PowerShell to Linux people, because
its string processing capabilities are not particularly good.

> SSH didn't exist when there were 300 baud connections

Technically true. However, telnet did exist, it was just less secure.

> SSH vs WinRM. Neither were around when the Unix TTY/PTTY/line drivers etc
> were established.

The point is that I keep hearing Linux admins clamoring for SSH support on
Windows, with the argument that Windows is hard to administer because it
doesn't have a secure remote shell. Even though it does. They just don't know
about it, because they use bash on Windows instead of PowerShell.

The irony is that securely distributing SSH public keys is essentially an
unsolved problem (unless I'm missing a recent development), whereas WinRM uses
Kerberos to automatically negotiate a temporary key.

Be honest: what fraction of the time do you verify that the public key
fingerprint of your first-time SSH sessions really match the fingerprints of
the boxes you think you're connecting to?

I'm guessing never...

> But hey, tell us what you think about systemd.

Sure: It's about time Linux caught up to Windows NT 4.0

I can't wait to hear the wails of anguish when the Linux world is dragged
kicking and screaming into the Windows 2000 world of Active Directory and its
magic powers called Group Policy and ACLs with more than 3 entries.

I had just recently wasted _days_ trying to figure out why some Linux box was
basically locking up on a customer network only to discover that pre-systemd
the secondary DNS doesn't do what you think it does. It's not a _backup_ DNS
server for the primary server at all! If the primary fails, then DNS has
failed, period. The primary will be tried 100% of the time with a 30s timeout
before the secondary is tried. The secondary will never be treated as a
primary, no matter what. Failures aren't cached. Successes aren't cached.
Nothing at all is memorised. TTLs may as well not exist.[1] If you have a
process that takes multiple DNS requests to succeed, you now have a guaranteed
connection timeout.[2] Meanwhile OSX, IOS, Windows, or Linux with systemd will
just instantly switch to the secondary DNS and keep trucking along like
nothing happened. You know... for redundancy.

I looked this up, researched the issue at length.

There were endless posts on the systemd forums asking for the legacy behaviour
back, arguing that the evil systemd people were destroying some sort of
precious heritage by introducing heretical notions from other operating
systems like _automatic failover_.

No logical arguments were made. Nothing sane was said. Just an endless torrent
of "but that's how it always was".

This is what I think of systemd: I wish there was more of it, and less
adherence to 1960s accidental history.

[1] I found it amusing that only RedHat had a working DNS resolver pre-
systemd. The others were either insecure due to being abandoned, or did not
follow DNS standards such as adhering to TTLs properly. We needed strict TLL
support because load-balancers on the network were using short TTLs for some
entries.

[2] Anything complex like Kerberos auth to Windows or SAML auth to anything
behind a load-balancer. This typically involves 5-20 DNS lookups. At 30
seconds a pop, it's a guaranteed authentication timeout for any reasonable DNS
timeout. Even if the DNS timeout is dropped to the minimum of 1 second, this
is outrageously slow for a middlebox that does authentication as a part of a
high-performance API workflow.

~~~
vetinari
> Most other operating systems, such as OSX and Windows have consistent GUI
> toolkits.

Has been not true for more than a decade. Between win32 user/comctl32/shell32
widgets, office widgets, xaml and uwp, saying nothing of the mirriad of third-
party widget libraries used by applications by Adobe, Autodesk and other third
parties, which one is supposed to be consistent and canonical?

Somewhat consistent widgets in windows applications were last seen at the end
of 90-ties. Since then, linux desktop blushes in envy, how inconsistent it
could be.

> I still can't use the del key like... 50% of the time I interact with non-
> Windows operating systems, particularly over SSH.

Has it occured to you, that this might be a problem at your end?

> The irony is that securely distributing SSH public keys is essentially an
> unsolved problem (unless I'm missing a recent development), whereas WinRM
> uses Kerberos to automatically negotiate a temporary key.

You know that you can use SSH with Kerberos too, right?

> If the primary fails, then DNS has failed, period. The primary will be tried
> 100% of the time with a 30s timeout before the secondary is tried.

Nope, but it is configurable. Did you happen to have a misconfigured system?
Default timeout is 5s; and your config option will be just capped to 30s max.

> Failures aren't cached. Successes aren't cached. Nothing at all is
> memorised. TTLs may as well not exist.

I guess you didn't notice nscd, part of the glibc since '98, either.

> Linux with systemd will just instantly switch to the secondary DNS

Systemd by itself won't do anything like that. You can use systemd-resolved,
which is an optional part of systemd (afaik only Ubuntu uses it by default);
but otherwise, systemd won't touch your resolver config. NetworkManager
(default in RHEL7 and 8) will, though.

~~~
jiggawatts
> Has been not true for more than a decade. Between win32
> user/comctl32/shell32 widgets, office widgets, xaml and uwp, saying nothing
> of the myriad of third-party widget libraries used by applications by Adobe,
> Autodesk and other third parties

This is somewhat proving my point.

Windows has _essentially_ only two GUI toolkits: Win32 GDI+ and WPF/UWP. Both
follow the same very-high-level paradigms: Where the toolbar belongs, what the
minimise/maximise/close buttons look like, how scrollbars work, keyboard
shortcuts, clipboard behaviour, etc...

OSX similarly has only had a couple at any one time, such as Cocoa and Carbon.

These were not introduced concurrently, but simply represent the evolution of
the operating systems over decades, with the explicit aim of standardising on
the latest framework.

It is precisely the apps that fail to follow these consistent paradigms that
feel jarringly alien.

Like you mentioned, Adobe applications are notable. They're ported from MacOS!
They use a complex emulation layer to run on Win32, which is why they feel
clunky and slightly weird even today.

Many CAD GUIs such as Autodesk products were developed in the DOS days, long
before standardisation. Even Excel suffers from this, it's the odd one out in
the MS Office suite because it was originally developed for Macintosh.

Sometimes this can be a good thing. Google Chrome introduced the tabs in the
title bar UI paradigm, and it's now becoming standard.

> Since then, linux desktop blushes in envy, how inconsistent it could be.

Linux always had several _competing_ GUI frameworks, many of which were
introduced concurrently, and continue to coexist. There's Unity and GTK+ as
notable examples, but there are many others.

> Has it occured to you, that this might be a problem at your end?

Explain to me what I'm doing wrong, such that on dozens of devices with many
different terminal emulators the "del" key specifically doesn't work for me
about half the time. What _mistake_ am I making? Am I pressing it too hard?
Not hard enough? Did I plug the keyboard in wrong?

Seriously though: I don't expect the Windows key to work on Linux, Solaris, or
BSD. I do expect the Del key to work. Every time. Not just sometimes. Not just
with some tools. Always. It shouldn't be a thing that can go wrong without
special effort.

> You know that you can use SSH with Kerberos too, right?

The Kerberos support in Linux is a hilarious joke compared to Windows.

It's almost like... there's a parallel universe where 99.999% of Kerberos
servers are _not_ Active Directory. There are only University labs with a
single IP address for the KDC because, _meh_ , if authentication fails, what's
the the worst thing that can happen? You just get to skip the CS lab class
today!

Kerberos as seen in Windows doesn't need kerbtab files and hard-coded IP
addresses. It supports site-to-site roaming efficiently, and can tolerate
spectacular levels of infrastructure failure before authentication actually
stops working.

I have an honest question for you: Do you have a reference to a good how-to
for setting up robust Kerberos auth for Linux with vaguely comparable features
to Active Directory? E.g.: Dual-redundant servers _per-site_ , site-local auth
by default, tolerance of arbitrary component failure, etc...

PS: I discovered how broken DNS is in Linux precisely because of Kerberos.
Linux as-is simply cannot handle something as "complex" as DNS-based server
discovery during auth, because it's not designed to have a reliable DNS
client.[1] The only vaguely robust, caching, standards-compliant DNS resolver
for Linux is the one in systemd.

> Nope, but it is configurable.

There is no timeout value that can be set that will make something as complex
as Active Directory Kerberos auth work consistently on pre-systemd Linux. If
you use 1 second, you'll get spurious timeouts when servers are busy, and 2
seconds is already too long because of the large number of DNS requests
required.

> nscd

I tried it, but it ignores TTLs and its caching behaviour is simply broken.
Some of these are known issues over a decade old marked with "WONTFIX". Here's
a recent one, as an example:
[https://bugzilla.redhat.com/show_bug.cgi?id=1367565](https://bugzilla.redhat.com/show_bug.cgi?id=1367565)

RedHat's "sssd" works well enough, but it's the outlier. The system I was
trying to fix was forced to use an older, pre-systemd SUSE distro.

As I said, I researched this for _days_. The issue was a show-stopper for the
client, so significant effort was sunk into trying to fix it.

The outcome of the investigation was: "upgrade to a SUSE distro with systemd,
all previous versions of Linux simply do not support DNS properly". That's
just nuts, if you think about it for a minute. It's not like DNS is a new
protocol!

> Systemd by itself won't do anything like that.

Well no, granted, but this is splitting hairs. Most systemd-based Linux
distros however use "systemd-resolved", which is AFAIK the only working DNS
client on Linux other than the RedHat-specific sssd.

The idea of systemd is to _move away_ from resolv.config, which is an ancient
and _fundamentally broken_ way of configuring DNS.

Mind you, even systemd has issues! It cracks me up to read things like this:

[https://unix.stackexchange.com/questions/466336/how-to-
make-...](https://unix.stackexchange.com/questions/466336/how-to-make-systemd-
resolved-stop-trying-to-use-offline-dns-servers/466340#466340)

The stated problem: "If I run systemctl restart systemd-resolved then it will
switch to another server and continue working, but it will randomly switch
back to the offline server after a while and name resolution will again fail.
How can I tell systemd-resolved to stop using an offline DNS server and
quickly switch to one of the other ones it knows about?"

The _insane_ response: "DNS professionals have known for long that if you want
DNS service resiliency in any network, you do not leave that decision up to
the client implementation. It is a too important decision to leave to the
resolver implementations of clients to make."

That's just crazy. Literally crazy. This idiot is saying that you need either
a hardware load-balancer appliance, anycast IP, or some other complex network
configuration because the client "cannot be trusted"!!!

Meanwhile _all other operating systems_ fail over to a working DNS sever
perfectly fine within milliseconds, completely transparently to the end-user.

Check out this _raw arrogance_ : "I implemented anycast DNS with iBGP and OSPF
in two ISPs and one University in the past, with dramatic improvements in the
uptime availability of the DNS service."

So what this Mr Bigshot Linux Admin is saying is that if you have a home
network[2] that gets a primary & secondary DNS pushed down from your ISP it is
YOUR FAULT for not configuring your ISP's iBGP or OSPF routing properly. Get
good, scrub!

[1] This is a difference in philosophies, which is interesting by itself.
Linux is highly modular, clearly separating client and server functionality.
So the DNS client is _just_ a client. It is not a "server" and does not
perform "server functions" such as caching or failover. If you "want" server
functions like caching, you have to run a local server on 127.0.0.53 and
loopback to it. This then forces all DNS requests to traverse multiple
processes and involve the network stack even if the data is in cache. Contrast
this with OSX or Windows, where the DNS client has a simple _in-memory_ cache
and the DNS server has a full database that caches on disk as well.

[2] Or WiFi hotspots. Or 4G tethering. Or any cloud network. Or large
corporate networks where you are not the network admin. Or any network using
Windows Active Directory DNS. This insistence of having "one reliable IP" for
DNS instead of "client-side failover between an alternate IP list" in Linux
will never stop being a constant, endless source of hard to fix failures until
it goes away and dies in a fire.

~~~
vetinari
> This is somewhat proving my point.

Not at all.

Microsoft Office always used custom widgets; the Office division wanted their
new toys for their package, but they didn't want to wait for or to be limited
to future Windows versions, so they shipped their own, much to the chagrin of
the Windows division. After Office shipped, some of them were incorporated
into system, but they were re-implementations, not the versions used in
Office, so they always were slightly different. Some of them were not
(remember the auto-hiding menus in Office 2003?)

On the Adobe side, even relatively new and modern apps, cross-platform from
day 1, like Lightroom, used custom widgets. For the "old" apps, they are using
their own thing; they are not native on Mac either. It doesn't matter, that
they were ported from MacOS, they grew their own thing. Photoshop was
originally written in Pascal, and that doesn't matter either.

CADs that were written in pre-Windows days had their UI completely rewritten
since then. Several times. Today, acad uses ribbon, and yet, the widgets are
non-native. They sometimes need to do things, that are difficult with native
widgets. And of course, they want to own their look and feels. Exactly like
the Office team.

And then there was the theming craze. Later, everyone wanted their own
branding. And then Electron happened.

> There's Unity and GTK+ as notable examples, but there are many others.

Unity is not a GUI framework. It is a shell (something like explorer.exe in
windows, that draws the desktop). While nothing prevents applications to draw
their own widgets (like Blender does, on all platforms, including Windows),
there are about 3 modern, usable widget libraries: GTK+, Qt and Electron. Qt
and Electron are used cross-platforms, they are not Linux exclusive. It is not
simple to use GTK+ outside Linux, and it is not an objective anyway, so few
people try.

Yes, historically there was Athena, Motif, and a bunch of others; there were
cross-platform toolkits like Tk, there were cross-platform wrappers like
wxWidgets. But most of them applied to Windows too.

> Explain to me what I'm doing wrong, such that on dozens of devices with many
> different terminal emulators the "del" key specifically doesn't work for me
> about half the time

I don't know, what specifically you are doing. Maybe your terminal emulator
configuration is broken. It might ask for a terminfo entry that it doesn't
support properly, or whatever. Contact the vendor of your terminal emulator
and try to work it out with them. I don't have any problem with del key,
neither on native linux desktop (gnome-terminal), nor with pc keyboards
attached to a mac (macs do not have del key on their native keyboards).

> The Kerberos support in Linux is a hilarious joke compared to Windows.

The Kerbeos support in Windows is hilariously broken. It can kinit only in
single realm (I'm routinely using several, at once) and it has to be AD.
Neither Linux nor Macs have a problem with this (Macs are using the Heimdal
Kerberos implementation, that some Linux distributions and Samba are using
too).

> There are only University labs with a single IP address for the KDC because,
> meh, if authentication fails, what's the the worst thing that can happen?

So for a broken Kerberos implementation, Linux is at fault?

To make things simple, just use sssd. Despite it being a Redhat sponsored
project, it is available in other distributions too, including Debian.

> Kerberos as seen in Windows doesn't need kerbtab files

Oh yes, it does. Keytabs are Kerberos secrets; that's how Kerberos works.
Windows just doesn't show them to _you_. They are secrets, after all ;). But
otherwise, try "ktpass /h" in your favorite windows terminal.

If you mean that applications that use SSPI do not have to be bothered with
them - that's something different. For something similar on the Linux side,
see gssproxy (it is by default on on RHEL).

> hard-coded IP addresses

Neither does any other system. But I suspect it has something to do with your
broken DNS. Or someone trying to workaround the broken DNS.

> It supports site-to-site roaming efficiently

Just not multiple realms, right?

> I have an honest question for you: Do you have a reference to a good how-to
> for setting up robust Kerberos auth for Linux with vaguely comparable
> features to Active Directory? E.g.: Dual-redundant servers per-site, site-
> local auth by default, tolerance of arbitrary component failure, etc...

Check out www.freeipa.org. It is a nice, packaged set of apps, that include
Kerberos, LDAP, PKI and more. It is vaguely comparable to AD; it has few
things that AD doesn't have (HBA!) and vice versa (don't expect GPO). You can
have multiple replicas, not just two, you can replicate among sites, etc.

There's just one problem, though: it won't work with Windows clients (easily).
It works perfectly with Linux and Mac clients. For Windows, I've thrown in the
gauntlet, created trust with AD domain and pointed windows towards AD (the
superior Windows Kerberos support, yay!). But I hear there are people who
managed to make it work with Windows clients in some limited ways (Kerberos
only. FreeIPA LDAP has different schema than AD LDAP, that will not work with
Windows clients, unless Microsoft starts play nice).

> Linux as-is simply cannot handle something as "complex" as DNS-based server
> discovery during auth

Querying srv and ptr records is not complex.

> The only vaguely robust, caching, standards-compliant DNS resolver for Linux
> is the one in systemd.

Systemd is not resolver. Systemd-resolved is. You are making exactly the same
mistake are most systemd detractors, conflating multiple applications into
one... Also, I guess that the makers of dnsmasq or kresd would take such claim
personally. Especially dnsmasq, which is a resolver that has been used long
before systemd-resolved existed.

> There is no timeout value that can be set that will make something as
> complex as Active Directory Kerberos auth work consistently on pre-systemd
> Linux.

Again, it is nothing complex, you just have something broken and project from
there.

> Well no, granted, but this is splitting hairs. Most systemd-based Linux
> distros however use "systemd-resolved", which is AFAIK the only working DNS
> client on Linux other than the RedHat-specific sssd.

If you redefine "most" as "only Ubuntu", then yes. Otherwise, no. Other
distributions are not using systemd-resolved.

SSSD is not DNS resolver either. It is identity/auth service. It won't make
your gethostbyname() work, but it is capable of verifying your credentials. It
is not Redhat-specific either, just developed by Redhat. It works perfectly
with Debian too; it happens to be the easiest way to join kerberos-based
realm.

> The idea of systemd is to move away from resolv.config, which is an ancient
> and fundamentally broken way of configuring DNS.

Not really true. Yes, resolv.conf is something that everyone would like to
move away, but there are still applications, that expect they will read it and
figure out DNS settings out of it.

For the same reason, OSX keeps resolv.conf too; but reading it could radically
differ from what `scutil --dns` would show you.

> This then forces all DNS requests to traverse multiple processes and involve
> the network stack even if the data is in cache.

Since we mention systemd-resolved here so often, it should be noted, that it
comes with nss plugin (nss-resolve). So it doesn't work as dns-proxy for most
apps, like you describe, only for these do their DNS resolving by themselves.

> Contrast this with OSX or Windows, where the DNS client has a simple in-
> memory cache

Except it is not, in OSX and Windows it works similarly. See dnscache ("DNS
Client") service in Windows, or mDNSResponder in OSX (yes, it is not only
bonjour responder, it caches DNS too. In older OSX versions, it was done by
Directory Service).

> This insistence of having "one reliable IP" for DNS instead of "client-side
> failover between an alternate IP list" in Linux will never stop being a
> constant, endless source of hard to fix failures until it goes away and dies
> in a fire.

Linux doesn't insist on this. Some people, which might be using Linux, do.
I've seen many incorrect claims or configurations across all systems, Linux
doesn't hold monopoly there.

------
petilon
I hate the Windows command prompt. Because when you have several of them open
and they overlap each other, there is no way to tell where one window ends and
the next one starts. The problem is the almost-invisible border. In Windows 10
they added fancy features such as translucence and took the border away, and
to some people this may look beautiful, but for others it created a usability
nightmare because overlapping windows just blend into each other.

------
cjamesd
Somebody fill me in. What is the strategic value to Microsoft of making their
own terminal? Especially when there are apparently so many out there. Also,
why are there are so many? I guess as a web dev I've always just accepted the
basic terminal and it's been fine for me. Am I missing out?

~~~
lenkite
Strategic value is turn developers from macOS back to windows and have better
sales for windows laptops.

The basic terminals on linux/macOS are fine. The basic CMD terminal on Windows
is terrible and is NOT ok.

~~~
cjamesd
I've done all my developing on a MacBook. This makes sense now. Thanks.

------
pastrami_panda
I've been using this for the past 6 months for git and enjoy it. I only have
two gripes: linebreaks are broken e.g. when writing long commit messages, and
there's still no way to do proper multi line commit messages. Hopefully this
is solved now, will check on Monday!

~~~
DHowett
For what it's worth, Terminal doesn't do anything special with line breaks on
shell prompts. PowerShell, however, might.

If you're using powershell, you can escape newlines with `. If git bash, \\.
If CMD, I don't know what to tell you -- I don't use it for any serious work.
:)

------
wiradikusuma
Last time I checked, long text wraps in the same line, and it's not even
visual only (when you press Enter to run it, throws error bcoz the command is
incomplete).

Also, lines pasted from Sublime don't include newlines.

------
OptionX
Gonna wait for the feature-complete release and try it out to see if I switch
out to it from Cmder.

------
rbanffy
If it does SGR 53 overline, with tmux 3 it'll be able to have some really nice
status lines.

------
imagiko
Been trying to set a shortcut to move between panes of a tab. Anyone done this
successfully?

------
navidr
Waiting for final release of this (and wsl 2) to switch to Windows from my
Linux.

------
CallMePK
Nice. Command Line Arguments part is great for opening tabs for the demo use

------
wnevets
I might finally ditch mintty that comes with Git for Windows

------
netfl0
No mouse support still? Am I wrong?

~~~
aksss
I can highlight text with mouse, right-click to copy it and then right-click
again to paste it. Ctrl-V, C don't work out of box. Gestures on track pad
don't scroll. What else are you missing?

------
allthebestforus
When will MS Terminal get slashes pointing in the right direction?

~~~
seabrookmx
Already does if you use WSL :)

~~~
nailer
Also powershell happily lets you use slash, as god intended.

------
devlife
Look at this wagon, honey. It has no horse. FFS.

------
ddevault
Ah, yes, the only terminal emulator which phones home to Microsoft to let them
know what you've been doing with it.

Or you could just, you know, actually use Linux or BSD.

~~~
seabrookmx
It's open source.

You mind pointing out in the code where it "phones home to Microsoft to let
them know what you've been doing with it"?

~~~
ddevault
[https://github.com/Microsoft/Terminal/blob/master/src/termin...](https://github.com/Microsoft/Terminal/blob/master/src/terminal/parser/telemetry.cpp)

[https://github.com/microsoft/terminal/blob/master/src/termin...](https://github.com/microsoft/terminal/blob/master/src/terminal/parser/tracing.cpp)

See also the corresponding hpp files.

~~~
DHowett
Funny enough, I crawled through this exact code to comment on another
thread[1] about telemetry in the console, but did so before the code was open-
source.

The files you're linking to--specifically in terminal/parser--serve to tell a
local developer running a text-mode application what VT sequences are in
common use to help that developer figure out where to apply effort. We can
also request that people enable these traces and _explicitly view their
contents, then choose to send us the data_ to help us troubleshoot VT parsing
issues.

There trace logs aren't even wired up to the "telemetry" stream that
everybody's so afraid of: TraceLogging is a local data capture solution first
and foremost, and anybody can look at what's being produced using Windows
Performance Analyzer. Nothing from this tracing provider leaves the user's
computer.

[1]
[https://news.ycombinator.com/item?id=19322398](https://news.ycombinator.com/item?id=19322398),
[https://news.ycombinator.com/item?id=19324538](https://news.ycombinator.com/item?id=19324538)

