[-] [email protected] 9 points 4 hours ago

I wouldn't be confident in recommending Fedora to noobs, because its a distribution that is on the bleeding edge side. But it depends on what type of noob we are talking about. There are noobs in Linux, who are technically well versed in Windows and have no problem in adapting to a new system. If someone wants to have the newest software, then Fedora might be it.

Also not many people have experience with Fedora, therefore less likely to be recommended. Most people use or used Ubuntu, maybe even started with Ubuntu. You or me may not like it, but its proven that Ubuntu is generally a good choice for newcomers to get into Linux. And that also plays into how many people know and are able to help. In contrast, Fedora is too much of a niche.

[-] [email protected] 7 points 4 hours ago

Always sad to see a game getting delisted. But props to the devs to notify us about half a year in advance. Usually these delistings are instant without notification and then its too late for people who want to buy it. Now the game is at a good discount, 80%. If I had interest into the game and there was no FH5 on Steam, then I'd buy it.

Licensing issues with music can easily be patched out and replaced by other music. But what can they do about the cars? I guess a lifetime license for the games is too expensive, so it will be a limited license and then the delisting is only matter of time. Man this sucks.

[-] [email protected] 1 points 17 hours ago* (last edited 17 hours ago)

What’s been a bit disappointing is DEs getting on the wayland train so late. A lot of the kinks could have been worked out way earlier if they had given their 2ct of feedback right from the start, instead of waiting 10 years to even start thinking about migrating.

That's the real issue. And its worse with Gnome, as Gnome doesn't want support "all of" Wayland and its protocols. That means Wayland will be broken on Gnome, despite Gnome being the most used DE (at the moment). People complain about the problems in Wayland, but not all problems are caused by Wayland itself.

However there were or are two big reasons I can think of why Wayland wasn't adopted early and for some may never: a) its much harder to be Wayland conform, because the window manager/DE has to do much more work, b) Wayland was just not ready before, as many important aspects were missing (in example some basic protocols, Nvidia) or broken. I don't blame them. For the record, I am not a Wayland chill, just talking about this, because there are many misconceptions (me included, I'm not perfect) and switched to Wayland just end of last year. Before that Wayland did just not work for me. I even switched from Qtile to KDE, because KDE has probably the best Wayland support (I hate manual window management).

Edit: I just remembered another reason why Wayland wasn't probably adopted early. Canonical/Ubuntu started a Wayland alternative called Mir (that was before Mir transformed into a Wayland compositor). And devs probably didn't want set on Wayland or Mir before knowing what will be around in the future.

[-] [email protected] 0 points 18 hours ago

Wayland kinda is an x.org project in the first place.

Not really. Wayland is fundamentally different from Xorg. Otherwise we would not need Wayland and create X12. It's like saying mechanical hard drives are kind of Solid State Drives, just because they allow to do something similar. Even if the developers are the same, does not mean the technology is.

AFAIK it’s officially organised under freedesktop but the core devs are x.org people.

I'm not sure if this is correct. But let's assume this is correct. Why does it matter? If Wayland was developed by different people than those who maintain Xorg at the moment, would not change the fact that we need Wayland, because it is different and solves issues that cannot be solved with Xorg without rewriting it. And nobody wants to rewrite Xorg or understand the code (other than very basic security maintenance).

[-] [email protected] 25 points 20 hours ago

Not surprised.

[-] [email protected] 1 points 21 hours ago* (last edited 20 hours ago)

If the alternative is a new system that literally does nothing? Sure!

You should read about Wayland. Doing nothing is absolutely wrong.

X11 may be old and whatever you want, but it works and it’s battle-tested.

It doesn't work. There are parts of X11 which are broken. And you reply to a reply where I already listed 2 huge points, which are not even the only ones. And you ignore that X11/Xorg code is totally spaghetti, huge and has lot of old code that not everyone understands, because it has ton of workarounds to make it somehow half baked working on modern times. Nobody wants to work on the code, doing more than basic maintenance. And you should think about the future too, not just about yesterday and today on your personal computer. Think bigger. X11 is just not enough anymore going forward, for the next coming decades.

Wayland can’t even launch a full desktop session in my machine, which is even less than the failure Pulseaudio was back in its day and that’s saying something.

Are you on Gnome? Did you install Wayland on top of a running X11 system and did not configure it correctly? X11 doesn't work on my machine too, because everything is Wayland configured. So whats your point? Off course one is not a 100% replacement. There will be changes, and both are incomplete and are not working 100% perfectly. The point of Wayland is not being 100% compatible with the setup you have for Xorg/X11. There are things like reading from keyboard on any application that is running is a security risk in X11. Wayland prevents that. Which in turn means that some programs (even important ones) won't work. And they are working on a solution.

I switched to Wayland just end of last year and one of the reasons is that X11 does not handle multiple monitors well, if they have different sizes and refreshrates, especially if you add G-Sync and probably FreeSync on the other monitor. X11 is broken at that front.

[-] [email protected] 2 points 1 day ago

I argue that X11 would have hyperactive development, if we did not have Wayland (or Mir, before it turned into a Wayland compositor). There are at least two major fields that do not work perfectly and cannot be changed by simple updates, it needs rewrite from ground up: a) advanced multi-monitor handling of different kind of monitors at the same time, b) security issues related to keyloggers, as apps are not isolated. Nobody want to touch the X11 code for more than simple maintenance, no one wants to rewrite major portions or add new features.

We just need Wayland, as you already noted there are very good arguments. A complete new base with modern code and people developing for modern times and hardware just makes sense. Think about it, do you really want to have X11 going forward the next decades? It's like holding to hard drives and saying its okay, there are no problems, and writing off SSDs.

[-] [email protected] 3 points 1 day ago

Yes, you are right. I always get tripped up with this one. Xorg is the implementation of the X11 protocol.

[-] [email protected] 10 points 1 day ago* (last edited 1 day ago)

We even disagree on what "dead development" means. :D ( Edit: To add a bit substance to my reply, minimal maintenance is not actively developed in my books. )

[-] [email protected] 8 points 1 day ago* (last edited 1 day ago)

Dead in the sense of development. ~~I thought this was obvious. But I explained it for you, here you go.~~ (Edit: I forgot to be nice. )

[-] [email protected] 26 points 2 days ago

Wayland is still incomplete, but that is besides the point I was making. X is still not dead, even living within XWayland, within Wayland. X11 is just one implementation of the X Protocol and XWayland is a new implementation.

Wayland itself is functional and working, just not 100% compatible to X11. The same could be said about X11, it would be nice if they could get some basic functionality working right; but they can't, and that is why we need to replace it with something more modern and better. I think Wayland is working on a solution for restoring window position and size.

When X was created, there was no compatibility needed. Wayland on the other hand is in a different position, where it needs to innovate, make it more secure and keep as much as possible compatibility to X11, DEs and window managers. It's just unfair to just say Wayland would not have basic functionality working. It also depends on the desktop environments and GNOME is often to blame for.

28
submitted 3 weeks ago* (last edited 3 weeks ago) by [email protected] to c/[email protected]

Solution: Thanks for finding the solution, kate (in the comments). The option to control this is --extractor-retries .


I recently start using SponsorBlock feature with yt-dlp . When it looks up SponsorBlock server, it tries 3 times to connect and download information. I would like to increase the retries for this specifically, but could not find the right setting or option in the manual (man yt-dlp) and help (yt-dlp --help). I would like to increase it to at least 5 or maybe even 10 retries per video.

I've noticed for sometimes it cannot login within the first 3 look ups, but when I retry the command after that it will just look up fine. Therefore an increase in the retries setting would be helpful. Especially helpful when downloading entire playlists, leaving it for some time alone.

16
submitted 3 weeks ago* (last edited 3 weeks ago) by [email protected] to c/[email protected]

Project name is changed from "ytdl" to "yt-dlp-lemon", after user "lol" in the comments convinced me. Thank you for the suggestion! Remember to change the directory name at ~/.local/share/ytdl to ~/.local/share/yt-dlp-lemon .


The terror continues...

10 days ago I posted the initial version of this script. Since then lot of changed and added. Here some of those changes since v0.1:

  • -h is now much more simple, to see full help use -H
  • -f to repackage to another container format, or -F to force re-encoding video content with a codec to any other format
  • -s and -b will operate on sponsors only, and -S and -B on complete list of SponsorBlock segments
  • similarly -e and -d will only embed and download only a few extra metadata and files, -E and -D does all extra files and data
  • new -R will download and name files in reverse order, with index starting at 1 for the bottom file, useful for playlists who add newest entry to top
  • by default all file names are simplified and sanitized a little bit, even if no option -r (for very strict) is used

My goal is to make the usage of yt-dlp itself easier with this script, without the need to study help, the manual and to write a configuration file and a script. And you don't need to test it with various sources. It does not everything what yt-dlp offers, but most of the stuff in the way I like it.

git clone https://github.com/thingsiplay/yt-dlp-lemon
cd yt-dlp-lemon
chmod +x yt-dlp-lemon
./yt-dlp-lemon -h

Output from simple help:

$ yt-dlp-lemon -h
yt-dlp-lemon [options] [url...]

Simple wrapper to yt-dlp with only a subset of options.

options:
-h                show help and exit
-H                show all options, notes and exit
-m HEIGHT         max height
-f FORMAT         repack format
-I                no ignore file
-s                add chapter marks + recognize sponsors
-b                remove sponsored segments
-c                split file by chapters
-p                playlist mode
-a                audio mode
-d                download description files
-e                embed meta and chapters
-q                show filepath only
-x                skip download

Copyright © 2024 Tuncay D. https://github.com/thingsiplay/yt-dlp-lemon
52
submitted 1 month ago* (last edited 1 month ago) by [email protected] to c/[email protected]

Today I'm here again to terrorize this community with my Bash scripts nobody asked for.

This new biggest is a script evolved from a much simpler version found at biggest.sh to something more complex and complete. Now there are even options to show a simple horizontal bar and relative percentage numbers instead the file size itself.

It's a script to control du command in combination with several other standard Linux utilities. I'm well aware of these alternative applications to help visualizing what the biggest files on the system are. Well, I like these kind of scripts and I like its not too much bloated. And especially the output as paths can be combined with other tools easily. It's also kinda fun doing this. Edit: Forgot to mention, it also reads stdin pipe, as output from another program like find in example.

Have a good day.

35
submitted 1 month ago by [email protected] to c/[email protected]

ytdl is a small script for Linux as an alternative interface to yt-dlp (which itself is a fork from youtube-dl, to download YouTube videos). My goal is to make some of its functionality a bit more accessible for the daily usage. This includes predefined settings and narrowing it down to options I care most about.

49
My Linux Command Line Tools (thingsiplay.game.blog)
submitted 1 month ago by [email protected] to c/[email protected]

A short list with categories of my smol terminal focused tools, scripts and functions I have created over the years. There are some general purpose and very specific ones. This list was needed, because in Github it was a bit cluttered. Maybe, just maybe, you find something useful or inspiring in there.

17
submitted 1 month ago by [email protected] to c/[email protected]

A week ago I started a little script to format the output of file and path listings from other programs. It got a little bit out of hand and I implemented lot of advanced features into the fmt commands; kind of a sub language to define how the output should be formatted and structured. Entire idea is to give it paths, process the stream (not the file content itself, but the path representing a file) and output them again.

fpath accepts two type of input: a) either as arguments like fpath *.txt or b) from stdin like ls -1 | fpath . With additional options and commands the output can be colored and reformatted to something entirely different. In example with -F option the advanced formatting is possible, such as fpath -F '{.size} {name}' as a simple example.

There is lot of functionality (based on Python, yes this is a Python script), such as {reverse}{name}{/reverse} to reverse font color and background of the segment that is enclosed by the command, a slice to get a subset as a range from the entire path {-1:}, or {center:80}text{/center} to add spaces to get centered text, or just {ext} to output the extension, {mime} to output the file mime type, or even execute arbitrary programs {!grep:a}{path}{/!} to reduce output that has an a in the path.

Did I over engineer it again? Or just ignore most stuff and use it with the most simple options, should be enough anyway: fpath -t -s red *.txt

61
submitted 1 month ago* (last edited 1 month ago) by [email protected] to c/[email protected]

I just watched an excellent 2 hour (just needed to edit title, as I noticed it was 2 hours and not 1, wow time really flew away!) long documentary. The build up in stages and showing the evolution of the best players achievements, is intense and very well edited, narrated and written documentary!

I know 1 hour is long and I wasn't planning to watch everything, but time flew away. If you have any slight interest into this topic, I highly recommend you to take some time to watch. The video itself is broken up in 5 or so sections. So you could just watch a section at a time, if 2 hour is too long. There is a specific reveal that I do not want spoil, which was epic. Just insanity!

BTW have fun. Edit: Here some timestamps:

  1. 2:32 Chapter 1
  2. 11:39 Chapter 2
  3. 16:28 Chapter 3: ENEOOGEZ
  4. 25:48 Chapter 4: Hypertapping
  5. 31:45 Chapter 5: The Next Generation
  6. 49:00 Chapter 6: Rolling
  7. 1:00:27 Chapter 7: Vaulting & Scaling
  8. 1:15:25 Chapter 8: Colors
  9. 1:25:00 Chapter 9: Crash

For anyone who don't want to watch it on YouTube, here is a link to an Invidious instance:

https://invidious.nerdvpn.de/watch?v=mOJlg8g8_yw

11
submitted 1 month ago* (last edited 1 month ago) by [email protected] to c/[email protected]

Hi all. Yesterday I posted a program/script which is focused on path based text formatting, such as output from ls or find. Today I want to share new version. I'm proud, even though its limited in its usefulness, but today I solved an issue that was complicated to me (and a few other issues).

Linux command file is used to display file type and mime information, which is super handy. Reason why this was complicated to me is, as I want it to run only once for all paths together for performance reasons. For over thousand files instead taking more than a minute execution time, its down to under 2 seconds when displaying file type information (which includes spawning file process in the background). A few examples:

$ find Desktop/*.* -maxdepth 0 | fpath -F'{type}   \t{name}'
text/plain      append.cfg
text/plain      dynamic.cfg
image/png       nearest.png
image/png       new.png

$ find Desktop/*.* -maxdepth 0 | fpath -a -F'{path}\n\t{file}'
/home/tuncay/Desktop/append.cfg
        ASCII text
/home/tuncay/Desktop/dynamic.cfg
        ASCII text
/home/tuncay/Desktop/nearest.png
        PNG image data, 1920 x 1440, 8-bit/color RGB, non-interlaced
/home/tuncay/Desktop/new.png
        PNG image data, 1920 x 1440, 8-bit/color RGB, non-interlaced

Update v0.3:

Rather than creating a new post, I want to note that I have a huge update. First off, the performance is increased drastically with recent optimizations. Even thousands of paths are now processed very fast (until operations reading from file system is involved).

Just to put into perspective: When I search and output list of paths with time baloosearch6 "a" in my home, I get 8468 files and it takes 0m0,048s. Now when I pipe that into fpath with default processing and without options, it takes 0m0,086s to process. But with a more complex command that involves reading file stats (like size and such) and colored output and a slice:

time baloosearch6 "a" | fpath -F'{.mode}  {.size} \t{-3:-1}: {blue}{name} {}' -sred

it only takes 0m0,200s to execute! But using {file} or {type} or {mime} will still take a long time, even if the subshell process is run only once (it will still read the information for every file):

time baloosearch6 "a" | fpath -F'{file}'

took 3m54,233s to run. But what do you expect with approx. 8 thousand files. Without this script, it would take the same amount of time when running bare metal file command on all of these files.

Secondly, I have implemented a slice command that works very well. It's like the index {3} thing, but now you can set a {start:end} range to not only get a single part, but all parts within that range. It even works with negative numbers like {-3:} to get the last three parts of a path. An empty index means to get everything until end of path.

I'm quite happy how this program turned to be out. Python (at least for me with Python v3.12) is not that slow after all.

23
submitted 1 month ago by [email protected] to c/[email protected]

I did it again; exaggerate a simple idea and make it look more complicated at the end with too much text in the readme. I was bothered with the output of file listings and how unreadable they can get, especially with long paths and many of them on screen. At the end, I am not sure how useful this will be in the long run, but that is something you can judge yourself. It was certainly fun to create and in my opinion it's also fun to use.

git clone https://github.com/thingsiplay/fpath
cd fpath
chmod +x fpath


What is this? Convenience script to style and reformat the output with path like formats. Designed to combine listings from other programs output, such as from find and even ls, or any other tool with similar capabilities. The script works mostly on text data rather than the file system, but some special commands are exception to this rule and will access the file system.


120
submitted 1 month ago* (last edited 1 month ago) by [email protected] to c/[email protected]

New features and improvements

  • Improved support for tablets on Windows
  • Backports of other GTK3 features

What’s next

Clearly one of the smallest releases ever in the 2.10 series, and it might be our last. We’ll see, though we also know some people get stuck longer than others on older series (especially when using LTS distributions of Free Software operating systems), so we might do (if we feel like it’s needed) a 2.10.40 release with bug fixes only just before or just after GIMP 3.0.0 release, as a wrap up.

In any case, we are now stopping backporting features in the 2.10 series. These graphics tablet support improvements for Windows are huge enough that they had to get in; yet from now on, we want to focus solely on releasing GIMP 3.0.0.

Now you might wonder when that is? Very soon! We are on the last sprint towards the release candidate. This includes a lot of bug fixes, but also still some API changes going on. We will keep you updated!

Don’t forget you can donate and personally fund GIMP developers, as a way to give back and accelerate the development of GIMP. Community commitment helps the project to grow stronger! 💪🥳


GIMP 3.0 (Development branch roadmap

12
submitted 2 months ago by [email protected] to c/[email protected]

cross-posted from: https://beehaw.org/post/13362507

It uses 7z to extract files from archives. By also utilizing GNU Parallel, multiple files can be processed at the same time.

The purpose is to streamline option handling and usability of both programs into a unified command line interface, by only incorporating functionality which I need. 7z's option and argument handling is a bit confusing and does things in unique and unfamiliar ways. On the other side, we have Parallel, which is extremely complex and has ton of functionality; also confusing. So I picked up my favorite options and bundled them into a manageable script.

Name of the script is inspired by unwrap() functionality from Rust programming language. It unpacks certain type of variables to make use what is inside of it.

7z (probably in package p7zip) and parallel are required and need to be present.

git clone https://github.com/thingsiplay/unwrap
cd unwrap
chmod +x unwrap

usage:

unwrap *.zip

unwrap -f -i '*.txt' -o . *.zip
38
submitted 2 months ago by [email protected] to c/[email protected]

It uses 7z to extract files from archives. By also utilizing GNU Parallel, multiple files can be processed at the same time.

The purpose is to streamline option handling and usability of both programs into a unified command line interface, by only incorporating functionality which I need. 7z's option and argument handling is a bit confusing and does things in unique and unfamiliar ways. On the other side, we have Parallel, which is extremely complex and has ton of functionality; also confusing. So I picked up my favorite options and bundled them into a manageable script.

Name of the script is inspired by unwrap() functionality from Rust programming language. It unpacks certain type of variables to make use what is inside of it.

7z (probably in package p7zip) and parallel are required and need to be present.

git clone https://github.com/thingsiplay/unwrap
cd unwrap
chmod +x unwrap

usage:

unwrap *.zip

unwrap -f -i '*.txt' -o . *.zip
view more: next ›

thingsiplay

joined 1 year ago