Hacker News Reader

Comment by arghwhat | Hacker News Reader

Yay for finally having a default text editor that works over ssh. Managing windows servers over ssh is a bit of a pain without.

They could just have packaged nano, but oh well.

View on HN

I wholeheartedly agreee. Nano is quite awesome, it is battle-tested and already has more features than needed for a basic text editor. Actually, Nano is too often frowned upon as too-basic, but is actually has a few advanced features that basic editors do not have (e.g., keyboard macros). I'd argue that Nano is simple rather than basic :).

I tried discussing it here a few months ago but it did not took off: https://news.ycombinator.com/item?id=41289773

I love nano and used it as my terminal editor on Linux.

Edit seems super approachable to newbies with it's mouse support in the menus. I love that and would love to see it in nano.

Just put

    set mouse

in your ~/.nanorc and then you can click on all the UI elements, including the actions/functions at the bottom of the screen, which play the roles of the menu in Nano.

:brainexplosionemoji: Thanks!

Try micro

I was about to say, I use nano regularly, both locally and over ssh (to machines which have it installed, which is pretty much all of them). This looks nice and I love old-style console UIs, I fondly remember EDIT.COM and NC.EXE, and still use `mc` regularly with one pane pointing at a sshfs.

Ages ago I had to maintain a .BAT file, editing in EDIT.COM, that threw stuff at EDLIN.COM (roughly MS version of `ed`). Those where the ... not-so-good old days.

These days, with windows versions of `nano` and `busybox` you have some power tools without a full linux install.

This could be a great text-mode IDE with the addition of some LSP, tree-sitter and DAP support. There is already an open issue about possibly adding support for tree-sitter grammars for fast syntax highlighting, but they do mention that this requires some sort of optional plugin system to avoid bloating up the codebase severely (for example, the tree-sitter grammars within the Helix editor take up hundreds of megabytes, which is obviously unacceptable here).

What on earth needs hundreds of megabytes to describe its grammar?

Even the hundreds of kilobytes used in the official grammars seems bulky to me. https://github.com/tree-sitter/tree-sitter-java/releases

That just feels like scope creep. Notepad would also be neat with some better keybinding support, plugins, lsp, ... - but then it wouldn't be notepad, and theres countless not notepads out there.

Tools like nano (well, pico) exist to provide a reliable and always available minimum feature set. If you expand it, then you end up with something that is neither the minimum nor capable enough to sensibly compete with fully fledged alternatives.

No, it would still be notepad, but a higher quality one where especially users who don’t know better wouldn’t have to suffer as much from bad/lacking functionality

More features ≠ higher quality.

But lack of useful features = lower quality, so you're just arguing for a permanent state of poor quality for some strange change-resisting reason and the fact that alternatives exist (so? why should that stop your alternative from becoming better?)

No. Adding superfluous features to an intentionally minimal baseline program defacto reduces it's quality by making it less suitable for its task and more likely to have defects.

There's decades worth of options for fatter editors out there. Tools like nano (and now edit) is ubiquitous because they are not such editors, and people need a reliable baseline without such features.

There are already: Notepad3 (https://sourceforge.net/projects/notepad3/) or metapad (https://liquidninja.com/metapad/).

But they aren't part of Windows, so "users who don’t know better" continue to suffer!

Well, Notepad is introducing AI support which already feels like scope creep to me…

https://support.microsoft.com/en-us/windows/enhance-your-wri...

... Yikes.

They already introduced it. It's been there for some months.

I am truly behind the times. I didn't know you can ssh into a Windows system.

Since windows 10/windows server 2019 afaik.

https://news.ycombinator.com/item?id=15904265

Thanks! It always bugged me that Windows didn't have a sshd, since it's so popular outside of Windows. I thought the reason for it not being added would be admitting a failure somewhere - RDP not winning or something. Seemed odd to prevent a way into Windows Server.

No. It was a fundamental conceptual difference in the operating system. After Xenix, Microsoft did not use a terminal paradigm in its operating systems. They all had a "console" paradigm, where instead directly attached VDUs, keyboards, and mice had explicit API support as first-class devices. Because they targetted "personal computers" where one knew from the firmware up that the machine had a VDU, a keyboard, and (possibly) a mouse.

* https://jdebp.uk/FGA/tui-console-and-terminal-paradigms.html

For a long time, so long that I had a widely used 2 decades old Frequently Given Answer about it, Windows NT had no way to capture console I/O, no way of waiting on consoles for buffer changes and to inject back-end input events. No way to do what a SSH server would need to do in order to capture and send/receive that I/O over a network.

Then along came Windows Terminal, and I finally got to change the answer in 2018.

* https://jdebp.uk/FGA/capture-console-win32.html

RDP is still the best remote desktop protocol - so much so that Gnome on Linux uses it for desktop sharing.

But, of course, it's a remote desktop protocol. Meanwhile Windows Server has been steadily moving onto command line & PowerShell for system administration for the past 12 years or so. The bespoke solution for remote admin has been remote PowerShell for a while, so ssh is arguably competing with that.

You can also run a ssh server in WSL2. You'll need to proxy connections to it or run a vpn though to have it visible from the outside. I use tailscale.

Ah, that makes sense then; I was really confused at first because I couldn't figure out why Windows would want a built-in text-mode editor. I suppose if folks are seriously using SSH to access Windows machines ... then I have other questions about why not RDP, but if that's a real thing people are doing then adding a built-in editor for them makes sense.

This might be the most obvious use case: https://learn.microsoft.com/en-us/windows-server/administrat...

I'm a powershell bigot and spend most of my windows admin life in a terminal (or vscode) so my take is to simply use psremoting but ssh is there if you need.

I prefer SSH because it fits into a standard workflow with far larger ecosystem (my file manager and editors can browse SSH directly, traffic can easily be routed over SSH in either direction), and is already what I'd use for the majority of servers and machines.

psremoting would be limited specifically to remote PowerShell on windows, which is comparatively limited. Even if I was purely a Windows admin I'd consider the SSH approach more powerful.

Understood and SSH figures heavily into any admin's workflow, but PSRemote brings some advantages when you're using powershell. Much like you can execute remote commands in SSH, I can do that w/ psremote while keeping the full object pipeline intact, whereas ssh just squashes all output to a single text string like most unix-native tooling.

Posh remoting works well because it's posh and you get all the nice object-oriented things that come from that. You do miss features like tunneling so I have SSH to fall back on where needed (and also for non-windows workloads etc). Right tool for the job and all that, and if you're not a heavy posh user the ssh option makes a lot more sense.

SSH is ubiquitous, lightweight, and now works for all machines equally.

SSH is integrated with everything and can be used to manage, transfer files/mount remote folders, forward ports in either direction, or proxy any network traffic through the remote end for debugging/access. You can open a remote folder directly in vscode, Zed or similar over SSH.

RDP to a standard Windows server (this was previously called "core" - having a desktop environment is a non-default add-on now) is silly as you're RDP'ing to solely see a cmd.exe window that asks you to use console-based configuration (sconfig.exe).

RDP to a windows server with "Desktop Experience" is silly because it is comparatively sluggish, streaming a (likely unaccelerated) video feed of heavier GUI applications vs. sending just a few text strings back and forth during editing.

Not to mention that containerized windows has no graphical stack and requires a text-centric workflow.

Or kilo[1]

[0]: https://github.com/antirez/kilo/

Or Micro[0]

[0]: https://github.com/zyedidia/micro

Micro is nice because it is a single-file, stand-alone executable that has mouse support, macro record/playback and syntax highlighting. (I haven't checked Nano recently). It is great for making quick edits to json configs, shell scripts, python scripts, etc. Syntax highlighting and line numbering are key. If I need to make a really quick edit, it is much faster to use this than waiting for VS Code or PyCharm to load. You also stay focused. By this I mean, your eyes don't leave the terminal window that you are currently working in. This allows me to more quickly complete the task at hand.

I was impressed that they actually looked at other editors in the ecosystem, I wasn't expecting that. Aside from WSL stuff does Windows distribute any other 3rd party utilities?

openssh, curl, bsdtar (also Windows built in archive support is libarchive)

It's such a simple program that it's better to roll a proprietary program that is well integrated with windows

You can use nano over wsl if you want

> You can use nano over wsl if you want

No, not when ssh'ing to a server to manage it. Pulling in a Linux VM to get a simple text editor also makes no sense.

There is also nothing to integrate - it's a basic text editor for a terminal with no fancy features. It either edits text or it doesn't.

you gotta make sure that hotkeys get passed in every keyboard configuration. Ctrl, CTRL Shift, Ctrl Caps, Alt, how do tabs work? Etc..

That something looks simple but is actually difficult is an error we all make

This is a console application, it does not manage the keyboard directly and there is nothing windows specific here.

All existing editors do these things well already, nothing that required writing yet another editor.

Actually, there is Windows-specific stuff in the new EDIT. When built for Windows, it uses a one-foot-in-each-camp mixture of high-level and low-level console I/O, high-level for output and low-level for input.

https://github.com/microsoft/edit/blob/main/src/sys/windows....

They could've just shipped YEdit, which is open source: http://www.malsmith.net/edit/ but there is NIH syndrome in MS.

Yedit actually was written by a Microsoft employee :P

It had some problems however with handling unicode (iirc). Basically, shipping yedit would have required a huge re-write of its underlying text buffer. In the end the discussions we had with Malcom concluded that just writing a new one was probably easier and more maintainable in the long run.

Now that they have a text editor that can be used in a terminal:

Calling it: 2025 will be the year of Windows on the server. /s

Aside from Windows being... "windows" (IE; graphical) and the whole "we will do our own paradigm for nearly everything including file paths (UUNC included) and encoding..." Windows is actually pretty stellar if you're writing high performance software.

You can go really far with IOCP and it's so nice to write compared to the contemporary kqueue (BSD) or epoll. I will admit to not trying IO_Uring myself though.

Also the Windows system probes predate any kind of bpf and are easier to use than dtrace.

This is the maximum amount of love I will ever send in Windows' direction though. Everything else is ball-busting.

It's not my idea of a good time, but Windows pioneered some stuff that's really handy for servers.

Receive side scaling[1] is super handy at high volume, and it came from Windows. And Windows has better apis for it than I saw in FreeBSD or Linux when I needed it (I didn't look too closely at Linux though, so maybe it was there).

[1] https://learn.microsoft.com/en-us/windows-hardware/drivers/n...

There are more windows servers than linux desktops

There are more floating turds than perfect pearls.

This is quite plausible.

I'm actually not sure, but not because I believe there are many of the latter.

Reply on news.ycombinator.com