People are hating on Powershell way too much. I don’t like its syntax really but it has a messy better approach to handling data in the terminal. We have nu and elvish nowadays but MS was really early with the concept and I think they learned from the shortcomings of POSIX compatible shells.

Also DXVK, though the period of time where DXVK existed and Proton didn’t is rather short (a little bit more than half a year).

I haven’t watched the video, but maybe it wasn’t in bad faith, but the author didn’t know better. bash can be arcane at times, like when I open my old scripts I often have no clue what exactly is going on without comments. Substring removal comes to mind.

I’m not even sure what strucrued data would really mean, so I’m pretty sure it’s not useful to my usecase lol

Probably not, but to give an easy example:

~> ls | where modified >= (date now) - 30day
╭───┬───────────┬──────┬────────┬────────────╮
│ # │   name    │ type │  size  │  modified  │
├───┼───────────┼──────┼────────┼────────────┤
│ 0 │ Downloads │ dir  │ 4,0 kB │ 4 days ago │
│ 1 │ Musik     │ dir  │ 4,0 kB │ a week ago │
╰───┴───────────┴──────┴────────┴────────────╯

Here, ls doesn’t just return a string representing directory content as text, but a table where each file is an entry with attributes that have their own data type (e.g. size is Filesize while modified is Datetime). That’s why I’m able to filter based on one of them; that part isn’t part of ls, but of the shell itself. In a classic shell, this filtering would need to be handled in the originating binary in its own specific way, or you’d need to parse its output, transform it using tools like sed and awk etc. This here is a special case because ls is built into the shell; for non-builtin commands, if they offer it, you can have them output structured data as json or something else and read it into nu, like

~> ip -j a | from json | where {|device| $device.address? != null and $device.addr_info? != [] and $device.link_type =~ "ether"} | get addr_info.0 | select -o local broadcast scope
╭───┬────────────────────────────────────────┬─────────────────┬────────╮
│ # │                 local                  │    broadcast    │ scope  │
├───┼────────────────────────────────────────┼─────────────────┼────────┤
│ 0 │ 192.168.178.72                         │ 192.168.178.255 │ global │
│ 1 │ 2001:9e8:4727:2c00:3071:91ff:fed1:9e26 │                 │ global │
│ 2 │ fdaa:66e:6af0:0:3071:91ff:fed1:9e26    │                 │ global │
│ 3 │ fe80::3071:91ff:fed1:9e26              │                 │ link   │
╰───┴────────────────────────────────────────┴─────────────────┴────────╯

It’s kind of cool, but I don’t need it that often either, so I just play around with it when I feel like it.

I’m glad you mentioned nushell (it sounds like) is a more poweruser thing.

It serves a different niche. nushell is very good for working with structured data. fish on the other hand is a “conventional” shell that’s not POSIX compliant. I guess that’s why they call it “a command line shell for the 90s” because it doesn’t incorporate modern concepts, it’s just more convenient than POSIX shells.

This results in some notable differences: nushell for example has actual data types (https://www.nushell.sh/book/types_of_data.html, though they are dynamically typed by default).

All this doesn’t mean that one is better than the other. I use fish daily and just sometimes dabble in nushell because most of my workflow doesn’t require all the stuff nu offers.

Oh yeah, I never used Python myself and did some very simple (but IMHO too much hassle in bash) Go stuff some time ago. It’s a really good language for that, and if you can’t build on the target, the binary is statically linked anyways.

What’s so bad about string replace World Bash $STRING?

Just don’t microwave it.

Same, but I don’t think it was ever intended differently; I mean the word interactive is literally in the name. If you want portable scripts, use bash. For simple helpers, quickly define a function. If you feel your script becomes too long, use Python.

None of this stuff for me. I prefer one tool doing one thing, like busybox

Oregon Trail?

I see, thanks

For instance, I recently discovered the structuredExtraConfig option for patching the kernel straight up does not work. This means you cannot unset any kernel options

From reading, I thought this option was for adding options, not removing them. Sure, you might be able to set options to “no”, but I don’t think this will override the defaults…

While you might have a point somewhere, I’m not sure it applies in this particular case.

PulseAudio was or still is (I don’t know actually) developed, but you don’t just change a system’s architecture.

creating a new project is easy, and even getting that project into distros can be easier than evolving older projects.

I think this downplays the achievements of PipeWire. Not only is it, contrary to what you write after, backwards-compatible; but if such a project was easy, why aren’t more people / companies doing it?

In my opinion, PipeWire turned Linux systems from being last in multimedia to maybe first place even. Remember capturing the screen or a window before? In fact PipeWire was only extended to audio because the design proved itself so well, so it actually did evolve. Just not from audio to better audio, but from video to video and audio. Saying that starting such a project [edit: is easy] might be technically correct, but then doesn’t make any point.

PipeWire doesn’t need replacement, which can’t be said for its predecessors. PulseAudio, OSS and raw ALSA had their shortcomings. PipeWire blows Windows audio out of the water in my opinion

What do you mean by that? I’m using TigerVNC with wayvnc on sway

From bash even, I generally think porting somewhat complex tools away from bash is a good choice

Not sure how you can read my comment that way, but you do you.

The discussion was implicitly around the changes brought by Vulkan and DXVK which enabled playing Windows Direct3D (this part is important) 11 and later 9 games without performance penalty. You could previously play Windows Direct3D 9 titles using Gallium Nine if you had an AMD card, though this was a bit iffy.

WoW mostly.

That’s OpenGL, so not affected.

Some StarCraft.

Not 3D even.

Minecraft.

Neither Windows nor Direct3D, but Java with OpenGL.

True, if all the games you played were OpenGL-accelerated, these changes didn’t matter. But about 95% of games on the market weren’t.

The thing is, back then, for the stuff to work on Debian, you needed to

• compile your own newer kernel
• compile the new mesa that depended on that kernel

and with how frequent updates were, this was something you’d probably do multiple times per month – at this point, why bother with Debian when you need to compile all the packages yourself? Remember that was a gaming machine… so why bother with Debian and spend hours each month when with Arch, it was just a pacman -Syu followed by a reboot and you could try out all that fancy new stuff?