I received a response stating something similar on the git repo. It is still incorrect to blame the controller, and I suggested instead to provide some compatible drive models to use instead like they already do in the more generic sections of the article. It should even be possible to to use the Mac drives with the Greaseweazle with an adapter because the 800k drives from the Apple computers are just Sony drives with an optional eject motor installed.
Unlike the Apple II they do not have a custom Apple PCB. It's possible Apple requested some tweaks when ordering from Sony but I don't think they are all that special. So it should be entirely possible to read the disks with other drives. Based on the information in the page you linked stating any 720k drive is compatible, I suspect the higher read rate may be a vestigial feature that Sony over spec'ed during the introduction and standardization of the 3.5in disk.
I do a lot of floppy imaging and some of my work on it has previously be discussed here[1]. I do not understand where they got the idea of "there are a number of disks that the Greaseweazle struggles to capture, namely the Apple formatted disks. If you have these disks in your collection, you may need to use an Applesauce controller."
The Applesauce is a macOS exclusive tool that has a contingent of dedicated users. While I have not imaged a wide sample set of Apple II and 800k Mac disks specifically, from my current experience the Greaseweazle is plenty capable of reading them. I would speculate the author was trying to use an included diskdef(a flux to binary decoding definition) for an incompatible disk. The Zone Bit Recording[2] Apple drives use is irrelevant when you increase the sample rate of the controller to accomplish the same thing. Similarly C64 disk drives are also ZBR but change the clock rate instead of media speed. So do not think that this means you need multiple drives and controllers when getting into floppy imaging, you can use standard PC drives with a Greaseweazle to read and write Apple II and Mac disks as well as almost anything else.
I have opened an issue on their github page for this site to seek clarification on this.
This section is disregarding a key lore element, the inhabitants of the grid are programs. Killing a process in this context more likely has an interpretation of an attempt to stop an individual such as the villain Clu. I would say an alternative explanation is is more story based, with Kevin Flynn trying to stop Clu from the outside world but being unable to and instead taking the last resort of entering the grid when he knows it would be dangerous.
> can't afford to pay one for whatever business I have
At small scales what "art" does your business need? If you can't afford to hire an artist (which is completely fine, I couldn't for my business!) do you really need the art or are you trying to make your "brand" look more polished than it actually is? Leverage your small scale while you can because there isn't as much of an expectation for polish.
And no, a band poster doesn't have to be a labor of love. But it also doesn't have to be some big showy art either. If I saw a small band with a clearly AI generated poster it would make me question the sources for their music as well.
I've been editing on linux with resolve since the launch of the BMPCC4K in 2018, were you trying to import MP4 footage? BMD can't be bothered to pay for the AAC audio codec for linux users even if they buy studio. So if you pay for studio you can read the h264 video stream but not the AAC audio. I end up converting everything to MOVs with pcm_le16 audio as a workaround.
The ALSA issues are beyond aggravating at this point. You do not want to actually run ALSA directly, you need it to connect to pulseaudio on 24.04. But I still have never been able to record audio within resolve. I've had mixed luck on newer wayland+pipewire setups with having to install the bridge packages to connect the different backends. Linux audio is cursed on its own so I don't fully blame BMD.
I exclusively run Kubuntu and have been using makeresolvedeb[1] for installing resolve and it has been pretty good.
> Some games are designed around content and "extraction". Many are not.
While I think the parent post leaves a lot of open ended questions, I think they are spot on about the tightness of design in games.
In many open world RPGs, or something like GTA, you cannot open every door in a city.
In street fighter you can't take a break to talk to your opponent.
In art games like Journey you cannot deviate from the path.
Games are a limited form of entertainment due to technical and resource restrictions, and they always will be. Even something as open ended and basic as minecraft has to have limits to the design, you wouldn't want the player to be able to collect every blade of grass off of a block just because you could add that. You have to find the balance between engaging elements and world building.
Having a LLM backed farmer in an RPG that could go into detail on how their crops didn't grow as well last season because it didn't rain as much seems good on paper for world building. But it is just going to devalue the human curated content around it as the player has to find what does and does not advance their goals in the limited time they have to play. And if you have some reward for talking to random NPCs players will just spam the next button until it's over to optimize their fun. All games have to hold back from adding more so that the important parts stand out.
This is the eternal struggle of trying to write about something like this on the modern internet. The video is the flashy thing that gets attention (and revenue which allows me to do this as my job) but the written part is just talking into a void and hoping someone notices. I agree this type of information is best presented in text which is why I made an effort to produce a written component as well. But there's no way that article would have ended up linked somewhere like here.
> Using terminfo or ncurses requires an extra dependency with a clunky interface.
Are there any linux distros for any platform that aren't shipping terminfo? I could see some embedded systems cutting it down for small storage solutions. But I don't think it's unfair to assume that terminfo is installed. ncurses is more complex so I won't disagree with that one, but tput isn't part of ncurses.
Clunkiness is an opinion, I see needing to look up what "\x1b[7m" means as being clunky compared to "tput rev".
> Using tput requires spawning a process, which gets slow if you have to do it repeatedly.
If you're pretty printing text for a human to read then I don't think the couple extra ms it will take to spawn a handful of tput processes is going to be an actual performance concern. If you're logging data that's another thing, but this was specifically about CLI programs.
> can be done in any language, and is going to work for at least 99.9% of the users out there.
> I haven't found a solution, other than hard-coding the ANSI escape code set, that I'm happy with.
This is most likely true and I don't disagree that my stated use case is in the 0.01%. I was going to refute the any language comment with libraries based on terminfo, but all the ones I ran across in 30 seconds just hard code the ANSI escape sequences. Since it will likely work 99.9% of the time, it is "easy" in a way to hard code them. So I understand why it is being done that way and why you would also prefer to hard code them. But there is a standard interface to use, it just may not be perfect.
This may be something where we are technically stuck between a rock and a hard place. We have a good resource database of technical information on how to format text. But there isn't a significant reason to put in the effort to use it.
Having been recently delving into getting a TRS-80 DT-1 emulating a Televideo 910 working with Linux, I couldn't agree more.
Even now for modern devices it wouldn't be the worst idea to avoid hard coding things like color (e-ink?). And it's not like it's difficult to avoid hard coding, using tput ( https://linux.die.net/man/1/tput ) means you don't have to write out the arbitrary escape sequences yourself while being compatible with any terminal.
"My team writes a lot of command line tools" is a valid excuse for internal use. But not for writing a educational post.
Unlike the Apple II they do not have a custom Apple PCB. It's possible Apple requested some tweaks when ordering from Sony but I don't think they are all that special. So it should be entirely possible to read the disks with other drives. Based on the information in the page you linked stating any 720k drive is compatible, I suspect the higher read rate may be a vestigial feature that Sony over spec'ed during the introduction and standardization of the 3.5in disk.