I'm curious how you came to the conclusion that naming it 'screen' was the best thing for your project?
It's unusual to see so many negative comments on a new project announcement and yet you persist and even double down with a sarcastic "thanks for your feedback" reply.
I named it screen because the main class is called screen. It was extracted from another library to make maintenance easier. It's not a tool that can ever be used outside of a PHP project, and it has no binary. It's namespaced under SoloTerm.
A nice analogy would be a package named @clerk/auth and then everyone complaining about the package being named auth. I mean it is... but that's not really the full name or how anyone would refer to it.
Most commenters didn't understand any of that nuance and got hung up on a surface level thing that didn't really matter. It was clear to me that the suggestion didn't apply in this case so I thanked them for the feedback. I don't have to take the feedback!
Several other folks commented that it's not really an emulator but rather a renderer. I thought that was a pretty good point and something I was wrong about. So I changed the readme! I thanked them for their feedback as well.
It's no secret that HN commenters lean cynical and can miss the majors for the minors. I just don't want to fight with them! I'm grateful for feedback. Some of it I take and some I completely ignore. As everyone should!
> Most commenters didn't understand any of that nuance and got hung up on a surface level thing that didn't really matter. It was clear to me that the suggestion didn't apply in this case so I thanked them for the feedback.
It's more nuanced than just that.
From your README:
> Solo provides a TUI (Text User Interface) that runs multiple processes simultaneously in separate panels, similar to tmux.
You already provide a tool similar to screen. You even call out one of its alternatives! This will lead to confusion.
Further, from another of your comments [0]:
> I use GNU Screen in Solo, where I also use Solo Screen, so I am aware of it.
combined with
> It was extracted from another library to make maintenance easier.
Looking at the code, Solo is the library you extracted it from. You built a technology on top of an existing, well-known project. Then, you extracted some of your code from it and reused the project's name that your tool leverages in that related library.
This is the first way in which your analogy is not sufficient to support your position.
The second is there is no common, well-known, age-old utility called auth in the auth space for people to co-opt.
To quote duskwuff [1] again [2]:
> They're both pieces of software which implement or interact with terminal emulators; I think some deconfliction is warranted here.
Given the context, I don't think namespacing it is a sufficient approach to reducing ambiguity. Especially since screen is often referred to without GNU.
As for this reason:
> I named it screen because the main class is called screen.
Saying you named it screen because the main class was called that isn’t really a justification - especially when you named the class in the first place.
The willful reuse of the utility's name that powers your code and pithy gratitudes all over this thread, to me, send a message of disrespect for the community at large.
script kiddies are now going to have high-fidelity shells with 256 colors for when they pwn you and get root on your godaddy drupal install
sidenote: screen is a terrible name for this as there is already gnu/screen (colloquially referred to as screen) which has 38 years head start - https://en.wikipedia.org/wiki/GNU_Screen
I'm a little confused--is it an interactive terminal? Or is it more like an ANSI renderer where you are producing a single static image of the final result of printing a series of bytes? I don't see any JavaScript to hint at interactivity.
Lol, what? Haven't heard of this...
What's your experience with nativePHP?
While i am a defender of modern (!) php for web applications, this does sound rather weird. But also interesting. Thanks for the link.
I wonder though how "native" this is? Glancing over the docs it seems to be built upon tauri / electron? Not as native as i expected, but probably more native than most people would dare to think about...
I am aware modern PHP is actually pretty good, but having grown up with PHP in the 2000s I can't help but get chills up my spine every time I read '$nonWebThing written in PHP'
Didn't we have this back in 2001. I seems to remember that we kicked a guy of our project because he installed one of the PHP consoles on our Solaris box, which basically gave it the same rights as the Apache user.
11 at the time here. For me it would be another 10 years or so before I saw a Solaris box or even knew what one was.
I did encounter, and try, Linux much sooner. But didn’t really “get it” either at the time. Like, I understood that it was neat and different. I installed Mandriva Linux on my machine when I was 13 or 14 or so, but I was lacking any books or guidance to understand how to do anything aside from opening the GUI programs that was on it.
It would take all until the age of 18, when I started at the university, before I got the help I needed in order to understand Linux and editing config files on Linux and writing my own scripts and programs on Linux.
To be fair in 2001 php was the underdog of tech stack. It has just got ride of the PHP (Personal Home Page) taste in the language mouth. So wouldn't be surprised if some company running solaris would kick him off.
Interesting. I remember php being on top at that time, with JSP just starting to take over. I was in a rural area, though, and our local developers were far more influential than any internet community during that period.
It's still a mainstay of certain malware for sure. Just pop in 'php shell' to your favorite search engine, and it's basically all stuff for either red teaming or shenanigans
I started a very similar project probably ten years ago and just never got it to a very usable state. My idea at the time was based in wanting to be able to write tests for the final output of scripts full of control codes.
I am very excited to see this and to play with it!
Check out the ComparesVisually trait! (It's described in the readme too)
It takes some text, outputs it to iTerm and takes a screenshot. Then it takes the same output, runs it through the Screen class, outputs it, and takes a screenshot. Then we compare the screenshots pixel by pixel. So freakin fun
Readit News
It's unusual to see so many negative comments on a new project announcement and yet you persist and even double down with a sarcastic "thanks for your feedback" reply.
I named it screen because the main class is called screen. It was extracted from another library to make maintenance easier. It's not a tool that can ever be used outside of a PHP project, and it has no binary. It's namespaced under SoloTerm.
A nice analogy would be a package named @clerk/auth and then everyone complaining about the package being named auth. I mean it is... but that's not really the full name or how anyone would refer to it.
Most commenters didn't understand any of that nuance and got hung up on a surface level thing that didn't really matter. It was clear to me that the suggestion didn't apply in this case so I thanked them for the feedback. I don't have to take the feedback!
Several other folks commented that it's not really an emulator but rather a renderer. I thought that was a pretty good point and something I was wrong about. So I changed the readme! I thanked them for their feedback as well.
It's no secret that HN commenters lean cynical and can miss the majors for the minors. I just don't want to fight with them! I'm grateful for feedback. Some of it I take and some I completely ignore. As everyone should!
It's more nuanced than just that.
From your README:
> Solo provides a TUI (Text User Interface) that runs multiple processes simultaneously in separate panels, similar to tmux.
You already provide a tool similar to screen. You even call out one of its alternatives! This will lead to confusion.
Further, from another of your comments [0]:
> I use GNU Screen in Solo, where I also use Solo Screen, so I am aware of it.
combined with
> It was extracted from another library to make maintenance easier.
Looking at the code, Solo is the library you extracted it from. You built a technology on top of an existing, well-known project. Then, you extracted some of your code from it and reused the project's name that your tool leverages in that related library.
This is the first way in which your analogy is not sufficient to support your position.
The second is there is no common, well-known, age-old utility called auth in the auth space for people to co-opt.
To quote duskwuff [1] again [2]:
> They're both pieces of software which implement or interact with terminal emulators; I think some deconfliction is warranted here.
Given the context, I don't think namespacing it is a sufficient approach to reducing ambiguity. Especially since screen is often referred to without GNU.
As for this reason:
> I named it screen because the main class is called screen.
Saying you named it screen because the main class was called that isn’t really a justification - especially when you named the class in the first place.
The willful reuse of the utility's name that powers your code and pithy gratitudes all over this thread, to me, send a message of disrespect for the community at large.
[0]: https://news.ycombinator.com/item?id=43439646 [1]: https://news.ycombinator.com/item?id=43439429 [2]: https://news.ycombinator.com/item?id=43439748
Perhaps adding a screenshot or video to the README.md showing what it does could help people understand it better.
Gonna stick with the name screen though
Dead Comment
sidenote: screen is a terrible name for this as there is already gnu/screen (colloquially referred to as screen) which has 38 years head start - https://en.wikipedia.org/wiki/GNU_Screen
also til screen is older than me
Deleted Comment
While i am a defender of modern (!) php for web applications, this does sound rather weird. But also interesting. Thanks for the link.
I wonder though how "native" this is? Glancing over the docs it seems to be built upon tauri / electron? Not as native as i expected, but probably more native than most people would dare to think about...
[0]: https://gtk.php.net
I guess maybe if it was PHP8 only...
I did encounter, and try, Linux much sooner. But didn’t really “get it” either at the time. Like, I understood that it was neat and different. I installed Mandriva Linux on my machine when I was 13 or 14 or so, but I was lacking any books or guidance to understand how to do anything aside from opening the GUI programs that was on it.
It would take all until the age of 18, when I started at the university, before I got the help I needed in order to understand Linux and editing config files on Linux and writing my own scripts and programs on Linux.
I started a very similar project probably ten years ago and just never got it to a very usable state. My idea at the time was based in wanting to be able to write tests for the final output of scripts full of control codes.
I am very excited to see this and to play with it!
It takes some text, outputs it to iTerm and takes a screenshot. Then it takes the same output, runs it through the Screen class, outputs it, and takes a screenshot. Then we compare the screenshots pixel by pixel. So freakin fun