Yeah, that localization was one of the reasons that was so well loved. The PSP redid all that and while still enjoyable, it wasn’t quite as compelling as the WD effort.

As I said, I’ve dealt with logging where the variable length text was kept as plain text, with external metadata/index as binary. You have best of both worlds here. Plus it’s easier to have very predictable entry alignment, as the messy variable data is kept outside the binary file, and the binary file can have more fixed record sizes. You may have some duplicate data (e.g. the text file has a text version of a timestamp duplicated with the metadata binary timestamp), but overall not too bad.

I still have weird glitches where applications don’t seem to update on screen (chrome and firefox, both natively doing wayland).

Lack of any solution for programmatic geometry interaction. This one has been afflicted with ‘perfect is enemy of good’, as the X way of allowing manual coordinates be specified is seen as potentially too limiting (reconciling geometry with scaling, non-traditional displays), so they do nothing instead of proposing an alternative.

The different security choices also curtail functionality. Great, better security for input, uh oh, less flexibility in input solutions. The ‘share your screen’ was a mess for a long time (and might be for some others still). Good the share your screen has a better security model, but frustrating when it happened.

Inconsistent experience between Wayland implementations. Since Wayland is a reference rather than a singular server, Plasma, Gnome, and others can act a little different. Like one supporting server side decorations and another being so philosophically opposed to the concept that they refuse to cater to it. While a compositing window manager effectively owned much of the hard work even in X, the X behavior between compositors were fairly consistent.

I’ve been using Plasma as a Wayland compositor after many failed attempts, and it still has papercuts.

Thing is that they could have preserved the textual nature and had some sort of external metadata to facilitate the ‘fanciness’. I have worked in other logging systems that did that, with the ability to consume the plaintext logs in an ‘old fashioned’ way but a utility being able to do all the nice filtering, search, and special event marking that journalctl provides without compromising the existence of the plain text.

Uh… Sounds like it’s not really system’s fault, your setup is just terrible.

I don’t know his specific issue, but the general behavior of systemd going completely nuts when something is a bit ‘off’ in some fashion that is supremely confusing. Sure, there’s a ‘mistake’, but good luck figuring out what that mistake is. It’s just systemd code tends to be awfully picky in obscure ways.

Then when someone comes along with a change to tolerate or at least provide a more informative error when some “mistake” has been made is frequently met with “no, there’s no sane world where a user should be in that position, so we aren’t going to help them out of that” or “that application does not comply with standard X”, where X is some standard the application developer would have no reason to know exists, and is just something the systemd guys latched onto.

See the magical privilege escalation where a user beginning with a number got auto-privileges, and Pottering fought fixing it because “usernames should never begin with a number anyway”.

Babbage’s

I think turn based is fine and in fact I like. However, when no one has a turn it’s annoying to sit around while nothing happens as the timer keeps ticking. Also, to make it “active”, the turn timer doesn’t stop when you hit the menu. If you delay your action the enemy may get to take their turn, just because you neglected to navigate the menu. I think ATB is actually the worst of both worlds, would prefer either turn based or action RPG rather than being forced to navigate a menu in some facsimile of ‘real time’.

Where FF7 kind of went south from a gameplay perspective compared to 6 was that in 6, summons were a brief flash. In FF7, by contrast, for example Knights of the round would “treat” you to an 80 second spectacle, which was cool the first couple of times, but then just a tedious waste of time. Generally rinse and repeat this for any action that was pretty quick in FF6 and before but a slow spectacle in FF7, with no real option to speed up those animations you had already seen a dozen times that wore out their welcome long ago. Just like that stupid chest opening in OOT.

Anyway, I did enjoy FF7, but the “game” half was kind of iffy.

Thing is those criticisms also mostly apply to FF7.

Disconnect between combat and exploration? I see that for Zelda, but ff7 goes harder, with a random encounter jolting you into a different game engine for combat.

To much time in combat waiting while nothing happens? FF7 battle system is mostly waiting for turns to come to with lots of dead time.

Exploration largely locked to narrative allowing it? Yeah, FF7 had that too, with rare optional destinations a very prescribed order and forced stops. It opens up late in the game.

The video generally laments that OOT was more a playable story than an organic gameplay experience, and FF7 can be characterized the same way. Which can be enjoyable, but it can be a bit annoying when the game half of things is awkward and bogs things down a bit. Particularly if you are getting subjected to repeated “spectacle” (the slow opening of chests in oot, the battle swirl, camera swoops, and oh man the summons in ff7…)

They both hit some rough growing pains in the industry. OOT went all in on 3D before designers really got a good idea on how to manage that. FF7 had so much opportunity for spectacle open up that they sometimes let that get in the way. Also the generally untextured characters with three design variations that are vastly different (field, battle, and pre rendered) as that team try to find their footing with visual design in a 3d market.

Agreed, as a game, as in fun, ff7 wasn’t very good. That music, those visual designs (the pre rendered stuff), and the story (though it suffered from bad localization) were compelling. But random encounters, fights filled with mostly waiting to be able to do things, the best attacks doing too much spectacle which was nice the first time, but pretty boring on repetition… The materia management became frustrating as you got more party members and no way to arrange or search, even with in game dialog mentioning how it was a pain…

Chrono Cross actually had significantly better game design, with enemies on screen and no standing around waiting for some characters turn to come up before anything would happen. Wish ff7 had clipped the “no action allowed by either side” time and that would have helped immensely. Then it just becomes a matter of if the player prefers real time adventure to menu driven play.

While I’m not particularly invested in their choice, I will say that I’ve got some counters to the points given as to why not:

• Logging for diagnostics: probably the closest point, but you can either centralize such logs where local disk does not matter, or leave log in ram with aggressive rotation out.
• Ability to update without rebooting. The diskless systems I work with can be updated live too. However live updates do eat more memory in my case due to reasons that will be clear soon. Besides, a rolling reboot should be fairly non disruptive to “bake” the live updates into the efficient form. Other Diskless situations just live in tmpfs, in which case live updates are no problem at all, though it is a lot of ram to do this.
• Diskless uses too much RAM: At least with the setups I work with, the Diskless ram usage is small, as the root filesystem is downloaded on demand with a write overlay in zram to compress all writes. Effectively like a livecd generally boots, but replace cd with a network filesystem.

Nothing much, just getting far fewer client emails for some reason…

Well, we got to see roughly something play out with the xz thing. In which case only redhat were going to be impacted because they were the only ones to patch ssh that way.

Most examples I can think of only end of affecting one slice or another of the Linux ecosystem. So a Linux based heterogenous market would likely be more diverse than this.

Of course, this was a relative nothing burger for companies that used windows but not crowdstrike. Including my own company. Well except a whole lot fewer emails from clients today compared to typical Fridays…

I’ve not used crowdstrike, but looks like a part of the pitch is “cloud managed”, which often implies that the vendor takes care of everything, including updates. Particularly since they market it as a security solution, they weld likely emphasize that they can update rapidly enough to keep up with security attacks that move very quickly because they don’t care about “risk”.

Related, I predict Windows on ARM will be a massive failure, again.

Windows is Windows because a critical mass of their market is terrified of being vaguely incompatible with any software they use today. Wine will never give them enough confidence just like ARM emulation of x86 will never give them confidence.

Extra bizarre, from what I’ve seen the Windows devices vendors are treating the ARM variants as a premium model and charging more for them, despite having no real compelling story for the customers. You can either have an x86 offering that’s from all appearances just as overall capable and absolutely able to run your software today, on an ARM offering that is more expensive and maybe a bit less compatible, with maybe better battery life (either sincerely or at least a belief).

Mac is able to force the issue because the hardware and software all wanted to make ARM happen and forced it, but with Windows on ARM, only Qualcomm really cares, Microsoft and all the device vendors would prefer to hedge their bets, which in this case tie goes to the incumbent.

Define “the OS package manager”. If the distro comes with flatpack and dnf equally, and both are invoked by the generic “get updates” tooling, then both could count as “the” update manager. They both check all apps for updates.

Odd to advocate for docker containers, they always have the app provider also on the hook for all dependencies because they always are inherently bundled. If a library has a critical bug fix, then your docker like containers will be stuck without the fix until the app provider gets around to fixing it, and app providers are highly unreliable on docker hub. Besides, update discipline among docker/podman users is generally atrocious, and given the relatively tedious nature of following updates with that ecosystem, I am not surprised. Even best case, docker style uses more disk space and more memory than any other option, apart from VM.

With respect to never having to worry about bundled dependencies with rpm/deb, third party packages bundle or statically link all the time. If they don’t, then they sometimes overwrite the OS provided dependency with an incompatible one that breaks OS packages, if the dependency is obscure enough for them not to notice other usage.

Depends on if you stick to distro provided dependencies, then you are generally good, unless a third party repo decided to supersede that dependency.

I have spent a long time carefully packaging as a third party repository and it’s generally doable. Just sometimes another repository isn’t as careful and blows away the distribution provided libraries.

You don’t need the distro to package your sodtware through their package management systems though. Apt and dnf repositories are extensible, anyone can publish. If you go to copr or ppa you can have a little extra help too, without distro maintainers.

The headache comes up when multiple third party repositories start conflicting with each other when you add enough of them, despite they’re best efforts. This scenario starts needing flatpack, which can, for example concurrently provide multiple distinct library versions installed that traditionally would conflict with each other. This doesn’t mean application has to bundle the dependency, that dependency can still be external to the package and independently updated, it just means conflicts can be gracefully handled.

Flatpack can be centrally managed, it’s just like a parallel distribution scheme, where apps have dependencies and are centrally updated. If a flatpack is made reasonably, then it gets library updates independent of the app developer doing it.

“App image” and " install from tarball" violate those principles, but not snap or flatpack.

And at least in some distributions, they do exactly that, a number of aliases for the same interface. And you can add your own.

Per https://www.gnu.org/software/tar/, it’s been the case since 2004, so for about 19 and a half years…