As a dev, I had to fix an O( n! ) algorithm once because the outsourced developer that wrote it had no clue about anything. This algorithm was making database queries. To an on-device database, granted, so no network requests, but jesus christ man. I questioned the sanity of the world that time, and haven’t stopped since.

Thank you for the explanation, now I understand the context on the original message. It’s definitely an entirely different environment, especially the kind of software that runs on a bunch of servers.

I have built business programs before being a game dev, still the kinds that runs on device rather than on a server. Even then, I always strived to write the most correct and performant code. Of course, I still wrote bugs like that time that a release broke the app for a subset of users because one of the database migrations didn’t apply to some real-world use case. Unfortunately, that one was due to us not having access to real world databases pr good enough surrogates due to customer policy (we were writing an unification software of sorts, up until this project every customer could give different meanings to each database column as they were just freeform text fields. Some customers even changed the schema). The migrations ran perfectly on each one of the test databases that we did have access to, but even then I did the obvious: roll the release back, add another test database that replicated the failing real world use case, fixed the failing migrations, and re released.

So yeah, from your post it sounds that either the company is bad at hiring, bad at teaching new hires, or simply has the culture of “lol who cares someone else will fix it”. You should probably talk to management. It probably won’t do anything in the majority of cases, but it’s the only way change can actually happen.

Try to schedule one on one session with your manager every 2 to 3 weeks to assess which systematic errors in the company are causing issues. 30 minutes sessions, just to make them aware of which parts of the company need fixing.

Sorry, this comment is causing me mental whiplash so I am either ignorant, am subject to non-standard circumstances, or both.

My personal experience is that developers (the decent ones at least) know hardware better than IT people. But maybe we mean different things by “hardware”?

You see, I work as a game dev so a good chunk of the technical part of my job is thinking about things like memory layout, cache locality, memory access patterns, branch predictor behavior, cache lines, false sharing, and so on and so forth. I know very little about hardware, and yet all of the above are things I need to keep in mind and consider and know to at least some usable extent to do my job.

While IT are mostly concerned on how to keep the idiots from shooting the company in the foot, by having to roll out software that allows them to diagnose, reset, install or uninstall things on, etc, to entire fleets of computers at once. It also just so happens that this software is often buggy and uses 99% of your cpu taking it for spin loops (they had to roll that back of course) or the antivirus rules don’t apply on your system for whatever reason causing the antivirus to scan all the object files generated by the compiler even if they are generated in a whitelisted directory, causing a rebuild to take an hour rather than 10 minutes.

They are also the ones that force me to change my (already unique and internal) password every few months for “security”.

So yeah, when you say that developers often have no idea how the hardware works, the chief questions that come to mind are

1. What kinda dev doesn’t know how hardware works to at least an usable extent?
2. What kinda hardware are we talking about?
3. What kinda hardware would an IT person need to know about? Network gear?

That’s not how I read it at all

By supporting work on a freelance basis for these topics, Valve enables us to work on them without being limited solely by the free time of our volunteers.

Seems pretty explicit to me. Valve is allowing some arch linux contributors to work freelance for valve and get paid money to work on the things they would otherwise be working on for free. This allows these contributors to spend much more time working on these things because they can treat this work as the-thing-I-do-to-put-food-in-my-mouth rather than something extra they would do on the scraps of time they have on the side.

There are plenty of pasta dishes and sauces that use cream, and while sour cream is not used in italian cuisine I think it tastes amazing :)

So I can absolutely see sour cream working in pasta

I am always amazed by how the japanese are often times very willing to experiment and be inventive in terms of melding their own culinary culture with foreign ones, considering the isolationist and conservative history and reputation they have overall as a people.

To me, that simply says that food really is one of the universal languages.

I’d love to try this dish if just for experimentation, although I suspect it wouldn’t be something I’d have more than once lol

Yeah, no judgement here, when one is poor they gotta do what they gotta do, and ketchup is probably cheaper than decent tomato sauce in some parts of the world I would imagine.

That said, I am willing to bet that the same pasta but with actual prepared tomato sauce (that means put it on the stove, let it simmer, add some salt, maybe a bit of pepper or a pinch of chili flakes if you like, and a drop of EVO oil when it comes off the heat) in place of ketchup would be even better.

Although in your case, the ketchup recipe likely brings back happy emotions relating to your childhood which, after all, are also part of the food experience. Cheers!

+1. Arch is super easy to install, just open the install guide on the wiki and do what it says.

It’s also really stable nowadays, I can’t actually remember the last time something broke.

As a counterpoint, on ubuntu I constantly had weird issues where the system would change something apparently on its own. Like the key repeat resetting every so often (I mean multiple times an hour), weirdness with graphic drivers, and so on.

That said, I also appreciate debian for server usage. Getting security updates only can be desirable for something that should be little more than an appliance. Doing a dist upgrade scares the shit out of me though, while on arch that’s not even close to a concern.

As an italian my strong belief is that your wife should put whatever she wants on pizza. Hell it’s a flatbread with condiments, go crazy. It’s meant for it. If you want a none pizza with left meat, you should have a none pizza with left meat.

Now if you put ketchup on pasta, I will judge your culinary literacy. Ketchup makes for a terrible pasta sauce

Can do, DM me the mail for the invite

I think it’s possible that the filesystem ran out of inodes, so even though there is space on disk, there is no space in the filesystem metadata to store new files.

Now, I don’t know off the top of my head how to check this, but I assume the answer is on the internet somewhere (am on phone and can’t help much more than this, sorry)

What is this mysterious device that requires specific libraries and kernel modules? So I can state the fuck away from the device and the brand

If by vim you mean neovim

vim.api.nvim_create_autocmd(“fileType”, {
    group = file_type_group,
    pattern = “make”,
    command = “setlocal ts=4 sts=4 sw=4 noexpandtab”,
})

Slap this in your config, done

if you’re using windows and expect any privacy at all […] throw that notion out the window

Correct. And the same is true even if you are using linux, macOS, android, or a butterfly to manipulate bits to send a message through the internet.

Because if your message ends up on the screen of a windows user, it’s also going to be eaten by AI.

And forget the notion of “anything you post on the internet is forever”, this is also true for private and encrypted comms now. At least as long as they can be decrypted by your recipient, if they use windows.

You want privacy and use linux? Well, that’s no longer enough. You now also need to make sure that none of your communications include a (current or future) windows user as they get spyware by default in their system.

Well maybe not quite by default, yet

They are yeah, but in that scenario you would also not have a window decoration with a close button, so I assumed the OP meant maximized :P

Reread the OP. They say:

not on GNOME, because you have a panel at the top

And

when usign GTK apps on those [non-GNOME] desktops

So you would not “access the controls above the app”, because having controls above the app is not covered by this scenario.

The scenario is:

1. You don’t have a top panel
2. You have a maximized GTK app

Which makes the close button be in the corner of the screen, but without actually extending to it.

On topic: never knew this was a problem, guess I got spoiled by the Qt environment

I thought mint was switching to a debian base but it looks like I am mistaken. While LMDE exists, it’s still not the default.

Got the feeling that’s probably gonna change soonish, we’ll see.

I don’t know about color profile data, but I can vouch for the EDID potentially being totally wrong sometimes on even basic data like physical size or even logical size (number of pixels).

As for the why, I don’t know, but following Occam’s razor I would guess that it’s cheaper when you just don’t care and leave it as somebody else’s problem.

Since my previous example didn’t really have return value, I am changing it slightly. So if I’m reading your suggestion of “rewriting that in 3 lines and a single nested scope followed by a single return”, I think you mean it like this?

int retval = 0;

// precondition checks:
if (!p1) retval = -ERROR1;
if (p2) retval = -ERROR2;
if (!p3 && p4) retval = -ERROR3;

// business logic:
if (p1 && !p2 && (p3 || !p4))
{
    retval = 42;
}

// or perhaps would you prefer the business logic check be like this?
if (retval != -ERROR1 && retval != -ERROR2 && retval != -ERROR3)
{
    retval = 42;
}

// or perhaps you'd split the business logic predicate like this? (Assuming the predicates only have a value of 0 or 1)
int ok = p1;
ok &= !p2;
ok &= p3 || !p4;
if (ok)
{
    retval = 42;
}

return retval;

as opposed to this?

// precondition checks:
if(!p1) return -ERROR1;
if(p2) return -ERROR2;
if(!p3 && p4) return -ERROR3;

// business logic:
return 42;

Using a retval has the exact problem that you want to avoid: at the point where we do return retval, we have no idea how retval was manipulated, or if it was set multiple times by different branches. It’s mutable state inside the function, so any line from when the variable is defined to when return retval is hit must now be examined to know why retval has the value that it has.

Not to mention that the business logic then needs to be guarded with some predicate, because we can’t early return. And if you need to add another precondition check, you need to add another (but inverted) predicate to the business logic check.

You also mentioned resource leaks, and I find that a more compelling argument for having only a single return. Readability and understandability (both of which directly correlate to maintainability) are undeniably better with early returns. But if you hit an early return after you have allocated resources, you have a resource leak.

Still, there are better solutions to the resource leak problem than to clobber your functions into an unreadable mess. Here’s a couple options I can think of.

1. Don’t: allow early returns only before allocating resources via a code standard. Allows many of the benfits of early returns, but could be confusing due to using both early returns and a retval in the business logic
2. If your language supports it, use RAII
3. If your language supports it, use defer
4. You can always write a cleanup function

Example of option 1

// precondition checks
if(!p1) return -ERROR1;
if(p2) return -ERROR2;
if(!p3 && p4) return -ERROR3;

void* pResource = allocResource();
int retval = 0;

// ...
// some business logic, no return allowed
// ...

freeResource(pResource);
return retval; // no leaks

Example of option 2

// same precondition checks with early returns, won't repeat them for brevity

auto Resource = allocResource();

// ...
// some business logic, return allowed, the destructor of Resource will be called when it goes out of scope, freeing the resources. No leaks
// ...

return 42;

Example of option 3

// precondition checks

void* pResource = allocResource();
defer freeResource(pResource);

// ...
// some business logic, return allowed, deferred statements will be executed before return. No leaks
// ...

return 42;

Example of option 4

int freeAndReturn(void* pResource, const int retval)
{
    freeResource(pResource);
    return retval;
}

int doWork()
{
    // precondition checks

    void* pResource = allocResource();

    // ...
    // some business logic, return allowed only in the same form as the following line
    // ...

    return freeAndReturn(pResource, 42);
}

Bad advice. Early return is way easier to parse and comprehend.

if (p1)
{
    if(!p2)
    {
        if(p3 || !p4)
        {
            *pOut = 10;
        }
    }
}

vs

if(!p1) return;
if(p2) return;
if(!p3 && p4) return;

*pOut = 10;

Early out makes the error conditions explicit, which is what one is interested in 90% of the time. After the last if you know that all of the above conditions are false, so you don’t need to keep them in your head.

And this is just a silly example with 3 predicates, imagine how a full function with lots of state looks. You would need to keep the entire decision tree in your head at all times. That’s the opposite of maintainable.