I chuckled.
Have Logger with StdoutLogger as basic example of it
Then FileLogger that extends it with few functions related to files
Then DBLogger with few functions related to logging to database
Then TestLogger for integrating with test framework
> stty -icanon && cat mario.nes - | nc play-nes.org 4444
stty makes the keyboard work, and "-" is needed after .nes.
< mario.nes nc play-nes.org 4444The actual command is "cat mario.nes - | nc ...”
The trailing dash allows you to actually control the game after the rom has been loaded.
The Wikipedia article even concedes that cat might be better:
> A cat written with UUOC might still be preferred for readability reasons, as reading a piped stream left-to-right might be easier to conceptualize.[10] Also, one wrong use of the redirection symbol ">" instead of "<" (often adjacent on keyboards) may permanently delete the content of a file, in other words clobbering, and one way to avoid this is to use cat with pipes.
I‘ll happily continue to “abuse cat” going forward and sleep perfectly well.
"oh but you can save one character" (one coz <> requires shift) yeah fuck that, if I was bothered with it I'd alias cat to c
> When I offer a pipeline as a solution I expect it to be reusable. It is quite likely that a pipeline would be added at the end of or spliced into another pipeline. In that case having a file argument to grep screws up reusability, and quite possibly do so silently without an error message if the file argument exists. I. e. `grep foo xyz | grep bar xyz | wc` will give you how many lines in xyz contain bar while you are expecting the number of lines that contain both foo and bar. Having to change arguments to a command in a pipeline before using it is prone to errors. Add to it the possibility of silent failures and it becomes a particularly insidious practice.
See Jonathan Leffler's comment on SO (also demonstrated by the the top-level parent comment here):
> As noted in the answer by kojiro, it is perfectly possible and legal to start the pipeline with `< file command1 ...`. Although the conventional position for the I/O redirection operators is after the command name and its arguments, that is only the convention and not a mandatory placement. The `<` does have to precede the file name. So, there's a close to perfect symmetry between `>output` and `<input` redirections: `<input command1 -opt 1 | command2 -o | command3 >output`.
- Someone who knows the trick
OP, I appreciated that bit
"Let me give a half effort on X product. Oh, see, nobody likes it. Well, guess I'll go ahead and shutter it."
It's a shame that products with so much potential have all the resources put into them wasted with their behavior.
Like most large organisation they tend to approximate a small government and they're inherently incapable of using their resources efficiently. Every once and then they will acquire a start-up that works to give new blood to the behemot.
Definitely this. The service itself was great, was ahead of the competition gameplay-wise. Google just did what Google does.
Stuff like GEForce Now is already great for that "core" gamer market that wants to be able to use their existing steam library but play them on their phone on the go or whatever, but that's a pretty small market because most "core" gamers would never use a streaming service as their primary system so the market is fairly small (latency, resolution, quality etc is poor compared to native).
But nobody has properly targeted that more general "I want to play games with zero up front effort or knowledge" case yet. And I suspect that's a pretty big market.
It's great to see somebody picking up the idea again and extending it.
It's a cool idea. Lots of possibilities for fun RPC projects with distributed processing.
Remotely accessible 80-column cards and custom mappers FTW, eh?
Good reminder that projects are meant to be implemented.
(Yes, this isn't entirely serious, but people could and did make use of it)
https://www.arewesixelyet.com/#gnome-terminal
Looks like if you build the latest libvte from master and make sure to explicitly enable sixel support via the appropriate build time flag, you can then build GNOME Terminal against that and you'll have sixel support:
It has coincided with the creation of a lot of new terminal emulators (some of the youngest have the most support for sixel and similar features), and with the trend of using GPU acceleration in terminal emulators.
I couldn't exactly say 'why now', but one guess is that macOS' explosion in popularity among developers and the relatively high popularity of desktop Linux within the developer community in particular have produced a generation of developers who appreciate the power and flexibility of the Unix command line but have also grown up with rich graphics on their computers from the start.
There's clearly a strong contemporary desire for a more IDE-like terminal experience, and for graphically enriched tools that are still decidedly text-centric. Efforts to establish new standards and protocols for this have mostly withered or seen little uptake, so resurrecting support for (today) rarely-used features of old physical terminals has emerged as a viable approach for adding graphics to our CLI environments.
Maybe some day we'll escape from the 80s, but for now it seems that we are still returning to them to find 'new' material, for various practical reasons.
It's not ideal unless you use a very small font, but it's better than nothing.
BTW some people recompile libvte to get proper sixel support in their favorite terminal: https://github.com/mate-desktop/mate-terminal/issues/410 and then get results like: https://www.youtube.com/watch?v=mLQbAYJGZMA
However, while i got the game to render, I couldn't get the game to respond to controls after that, so YMMV
Given you have a NES ROM named “mario.nes” in your current folder, you will play that ROM by executing the full command.
It literally reads the ROM file, what cat normally does.