I shouldn't really have to look up the instruction manual of a text editor to do a simple action like close the program. Every single other text editor I've ever used was intuitive enough to get started right away, going back to 1989.
Once you get used to it, it can be a dang powerful tool. For people doing a lot of config-wrangling on the CLI (i.e. admins working a lot ovet SSH), overcoming the learning curve will pay dividends.
If you’re working mostly locally and in a GUI environment environment, it’s probably not worth it - there’s a reason most devs use more specialized IDE’s.
If it’s not intuitive enough then don’t use it and don’t open it. You can always close with Ctrl+z and then kill it. Or close a terminal window like any other intuitive editor.
Nowadays it’s easy when you open vim inside gnome terminal, in my old offline noob days it was like “oh shit my terminal is locked” and the way out was either Alt+F2 and then try again or Ctrl+Z; pkill %1.
I never caught the vim bug and started with using joe and switched to nano later, I played with Emacs for some time but ended up using a GUI editor instead.
Just use a windows VM lol. Only problem I’ve encountered outside of that was a lockdown browser for school but I just put that on a burner laptop because there is no way I’m letting some rando have root access to my main pc
Yes this makes sense. Linux running a 25yr old binary would throw errors for shared libraries, or kernel compatibility or just the fact it’s the wrong arch type.
Did that as a work project on Unix. My peer had a similar porting project.
I thought I was screwed: 20-year-old c-based backup tool. His was easy: this perl web app is installing on a new box because its old one is being lifecycled.
Actual: after 3 weeks of dependency hell he tossed it all and rewrote the thing in c from scratch overnight. My c project was make;make-install with no errors.
I think it’s been recompiled a few times since then, without any code changes.
In my experience, on Windows a lot of old stuff runs as long as you have whatever registry setting enabled that lets you run non 64 bit programs. This isn’t available on every windows pc but if you’re running it on your home pc, you can probably get it. A lot of old games don’t work but old things that don’t use graphics almost always run.
In wine, it’s basically the same story. A lot of old stuff runs especially non graphical old stuff. Some old windows games don’t work on wine but just because something old doesn’t work on Windows doesn’t necessarily mean it won’t work on wine and vice versa.
I would rate wine as slightly more compatible with late 90s and early 2000s games than Windows is but ymmv. Graphics stuff tends to work a little more often on wine. Some mid 2000s games use obscure hacks that are impossible to ever get running on wine.
registry setting enabled that lets you run non 64 bit programs
Do they seriously not support 32bit software out of the box anymore? I know getting 16bit software to run on x64 is close to impossible (look up NTVDM x64) for obvious reasons but there is still lots of x86-only stuff.
That’s what I thought because that was my experience last time I used Windows; that’s why it surprised me that the previous comment suggested otherwise.
linuxmemes
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.