AVincentInSpace

@AVincentInSpace@pawb.social

This profile is from a federated server and may be incomplete. Browse more on the original instance.

Good luck web devs (lemmy.world)

Alt text:Twitter post by Daniel Feldman (@d_feldman): Linux is the only major operating system to support diagonal mode (credit [Twitter] @xssfox). Image shows an untrawide monitor rotated about 45 degrees, with a horizontal IDE window taking up a bottom triangle. A web browser and settings menu above it are organized creating a...

AVincentInSpace,

I would love it so much if xrandr was able to keep up with that and didn’t blink for 3 seconds every time you changed orientation

AVincentInSpace,

Why does this low key feel like something I would actually want to use

AVincentInSpace,

ah yes, i’ve been propagandized into… wanting my phone to have a diagonal mode

there are very few things more politically neutral than this.

AVincentInSpace,

Very good point. Just because Valve hasn’t screwed us over yet is no excuse for assuming they never will.

AVincentInSpace,

Again, just because Valve hasn’t screwed us over yet is no excuse for assuming they never will.

AVincentInSpace, (edited )

Yeah? And what would that achieve? What the hell are gamers gonna do?

For God’s sake, we couldn’t even keep a protest going on Reddit because people were afraid of the sunk costs. People give Valve money.

AVincentInSpace,

Which one are your files encoded with?

(You can check this by running ffprobe on the file.)

AVincentInSpace, (edited )

ffprobe is included in the ffmpeg package. For future reference you can find what package contains a file by doing dpkg-query -S /bin/ffprobe (note that the path you give it is relative to /usr)

AVincentInSpace, (edited )

Looks like that video is encoded H.264, which according to Google is one of the codecs that Debian only makes available via third party repository.

Here are instructions from debian.org for installing the codec by manually downloading and installing a single package file:

wiki.debian.org/MultimediaCodecs

And here are instructions from a third party explaining how to tell apt how to install them so they can be kept up to date (be sure you read the warning on the debian.org page about why they don’t tell you to do that before you do it):

debiantutorials.com/how-to-install-ffmpeg-with-h-…

Depending on how exactly your file manager works, installing the codec may or may not be sufficient to display thumbnails. If not, there are probably instructions specific to your file manager for installing the appropriate plugin.

AVincentInSpace,

You have openh264 installed already which should cover your bases. Since it quite clearly isn’t I’m not sure what to suggest. What file manager is this that’s having issues?

AVincentInSpace, (edited )

Ext4 is a filesystem. That is the part of the kernel that actually stores and retrieves the files on disk. What program are you using to browse files? It’s a bit hard to tell from this screenshot what program it’s a screenshot of, but it looks like Nautilus (the default file browser in GNOME). Is that it?

AVincentInSpace,

sorry, wait, back up, did you manage to install a desktop Linux environment on a TV

AVincentInSpace, (edited )

…and why is that…better?

Programs still have to be written to accommodate the specific protocol that the program on the other end speaks, and dbus paths could translate pretty directly to subdirectories of /run. All adding dbus in the middle does is add a daemon where there doesn’t need to be one and force the programs to talk to each other through that rather than directly to each other

AVincentInSpace,

It occurs to me that sendmsg() is already kind of a standard, and the problem of drop in replacements could be solved by just making the replacement bind to the same file path and emulate the same protocol, and the problem of automatically starting the daemon could be handled by a systemd socket (or even inetd if you wanna go old school). The only advantage that I can see dbus really having over Unix sockets is allowing multiple programs to respond to the same message, which is a definite advantage but AFAIK not many things take advantage of that.

AVincentInSpace, (edited )

Message formatting

still have to do that with dbus

Service addressing

They’re Unix sockets, dude, they’re file paths in /run

Data marshalling

Still have to do that with dbus, also that’s the same thing as message formatting

Pubsub

Again, sockets. One application binds and many can connect (how often do you really need more than one application to respond to a method call? That’s a valid reason to use dbus in lieu of sockets, but how often do you need it?)

Method calling, marshalling of arguments and responses

They’re called “unix doors”, and that’s the third time you’ve said marshalling. As for that, language agnostic data marshalling is kind of a solved problem. I’m personally a fan of msgpack but JSON works too if you want to maximize compatibility. Or XML if you really want to piss off the people who interact with your API.

Broadcast and 1:1 messaging

Sockets and doors can only do 1:1, and that’s true enough, but it occurs to me that 99% of use cases don’t need that and thus don’t need dbus. dbus can still be used for those cases, but less load on dbus daemon = less load on system. Also you said that already with pubsub.

As for that blob at the bottom, again, who said anything about there not being a language agnostic library? It’d be a lot of work to make one, sure, but that doesn’t mean it’s impossible. Besides, most of the work has been done for you in the form of language agnostic marshalling libraries which as you said are like 50% of the problem. The rest is just syscalls and minor protocol standardization (how to reference FDs passed through the door in the msgpack data etc.)

And what I’ve just described isn’t a reimplementation of dbus without any of the good parts, it’s a reimplementation of dbus on top of the kernel instead of on top of a daemon that doesn’t need to be there.

AVincentInSpace, (edited )

…systemd very much does use the init system to launch userland and GUI processes. That’s how GNOME works.

Dbus is for interprocess communication. The fact that its primary use case is communication between desktop applications is hardly relevant to its design. I don’t see how GUI frameworks are at all relevant, or how it would be possible to create an interprocess communication mechanism that only worked with one GUI framework without some heroic levels of abstraction violation (which I would not put past Qt, but that’s another story).

I don’t see why having an entire dbus daemon running in the background is better than having a cluttered /tmp or /run directory.

AVincentInSpace,

nah they’d take one look inside that guy’s mind and go “well fuck this species”

AVincentInSpace,

It means that if I want access to something that has been texted to you, I don’t exactly need to be a government in order to get it.

AVincentInSpace,

It means that if I want access to something that has been texted to you, I don’t exactly need to be a government in order to get it.

AVincentInSpace,

Then you don’t have to worry about accidentally doing

AVincentInSpace,

Write angry blog post about why criticizing people should be impossible

FTFY

AVincentInSpace, (edited )

Every time I commit I have to look through git diff, figure out what the hell I actually did, come up with something intelligent to say about jt, possibly split the commit into multiple commits if I changed multiple things, do some shuffling with git reset and git add

For some reason all my personal projects are all like 4K SLoC with 50 total commits, all of which include apologies for not doing more smaller commits

  • All
  • Subscribed
  • Moderated
  • Favorites
  • localhost
  • All magazines
  • Loading…
    Loading the web debug toolbar…
    Attempt #