• 0 Posts
  • 25 Comments
Joined 2 years ago
cake
Cake day: July 1st, 2023

help-circle
  • arc@lemm.eetoLinux@lemmy.ml*Permanently Deleted*
    link
    fedilink
    arrow-up
    5
    ·
    4 months ago

    Depends what you mean by bloat. It has a very large repo, but it compiles into little commands with least privilege execution. A lot of those commands are specifically there so someone doesn’t have to pull in other repos with a larger attack surface. e.g. there is a time sync daemon to replace having to pull in ntp which is a lot more complex and fraught and the one thing most desktops need of NTP which is to set the clock.


  • arc@lemm.eetoLinux@lemmy.ml*Permanently Deleted*
    link
    fedilink
    arrow-up
    2
    arrow-down
    1
    ·
    edit-2
    4 months ago

    Why do you still exist? I try understanding what the purpose of your reply could be? Screenrecords do not work. For plenty of people. Google it. Yet you feel entitled to share you smalldick energy wisdom of “proper way”. That is exactly the vibe of the shit ppl. You do not help Wayland or x11 or anything, you just fap into your own mouth because nobody can ever love you like that. Go get help.

    Wow, someone needs to grow up. You laid into Wayland when screen recording doesn’t even go through Wayland. The app asks the WM to screen record via DBus. A more constructive response would have been “thanks I didn’t know that”, or perhaps “oh it’s a driver issue”, or “it’s an issue with that WM/ffmpeg/pipewire or whatever”, or anything else likely to be the underlying cause. But it’s not Wayland. Have you got that? Not Wayland. There is no need to be sore and immature about it.


  • arc@lemm.eetoLinux@lemmy.ml*Permanently Deleted*
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    edit-2
    4 months ago

    Screen records do work providing the app asks for a screen cast in the proper way (which BTW is not via Wayland but through a message to a DBus service). The service and the desktop then ask permission from the user if necessary. X11 didn’t give a damn about protecting the contents of your screen and any app whether it was beneficial or malicious could do it with impunity. So you should see this as a major security improvement - you can screen record but only if permission is granted.


  • arc@lemm.eetoLinux@lemmy.ml*Permanently Deleted*
    link
    fedilink
    arrow-up
    6
    ·
    4 months ago

    Yes it’s been stable for some time with a couple of caveats - you need a decent graphics driver and not be using apps with edge cases.

    Here is a simple example of an edge case and it’s not hard to find people blaming Wayland even though with some thought this was a security issue - apps like Zoom, Discord, MS Teams want to do screen sharing which is easy in X11 because it has non existent security - just steal the screen bitmap. That’s a problem.

    Wayland (the protocol) provides no means for one app to grab the screen, or other apps. This is by design for security. Instead the app must be a good citizen and send a “i want to screen cast” message to the xdg-desktop-portal (a service provider implemented by GNOME, KDE etc.), the desktop asks for user consent and then the app gets a video stream. So it’s a lot more secure but it requires the app and the WM do things properly.

    Desktops and apps have matured and these issues are thankfully going away. I think the biggest hurdle left is proper graphics drivers, especially the problem of getting NVidia drivers working.






  • That’s more or less it. Linux Torvalds hates the different package managers and dependencies in different dists and versions of dists. He claims it’s virtually impossible to ship products that just run on some random dist and cites his own sideproject which is a sea diving app where he builds binaries for Mac OSX and Windows but can’t for Linux. He also praises Valve for using containers.

    In theory it means slightly larger binaries, but the flipside it means Steam for Linux runs on a lot more dists, and so do the games and it’s far easier to test they actually run.



  • Personally I think that the following car functions should be mandatory physical controls - wipers, indicators, hazards, side/headlights, door locks, defogger / defroster, electronic parking brake. forward/reverse/neutral/park. And they should be controls that have fixed position in the car (i.e. not on the wheel) with positive and negative feedback.

    And fuck Tesla or any other manufacturer that wants to cheap out on a couple of bucks by removing them. Removing physical controls has obvious safety implications to drivers who are distracted trying to find icons on a tablet.


  • Yuzu gave them the opening to sue though. If they had been more circumspect - “Oh this is to develop homebrew / indie games nudge nudge” then maybe Nintendo wouldn’t have unleashed the lawyers or done so ineffectively. After all it wouldn’t be Yuzu’s fault if some wicked website corrupted their pure intentions by releasing device keys or patches that allowed their emulator run commercial games. But they were more blatant than that.

    Also from an empathic perspective, of course Nintendo were going to sue. Yuzu should have known they would since that’s what console platforms do when something interferes with their profits. Yuzu is doubly bad since it interferes with hardware sales and game sales unlike custom firmware / cartridges which only affect game sales.

    Of course the genie is already out of the bottle. Yuzu’s source code and binaries were on github for anyone to clone / fork. All the games are out in the wild. The piracy will carry on. I think it’s fair to say the NSP is effectively dead as a platform at this point. If a NSP2 turns up this year, as rumored, then I expect it will have revised anti-piracy measures and potentially a heavy online service aspect to go with it - it’s far easier to detect pirates and wield the banhammer when a device is online.



  • If you look at any modern desktop application, e.g. those built over GTK or QT, then they’re basically rendering stuff into a pixmap and pushing it over the wire. All of the drawing primitives made X11 efficient once upon a time are useless, obsolete junk, completely inadequate for a modern experience. Instead, X11 is pushing big fat pixmaps around and it is not efficient at all.

    So I doubt it makes any difference to bandwidth except in a positive sense. I bet if you ran a Wayland desktop over RDP it would be more efficient than X11 forwarding. Not familiar with waypipe but it seems more like a proxy between a server and a client so it’s probably more dependent on the client’s use/abuse of calls to the server than RDP is when implemented by a server.





  • tar was originally was for tape archiving so it’s just a stream of headers and files which end up directed to a file or a device. It’s not well ordered, just whatever file happens to be found next is the next in the stream. When you compress the tar this stream it’s just piped through gzip or bzip2 on its way.

    The tradeoff for compressing this way is if you want to list the contents of the tar then you essentially have to decompress and stream through the whole thing to see what’s in it unlike a .zip or .7z where there would be a separate index at the end which can be read far more easily.


  • arc@lemm.eetoLinux@lemmy.mlHow to write a 'tar' command
    link
    fedilink
    arrow-up
    11
    ·
    edit-2
    2 years ago

    I know the basics off by heart. Not the hardest command syntax to learn all things considered.

    The most annoying would be the growing collection of “uber commands” which are much more of a pain in the ass - aws, systemctl, docker, kubectl, npm, cargo, etc. - the executable has potentially dozens of subcommands, each of which has dozens of parameters.