1. 2

    BTW, this is clearly, not an up-to-date Linux kernel coding style (see a direct link above/below), but a SLURM coding style, based on an abridged version of the former.

    1. 1

      The original still contains the same glory though, it is just in a more verbose manner ;-)

    1. 3

      … or one can simply link to the source ;^)

      1. 1

        True, my bad ;-).

        edit: .. but still the same glory in a more verbose manner.

      1. 4

        This is still pure gold. To the point and full of sarcasm.

        1. 1

          Nice work. Do you plan to keep the filter updated on list changes?

          1. 1

            I might publish an updated one in a year or two, but the most frequently used passwords tend to be simpler and don’t change often.

            1. 1

              Ok, cool. As an idea, depending on how you build the filter, you could automatically rebuild it and release an updated version based on changes to the list or just on a fixed interval maybe.

              1. 1

                It could be more scripted / automated, but I’d probably schedule it manually since the master list is ~20gb.

                It’s very easy to cut a new release though - just point the data prep script at the master file and it’ll regenerate the bloom filter.

          1. 1

            Nice read, what exactly happens if there are multiple drivers claiming device support? Will it be a first come first serve kinda situation?

            1. 4

              First come first serve. If a device is already paired with a module, the driver’s probe() function is skipped [1]. As a side effect of being part of the kernel image, builtin modules get the first shot at it. Of the builtins, the order they’re served is the order in which they’re linked in to the kernel [2].

              [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/base/dd.c#n943 [2] https://lwn.net/Articles/260856/

            1. 3

              I planned to learn the basics / essentials of awk, but life had different plans and I need to fix some production impairing db issues. But maybe there is time on Sunday, anybody has some good resources to look into?

              1. 4

                Flutter is really nice, at least for an inexperienced mobile developer as I am, but Dart the language is not so awesome. I understand Google wants to have full control over an ecosystem, especially after their adventures with Java and Oracle, but I just wish there would be something else than Dart for Flutter.

                1. 2

                  What is it that you don’t like about Dart?

                  1. 4
                    • Dart promises strong type system, but some type errors are thrown in runtime step instead of compilation step, while in other languages, even older ones like C++, the same class or errors are caught in compilation step.

                    • Types are optional instead of mandatory; it’s possible to just skip type annotations and use dynamic which is like void*, or it’s possible to just don’t specify the type at all, which has the same outcome I think (the ‘dynamic’ type).

                    • Public/private fields are specified only as a naming convention instead of being supported by the language. I.e. private fields are named with an underscore before the name. I mean, if something has its own convention of doing things the right way, then maybe a new language should have support for it? I get that Dart is not really new, but it’s not old either.

                    • (this is pretty subjective, but still) It uses <type> <variable_name> notation instead of <variable_name>: <type> (postfix) notation, which makes it feel that type inference was not a part of the original design document, but was hacked at some later stage (but I haven’t researched if that’s the case),

                    the arguments come all the way down to some pretty subjective and not very important things (like that I have to write void main :P, or when I declare int main and return error code, Dart silently ignores this and returns 0 to the shell instead), that bothers probably only me, so I’ll skip them.

                    1. 3

                      Public/private fields are specified only as a naming convention instead of being supported by the language. I.e. private fields are named with an underscore before the name.

                      FWIW, Python also works this way, and I really like it. It’s what I call (or maybe I’ve heard it called) the “we’re all adults here” approach. Languages that strictly enforce private vs public have a problem sometimes where a library author makes something private that you want to use, and you can’t get at it. With a convention you can indicate something is supposed to be private, but users can still access it if they decide they need to.

                      1. 1

                        I understand your point of view, but I respectfully disagree with it. Normally private parts of a library is not an API, and by using it you’re increasing the risk of your project not being compatible with future versions of the library, so you’re limiting yourself. If your project is massively popular, up to the point that its popularity surpasses the popularity of the library, using libraries private fields can limit the development of the library itself; the author will no longer be able to introduce all changes to its internal wiring because you’re depending on specific behavior of its internal wiring.

                        Reading about Microsoft’s adventures in providing backward compatibility in Windows is a good source of information why the “we’re all adults here” can be problematic in the long run. They have to emulate their own internal structures that were never APIs, because lots of “clever” application programmers of big and popular applications used parts of Windows that were basically private fields or methods.

                        Lots of languages do allow the user to use private fields if there’s absolutely no choice, i.e. Java allows to use reflection to use private fields. And by using reflection at least you’re forced to check if the thing you’re trying to use actually exists, because it very well might be removed in some new library version, without notice from the author.

                        1. 1

                          Just to clarify, Dart’s language visibility (public vs library-private) is not simply a naming convention but enforced by the compiler toolchain, static analysis, vm runtime etc. Note that Dart’s concept of ‘private’ is library-private, not class-private. That is to say that private API is visible to all code within the same library: a source file plus any other source files making up that library via ‘part of’ directives.

                          See section 6.2 of the spec for details.

                    2. 1

                      For me it’s more the fact that there are several good options available already. I do not see any reasons to introduce yet another language into the current mix. Why didn’t they just go Typescript for example?