ugo

+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.

Code example looks wrong? null is passed as updater to a. As far as I understand, what is passed as callback to a is supposed to be the updater instead (especially since the ctor errors on both val and updater being null). Also, would be more clear what the difference and usage of updater and callback are if they were called something like calcVal and onValChanged respectively

We use null objects at work, and as another person said they are a safety feature. Here’s how they work: they are wrappers around another type. They provide the same interface as the wrapped type. They store one global instance of the wrapped type, default initialized, in a memory page marked read-only.

Here’s why they are considered a safety feature (note: most of this is specific to c++).

Suppose you have a collection, and you want to write a function that finds an item in the collection. Find can fail, of course. What do you return in that case? Reasonable options would be a null pointer, or std::nullopt. Having find return a std::optional would be perfect, because that’s the exact use case for it. You either found the item or you did not.

Now, the problem is that in most cases you don’t want to copy the item that was found in the collection when you return it, so you want to return a pointer or a reference. Well, std::optional is illegal. After all, an optional reference has the same semantics as a pointer, no? This means your find function cannot return an optional, it has to return a pointer with the special sentinel value of nullptr meaning “not found”.

But returning nullptr is dangerous, because if you forget to check the return value and you accidentally dereference it you invoke undefined behavior which in this case will usually crash the program.

Here’s where the null object comes in. You make find just return a reference. If the item is not found, you return a reference to the null object of the relevant type. Because the null object always exists, it’s not UB to access it. And because it is default initialized, trying to get a value from it will just give you the default value for that data member.

Basically it’s a pattern to avoid crashing if tou forget to check for nullptr

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

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.

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.

The “or later” is optional, the FSF specifically doesn’t have the power to update the terms of every GPL-licensed software because the wrote the clause in such a way that they don’t.

If I give you software licensed under the GPL3, and a GPL3.1 comes out, it doesn’t apply to your copy of the software. Likewise the copyright holder of the work is also not forced to relicense their software under the GPL3.1. And even if they did, copies of the software distributed under the GPL3 would still be licensed under the GPL3.

The “or later” clause simply means that if I received a copy of a GPL3 software, I can redistribute it under the GPL3.1 if I so wish (where “I” in the previous sentence is everyone with a copy of the work, as the GPL gives everyone with a copy redistribution rights)

I don’t know how to help you directly, but you could write a script that turns vibration on, then sleeps for an appropriate amount of time, and loops indefinitely. This way even if vibration stops after a few seconds, the script will turn it back on immediately.

As for vibration strength, I have no clue. SDL has controller APIs, maybe it’s able to control vibration intensity. In which case, one could write a CLI SDL-based program for this.

Are we reading the same article? I read it when it came out, and read it a second time now. The article:

• is not a bitchfit
• nowhere states CVE is bad or useless (it even links a list of CVEs directly hosted on curl’s website)

The article is about missing checks in the CVE ecosystem that allows useless fearmongering perpetrated by badly filed CVEs to spread, citing one particular CVE as exemplary of all the faults

Preach. I got a free EA game from the epic store once. Even at that price point, it was not worth what I paid. Literally, there’s so much better shit I can fit in 100GB that even at 0$ that’s a bad investment

My IT department likes to install antivirus software that makes it impossible to do your job because it will scan every compiled object file, inflating compilation times by an order of magnitude, even for distributed compilation jobs.

Or stupid “workspace management” software that will randomly uninstall work-related software and / or reboot your machine whenever it pleases.

Luckily I can use Linux at work, otherwise I’d have to either quit or tamper with my work machine to do my job.

And yes, the IT department knows. But they are always “understaffed” to fix stuff. Curiously, they are never understaffed to roll out new stuff that doesn’t work though.