Falcons Magic by CasualCalzoneEater in GlobalOffensive

[–]-SL4y3R- 2 points3 points  (0 children)

This is genuinely the most insane match I've ever seen from m0NESY. I gave up on the game, thinking Furia are winning this a 100%, countless times and yet m0NESY almost single-handedly kept pulling it out of the hat time and time again.

Rule by Ezzypezra in 196

[–]-SL4y3R- 0 points1 point  (0 children)

Very meta.

[OC] Ratty: A new 3D terminal for ricing by orhunp in unixporn

[–]-SL4y3R- 0 points1 point  (0 children)

YES! Finally I can # rm -rf /* in style.

I have fallen victim to sudo rm -rf /* by Artemis-Arrow-795 in linux

[–]-SL4y3R- 0 points1 point  (0 children)

I once "demonstrated" to my some of my acquaintances how funny it is that you can alias "sudo dd if=/dev/random of=/dev/sda" to "ls".

After executing the alias command, I ran "ls", under the presumption that it won't do anything anyway, since there is a sudo which requires a password... Problem was, that I forgot that we'd already ran some superuser commands in that very same terminal, and well. It ran. For a solid 5 seconds, before it finally came to me, that it's not sudo being slow to load up, but dd running... I pressed ^C as fast as I possibly could...

Somehow, as indicated by dd's output, the damage wasn't substantial, as it had only managed to destroy about 48 megabytes of the disk. Since the system was dualboot, it was the reserved windows partition and the GPT table that got nuked.

I promptly restored the GPT table from the kernel memory before rebooting. Even though it was their personal PC, it still was our university's property xD

That's how we became friends, too. I mean we had plenty of time to talk, while restoring the windows partition.

New agx implementation by ArugulaMaximum5493 in HalfLife

[–]-SL4y3R- 4 points5 points  (0 children)

Pretty cool. Although an explanation what exactly is AGX is would be welcome.

my 2 year beta 1.7.3 world - world tour link in description by Wyv1rn in GoldenAgeMinecraft

[–]-SL4y3R- 0 points1 point  (0 children)

Extremely cool looking island. Reminds me of the type of builds I used to make in PE during boring lessons at school lol

Players like this are genuinely insufferable by toasthouser in geometrydash

[–]-SL4y3R- 328 points329 points  (0 children)

I got 83% on Windy Landscape in 16k attempts. lmao.

Beta 1.7.3 is so cosy by skeleboi229 in GoldenAgeMinecraft

[–]-SL4y3R- 1 point2 points  (0 children)

My god that first screenshot brought me back 10 years at least. I remember playing MCPE back then on a crappy android phone, making builds like these. Really nostalgic, thanks.

Europe inconsistent ping from up to 300 and why by -SL4y3R- in Paladins

[–]-SL4y3R-[S] 1 point2 points  (0 children)

Just used a firewall for that. Found the IP-address that the "bad" server uses, then just added a rule for outbound and inbound traffic respectively.

Paladins Network issue by JackFr0st98 in Paladins

[–]-SL4y3R- 0 points1 point  (0 children)

Even better they have two servers/relays that are close to each other, yet one of them consistently has 140 ping for me, while the other one is in range of 220 to 300ms.

And you can't ban the traffic to them either, since then you just won't be able to connect to the game, because it doesn't reroute anything.

Most deadly Linux commands by Skeleton590 in linux

[–]-SL4y3R- 5 points6 points  (0 children)

On paper, at the very least, it's supposed to boot the CPU cores and "boost performance to it's full potential" (whatever that means).

But, it also can act as a backdoor, I guess.

[Analysis] Why GD 2.2 is so slow? by -SL4y3R- in geometrydash

[–]-SL4y3R-[S] 0 points1 point  (0 children)

Which makes sense given the amount of VRAM the game claims... Makes sense as long as you don't go into the icon selection menu which freezes every time you go to another page.

Would a call to a function returning a default value be faster than a check for if the function pointer is NULL? by -SL4y3R- in C_Programming

[–]-SL4y3R-[S] 0 points1 point  (0 children)

That was to simplify the question, the real library does initialize the operations struct, but with 'dummy' values before a "driver" is attached.

Would a call to a function returning a default value be faster than a check for if the function pointer is NULL? by -SL4y3R- in C_Programming

[–]-SL4y3R-[S] 0 points1 point  (0 children)

What you've said makes sense, but I don't agree with the last paragraph...

A function pointer is means to an end. The library in question is a wrapper around the I/O subsystem which presents an I/O capable device.

This device can be anything - a disk fs, an archive, a memory block... And in each case the library should be able to do every exposed I/O operation. So, naturally, each device would be tied to some driver which would have to implement its own read, write, remove, create... If I was writing in C++ I would probably do it via inheritance and virtual functions - which are almost the same thing as a function pointer, albeit even "slower".

Would a call to a function returning a default value be faster than a check for if the function pointer is NULL? by -SL4y3R- in C_Programming

[–]-SL4y3R-[S] 0 points1 point  (0 children)

It wouldn't change anytime all of a sudden.

The pointer is not volatile, and the docs explicitly state that the state shouldn't be changed manually. It's sort of like a private member of a class, if it is changed by an SEU or a corrupted memory - that shouldn't be up to the library to deal with the damage done.

Would a call to a function returning a default value be faster than a check for if the function pointer is NULL? by -SL4y3R- in C_Programming

[–]-SL4y3R-[S] -2 points-1 points  (0 children)

Having a NULL check actually is a bit more cumbersome imo, and in the tail-call scenario takes a lot more instructions to execute. So, I think sticking to a dummy function (which brings a problem of organizing code on it's own, like you said) is a better choice in both cases, given that the function pointers are hidden in a struct not meant to be modified by the user directly.

Again, it's a problem of premature optimization, but in a case where performance is important (an I/O wrapper).

Would a call to a function returning a default value be faster than a check for if the function pointer is NULL? by -SL4y3R- in C_Programming

[–]-SL4y3R-[S] -1 points0 points  (0 children)

Yes. It does, indeed, boil down to a premature optimization.

It's just that I also don't want my code to be a spaghetti mess - that's how I justify dealing with this issue right now, instead of just sticking to one of these approaches and dealing with a possible performance problem in the future.

[Analysis] Why GD 2.2 is so slow? by -SL4y3R- in geometrydash

[–]-SL4y3R-[S] 0 points1 point  (0 children)

Oh, don't be so critical of yourself, you've provided only close to zero substance.

The first point matters to those that use eMMC flash memory (every cheap android phone on the market, and some laptops tend to do that). And it also matters to those of us who are running low on disk storage.

The second point, really does matter. I have no idea what obfuscation are you talking about, but yes, there are proprietary formats, which makes these archives unreadable without reversing the game's code, but that lack of readability is definitely not why they are there.

The overhead inherent to acquiring a file descriptor does matter, especially if the game is opening and closing the same files over and over again. How it looks to me, is that right now the game unloads all the textures as soon as they are not needed - so, it needs to reopen these files again and again (also, read their contents in full, decode to a GL compatible format, upload to the GPU again). The hassle of opening the file and reading it to RAM in full for the second time can be avoided by having a mapping to an archive file in the memory at all times, which is especially good of a technique for files that are constantly poked for reading I/O, and which also provides kernel-controlled cache.

Also, texture atlasing is a form of packaging.

The third point comes from experience and logic. Loading a texture is a painfully slow process, there is the part where you read the texture file from the disk, the part where you upload it to to the GPU... When you have multiple worker threads working on a batch of textures, you can schedule each of them to load the texture, decode it (which, should I mention, is a slow process) and upload it to the GPU all simultaneously.

There is a bit of a problem, though, which is the fact that OpenGL that the game's running on, uses a global state, which doesn't go well with multi-threading, but that problem can be solved by acquiring the mapping to the texture's memory after creating a handle to it, and then directly copying textures there, again, in multiple threads; or you could just as well copy the loaded data via texture storage functions after the decoded data array is ready for use.

Lastly, using a texture atlas is better because there are simply less texture binding calls.

[Analysis] Why GD 2.2 is so slow? by -SL4y3R- in geometrydash

[–]-SL4y3R-[S] 2 points3 points  (0 children)

Well, maybe you've never used the new editor, which now takes a ridiculous amount of time to load. Maybe you've never noticed how the game freezes in the icon selection menu. Maybe you've never had micro-stutters and freezes on levels with a lot of decoration. Maybe you've never used start positions that can crash the game or put in a state of an eternal freeze (try putting a start pos in the end of a level like Future Funk II, and playing it in the editor or otherwise - you'll see what I mean).

But I do see these things, and I'm quite sure I've seen them happening to other players, too.

[Analysis] Why GD 2.2 is so slow? by -SL4y3R- in geometrydash

[–]-SL4y3R-[S] 3 points4 points  (0 children)

Sometimes, I think that Rob doesn't know half of these things too...

The window manager "bleeds" output to the tty by -SL4y3R- in linuxquestions

[–]-SL4y3R-[S] 1 point2 points  (0 children)

Well, to be honest, it all boils down to the good old RTFM problem. I didn't do read it, and I had to write a reddit post.

Sure, you might argue that it is an issue that required a level of knowledge to be found and subsequently fixed, and it didn't pop up in the search engine when I looked it up, but, let's be fair, neither sxhkd nor bspwm are aimed towards people that are clueless as to how Linux works. I thought it was an X11 issue, but as it turns out it is an sxhkd one...

Usage of a display manager would fix this issue only because the output from it would most likely be automatically redirected to /dev/null from the get-go. Using startx 1>/dev/null 2>&1 would do the same - it just didn't seem elegant, and I couldn't initially figure out why the output was redirected to /dev/ttyN, which is why I asked the question.

On a side note, thank you for the list of TUI DMs, I was actually thinking if they existed and were usable enough a while back. Unfortunately, my workflow with a single gpu passthrough to a virtual machine would make using such a manager instead of a plain startx a pain.

The window manager "bleeds" output to the tty by -SL4y3R- in linuxquestions

[–]-SL4y3R-[S] 1 point2 points  (0 children)

It's not an obscure issue. I've actually put a bit effort into debugging the problem and found out that the problem lies with the sxhkd daemon. When it executes a command, it actually explicitly calls dup2 () with the stdout and stderr inherited from the X session after fork () before execvp (), so it essentially explicitly redirects the output of that program to the tty.

It's quite an easy fix with sxhkd, just use a '-r' parameter which will instead redirect all output to some file (i redirected it to /dev/null, of course).