1. By the author - https://news.ycombinator.com/item?id=44034961 2. Ubuntu Publication - https://news.ycombinator.com/item?id=44306892
And this post.
--
`edit` doesn't even support syntax highlighting (atleast, out of the box when I tried it).
Prose thrives in the terminal. Ice and Fire was written in WordStar, as just one popular example.
The trick is doing it while keeping the binary size small, so tree sitter is not an option.
What turbo vision brought to the game was movable, (non) modal windows. Basically a lot of rewriting that array in a loop. Pretty snappy. I made a shitload of money with that library.
So good.
Arrays in TP were laid out in row-major order, and each character was represented by two bytes, one denoting the character itself and the other the attributes (foreground/background color and blinking). So, even better, array[1..25, 1..80] of packed record ch: char; attr: byte end absolute $B800:0000.
Replace $B800 with $B000 for monochrome text display (mode 7), e.g., on the Hercules.
…but is it really less secure than brew or choco? The installers are coming from reasonably trusted sources and are scanned for malware by MS, a community contributor has to approve the manifest changes, and the manifests themselves can’t contain arbitrary code outside of the linked executable. Feels about as good as you can get without requiring the ISVs themselves to maintain repos.
There are ISVs that would like to lock down their software so they can maintain it but a trillion dollar company couldn't spare a dollar to figure out a "business process" to do this. As far as I know, Microsoft has a single employee involved who has laughed off any security concerns with "well the automated malware scanner would find it".
The "community contributors" were just... people active on GitHub when they launched it. Was anyone vetted in any way? No.
The Microsoft Store has actual app reviewers, winget has... "eh, lgtm".
There is no validation when you winget whether or not the executable is from the official source or that a third party contributor didn't tamper with how it's maintained.
HTTPS only guarantees the packets containing the unverified malicious code are not tampered with from the server to you. A server which could very well be compromised and alternate code put in its place.
You are drawing an egregious apples-to-oranges comparison here. Please re-read what you said.
You could serve digitally signed code over plain HTTP and it would be more secure than your example over HTTPS. Unfortunately there are a lot of HTTPS old wives' tales that many misinformed developers believe in.
It's trivial for a remote server to hand two different versions of a script with the traditional `curl | bash` pipeline. https://lukespademan.com/blog/the-dangers-of-curlbash/
There is 0 validation that the script that you are piping into bash is the script that you expect. Even just validating the command by copying and pasting the URL in a browser -- or using curl and piping into more/less is not enough to protect you.
It's not hard to run the `show` command to see what a winget install will do. https://learn.microsoft.com/en-us/windows/package-manager/wi...
It's easy enough to view the manifests (eg, https://github.com/microsoft/winget-pkgs/blob/2ecf2187ea0bf1...) and arguably, is better then the protection for MITM that you would get using naked cURL & Bash, simply because there are file hashes for all of the installer files provided by a third party.
> They are saying curl is strictly better, not that it is impenetrable
Right. But it arguably is not strictly better.
> You can't trust winget
Again, this is not backed up by anything. I have trust in winget. I can trust that the manifest has at least been vetted by a human, and that the application that will be installed should be the one that I requested. I can not trust that this will happen with curl | bash. If the application that is installed is not the one that I requested, there is tooling a process to sort out why that did not happen, and a way to flag it so that it doesn't happen to other users. I don't have this with curl | bash.
> It's trivial for a remote server to hand two different versions of a script with the traditional `curl | bash` pipeline.
I’m confused by this; it seems to be written in the tone of a correction but you both seem to be saying that you get whatever the server sends. (?)
Yes, but I am also saying that you can't verify that the script that is run on one machine with a pipe is the same script that runs on a second machine with a pipe.
The key part of the original statement is the server can choose to send different scripts based on different factors. A curl&bash script on machine 1 does not necessarily mean the same curl&bash script will be run on machine 2.
The tooling provided by a `curl | bash` pipeline provides no security at all.
With winget, there is at least tooling to be able to see that the same file (with the same hash) will be downloaded and installed.
There are ways to do this better, for example, check out https://hashbang.sh. It includes a GPG signature that is verified against the install script, before it is passed to curl.
Manage configuration, and external dependencies such as lsps with nix.
Then have separate nix shells for each project to load tooling and other dependencies in an isolated/repeatable session. Add in direnv to make it more seamless development experience.
...
Anyways, here's how to tell if your LED sign is cheap!
The one thing that vexed me for something based on edit, was CTRL+P being hijacked for something that isn't print, is like we forgot about about CUA over the last 15 years.
SqlServer like it's the one that found sql or it's the only product that serves sql.
It was my favorite editor back in the old days.
It worked, did the basics really well and got the job done. Glad to see it’s back.
I guess they thought that inheriting 25 years of C code was more trouble than designing a new editor from scratch. But you'd have to ask the devs why they decided to go down that route
Rust + EDITOR.COM is kind of like remaking/remastering an old video game.
Reminds me of my days on a support line.
"Type edit autoexec.bat....." etc
I remember you could use it in a batch file to script some kinds of editing by piping the keypresses in from stdin. Sort of a replacement for a subset of sed or awk.
I haven't tried but this should be possible with vi too. Whether that is deeply cursed is another question.
anyfoo•8h ago
DrJokepu•7h ago
> The goal is to provide an accessible editor that even users largely unfamiliar with terminals can easily use.
scblock•7h ago
cosignal•7h ago
cAtte_•7h ago
zamadatix•7h ago
The previous HN posts which linked to the blog post explaining the tool's background and reason for existing on Windows cover it all a lot better than a random title pointing to the repo.
kevin_thibedeau•7h ago
mikepurvis•3h ago
I can definitely see msedit having a useful place.
hulitu•3h ago
paulfharrison•6h ago
I've met biologists who enjoy the challenge of vim, but they are rare. nano does the job, but it's fugly. micro is a bit better, and my current recommendation. They are not perfect experiences out of the box. If Microsoft can make that out of the box experience better, something they are very good at, then more power to them. If you don't like Microsoft, make something similar.
hulitu•3h ago
mcedit ?
rtpg•5h ago
EDIT.COM, on the other hand... nice and straightforward in my book
justsomehnguy•7h ago
/rant Today I spent 3 (three) hours trying to setup a new MSI AIO with Windows Pro. Because even though it's would be joined to the local ADDS and managed from there - I need to join some Internet connected network, setup a 3 stupid recovery questions which would make NIST blush and wait another 30 minutes for a forced update download which I cannot skip. Oh, something went wrong - let's repeat the process 3 times.
xeonmc•7h ago
Gormo•7h ago
This particular application is incredibly basic -- much more limited than even EDIT for DOS.
cool_beanz•7h ago
iknowstuff•7h ago
tim--•7h ago
It's impressive to see how fast this editor is. https://github.com/microsoft/edit/pull/408
> By writing SIMD routines specific to newline seeking, we can bump that up [to 125GB/s]
_verandaguy•7h ago
Who's editing files big enough to benefit from 120GBps throughput in any meaningful way on the regular using an interactive editor rather than just pushing it through a script/tool/throwing it into ETL depending on the size and nature of the data?
tomrod•7h ago
anyfoo•7h ago
WD-42•7h ago
anyfoo•7h ago
_verandaguy•6h ago
If you build the world's widest bike, that's cool, and I'm happy you had fun doing it, but it's probably not the most useful optimization goal for a bike.
WD-42•4h ago
tim--•7h ago
Fuzzy search, regular expression find & replace.
I wonder how much work is going to continue going into the new command? Will it get syntax highlighting (someone has already forked it and added Python syntax highlighting: https://github.com/gurneesh9/scriptly) and language server support? :)
_verandaguy•6h ago
Add on a well-built plugin API, and this will be nominally competitive with the likes of vim and emacs.
tiagod•6h ago
orthoxerox•1h ago
magicalhippo•6h ago
Typically we just hand edit them. Actually been pleasantly surprised at how well VS Code handles it, very snappy.
cerved•3h ago
kgwxd•5h ago
z3ratul163071•4h ago