Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
nudgenudgetilt
Mar 18, 2003


BlankSystemDaemon posted:

so if you're on a train while using WWAN, basically

does that even matter any more? I was holding open an ssh tcp connection through the sf subway, transbay tube, and all that poo poo a decade ago with umts/hsdpa.

mosh was that thing everyone wanted to keep their eye on for a few years when it came out, because it solved a problem we had at the time, but we didn't consider mosh safe/stable enough to see widespread use. then connectivity got better and mosh was kinda pointless for the majority of the users who thought it was neat.

Adbot
ADBOT LOVES YOU

nudgenudgetilt
Mar 18, 2003


akadajet posted:

imagine buying an amd gpu. lol

got me one of them amd laptops so I can amd while I amd on my amd

nudgenudgetilt
Mar 18, 2003


Sapozhnik posted:

well, a lot of that stuff is thanks to the kernel's DMA-BUF infrastructure, which is a fairly recent thing, and nvidia proprietary driver support for it is even more recent.

I hope the dma-buf work helps unfuck the reverse prime situation on nvidia. god forbid I be able to use an external display at the same time as my laptop's built in display.

nudgenudgetilt
Mar 18, 2003


Tankakern posted:

hm what's not working?

my xps has a nvidia which is not connected to any outputs, but dri prime works fine (well, since i use prime sync or whatever they call it, i do have to reboot or restart x to boot it up, but oh well works for the three times a year i start up a game)

I have a asus g14 (amd/nvidia) and msi delta (amd/amd). on the g14 in hybrid mode, connecting an external display at any time causes x to crash (arch btw, etc). if I try kde wayland or force gnome into wayland it just doesn't see the external display connected. for better or worse, I now basically use this laptop as a desktop in nvidia-only mode -- which has its own quirts where the external display has to be disconnected until after login, at which point I can connect the external display and get completely trash opengl perf until I disable the internal lcd panel. it's all hilariously horrible, but I suspect it will suck less once gnome 42 is using gbm, and the new nvidia driver goes stable.

I contrast this with my delta where everything just works, x or wayland, I strongly suspect due to mature dma-buf (and gbm for that buttery smooth wayland)

nudgenudgetilt
Mar 18, 2003


previously read those links more times than I'd care to remember. mixed feelings about the whole asus-linux.org thing. they submit a lot of patches for asus-wmi that land in mainline pretty quickly, and you really only need asusctl if you're loving with fan curves now. the graphics switching functionality was extracted to supergfxctl, which i think he plans to make cross platform. you don't even need supergfx if you're not switching out of hybrid mode. again, contrasting with the msi, keys like mic mute are busted, and msi-wmi looks to be super neglected, so tradeoffs

nudgenudgetilt
Mar 18, 2003


pointsofdata posted:

it's pretty cool how you can use a good os instead and not worry about if your mic mute key will work or not

no, I can worry about what registry keys I need to tweak to get all the bullshit to go away instead

nudgenudgetilt
Mar 18, 2003


we had a physical card catalog in elementary school, but my first year of middle school shifted to something software based on the brand new windows 95 machines in the library

nudgenudgetilt
Mar 18, 2003



the panfrost project is just insane. it's largely the product of someone who got involved as a high school student

nudgenudgetilt
Mar 18, 2003


mycophobia posted:

if you use linux, you watch anime. simple as

lies. i am professing my hate for anime from the linux



arch, btw, etc

nudgenudgetilt
Mar 18, 2003


looking for a new internet janitor job, it seems like every gig out there wants kubernetes regardless of their environment or application

maybe this rant belongs in the security thread, but how the gently caress is it that k8s *still* has no baked in image verification mechanism in 20 loving 22?

for decades now, cryptographically signed sources/binaries have been the standard for distributing software, then dockerhub and gcr come along and everyone just says "yolo bitches, tls is all the integrity guarantee I need"

nudgenudgetilt
Mar 18, 2003


Sapozhnik posted:

i think you can stick @sha256:whatever on the end of an image tag?

not ideal admittedly but it's something

you *can* but nobody *does*

in the realm of things you *can* do are some pretty robust solutions like portieris, which will check dct and redhat simple signatures (among other things) as an image admission controller....

...but good luck finding signed images. gcr doesn't support dct at all, and dockerhub images are either totally unsigned, or rubber-stamp signed by dockerhub controlled keys

and that's all assuming you found a way to verify the etcd and apiserver and other kube infrastructure images when you deployed them

I get that this is :tinfoil: as gently caress, but it all feels like a major regression in supply chain security from having an os package keyring containing keys from your distro and the occasional 3rd party vendor.

nudgenudgetilt
Mar 18, 2003


sb hermit posted:

I get the impression that the sha256 digest is more for identifying an image, rather than for verification

this could just be something I dreamt up in a fit of docker hate, but I want to say at one time the docker image hash was only of image metadata, and not of the image contents itself

nudgenudgetilt
Mar 18, 2003


sadly I don't think it'll happen because there is no money to be made in locking down the supply chain

instead it seems like we're moving in the direction of subscription services that scan images for malware and subscription image blacklists

nudgenudgetilt
Mar 18, 2003


sb hermit posted:

From what I remember, the image metadata names the data layers via their sha256 hash. So it's a bit roundabout, but you can still establish a chain of image integrity.

I'm not a docker expert so maybe someone else can correct me on that.

yeah, I'm not 100% positive, but a quick googling leads me to think the image digest was added in v2 of the manifest, while v1's image id was a hash of just the manifest (with nothing in the manifest to verify the image itself)

https://docs.docker.com/registry/spec/deprecated-schema-v1/

this vaguely mentions v1 being insecure

nudgenudgetilt
Mar 18, 2003


Progressive JPEG posted:

from what I've seen of banks and stuff, they end up enforcing what's on the images by not allowing use of any outside images and building their own from scratch

that's been my general approach -- grab the cloud image rootfs tarball from canonical, use gpg/sha256 to verify it, then import into a scratch image. at one recent gig I put together tooling to recursively fetch and flatten dockerfiles, so they could be reviewed and locally versioned

unfortunately unless you're at an organization with a very strong security culture, doing the above will just get you labeled as a :tinfoil: nutjob

nudgenudgetilt
Mar 18, 2003


Antigravitas posted:

Web devs are basically reimplementing Windows, aren't they.

funny enough, windows largely solved this problem years ago with signed binaries

nudgenudgetilt
Mar 18, 2003


Sapozhnik posted:

i have been playing the new smash hit george ronald reagan martin video game elden ring on my linux system

it works pretty well on day one, and the anti cheat system has even been specially modified to work in a linux compatibility environment. of course valve probably leaned on bamco to make the anti-cheat work since valve have yet another stupid doomed linux gaming hardware thing coming out right now that they're going to abandon in six months just like all the others but hey i'll take it. apart from the anti-cheat stuff it's still pretty cool technological progress in vkd3d/proton/whatever.

that being said it is a bit stuttery in open world areas, but supposedly it's like that on windows too. whether it is worse under linux i do not know.

proton is loving amazing right up until the moment it isn't, and then it becomes absolutely rage inducing

take jurassic park tycoon 2 for instance. about half the game modes (the "campaign" mode, and a couple of the chaos theory modes) work perfectly, but the other half crash on load. getting a game to 50% completion after 40 hours of play, only to be blocked from any further progression is a helluva buzzkill

for better or worse, this only happens on my amd/nvidia system, so I guess I have the option of using my underpowered all-amd system to finish the game as a 640x480 slide show

nudgenudgetilt
Mar 18, 2003


Buck Turgidson posted:

i am also using proton to play elden ring, although I can't play online for some reason. otherwise works nicely. i also have fsr forced on which seems to give me a few more fps

how are you turning on fsr?

I've been eyeing gamescope, but haven't been motivated enough to try it out

nudgenudgetilt
Mar 18, 2003


Buck Turgidson posted:

proton lets you set launch options for each game. for the latest proton-ge build at least, you can add the following:

WINE_FULLSCREEN_FSR=1 %command%

word. I'd considered that as well, but having to install proton-ge from aur seemed like something worth giving a shot after trying gamescope from my distro repo

either way I have to gently caress around with game launch settings :effort:

nudgenudgetilt
Mar 18, 2003


I think there has been an experimental proton since shortly after it was released. I've never seen a point in not using it, since it's just a dropdrown in prefs, and seems to consistently work as well or better than "released" versions.

nudgenudgetilt
Mar 18, 2003


The_Franz posted:

the latest nvidia drivers are actually pretty good under wayland. the only real holdup with wayland at this point are applications that dragged their feet on support (mpv still has some bugs and java only recently started working on native wayland support so everything is still blurry with hidpi scaling)

which compositor are you using? I'm still having wayland troubles on my amd/nvidia/gnome system. running in nvidia-only mode with wayland and plugging/unplugging an external display intermittently crashs gnome-shell. running in hybrid mode with wayland, the external display isn't detected at all until I power up the nvidia card via prime-run, then does the same intermittent crashy poo poo as an nvidia-only config

for a long time the only way I could get an external display working on this thing was running nvidia-only mode with x11, but with nv 510 drivers, the external display finally started working in hybrid mode x11 (yey dma-buf). I have my fingers crossed that gnome 42 will clear up some of the wayland behavior

nudgenudgetilt
Mar 18, 2003


Progressive JPEG posted:


to be fair to synergy i imagine there's a bunch of issues with running something like it with wayland's process/security model, probably has to go into the wm or something

I think the security model problems are mostly solved by pipewire and xdg-desktop-portal, but it seems like maintainers of legacy tools are more interested in screaming about how wayland is destroying their world than contributing to or adopting new protocols

nudgenudgetilt
Mar 18, 2003


Tankakern posted:

(and you can use raid56 too, just research it and know about the caveats)

This. I have an array of 8x8tb spindles in a btrfs raid6, it's my primary media store, but honestly I just consider it a cache between usenet and kodi -- anything rare gets backed up elsewhere, but most of it can be obtained from usenet again in minutes. (really this makes me think I should drop it to raid5 now).

Over the course of two years, I've had to rebuild the filesystem once, because I was rebalancing from 6 disks to 8, and a curious cat disconnected the array's usb-c cable from the host, leaving the fs in a bad state. Otherwise it's been just peachy.

nudgenudgetilt
Mar 18, 2003


Farmer Crack-rear end posted:

assuming btrfs wasn't buggy, would there be particular benefits to using btrfs raid instead of mdraid?

in theory, btrfs can be smarter about writes by knowing the underlying array layout

in reality, you do it because you're bored, your data doesn't matter, and you hope to be able to catch a bug or two that might help it become production-worthy in the future.

nudgenudgetilt
Mar 18, 2003


my homie dhall posted:

zfs on Linux is embarrassingly slow and bad, donít use it

I love how every post or high level "how-to" about zfs on linux (or any os, really) related completely ignores how unsuitable a default config zfs is anywhere but on a file server. The typical new zfs user spends about 6 months before they go "where the gently caress did my ram go?" and learn about configuring arc.

nudgenudgetilt
Mar 18, 2003



is it safe to use xfs on a machine without a battery yet?

nudgenudgetilt
Mar 18, 2003


Cybernetic Vermin posted:

bit of a rollercoaster ride all of this

not sure I see the rollercoaster -- mentioned I'm using an experimental filesystem configuration for throwaway data (coincidentally, though not mentioned, on a ups), I further clarify that you should only run that configuration if you're fine with thowing your data away and are more concerned with exposing bugs.

nudgenudgetilt
Mar 18, 2003


murderfs was a must if you had a large maildir deployment

nudgenudgetilt
Mar 18, 2003


and god bless the free log management

spew to stdout/stderr and let the journal handle things

nudgenudgetilt
Mar 18, 2003


FlapYoJacks posted:

Ash supports tab completion. What shell are you using?

probably busybox


but if you're regularly doing cli janitor work on a system with only busybox, you done hosed up and landed yourself in one of three situations

1) you're working on an embedded device so incompetently designed by someone else that it doesn't expose sane configuration and debugging interfaces
2) you've designed an embedded device so incompetently that it doesn't expose sane configuration and debugging interfaces
3) you're working on an embedded device you don't actually understand how to configure or debug, so you figure you can use your server janitor skills to hack it into submission

if you're on a busybox system and find yourself running journalctl or kubectl, you're probably in situation three

nudgenudgetilt
Mar 18, 2003


the bluetooth situation isn't really linux specific -- it's an issue with the profiles supported by most devices. pipewire is a must regardless, but you still gotta find a device with the right profiles

msbc is the baseline profile that supports both sink and source but sounds like trash. it's pretty much the only profile you're guaranteed to find everywhere.

next up you have aptx (qualcomm), which doesn't sound terrible, but has no support for being an audio source, only a sink. the moment you try to use it as a source, the device will drop out of the profile to one that supports being a source.

past aptx, you have aptx-hd, which ups the quality of aptx, but behaves the same with regard to being sink only.

similar to aptx, is ldac (sony). ldac is arguably the best quality profile and in theory supports being used as either a sink or source, but I've never actually seen a device that supports being an ldac sink. (I've also only used cheapo ldac devices, and never a nice set of sonys).

finally, the only profile I've found that actually works on a real world device without going to poo poo is aptx-ll (low latency). it was apparently really short lived, and only a handful of devices seem to support it. of the tens of bluetooth headsets I've purchased trying to understand why in 202x I had to deal with trash audio calls, only the Avantree Aria Pro has been usable.

nudgenudgetilt
Mar 18, 2003


pseudorandom name posted:

those aren't profiles, profiles are things like HFP/HSP and A2DP, those are codecs and the reason why nobody supports encoding using any of those codecs is that encoding has licensing fees but decoding is free

yes, apologies, they're codecs as opposed to profiles. run an s/profile/codec/ on my post and everything still stands though.

you're kinda-sorta right about the license situation. it isn't free on either side, it's just that on the headphone side you're almost guaranteed a bundled license via the audo soc (the vast majority are qualcomm). similarly on the decoding side a massive percentage of android devices get a free license bundled with their qualcomm soc.

nudgenudgetilt
Mar 18, 2003


mystes posted:

Anyway, the problem is just that the Bluetooth profiles don't allow high quality bidirectional audio, period. It has nothing to do with licensing.

a2dp def supports sink/source with the right codec. I'm using it this moment.

nudgenudgetilt
Mar 18, 2003


Lady Radia posted:

whatcha listening to

it's a command and conquer soundtrack kind of night. fight, win, prevail!

nudgenudgetilt
Mar 18, 2003


pseudorandom name posted:

actually I think I'm wrong, it is free on the encoding side but decoding it costs money

whichever scenario promotes adoption and those sweet licensing fees but also conveniently allows Linux to support aptX

turns out I was wrong in my understanding that both sides required licensing:

https://www.mail-archive.com/package-review@lists.fedoraproject.org/msg410519.html

looks like the patents for both the main parts of aptx, and the return audio bits of aptx-ll are both expired at this point.

nudgenudgetilt
Mar 18, 2003


Jonny 290 posted:

Because I like Docker a whole lot and containerize everything i can and also i do it for my job now. Next

When the only tool you know how to use is a hammer...

nudgenudgetilt
Mar 18, 2003


https://github.com/Jeeaaasus/youtube-dl/blob/master/Dockerfile#L43

Let's embed our dependency version and url into our Dockerfile! Well, only if we're running x86_64 -- otherwise let's just use the latest version of the distro package. Why not always use the distro ffmpeg?


Then this poo poo:
https://github.com/Jeeaaasus/youtube-dl/blob/master/Dockerfile#L79

Why? Just Why?

Don't run a loving init inside your container. Run containers for each service. An init in your container just obscures the visibility docker provides into your service and fucks up your logging situation. One (primary application) process, one container, one set of logs.

nudgenudgetilt
Mar 18, 2003


Beeftweeter posted:

hurr durrr babby's first script is possibly dangerous and has so many dependencies it needs its own special sandbox to play in

It's worse than babby's first script, because when you cram babby's first script into a Dockerfile, babby starts having to escape each of their scripts so the full script runs in a single RUN, and cleans up after itself so as to not pollute the layer.

nudgenudgetilt
Mar 18, 2003


Beeftweeter posted:

"pip install youtube-dl" is kinda easy, too. it even works on ios!

so is apt-get install (youtube-dl|yt-dlp)

you can even get up to date versions from backports

Adbot
ADBOT LOVES YOU

nudgenudgetilt
Mar 18, 2003


Jonny 290 posted:

i don't care. this is so i can download music videos via youtube.

Jonny 290 posted:

Because I like Docker a whole lot and containerize everything i can and also i do it for my job now. Next

do you do this bullshit at work though?

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply