Unfortunately many older mud servers (diku? Rom?) started with the wrong \\n\\r and codebases spawned from them just continued.
Very few send the proper \\r\\n
I started "real" programming with MUDs, and after a hiatus I'm still helping run a C-based MUD, and it's awesome.
Much water has passed under bridges, yet there are dozens of us even creating new ones and doing all sorts of weird things with this great hobby.
The Multi User Dungeon discord is nowadays the place to meet like-minded people who like, or code, or balance, or design, or write or use clients for, MUDs. Join us at https://discord.gg/multi-user-dungeon-279748146316312576
> 6. No Discrimination Against Fields of Endeavor
> The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
So if you wish to restrict the use of the Software "in a business" (or in other endeavours), it won't be considered "open source".
The CC licenses aren't great for software, either, IMO. They're great for things like assets, basically... and that's about it.
That said, there's plenty "code available" licenses you may use. You just can't then call them "open source" since they're not.
Another way to put it: say I provide a patch to that software for you. I release it under the same terms as you provided. If you use it, well... you can't use it in your commercial product... as the license forbids it? ;-)
> Why do I, some random person installing this module, care if the tests pass now?
Because running those tests in your environment ensures that... that module can run in your environment.
By way of example, if a module requires a specific library installed to actually run, running its tests will ensure you catch the problem, and install it, so it can then actually run. Else you'd only find out at runtime that something's missing.
Note also that not all tests are the same, and (unfortunately!) not all modules' tests are the same, either: there's tests that ensure the module works "generally", and there's some author/development tests that on a _properly written_ module are only ran by the author/developer, and skip running when the modules are instead installed by mere users, for whom instead the "standard" "will this module work in this environment?" tests are the only one that get ran.
> I have horrible memories of the DBD::MySQL package failing to install because it ran tests that assumed localhost was running a MySQL server
I believe that got fixed, IIRC, as I've had no trouble installing that module (and running its tests at install time, natch). I said "fixed" as that seems like the sort of test that makes sense for the module's authors/developers to run, and not mere users of it.
That depends on "which version" of "Perl 7" you're saying, as IIRC there were various "factions" that had varying ideas about what ought to happen when "perl7" runs programs that didn't specify a "use v..." or that specified a specific "5.something" version.
I'm personally of the idea that enough backwards compatibility _should_ be preserved, but not _so_ much as to inhibit new/better syntax constructs and the like.
But honestly it's the sort of thing that is more like "I'll know it when I see it" more than anything.
Re "long term maintenance mode", there's the not so small matter of how many people can, in fact, actually develop perl. The codebase is large and full of many traps. It's a difficult, but not impossible, codebase to contribute to.
My sincere hope is that enough things will get out of "experimental", including quite a bit more of the "class" feature, for the end result to be enough to be called "7" and we'll go from there.
Basically... mostly a marketing thing, as today's 5.40 is way, way different (and better in so many respects) than 5.8 or 5.20 or even 5.32... but the (minor) version number doesn't show that.
> trying to guarantee backwards compat for all the legacy code
Not "all", as there are indeed deprecations added over time, but _most_.
I really, really like that I can, more often than not, take a program I wrote decades ago and it will still run properly.
> What's your reason to migrate from kitty to wezterm?
My reason to no longer using kitty is simple: I don't like having to copy kitty's terminfo data to every single system I connect to in order to have my terminal work.
It's fine for those few systems I very often connect to, of course.
But I also connect to ephemeral systems, sometimes for a short session, and the toil and friction inherent in having to do that just isn't worth it.
Sure, "kitty +kitten ssh ..." can work in most people's scenarios. Didn't quite work in mine, due to various intricacies about my ssh setup - multiple ssh keys, handled mostly by ssh-ident.
wezterm Just Worked for me. As I got "back" to also using other systems like Windows and MacOS, it Just Worked there, too. No fiddling with terminfo, no fiddling with $TERM, either.
I had a long battle with making kitty work with tmux. I settled on the following in ~/.tmux.conf, before moving to wezterm for good. Maybe it fixes things for you, too:
Looks like there's a bunch of stuff that might opinably fit, depending on who those 10 clients were or what your company does.
- Regulated industries such as: Financial products and services / Investment and brokerage services
- Money transmitters, currency exchange services and other money services businesses
- Neobanks / challenger banks
- Other financial institutions
- Credit card and identity theft protection services
- Other age restricted goods or services
- Virtual and cryptocurrencies, non-fungible tokens (NFTs), and mining services
- Sale of stored value or credits maintained, accepted and issued by anyone other than the seller
- Businesses where sellers get their revenue both from selling items and from signing up new sellers
- When you sign up for Stripe Issuing, you share with Stripe the location of your business, the physical address of your beneficial owners, and the jurisdiction in which your business is registered. Stripe requires that the physical location of your business, its jurisdiction of registration, and the physical address of at least one of your beneficial owners all match. Furthermore, you must use Issuing cards primarily in the same jurisdiction
- Use of Stripe's services for any dealings, engagement, or sale of goods/services linked directly or indirectly with jurisdictions Stripe has deemed high risk, such as Cuba, Iran, North Korea, Syria, and the Crimea, Donetsk, and Luhansk Regions, or persons Stripe has deemed high risk, such as those individuals or entities named to a restricted person or party list of the U.S., United Kingdom, European Union or United Nations, including the sanctions lists maintained by the U.S. Office of Foreign Assets Control or the Denied Persons List or Entity List maintained by the U.S. Department of Commerce, is prohibited. Additionally, it is prohibited to use Stripe's products and services to directly or indirectly export, reexport, sell, or supply accounting, trust and corporate formation, management consulting services, architecture services or engineering services to any person located in Russia. Further, it is prohibited to use Stripe’s products and services directly or indirectly related to any goods prohibited by law (e.g. luxury goods) from Russia.
From a cursory search of email, name, company... I find it plausible that something above might've matched. Or maybe it's a matter of who those 10 clients were, and where they're located. Iran? Cuba? Crimea? Russia? That might do it.
Maybe your competitor also matches, which might be ground for -- if Stripe doesn't want that kind of business on their platform -- for shooting them off, too.
Or maybe it's not a matter of the business type, but of where the clients reside.
Perl continues to flourish into its fourth decade thanks to a vibrant community of users and developers. The following people are known to have contributed the improvements that became Perl 5.38.0:
Alex, Alexander Nikolov, Alex Davies, Andreas König, Andrew Fresh, Andrew Ruthven, Andy Lester, Aristotle Pagaltzis, Arne Johannessen, A. Sinan Unur, Bartosz Jarzyna, Bart Van Assche, Benjamin Smith, Bram, Branislav Zahradník, Brian Greenfield, Bruce Gray, Chad Granum, Chris 'BinGOs' Williams, chromatic, Clemens Wasser, Craig A. Berry, Dagfinn Ilmari Mannsåker, Dan Book, danielnachun, Dan Jacobson, Dan Kogai, David Cantrell, David Golden, David Mitchell, E. Choroba, Ed J, Ed Sabol, Elvin Aslanov, Eric Herman, Felipe Gasper, Ferenc Erki, Firas Khalil Khana, Florian Weimer, Graham Knop, Håkon Hægland, Harald Jörg, H.Merijn Brand, Hugo van der Sanden, James E Keenan, James Raspass, jkahrman, Joe McMahon, Johan Vromans, Jonathan Stowe, Jon Gentle, Karen Etheridge, Karl Williamson, Kenichi Ishigaki, Kenneth Ölwing, Kurt Fitzner, Leon Timmermans, Li Linjie, Loren Merritt, Lukas Mai, Marcel Telka, Mark Jason Dominus, Mark Shelor, Matthew Horsfall, Matthew O. Persico, Mattia Barbon, Max Maischein, Mohammad S Anwar, Nathan Mills, Neil Bowers, Nicholas Clark, Nicolas Mendoza, Nicolas R, Paul Evans, Paul Marquess, Peter John Acklam, Peter Levine, Philippe Bruhat (BooK), Reini Urban, Renee Baecker, Ricardo Signes, Richard Leach, Russ Allbery, Scott Baker, Sevan Janiyan, Sidney Markowitz, Sisyphus, Steve Hay, TAKAI Kousuke, Todd Rinaldo, Tomasz Konojacki, Tom Stellard, Tony Cook, Tsuyoshi Watanabe, Unicode Consortium, vsfos, Yves Orton, Zakariyya Mughal, Zefram, 小鸡.
That seems risky.