[zh-cn] sync device-plugins.md disruptions.md

content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
content/zh-cn/docs/concepts/workloads/pods/disruptions.md

/lgtm


Failed to resolve vue-toastification

System Info
@rspack/core v0.4.3
System:
OS: macOS 13.5.2
CPU: (10) arm64 Apple M1 Pro
Memory: 417.52 MB / 32.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Yarn: 1.22.19 - ~/Library/Application Support/fnm/node-versions/v18.14.1/installation/bin/yarn
npm: 9.3.1 - ~/Library/Application Support/fnm/node-versions/v18.14.1/installation/bin/npm
pnpm: 7.18.1 - ~/Library/Application Support/fnm/node-versions/v18.14.1/installation/bin/pnpm
Browsers:
Chrome: 120.0.6099.109
Safari: 16.6
Details
Failed to resolve vue-toastification package:

The browser field is quite special 🤣 but webpack can handle it:

Reproduce link
https://github.com/chenjiahan/rsbuild-repro-vue-toastification
Reproduce Steps

pnpm i
pnpm build

@chenjiahan I think you should assign this to @Boshen

get 👌

Fixed in https://github.com/web-infra-dev/rspack/pull/5047

Awesome 👍


Using lightline, the neovim welcome screen flickers out

This is a minor annoyance, but disable/enable lightline causes the welcome screen to flicker out almost instantly after booting vim.

not sure how to fix that behaviour, feel free to open a PR if you find any fixes!

Maybe the issue should remain open? I tried to look into it a while back but I couldn't figure it out either


Add a new column 'is_prior' to the dataset

closes https://github.com/asreview/asreview/issues/1599

Do we want to name the column is_prior or ASReview_prior to make it consistent with how we export to RIS files (ASReview_relevant etc)?


supercollider: fix build with libsndfile >=1.1.0

Description of changes
Add patch from supercollider/supercollider#5761 to fix supercollider build with the libsndfile update in #166374
ZHF: #172160
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

I guess this should be a part of ZHF, since it is currently failing in Hydra
@NixOS/nixos-release-managers

Result of nixpkgs-review pr 172208 run on x86_64-linux 1

8 packages built:

foxdot (python39Packages.foxdot)
python310Packages.foxdot
sonic-pi
supercollider
supercollider-with-plugins
supercollider-with-sc3-plugins
supercolliderPlugins.sc3-plugins
supercollider_scel


[planner] Use generics in SelfCollisionChecker refering to JointPathPlanner

SelfCollisionChecker is similar to JointPathPlaner, and we start to create a new struct describing common parameters of them.
As the first step of the challenge, this PR introduces generics in SelfCollisionChecker as used in JointPathPlanner.
Reference:
https://github.com/openrr/openrr/blob/52af54eaf69ad0b9152dd2d1e6000dd36c7e85a9/openrr-planner/src/planner/joint_path_planner.rs#L25-L390

Have you checked that this change does not break our closed source?

Thank you for reminding me this. Now I open another PR corresponding to this change there.


License confusion

"The mod is licensed under the MIT license with the one stipulation that the name has to be changed, the reason for this is so that we do not have to deal with code that we didn't write.
The mod itself may be redistributed in modpacks as long as these modpacks are distributed for free. No money can be made from the distribution of the mod."
Those two clauses are mildly conflicting, as that makes the project as a whole "not MIT-licensed". However, I think the latter clause has been present in MineTweaker already, so to change that we'd need to probably poke the previous contributors.

Paging @stanhebben

In past, I intentionally didn't set it to an MIT license since I wasn't sure of my plans with the code. Also, I wanted to have leverage to prevent parties such as 9minecraft to "abuse" our work just for their own profit. (in fact, I did file them a takedown notice using exactly this license as backing, and they did remove Minetweaker from the site)
To me, it's fine to use the code to build upon for other nice things, whatever those are. But I'd like to have (and keep) at least some leverage to say "hey, this is ours, you can't just use it to make a profit". Since that isn't what I made it for.
I'm open to discussion as to which direction we want this to go, and adjust the license accordingly.

@stanhebben
The problem is mostly in terms of code modification and reuse by other developers. What I mean by that is - let's say I want to incorporate parts of the CraftTweaker source code in my mod. Unfortunately, due to the non-commercial clause, this now means my mod as a whole is non-commercial, which might not be desirable (especially if the code is later used in a non-mod context). And clauses such as "you can use parts of the code but not the entire mod in a commercial context" are very iffy - a rogue party could just remove a single, irrelevant class and cal it a "part" of the code and run with the money.
For CraftTweaker in particular, my first suggestion would be to make the project MIT as a whole and instead put restrictions on usage of the project's official name. That way, websites like 9minecraft could hypothetically host the mod, but as they would not be allowed to use the CraftTweaker/MineTweaker name or brand, it wouldn't earn them the clicks they crave so much.
What do you think about that? Also paging @alexbobp as an interested party.

Or perhaps consider a modification of 3-clause BSD, which adds restrictions not just on the usage of the names of the contributors, but the usage of the name itself.

That is correct. Derived work would need to license it either under a compatible license, or ask me for a license (and if the derived work only uses a small part of the work, they'll also get it). In fact, it is incorrect to call CraftTweaker MIT licensed, since MIT is not compatible with the MineTweaker license and I can't recall being asked for it ;) .
I'll think about the suggestions. Problem is that if we implement it as such, enforcement would be harder. Are there any specific uses you (or others) may have?

Honestly? No, it's strictly ideological, mostly as CraftTweaker is an effective cornerstone of modding with many mods providing compatibility with it as the sole official way of manipulating their state for modpacks, including mods which are otherwise libre and open source. If you aren't willing to do it, I won't push, though.

I do agree with what asie said above.  You can have a properly opensourced codebase and retain control of your branding (there are many popular examples, like firefox, etc).  A proper open source license is needed to give other developers peace of mind.
Say I maintain a mod, and I take a snippet from your code... now my mod must be licensed as MIT-with-provision-A-ducttaped-on.  Now later I want to take a code snippet from a mod that is MIT-with-provision-B.  What do I get?  MIT-with-both-provisions?  Nope actually... the licenses are incompatible now, and I just can't do it.  It breaks open source, and that's why there are a small group of widely used and well known (as in, well known by lawyers, to actually be written correctly) open source licenses, and something is generally not considered open source if it's not compatible with any of those licenses.
If what you want is control of your branding, then the fact is, this is irrelevant.  Anyone can make any tweaks mod and call it CraftTweaker or whatever, and your only actual legal protection would be trademark protection.  I'm not sure if you've registered a trademark...  If not, it's worth considering if this is a major concern.  But the licensing issue keeps people from using your code in their own projects, instead.  Ultimately, the best name protection you have, and what you should really count on, is the community: we love our modders and we are quick to gang up on someone trying to deceptively capitalize on someone else's work.  If you can contribute your code to the open source community, there are those of us in the community who really care about that sort of thing and will respect you all the more for it.

I don't have definitive stance for it, I just want to make sure to consider the implication carefully before releasing everything completely open. You know, you can always assign a more permissive license, but not in the other way around if you notice it wasn't a great idea ;)

@stanhebben That is absolutely correct. It's ultimately your mod, and your decision. I guess I'm just trying to offer my personal perspective, but you put in the hours, not me.

I'd like to add, I've been working on an open source modpack, and I have been fairly strict with the definition of open source I apply.  Crafttweaker is, of course, nice to have in any pack, if I end up being allowed to use it, so I am biased here towards wanting it open sourced.
The reason I have to be strict about inclusion is to fulfill the promise of the open source modpack to users: they will be able to not only fork and modify the pack, but make any changes they want to any mods therein and publish those changes.  Also, of course, to showcase and bring popularity to those mods generously made open source.

Sure. But my work is ultimately intended to benefit the public. If putting its usage completely open provides a clear benefit compared to having its usage restricted, then I will do so. It's a matter of finding the best solution for its purpose, and I'm always glad to accept input on it.

Besides the license does allow forking and redistribution, albeit with some limitations.

If the mod has useful code, that could be useful for modders to include in their mods (which seems overwhelmingly likely), then there is a clear benefit to the community if it is properly licensed as open source.  Even if you have some github issue somewhere saying "hey if you just ask, I'll totally relicense snippets to meet your needs," most developers will just see a lack of a clear open source license and move on, for fear of long conversations that might just result in them not getting what they want anyways, which not everyone does as a hobby like asie and I do.  I can definitely say that to almost any modder who has an MIT licensed mod now, relicensing their own mod to no longer be open source will seem intolerable.
Beyond what I've said, I can only go in the philosophical direction.  There have been many writings on why people think that open source is the way to go.  Eric Raymond's The Catherdral and The Bazaar is a classic.  Perhaps asie can suggest others.  Personally, I very strongly believe that the right attitude here is "if you love it you have to let it go free."  You talk about wanting to be able to maintain leverage over what people can do with the mod.  The fundamental problem here is not what you want to use that leverage for.  You can have the purest intentions in the world, but maintaining the leverage will hamper your software's potential anyways.
You'll have to look into the philosophy and see if you can agree, but to me, it seems that there's ultimately a choice between maintaining control and reaching people.  But I think it's a deceptive choice, because the lost control is mostly an illusion.  People can fork your work and compete, but they usually won't, because maintaining code is hard.  Being the person willing to do that is a large amount of power in itself.  If someone does compete with a version of your code that you don't like and don't want to pull changes back from, it might be frustrating in some abstract way, but it doesn't necessarily have to affect your work or the userbase who prefers your version.  Ultimately, you're overwhelmingly to find that you maintain full control of the project by simple fact of the community appreciating your work, and you will have more influence if the work reaches more people.  At such a time that influence starts to drift away from you, it will probably be because you've started devoting your time to other things, and it will feel fair.

@alexbobp You're not considering Stan's threat model here. It's not "competitive forks", rather it's "people who monetize other people's unpaid work" and the feeling of unfairness.

Currently discussing with Jared if we should use the CC-BY-NC-SA (https://creativecommons.org/licenses/by-nc-sa/4.0/deed.en) for this case as it is more standard and I think should fit the bill.

It's not exactly clear to me what kinds of monetization we are talking about here...  People monetizing their own minecraft modding work is an abstract concept to me, much less someone else's

CC with the NC clause is also definitely not open source, and CC is improper to use for software source code, so that doesn't help and muddies things further

@stanhebben CC BY-NC-SA is even worse, as the "noncommercial" clause is very vague and covers just about everything remotely connected with commercial usage. (I wonder why modpack developers don't realize it more often - many of them do probably get small amounts of revenue from advertisements...)

Good point. I'll think about it further.

Like, if you want to keep the mod's binaries non-commercial for distribution, I think the best route is just to leave things as-is. Relicensing the project is a bit of a headache, and relicensing it to something more restrictive is probably pointless and could end in drama.

Relicensing to something more restrictive would result in well-justified drama, yeah.
Like asie notes, there are probably a huge amount of modpack/server admins inadvertently violating some mod's licenses because they had ads next to the pack or collected donations for their server, etc, and on the other side, you have mod devs who were probably well intentioned and didn't actually intend to be so draconian and anti-user, but the idea of not allowing commercial use sounded tempting in theory and they never talked to a lawyer or other experts before selecting a license.

I believe that this commit resolves this issue.
https://github.com/jaredlll08/CraftTweaker/commit/6592b96f45d71c899d62cf96dba161fb38f7d941

just fyi, the license mentioned in the readme is now different than the one in readme.md :0


Externalize existing documentation page

Externalize source code snippets
Import source code snippets in docs
Add ability to generate HTML from it via Asciidoctor
Change documentation to reflect different plugin behavior

I was thinking to use GitHub Pages for this. We can store the sources of the documentation in this repository directly. See https://help.github.com/articles/configuring-a-publishing-source-for-github-pages/#publishing-your-github-pages-site-from-a-docs-folder-on-your-master-branch
cc @eriwen
What do you mean by

Change documentation to reflect different plugin behavior

I was thinking to use GitHub Pages for this.
That was the plan. It's also what I do for all of my open source plugins.

Change documentation to reflect different plugin behavior
For example:

Any change to the DSL that needed to happen because we are not using the software model anymore.
Removal of plugins that existed before (like the CoffeeScript plugin).
Any other difference in behavior from how the plugin worked before e.g. that you cannot add custom source sets for Twirl (explicitly feature of the software model).

Implementation:

https://github.com/gradle/play/blob/master/buildSrc/src/main/kotlin/com/playframework/gradle/UserGuidePlugin.kt
https://github.com/gradle/play/tree/master/src/docs


Transferring the project named Elemental on PyPI

I have a Python project called Elemental which I'm trying to publish to PyPI (Python's package index), but I've hit a hurdle.
There's currently an empty/invalid project on PyPI with the name "elemental" which looks to have been created by @primalmotion in 2016. I'm guessing that the aporeto-inc/elemental project might have some historical connection to that, hence this ticket.
Because there is an empty/invalid project using the name "elemental" on PyPI, we can't publish our project to PyPI with that name. More info at red-and-black/elemental#1.
When naming our project we searched PyPI for an existing project called "elemental", and no project with that name appeared in the search results, so we didn't think we'd have a problem using it. We've since concluded that empty or invalid projects don't show up in the search results :slightly_frowning_face:
Our project (https://github.com/red-and-black/elemental) is ready to be published, has 100% test coverage, and is fully documented (https://elemental.readthedocs.io).
We're really excited to share it with the Python community, and the only thing standing between us and doing that is being able to publish it to PyPI.
We haven't been able to reach @primalmotion, so we created a PyPI support ticket (pypa/pypi-support#620) to have the name "elemental" made available for our project. That request was approved, but we've also found out that it's possible that it will take months to be completed.
@primalmotion, can you pretty-please help us get our project onto PyPI without having to wait months for the PyPI admins to do the name transfer? All you'd need to do would be assign the "elemental" name to PyPI user @countermeasure or @GeneralStrike.
You'll save us a long wait if you do and we'd really appreciate it :slightly_smiling_face:

@primalmotion Pinging you to draw your attention to this issue in case you missed it a few weeks ago when it was created.

The PyPI admins have transferred ownership of the Elemental package name to us, so this issue is now redundant.


Authentication Header, Interceptor & Refresh Token

I have sat and Googled & GPT, and trawled through a lot of issues here.
I'm looking for a way to be able to send my Bearer Token with every API call. And should I get 401 or 403 back, it has to send its Refresh Token and a new token, then try the call again before it completely fails.
I have a Dio Interceptor that does this, but I'd like to use this package rather than making one myself.
class AuthenticationInterceptor extends Interceptor {
  final Dio _dio;
  final String _apiBaseUrl;

  AuthenticationInterceptor(
    this._dio,
    this._apiBaseUrl,
  );

  @override
  onRequest(RequestOptions options, RequestInterceptorHandler handler) async {
    // Retrieve the authentication token from local storage
    final authenticationToken = await LocalAuthenticationTokenIsarService.get();

    // Extract the access token from the authentication token
    final accessToken = authenticationToken?.accessToken;

    // Add the access token to the request header
    options.headers['Authorization'] = 'Bearer $accessToken';

    return handler.next(options);
  }

  @override
  onError(DioException err, ErrorInterceptorHandler handler) async {
    // Check if the response status code is 401 (Unauthorized) and it's not the login request
    if (err.response?.statusCode == 401 &&
        err.response?.requestOptions.path != authenticationLoginUrl) {
      // Retrieve the authentication token from local storage
      final authenticationToken =
          await LocalAuthenticationTokenIsarService.get();

      // Extract the refresh token from the authentication token
      final refreshToken = authenticationToken?.refreshToken;

      // If a 401 response is received, refresh the access token
      String? newAccessToken =
          await _getAuthenticationToken(_dio, _apiBaseUrl, refreshToken ?? '');

      if (newAccessToken != null) {
        // Update the request header with the new access token
        err.requestOptions.headers['Authorization'] = 'Bearer $newAccessToken';

        // Repeat the request with the updated header
        return handler.resolve(await _dio.fetch(err.requestOptions));
      }
    }

    return handler.next(err);
  }
}

Future<String?> _getAuthenticationToken(
    Dio dio, String apiBaseUrl, String refreshToken) async {
  try {
    // Send a request to refresh the access token using the refresh token
    final response = await dio.post(
      '$apiBaseUrl$authenticationRefreshUrl',
      data: {'refreshToken': refreshToken},
    );

    // Check if the response status code is 200 (OK)
    if (response.statusCode == 200) {
      // Parse the response to get the new authentication token
      final AuthenticationToken authenticationToken =
          AuthenticationToken.fromJson(response.data);

      // Update the local storage with the new authentication token
      await LocalAuthenticationTokenIsarService.addUpdate(authenticationToken);

      // Return the new access token
      return authenticationToken.accessToken;
    } else {
      await LocalAuthenticationTokenIsarService.delete();
    }

    // Return null if the response status code is not 200
    return null;
  } catch (error) {
    // Handle any exceptions or errors that occurred during the process
    logger.e('Error refreshing authentication token: $error');
    // You may choose to rethrow the error, return a default value, or handle it in another way
    return null;
  }
}

Can I make an Interceptor for this package? Or use Dio as the default instead of HTTP with this Interceptor for Flutter_Data?
I'm missing some code that works, when I look at examples it's too old and doesn't work.  Could use some help :D
But the case is, as I said, send the token along in the header, if 401 or 403 then refresh the token and try again. Otherwise, error.
Help ;)

Have you found a way?
First thing that comes to mind (pseudo code), in your overridden adapter:
@override sendRequest() {
 try {
   super.sendRequest();
  } catch (401) {
    // refresh token
    super.sendRequest();
  }
 }

There's probably a more elegant way to do it, I could sit down and have a closer look soon.

I have not.

That's one way to do it. Great to hear it's working for you!