nameiscubanpete

ConEmu is the best solution on Windows. Hopefully the new Windows Terminal brings console API changes that ConEmu can take advantage of; there is a lot of black magic going on under the hood.

That was my first thought. But then I realized some guy basically broke something so his stuff would work and someone else's wouldn't. He didn't destroy files, but that was malicious as hell.

It's better that "Hello, world" take 5 seconds to print than 1 second to crash and print nothing.

Speaking of code readability, the article uses a function in the example called "isNotOpenSource()". If you have a function that returns a boolean, it's best not to put another boolean in the function name i.e. "isOpenSource()" is cleaner and more readable.

Honestly, it's a code smell that makes me trust my initial reaction that the switch statement is indeed more readable than the authors solution.

Check out Stallmans argument. He ends up at the same place as Theo, but goes into the why's:

https://www.gnu.org/philosophy/programs-must-not-limit-freed...

It's harder to be moral when you know you can do the wrong thing and get away with it.

I see your point and not necessarily disagreeing, but noting the creators of typescript refer to it as a superset.

It's really kinda both, but context sensitive.

I'd almost guarantee that it's Typescript. But being a superset of Javascript, it's still correct to call it Javascript.

> The Bash scripts were good, but if someone was working on a Windows machine, they couldn’t be run

Git Bash. The only requirement is installing Git For Windows, which is an easy install.

It's a PITA for any reasonably large/old CVS repo. Partly because CVS is fundamentally broke.

Just to note, you can indeed browse build artifacts on GitLab, but finding it is a PITA. You have to drill into your CI Job and there's a button link on the right. It'd be nice to have a "Browse artifacts" option in the Download widget.

I come to this site for articles like this.

It could be. I got into this mode of thinking many years ago and Debian may be just as suitable nowadays.

Trying to install Slackware on a laptop with 4MB of RAM is my Linux coming of age story.

I think perls niche is sort of it's downfall. For example, I used to work at a company with 70% C, 25% shell script, and 5% perl. Any time I ran into a perl script I had to switch my brain into Perl mode, with the understanding that what I was working on would be just as good or better in C or shell. I had nothing against Perl as a language, but always enjoyed exorcising a perl script from the codebase.

I use debian for my own stuff, but always push for RHEL/CentOS at work. Why? Because it's easy to persuade people into keeping the damn systems updated. As long as you stay within the same major version, updates don't break builds or require new rounds of QA.

Under what shell? If this works as described, then it's broke.