nous

Of course it is opt in. Why would it not be? Microsoft have opted in automatically on your behalf. Soon you will only be able to opt in, for your convenience, as too many people were accidentally opting out. /s

That's what happens when you make it expensive to import anything and don't have any domestic manufacturing for computer components.

The readme for smol has an example for stdout. I assume stdin is the same:

        let mut stdout = Unblock::new(std::io::stdout());
        io::copy(stream, &mut stdout).await?;

And there is more information about how to use it for reading/writing on the Unblock docs.

By far the most important thing is consistency

This is not true. The most important thing is correctness. The code should do what you expect/want it to do. This is followed closely by maintainability. The code should be easy to read and modify. These are the two most important aspects and I believe all other rules or methodologies out there are in service of these two things. Normally the maintainability side of things as correctness is not that hard to achieve with any system of rules out there.

You must resist the urge to make your little corner of the code base nicer than the rest of it.

Uhg. I really don't like these words. I agree with their sentiment, to a degree, but they make it sound like you should not try to improve anything at all. Just leave it as it is and write your new code in the same old crappy way that it always has been. Which is terrible advice. But I get what they are trying to say - you should not jump into a area swinging a wrecking ball around trying to make the code as locally nice as possible at the expense of the rest of the code base and other developmental practices around.

In reality there is a middle ground. You should strive to make your corner of the code base as nice as possible but you should also take into account the rest of the code base and current practices as well. Sometimes having a little bit better local maintainability is not worth the cost of making the code base as a whole less maintainable. Sometimes a big improvement to local maintainability is worth a minor inconvenience to the code base as a whole - especially for fast moving parts of the code base. You don't want something that no one has touched in 10 years to drastically slow down current features you are working on just to keep things consistent.

Yes consistency is important. But things are far more nuanced than that statement alone. You should strive for consistency of a code base - it does after all have a big effect on the maintainability of the code base. But there are times that it hampers maintainability as well. And in those situations always go for maintainability over consistency.

Say for instance some new library or an update to a library introduces a new much better way of working. Your code base is full of the old way though. Should you stick to the old way just to keep up with consistency? If the improvement is good enough then it might be worthwhile. Ideally if you can you would go though and update the whole code base to the new way of working. That way you improve things overall and keep consistency of the code base. But that is not always practical to do. It might be better to decide that the new way is worth switching to for new code, and worth refactoring old code when you are working in that area anyway but not worth the effort of converting the whole code base at once. This makes maintainability of the new code better, at the expense of old less used code.

But the new way might not be a big enough jump in maintainability of new code that it is worth sacrificing the maintainability of the code base as a whole. Every situation like this needs to be discussed with your team and you need to decide on what makes most sense for your project. But the answer is not always that consistency is the most important aspect. Even if it is an important aspect.

Consistency as a means to correctness still means correctness is the more important aspect. Far too many projects and people that go hard on some methodologies and practices lose sight of their main goal and start focusing on the methods instead. Even to the point were the methods are no longer working toward the goal they originally set out to accomplish.

Always have the goal in mind, once your practices start to interfere with that goal then it is time to rethink them.

Most packages managers can run arbitrary code on install or upgrade or removal. You are trusting the code you choose to run on your system no matter where you get it from. Remember the old bug in ubuntu that ran a rm -rf / usr/.. instead of rm -rf /usr/... and wiped a load of peoples systems?

Flatpacks, Apparmor and snaps are better in this reguard as they are somewhat more sandboxed and can restrict what the applications have access to.

But really if the install script is from the authors of the package then it should be just as trustworthy as the package. But generally I download and read the install scripts as there is no standard they are following and I don't want them touching random system files in ways I am not aware of or cannot undo easily. Sometimes they are just detecting the OS and picking relevant packages to install - maybe with some thrid party repos. Other times they mess with your home partition and do a bunch of stuff including messing with bashrc files to add things to your PATH which I don't like. I would never run a install script that is not from the author of the application though and be very wary of install scripts from a smaller package with fewer users.

I disagree with this. Stack traces are a lazy way to handle errors. They are useful only to the developer of an application for logic errors and bugs in the program. That is their one usecase and are very handy at that usecase.

For instance the very stack trace he gives us:

Traceback (most recent call last):
  File "/home/piku/.piku/envs/wikdict/lib/python3.11/site-packages/flask/app.py", line 1511, in wsgi_app
    response = self.full_dispatch_request()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/piku/.piku/envs/wikdict/lib/python3.11/site-packages/flask/app.py", line 919, in full_dispatch_request
    rv = self.handle_user_exception(e)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/piku/.piku/envs/wikdict/lib/python3.11/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/piku/.piku/envs/wikdict/lib/python3.11/site-packages/flask/app.py", line 902, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/piku/.piku/apps/wikdict/wikdict_web/lookup.py", line 119, in lookup
    if r := get_combined_result(lang, other_lang, query):
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/piku/.piku/apps/wikdict/wikdict_web/lookup.py", line 91, in get_combined_result
    conn = get_conn(lang + "-" + other_lang)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/piku/.piku/apps/wikdict/wikdict_web/base.py", line 103, in get_conn
    raise sqlite3.OperationalError(
sqlite3.OperationalError: Database file "/home/piku/.piku/data/wikdict/dict/en-ko.sqlite3" does not exist

Assuming that is related to a user input this could just be

Error: Database file "/home/piku/.piku/data/wikdict/dict/en-ko.sqlite3" does not exist.

Even better to give suggestions on how the user might want to fix that problem. Everything else in that stack trace is useless noise that looks scary and takes far more time to parse and get the useful into to users of the program. Stacktraces are just as bad as not adding context to input/environmental errors, maybe only marginally better for the developer. But no user should EVER see a stacktrace and IMO any stacktrace seen should indicate a bug in the application. They are a developers tool, not a way to show users an error message.

Don't be lazy and add context and print out your errormessages in a way that is useful to the users of your application. A stacktrace is not that.

And on the side of stacktraces, they can be more noisy then necessary even for a developer. Here span traces can be useful to find the source of an error without needing to print out the current stack trace which is often vastly less useful in async contexts or other things that are not strictly a straight forward nested call stack.

Also if you are looking for a replacement for find that is not a full tui then take a look at fd which works more like what the author expected from the find commad - fd <pattern>.

What isn't associated with cancer? You can probably find a study on most things that have a link to cancer. If not chances are it just has not been studied yet.

The common-knowledge number seems to be about 70% of open source projects are under the GPL and (more importantly) many of the most crucial and successful ones are.

I am calling bullshit on that number. The vast majority of libraries in modern languages are under far more permissive licences, MIT, Apache2, etc. So most libraries for python in pip, rust in crate.io, node in npm, golang modules etc Which makes up a huge amount of software projects. These are languages and libraries used by companies for their own closed source products or tooling for these langauges and a huge amount of success for these is due to their permissive licenses. Companies would not touch GPLed libraries in the same way which would drastically reduce the amount these sources are used and thus their overall contents.

If you only look at the linux desktop you might see more GPLed software, but that is not the majority of opensource software. I don’t know the real percentages of everything, but 70% is a made up number. I would not be surprised if it was 70% being under a permissive license.

Once had a missing semi colon at the end of a c header file. The compiler kept complaining about the c file and never mentioned the header. Not all errors lead you to the right place.

Though most of the time people just don't read them. The number of problems I have solve for people by just copy pasting the error they gave me back to them...