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.
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.
"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.
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.
Hyper is slow because it is an Electron app built with web technologies. Try alacritty [0], a terminal written in Rust. It is supposedly the fastest terminal.
I second that, and it just seemed to be lacking features overall, and that was the direction the author wanted the project to go. It was great, but too many things missing for me.
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?
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).
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.
The WSL filesystem is already exposed at \\wsl$\distro-name (that landed in the Windows build from 6 or 12 months ago, so you can try it now on a release channel WSL 1 distro). I doubt that’s enough for file watching (certainly things like file locking aren’t supported), and I don’t believe CIFS would allow that either.
For watching file changes specifically, I imagine that you’d need a helper that could run on the Linux side and do any inotify or similar stuff there. I have no idea what IntelliJ might or might not support along these lines. I get the impression that VS Code is generally the tool with the best support, though again I have no concrete knowledge about file watching in particular.
I really enjoy WSL 2. I mostly use it on my ThinkPad; my workplace is mostly .NET + Angular, so I kind of need Windows as my primary OS, but I'm personally more used to dev work via Linux. (There are coworkers who get away with using Macbooks but some of the tooling we use is difficult for them to run.)
I dual boot at home, but for work dual book isn't really the tool I need. What I want is to be able to use bash and the *nix tools I know best as an interface to the Windows-based projects I work on. I'm much faster navigating the FS, even the Windows FS, using bash commands than the nightmare that is cmd, and Powershell just feels like too much -- like Java in the shell. So WSL has been exactly what I need.
Working on projects within the Windows directories does feel slower, but I haven't noticed anything like 100x slowdowns. NPM installs are essentially the only part of my regular workflow that feels painful.
Also it lets me work on my pet roguelike project during slow meetings, but that's our little secret....
What is annoying about WSL is the hyperv windows features it needs to be enabled cause virtualbox to not work
There is an experimental feature in virtualbox that works around that but supposedly caused vb to be slow (didn’t work for me)
WSL 2 is what finally made WSL usable for me. On WSL 1, build times were significantly slower for large compiles due to file i/o but WSL 2 is basically at parity with native Linux.
I recommend to check out the 16 million colors; Windows Terminal, tmux, and [neo]vim - all support it out of the box (assuming you use versions recent enough). See more at my infamous "truecolor" list[1]. Or an example[2] of such a condiguration.
> I'm doing tmux + vim with 256 colors. So a lot of stuff has to come together and "just work"
Very true. I eventually gave up on that because some computers I use still have Windows 7, so it was just easier to use gVim, than mess with installing and configuring a terminal (and PTY?) too.
I've been using kitty running through WSL/VcXsrv. Which has been an overall better experience than any native windows terminal I've used. Had to setup a few scripts to get everything working 'quake' style, but it works.
You can probable disable Win + M with something like AutoHotkey, which you may already even have installed as a dependency. Alternative, if you're talking about Win + D, you can reverse it by pressing Win + D again.
I tried AutoHotkey for the firs time yesterday. Am I correct in saying a text file has to be edited to disable the key? What would it look like?
I also heard about Win + D, which could be what I'm hitting a % of the time. Correct me if I'm wrong: but positioning any window after minimization (possibly including the bottom show-desktop / taskbar area) will make it so the window settings can't be reverse back?
My dream scenario would be something in Windows 10 settings where shortcuts can be remapped (or disabled) one-by-one, without registry/group policies.
I've never actually used AutoHotkey much; I've always just interfaced with the Windows hotkey API directly. Since it's installed on my computer as a dependency for something else, I gave it a quick look-through to see if I could figure out how to disable Win + M and Win + D. It seems pretty straightforward:
1. Right-click on your desktop (or any other folder) and choose New -> AutoHotkey Script.
2. Name the file something like DisableMinimize.ahk.
3. Right-click the file and choose Edit Script; alternatively, open it in your text editor of choice.
4. Keep the existing text that's in the file, but add the following to the end:
#d::
return
#m::
return
This script will work just like a program. Double-click it to run it, or put it in your Startup folder. You can even right-click -> Compile Script to generate a standalone EXE.
> I also heard about Win + D, which could be what I'm hitting a % of the time.
Both Win + D and Win + M seem like pretty obscure shortcuts to be hitting by accident. Some touchpads and mice have gestures or buttons that minimize all windows, though; in particular, on lower-quality laptops, I've found that the "minimize-everything-and-interrupt-whatever-I'm-doing" gesture likes to fire randomly. It even used to happen a lot on some older Surface devices. Is it possible that's the issue?
> Correct me if I'm wrong: but positioning any window after minimization (possibly including the bottom show-desktop / taskbar area) will make it so the window settings can't be reverse back?
You'll lose the memory of which windows were visible, but with both Win + M and Win + D, their positions and sizing should be preserved. If a window doesn't restore to its same position and sizing when you restore it, that's most likely a bug in the individual application.
One notable shortcoming is that you have to run Autohotkey as administrator if you want it to work perfectly. Otherwise if you have an active window with admin privileges the system hotkeys will reassert themselves. (I don't run it as admin, so this is a constant annoyance when I start an admin powershell prompt and try to maximize it.)
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.
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.
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.
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
The Console/Terminal team first took-ownership of the Console & Cmd codebases in late 2014, so it's been ~5.5 years.
Until v. recently, the team averaged ~2.5 devs and 0.5 PM (I had to split my time across Console and WSL).
Since spring 2019 when we began the effort to build Windows Terminal, we've grown the team to 4 devs and 1.25 PM (I am now the .25 since Terminal now has a dedicated PM).
During this time, we have shipped improvements to Console in every release of Win10, including transparent background, VT, 24-bit color, and many perf, stability, etc. fixes. But we can only do so much to the Console before we start to break users' existing systems, apps, and tools.
Since Console & Cmd's key responsibility is backward compat, we're pretty much leaving them alone.
But we're plowing ENORMOUS effort into building Windows Terminal which is shaping-up nicely for its v1.0 release this summer. Please give it a try and if you find problems, find/file issues in the github repo because, yes, Windows Terminal and Console are open-source!
Maintaining compatibility and not breaking stuff generally adds a severe multiplication factor to the development time compared to a greenfield project.
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.
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.
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).
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.
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.
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.
> 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.
I'm not trying to knock your efforts but wouldn't you say being able to use the mouse takes priority over things like this? Especially since your target audience is Windows users.
I could be totally wrong but every time I try out the MS terminal I get the impression that no one on the dev team uses it in their day to day because there's no way it could ship multiple times for years without mouse support otherwise.
I would say that emoji support takes precedence, because emoji support implies support for UTF-16 surrogate pairs. Originally the console could only support UCS-2 which could not represent all CJK characters. Adding surrogate pair support brought better functionality to a significant portion of the world's population. Emojis were only a (very visible) part of that feature.
Besides, the console does support the mouse. It's my understanding that mouse input events have been available for decades. I'm not sure where you're seeing problems with them.
I can guarantee that everyone on the dev team dogfoods their product.
> It's my understanding that mouse input events have been available for decades. I'm not sure where you're seeing problems with them.
Here's a narrated few minute video that shows how mouse events don't get passed through to the terminal (with or without tmux), and how they do get passed through using WSLtty using the same exact tmux and Vim configs for both environments.
> if you use tmux and have Vim open and try to click into Vim or any tmux window, nothing happens.
This means one of three things:
* tmux doesn't know to enable mouse reports, which will be almost certainly a TERM and terminfo configuration issue.
* The terminal emulator does not recognize the control sequences that turn on the various kinds of mouse reporting (DEC Locator, X10, Unicode rxvt, and ECMA-48-conformant XTerm).
* The terminal does not pass on mouse input events as mouse reports.
I shouldn't play the "mouse input events have been around for decades" card here, if I were you. DEC Locator reports precede anything relating to Win32, dating back to the VT220 in 1983. People could quite justifiably play the "Windows Terminal is not as good as a terminal from 1983" card in response. (-:
... and zamadatix did point to the known open issue on this. It's both the second and third items.
WSLtty is just Mintty, which is just PuTTY. PuTTY et al have had a very long time to mature, and I still find them to be quite problematic. They don't perfectly match any terminfo/termcap entries (they're far from matching xterm--Windows Terminal is actually closer in that regard), and even if they did, some key combinations that should send unique codes don't--for example, Shift + arrow keys, which I use with tmux.
It does, but I've found it to be inaccurate at times, or at least have some oddities with the programs I tend to frequent (tmux with byobu configuration in particular). That's not to say it's not an improvement, but it doesn't fix everything.
It's not just a mismatch issue. For example, I expect Shift + arrow keys to send unique sequences so they'll be differentiated from just plain arrow keys. PuTTY doesn't do that, nor does it provide an option to do so.
I'm glad I'm not the only one struck by how bizarre those seemed as headline features. Compare to other toolkits (I'll use macOS) where automatically transitioning between windows and tabs is a standard feature of the GUI toolkit, and emoji support is provided for free by the operating system's text subsystem.
I would've imagined this to be the case on Windows, at least for Metro apps — isn't that where the new GUI development is going on?
I'm probably way off-base, but it always seems like problems that should be solved system-wide on Windows are solved in different ways by different teams at different times.
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:
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
One thing that's uniquely advantageous for me with WSL is having multiple distributions at hand all atop Windows without the hard lines of traditional VMs. So I use Ubuntu on WSL for stuff like server/network admin. But if I want to work on some code for my RPi GPIO project, I can easily access Debian on WSL (where RPi libraries will actually install), all while still having the primary OS be Windows (which confers a lot of advantages in daily productivity app use, games, etc).
I'm not sure that a Mac (for instance) can match that kind of flexibility as elegantly. I may be an edge case in not sticking to one distribution but I definitely see the whole system as a uniquely better environment because of that flexibility.
Some of that performance is negated by WSL. The storage in particular, if you're using WSL 1. I find node development intolerable.. npm likes to write many small files and installs take ages.
WSL 2 is probably an imperceptible difference for most tasks though since it's just a svelte Hyper-V VM.
It does look like it, but isn't it based on electron? Personally I like this, but all the environments I've had to use windows on can't use this because they use an ancient windows LTS release. In an enterprise setting where I mostly see windows I always end up having to use a linux VM.
Actually in those environments I've had success using Electron[1]. But well, that's electron...
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!
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
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.
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.
> 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?
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”.
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.
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.
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.
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.
* 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
* 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.
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.
> 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.
> 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.
> 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
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:
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.
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.
Both those articles state that the behaviour is inconsistent and requires complex coding to support in each and every application.
The second article says that 2 of the 3 'delete-like' keys have wonderfully unique failure modes that are essentially unpredictable to the end-user and not fixable from their perspective much of the time.
Meanwhile these keys "Just Work" for all Windows applications, all of the time.
This is my point. The articles you linked are agreeing with it.
If you're using PowerShell Core, add the following to Documents\PowerShell\Profile.ps1. If you're using legacy PowerShell, add it to Documents\PowerShell\Microsoft.PowerShell_profile.ps1 instead.
Remove-Alias cls
function cls {
echo "$([char]27)c"
}
A similar solution was provided in the GitHub issue that works on older versions of Windows Terminal.
Using the RIS control sequence is a bad idea. Its long-standing functionality has included completely resetting the serial communications at the terminal end.
ED (Erase Display) is the control sequence to use for clearing the screen in systems with a terminal I/O paradigm. Emit it twice, as ED 2 to clear the whole main screen and as ED 3 to separately clear the scrollback buffer.
Normally it's not what I'd use, but Windows Terminal still has some quirks. It was the only thing that seemed to work reliably. However, now that I've done additional testing, even that doesn't seem to work reliably.
Keep in mind that the context here is finding a workaround for a specific terminal emulator.
The workaround, which isn't really a workaround at all because it's the standard way of doing this (plus a fairly modest common extension that we terminal emulator authors have mostly agreed upon), has already been found. The Microsoft people in the GitHub issue said to use ED 2 and ED 3, as well.
I merely additionally explained why your doing something that they did not suggest is wrong, not only for the reasons that the Microsoft people already said, but for the additional reasons that it has a standard function that is not what is desired here.
It doesn't work, though, as I've already explained elsewhere in the comment tree. It works in naive examples, but fails to clear at the correct time in more complex situations.
I don't know if I'm using "Legacy" Powershell. `(Get-Host).Version` reports 5.1.18362.145. I added your workaround to both .ps1 files. It doesn't change any behavior in any obvious way. Even if it did, it's still a work-around at best. If this actually worked, I can't imagine a reason this shouldn't be built in to the product. But I really don't think it works. Regardless of whether any of these profile scripts are taking effect, invoking `echo "$([char]27)c"` directly also doesn't clear the scroll history, so I doubt it would even work even if I could figure out how create a profile script. I did notice that there were a number of other proposed work-arounds in the github thread. Each one of them seems to have some feedback saying that it doesn't work.
In my opinion, this is shortcoming of this product.
It looks like others have already given you long explanations of why PowerShell works this way. Nevertheless, the behavior you're describing can still be desirable at times.
In the future, the following will probably work:
echo "$([char]27)[3J$([char]27)[H$([char]27)[2J"
This matches the output from `tput clear` in WSL.
However, as of writing, it's a bit quirky when combined with other PowerShell commands; for example, the following behaves oddly:
ls; echo "$([char]27)[3J$([char]27)[H$([char]27)[2J"; ls
Unfortunately, I don't have a good solution at the moment.
To be honest, it's pretty much all over my head. I'm just a simple man, trying to clear my console. The only way to do it seems to be completely restart it, which I guess is ok, but certainly inconvenient. I'll probably check back in on Microsoft Terminal in a few months and see if any of the terminal wizards have discovered a way to clear the console.
Part of your problem is self-inflicted. The deficiencies of the CLS command have been known for about a quarter of a century, long before Windows Terminal was even an idea. It's why 4NT, later to become TCC, added a /C option to its CLS command, making it clear the entire screen buffer instead of just the window rectangle.
I have never heard of 4NT or TCC. By the way, the problem also affects the `Clear-Host` powershell command. `cls` seems to work exactly how I want outside this new Terminal program, so it's hard to understand how it could have been so well known.
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.
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?
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!
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. :)
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.
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?
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.
I got a firewall popup when I opened Windows Terminal today. I forgot which IPs it was trying to communicate with, but it definitely tried to open some kind of connection.
Would you mind reporting this on our public tracker[1]? We absolutely do not expect there to be any outgoing connections unless you explicitly request them. Everything we're shipping is something visible in our public source, so you don't need to take my comment at face value.
My work dictates that I use an issued Thinkpad or a Macbook Pro, and we are not allowed to install our own OS choices on those. I like the Thinkpads they give us more, especially since the Macs have the widely reviled touch bar. WSL and the new Windows Terminal have been great tools for me.
Just a reminder: your work is wrong. The idea behind is that they have 'supported configurations' where 'supported' often means 'trying to reduce service desk load' and 'pretending that imaging a system once and then hoping the lifecycle on all of them is the same'. In reality that is almost never the case (unless the systems are reduced to barely usable configurations), and you end up with a system that is only 'work-supportable' on the surface, while being a pain for everyone else.
Some of the recent changes I've seen happening at an increasing scale is having practical support levels:
- fully-managed
- half-managed
- BOYO (Being on your own)
This is then applied to both company-delivered systems as well as BYOD systems. Combined with standard interrogation tools like osquery you can get a much better picture of what is happening and what level of compliance you can measure.
Instead of them implicitly trusting or hoping a device is okay you actually get to measure it. This enables a BOYO-BYOD BSD fanboy to present themselves as being in-spec and compliant while being in their own comfortable environment for maximum productivity. At the same time, someone who has a hard time figuring out how to turn a laptop on just goes for fully-managed, still gets measured periodically and on-access and gets a generic experience allowing normal-people productivity.
