Quoting: Ehvis

Quoting: kokoko3k

Quoting: Liam DaweIt's a repeating problem. What's one of the main things people outside the Linux bubble are afraid of and turn their nose up at learning and using? The terminal. It's about knowing the audience in regards to the Steam Deck, it is *mostly* people coming from Windows and traditional consoles, and largely (in the nicest way) a large pool of tech illiterate people who prefer pressing buttons. You hook 'em in with an easy app, then you can start the terminal talk.

Yes, I understand that and I 100% agree!

Indeed, I was not objecting the use of warpinator per se (I've specified that I understand how it is useful for cross-platform use cases; using python in Windows is not a simple task at all), but the fact that you justified it through the statement: "The point is to avoid the terminal for simple guides.", that's all.

A simple guide should be useful for all people. Since most people have a system crash when they see a terminal pop up, it is not possible to make a guide for all people that has terminal usage in it. So I would have to agree with Liam, a simple guide must avoid the terminal. And "our" definition of "simple" is irrelevant there.

Well, I myself have an earth attack when I hear "flatpak".
I don't think I never used one, and if i did it, it means I deleted that experience from my memory, so when i read something like:
"Linux / Steam Deck: install Warpinator from Flathub. Available in the Discover software centre for plasma.", the bold text represents a black box/hole to me, because i don't know well what is flathub, and I'm even lucky because i use Plasma! But unfortunately, i've really never used Discover.

So, how much simple is that statement to understand to someone like me who doesn't know about those tools?

It is still NOT for everyone, and certainly not more than the other side of the story; not counting that i think that there are more Linux users who are familiar with the terminal than ones familiar with plasma,discover and flathub, but I might be wrong.

But as everyone can click on the icon of discover and write keys on his keyboard to search for the software, and then click to install the software, and then click to launch the software and then use the software, everyone can... well, click on a black icon and paste into a black window.

Objectively, what requires minor efforts to someone who have to understand from scratch:
* Understand how to copy/paste a string into a black window which opens after you clicked an icon named "terminal"
or
* follow the guide in the article?
Biased opinion here, but still I bet the former wins.

That's why, while I agree in that kind of tutorials for cross platform uses, I object the choice of "Avoiding" the terminal even for Linux only audience.

-EDIT-
(The article with the already included terminal command expresses certainly the best of both worlds, so I'm here writing just for the fun of it )

View this comment - View article - View full comments

Quoting: Liam DaweIt's a repeating problem. What's one of the main things people outside the Linux bubble are afraid of and turn their nose up at learning and using? The terminal. It's about knowing the audience in regards to the Steam Deck, it is *mostly* people coming from Windows and traditional consoles, and largely (in the nicest way) a large pool of tech illiterate people who prefer pressing buttons. You hook 'em in with an easy app, then you can start the terminal talk.

Yes, I understand that and I 100% agree!

Indeed, I was not objecting the use of warpinator per se (I've specified that I understand how it is useful for cross-platform use cases; using python in Windows is not a simple task at all), but the fact that you justified it through the statement: "The point is to avoid the terminal for simple guides.", that's all.

View this comment - View article - View full comments

Quoting: Liam Dawe

Quoting: g000h

Quoting: x_wingOr just run this in the folder with the data to upload:

 
python -m SimpleHTTPServer 5555

And open in the deck browser YOUR_HOST_IP:5555

or python -m http.server 5555 for when your system is defaulting to python3.

The point is to avoid the terminal for simple guides.

Edit: however, that's pretty cool! I'll add a note.

I can understand that warpinator is cross platform, but not the answer that the point is to avoid the terminal for simple guides.

Why?

Terminal can simplify complex and simple tasks, and this is an excellent example.
The sooner the people will understand that, the sooner we can progrsss instead of involve into dumbness (no offense).
I doubt there is something simpler or even easier than that command, really... software is already installed on both ends (literally, the challenging task here is to know an ip address and the location of a file) let alone install and use warpinator with all of the steps involved on both systems.

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: kokoko3kOne ring to rule them all

Quoting: PhiladelphusThis is probably a stupid question, but…why is there a split in the first place? Why can't consumer audio be low latency too? Or is this massive overkill like providing the average office worker with a monitor with a 500 Hz refresh rate?

You don't want nor need that, the monitor example is vaild if the compositor needs to render the same image 500 times per second.
Pro audio often needs extremely low latency (maybe even high bit depths and samplerates) that taxes the cpu, because to achieve it, you need to continuously load very small chunks of audio data to the audio card and that thread needs to run with realtime privileges or you'll end with what is called XRUN (empty buffer == audio glitches).

For example if you need to hear a sound sampled as soon as possible, say with a latency of 5ms, if i'm doing the math right, you need to load at most 1000ms/5ms = 200chunks of audio per second with a thread running at realtime priority.
So, if you don't want to use too much cpu just to play a wav file, maybe it is better to use latencies in the order of 20..40 msecs.

With pipewire, you can have the best of both worlds when you need one thing or the other.
As a side bonus, it provides interoperability between jack,alsa (usespace) and pulseaudio without the need to switch between them, nor to load them, because it implements all of them natively, and that will allow to do and play with ease with all the pro-audio apps/effects/equalizers available in the jack domain, much better than just pulse/easyeffects.

For once, there is work to reduce fragmentation done the right way, imho.
Granted, the software is still not perfect, but is under active development and devs are fast in fixing bugs, but they need users to report them ofc.

I mean latency is one of the reasons that the Atari ST is still considered excellent for MIDI production. Granted there are less people who utilize MIDI these days, but they are excellent machines!

I didn't know about Atari ST and latency and MIDI, probably it was just good marketing strategy (ST came with builtin MIDI ports, where amigas,much more capable, did not, also ST had cubase), but it is like comparing apples to oranges.
MIDI is a protocol to transfer commands, not audio data.
You dont send sounds over a midi cable, but you send something like "play a C note from the sound bank 5 at volume 70 with a little vibrato".
Even a c64 has low latency doing that, let alone Linux on a 2022 machine!
Jack,pulse or pipewire don't solve that problem, because there is no need to.
You can compare midi to a joypad controller; there is no latency in sending commands even on a consumer system.

As for sample playing, you're right, there are hardware differences between an atari st, an amiga, a sega megadrive and so on, and an ibm pc compatible system that make low latency complex on the latter; but even if the hardware were the same, the goals are still different, because the process of mixing different sources, applying countless audio effects and so on require to work on audio buffers, and would introduce latency even on an atari st.

View this comment - View article - View full comments

One ring to rule them all

Quoting: PhiladelphusThis is probably a stupid question, but…why is there a split in the first place? Why can't consumer audio be low latency too? Or is this massive overkill like providing the average office worker with a monitor with a 500 Hz refresh rate?

You don't want nor need that, the monitor example is vaild if the compositor needs to render the same image 500 times per second.
Pro audio often needs extremely low latency (maybe even high bit depths and samplerates) that taxes the cpu, because to achieve it, you need to continuously load very small chunks of audio data to the audio card and that thread needs to run with realtime privileges or you'll end with what is called XRUN (empty buffer == audio glitches).

For example if you need to hear a sound sampled as soon as possible, say with a latency of 5ms, if i'm doing the math right, you need to load at most 1000ms/5ms = 200chunks of audio per second with a thread running at realtime priority.
So, if you don't want to use too much cpu just to play a wav file, maybe it is better to use latencies in the order of 20..40 msecs.

With pipewire, you can have the best of both worlds when you need one thing or the other.
As a side bonus, it provides interoperability between jack,alsa (usespace) and pulseaudio without the need to switch between them, nor to load them, because it implements all of them natively, and that will allow to do and play with ease with all the pro-audio apps/effects/equalizers available in the jack domain, much better than just pulse/easyeffects.

For once, there is work to reduce fragmentation done the right way, imho.
Granted, the software is still not perfect, but is under active development and devs are fast in fixing bugs, but they need users to report them ofc.

View this comment - View article - View full comments

Beware Liam, that some Unity games use "/usr/bin/pulseaudio --check" to check for pulse support and that binary is not provided by pipewire.
Workaround is to use steam soldier runtimes or link /usr/bin/true to /usr/bin/pulseaudio or setting a different path for binaries... whatever you prefer.

View this comment - View article - View full comments

Let's hope Valve will actively help kde devs to fix plasma remaining bugs!

View this comment - View article - View full comments

If i've not missed it, what's the boot time from powered-off to the library?

View this comment - View article - View full comments

Civilizations games are time sucker and you have to play a lot to master them, so honestly, I can't imagine someone buying those bundles and then *really play* all the titles inside them.
Sure, I would really like to have the time to play bundles like this, but honestly, who the hell in the world has?

Also, a lot of times you see bundles made to sell quantity over quality and even if this isn't the case at all, I only see users buying quantity here; why? To increase their collection?

I guess you may be interested only in part of the bundle and still go to get everything because it is still a good deal, then you can just sell the "shrinkage" in a gray market (hoping to use the right noun).

View this comment - View article - View full comments

I wonder why supraland is marked as unsupported.
Last time i tried it worked fine in native mode and much better with proton; ati and nvidia.

View this comment - View article - View full comments