Live data from Hacker News

NirSoft Freeware (2008)

nirsoft.net

211–220 of 241 posts

Re: NirSoft Freeware (2008)

#211
post #99
post #57

Earlier quoted context omitted.

It's still hard to understand that they haven't touched Notepad in such a long time. The effort to get a good editor must be tiny compared to a lot of other stuff they are doing. I am pretty sure I could improve Notepad substantially with just a few days of work.

I'm sorry for going off topic, but I keep seeing this kind of comment and I want to get an answer - how is Notepad not a good editor? It can take any ASCII/ANSI/UTF file and output it in plaintext. It has line-wrap as an option. It loads fast and can handle files of decent size without lag. Users can set display and print fonts, etc. I'm really lost as to why anyone says Notepad is not a good text editor for basic te…

One the machines I'm using at home and at work (Windows 10 Desktop + laptop, Windows 7 latptop, Windows server 2012 running in VMware), I've found that notepad is way slower than notepadd++ to launch. And adding tab support, syntax coloring, sane undo, restoring workspace on load and reload the file without closing the app, there's no competition between the two.

Re: NirSoft Freeware (2008)

#212
post #197

I love NirSoft utilities as much as anyone, but this isnot right > Anonymous Information Collected on this Website: Anonymous data is recorded on this Web site. Most of the information collected from this website is anonymous information, such as the pages you visit. Other anonymous data I may collect might include the name of your internet service provider, the website that you used to link to my site, the websites…

At least he's upfront that he's keeping info from user connecting to his website. And perhaps at the time when it was written (2008), the author considered that IP was anonymous enough, from his viewpoint, as he couldn't do much with it.

Re: NirSoft Freeware (2008)

#213
post #98

Earlier quoted context omitted.

> It's probably one of the simplest changes you can make to Windows. I hope we can agree on that. I certainly do not agree with that! For example, Notepad has been one of the buggiest and weirdest pieces of software I used on stock Windows. It does weird things when saving files, like moving your cursor to another location, so if you are typing and saving and typing and saving you will end up with text misplaced all…

Well, then make a new editor and give it a different name. Leave the old one in for compatibility. It's not hard.

They did, it's called Wordpad

Re: NirSoft Freeware (2008)

#214

Earlier quoted context omitted.

There's no reason a text editor, or most applications really, need unrestricted access to a user's disk. They have to prompt the user with a file open dialog anyway, so you may as well let the OS handle that and pass an fd/handle across the boundary for you.

What if you are using a smart IDE like editor that, for instance, minimizes and concatenates your css and js files? It’s going to want access to all files in that directory, not only the ones you are editing.

tbh that doesn't sound like a huge problem to solve. Setup some working folders that the PWA has R/W access to and leave it at that.

Re: NirSoft Freeware (2008)

#215
post #92

Earlier quoted context omitted.

Isn't this basically what PWAs will hopefully solve? Rather than Spotify, Slack, Discord, ... all coming with their own Electron bundle they can be packaged up as a PWA and use the browser as the runtime environment along with all the nice offline stuff, safe OS integration for notifications, sandboxed file system access, ability to still do some work in S0i3 (aka Modern Standy on Windows), etc. Or am I totally wrong…

All good questions and some things will probably be well addressed by PWA or whatever we decide to call JavaScript rich webpages by then. But some UI issues, like the lack of a proper menu, browser's chrome and address bar will still be a turn off. Besides, having unrestriced access to the user's drive is not something a web page should be able to do and is a must for something like a text editor.

Browser chrome and address bar are not an issue as I believe a PWA can run in a generic application Windows with it's own icon, etc. Similar to if you have used a Chrome Web App in the past? Unless you go looking for it you wouldn't know it was running within a Chrome process.

Not sure how menus are handled. A standard menu API would seem to make the most sense to me?

Re: NirSoft Freeware (2008)

#216
post #204

> While many software companies create a bloated installation package with size of 1 - 3 MB, the size of single utility in NirSoft is usually less than 100KB. The early 2000s were a different time. While as modern day electron apps are regularly 100+ MB.

I've come to see the rise of Electron not as a shortcoming of other UI tech, not a problem with Electron. OSX, Windows and Linux failed to have any viable cross-platform UI solution[0]; Electron is what we deserve for this failure. [0] I would be very happy with Qt/QML and would grudgingly accept GTK, but others apparently are not that complacent

We've had perfectly viably cross platform GUI-applications for decades. Lots of them. Done one way or another, or a third. I'm sorry, I fail to see the problem that abominations like Electron are trying to solve.

Re: NirSoft Freeware (2008)

#217

Earlier quoted context omitted.

Around 2000, I had a laptop with 5g of harddisk and 64mb of ram, now I'm at ~1tb and 16gb ram. Roughly a 200x increase in raw numbers, though lots of other things since then make the actual increase larger, so it sounds like we're using net-smaller apps :)

My personal complaint is that, with 200x more compute, we should be doing 200x more and/or more powerful things. Instead we're doing the same things ~200x less efficiently.

Yep. If you look at many of the daily tools out there, they do basically the same as was done using CLI or TUI tools back in the day, but now they pile on graphics "assets" to make the experience shinier.

Re: NirSoft Freeware (2008)

#218
post #204

Earlier quoted context omitted.

I've come to see the rise of Electron not as a shortcoming of other UI tech, not a problem with Electron. OSX, Windows and Linux failed to have any viable cross-platform UI solution[0]; Electron is what we deserve for this failure. [0] I would be very happy with Qt/QML and would grudgingly accept GTK, but others apparently are not that complacent

We've had perfectly viably cross platform GUI-applications for decades. Lots of them. Done one way or another, or a third. I'm sorry, I fail to see the problem that abominations like Electron are trying to solve.

Effectively it is VB for the web age...

Re: NirSoft Freeware (2008)

#219

Earlier quoted context omitted.

We've had perfectly viably cross platform GUI-applications for decades. Lots of them. Done one way or another, or a third. I'm sorry, I fail to see the problem that abominations like Electron are trying to solve.

Effectively it is VB for the web age...

Exactly. And nothing new in my being contrarian. Back in my Windows days, back in the nineties, I had an iron rule that no vbrun.dll ever entered my machines. Mainly because they invariably turned out to be badly designed, poorly implemented, and just not worth the trouble.

These days, I do* have a couple of Electron-things installed, because I occasionally need them, but they are ugly hacks which bring me no joy.

No JRE either, by the way, if I can help it. Same reasoning.

Re: NirSoft Freeware (2008)

#220

> While many software companies create a bloated installation package with size of 1 - 3 MB, the size of single utility in NirSoft is usually less than 100KB. The early 2000s were a different time. While as modern day electron apps are regularly 100+ MB.

Around 2000, I had a laptop with 5g of harddisk and 64mb of ram, now I'm at ~1tb and 16gb ram. Roughly a 200x increase in raw numbers, though lots of other things since then make the actual increase larger, so it sounds like we're using net-smaller apps :)

To go further back into the 80s where we were hard locked at 64k for commodore or 640k for DOS Assembly became the norm and optimizing for everything was the common goal for the whole community. It ended up creating a hack centric environment but it sure wasn't A) pretty nor B) beginner friendly. I'm old and have fond memories of assembly on the C64 as a kid, but I think we are in a better place where we have higher level languages and where Racket (Lisp of your choice here) and Python can run on a micro controller.
Post reply on HN