ircdHybrid: 8.2.22 -> 8.2.24

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/ircd-hybrid/versions.
These checks were done:

built on NixOS
ran ‘/nix/store/ggb89l411451a7f99590qx4l374kjgbr-ircd-hybrid-8.2.24/bin/mkpasswd -h’ got 0 exit code
ran ‘/nix/store/ggb89l411451a7f99590qx4l374kjgbr-ircd-hybrid-8.2.24/bin/mkpasswd --help’ got 0 exit code
ran ‘/nix/store/ggb89l411451a7f99590qx4l374kjgbr-ircd-hybrid-8.2.24/bin/ircd help’ got 0 exit code
found 8.2.24 with grep in /nix/store/ggb89l411451a7f99590qx4l374kjgbr-ircd-hybrid-8.2.24
directory tree listing: https://gist.github.com/f272ead9b6591f5ffe113885b6151952

Success on x86_64-linux (full log)
Attempted: ircdHybrid
Partial log (click to expand)
shrinking /nix/store/ggb89l411451a7f99590qx4l374kjgbr-ircd-hybrid-8.2.24/lib/ircd-hybrid/modules/autoload/m_who.so
shrinking /nix/store/ggb89l411451a7f99590qx4l374kjgbr-ircd-hybrid-8.2.24/lib/ircd-hybrid/modules/autoload/m_whois.so
shrinking /nix/store/ggb89l411451a7f99590qx4l374kjgbr-ircd-hybrid-8.2.24/lib/ircd-hybrid/modules/autoload/m_whowas.so
shrinking /nix/store/ggb89l411451a7f99590qx4l374kjgbr-ircd-hybrid-8.2.24/lib/ircd-hybrid/modules/autoload/m_xline.so
gzipping man pages under /nix/store/ggb89l411451a7f99590qx4l374kjgbr-ircd-hybrid-8.2.24/share/man/
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/ggb89l411451a7f99590qx4l374kjgbr-ircd-hybrid-8.2.24/lib  /nix/store/ggb89l411451a7f99590qx4l374kjgbr-ircd-hybrid-8.2.24/bin
patching script interpreter paths in /nix/store/ggb89l411451a7f99590qx4l374kjgbr-ircd-hybrid-8.2.24
checking for references to /build in /nix/store/ggb89l411451a7f99590qx4l374kjgbr-ircd-hybrid-8.2.24...
/nix/store/ggb89l411451a7f99590qx4l374kjgbr-ircd-hybrid-8.2.24

Success on x86_64-darwin (full log)
Attempted: ircdHybrid
Partial log (click to expand)
/nix/store/5lkrw9dnsgy62qm1ampvww1c5n1pdm4b-coreutils-8.29/bin/install -c -d /nix/store/hmi6avwd88kgxy0d3xydbjdkrhvxkxzc-ircd-hybrid-8.2.24/var/run
make[2]: Leaving directory '/private/tmp/nix-build-ircd-hybrid-8.2.24.drv-0/ircd-hybrid-8.2.24'
make[1]: Leaving directory '/private/tmp/nix-build-ircd-hybrid-8.2.24.drv-0/ircd-hybrid-8.2.24'
postinstall
post-installation fixup
gzipping man pages under /nix/store/hmi6avwd88kgxy0d3xydbjdkrhvxkxzc-ircd-hybrid-8.2.24/share/man/
strip is /nix/store/kdff2gim6417493yha769kh00n63lnrw-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/hmi6avwd88kgxy0d3xydbjdkrhvxkxzc-ircd-hybrid-8.2.24/lib  /nix/store/hmi6avwd88kgxy0d3xydbjdkrhvxkxzc-ircd-hybrid-8.2.24/bin
patching script interpreter paths in /nix/store/hmi6avwd88kgxy0d3xydbjdkrhvxkxzc-ircd-hybrid-8.2.24
/nix/store/hmi6avwd88kgxy0d3xydbjdkrhvxkxzc-ircd-hybrid-8.2.24

Success on aarch64-linux (full log)
Attempted: ircdHybrid
Partial log (click to expand)
shrinking /nix/store/7nk1y8ymkcp49zdpx8k8y5zhijhlr9lk-ircd-hybrid-8.2.24/lib/ircd-hybrid/modules/m_die.so
shrinking /nix/store/7nk1y8ymkcp49zdpx8k8y5zhijhlr9lk-ircd-hybrid-8.2.24/lib/ircd-hybrid/modules/m_bmask.so
shrinking /nix/store/7nk1y8ymkcp49zdpx8k8y5zhijhlr9lk-ircd-hybrid-8.2.24/bin/ircd
shrinking /nix/store/7nk1y8ymkcp49zdpx8k8y5zhijhlr9lk-ircd-hybrid-8.2.24/bin/mkpasswd
gzipping man pages under /nix/store/7nk1y8ymkcp49zdpx8k8y5zhijhlr9lk-ircd-hybrid-8.2.24/share/man/
strip is /nix/store/j7d4mr0ikv974ig7yzhknpsq288js4bs-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/7nk1y8ymkcp49zdpx8k8y5zhijhlr9lk-ircd-hybrid-8.2.24/lib  /nix/store/7nk1y8ymkcp49zdpx8k8y5zhijhlr9lk-ircd-hybrid-8.2.24/bin
patching script interpreter paths in /nix/store/7nk1y8ymkcp49zdpx8k8y5zhijhlr9lk-ircd-hybrid-8.2.24
checking for references to /build in /nix/store/7nk1y8ymkcp49zdpx8k8y5zhijhlr9lk-ircd-hybrid-8.2.24...
/nix/store/7nk1y8ymkcp49zdpx8k8y5zhijhlr9lk-ircd-hybrid-8.2.24


Should rez env inherit all variables from the parent rez environment?

Need an option to not inherit undefined variables from parent environment.
Motivation
Here's an example, I have 2 packages: PySide2 and maya
In PySide2:
env.PYTHONPATH.append('{root}/site-packages')
In maya:
env.PATH.append('{this.root}/bin')
I first do 'rez env PySide2' to open a gui, then in this gui I will click maya icon to open maya by executing 'rez env maya -- maya'.
In the final environment, the PySide2 dir still exists in PYTHONPATH and maya crash(I know it's because I used a different version of PySide2). Currently I have to add a new line in maya package.py
env.PYTHONPATH.append('a not existing path')
Then in final environment, the PySide2 dir will not exist in PYTHONPATH
This is just an example and will be dangerous in other cases. Actually I hope each rez env is based on the clean environment at beginning.
Is there any way to avoid inheriting variables from parent rez environment?

What platform are you on? rez does try its best to isolate its own environment from the environments it resolves as way as nested resolves. However it does not simply wipe all environment variables. It only resets environment variables that are touched by any package of the resolve. So if any package in your nested resolve edits PYTHONPATH then it will be reset. If not it will be left alone. Here is also a bit of information in the Wiki: https://github.com/AcademySoftwareFoundation/rez/wiki/Configuring-Rez#parent_variables

I'm using CentOS8, python 3.6(from system), rez 2.112.0.
Here's my test process:

set env:
rez-env python-3.9 PySide2-<IP_ADDRESS>
open a gui which contains a maya icon
click the icon then open maya using subprocess
rez-env maya-2022 -- maya

In this case, maya will try to launch under wrong PYTHONPATH and fail.
Is it possible to record the initial (before rez-env) environment under tmp, and then use that original environment as parent during each nested resolves?

I'm using CentOS8, python 3.6(from system), rez 2.112.0.
Here's my test process:

set env:
rez-env PySide2-<IP_ADDRESS>
open a gui which contains a maya icon
click the icon then open maya using subprocess
rez-env maya-2022 -- maya

In this case, maya will try to launch under wrong PYTHONPATH and fail.
Is it possible to record the initial (before rez-env) environment under tmp, and then use that original environment as parent during each nested resolves?

rez has no way to really know what your intent is. I think what you are looking for is patched requests. (rez-env --patch) This takes an existing resolve and changes it. From the docstrings:

New package requests override original requests based on the type - normal, conflict or weak. So ‘foo-2’ overrides ‘foo-1’, ‘!foo-2’ overrides ‘!foo-1’ and ‘~foo-2’ overrides ‘~foo-1’, but a request such as ‘!foo-2’ would not replace ‘foo-1’ - it would be added instead.

Note that requests in package_requests can have the form ‘^foo’. This is another way of supplying package subtractions.

Any new requests that don’t override original requests are appended, in the order that they appear in package_requests.```


Investigate other themes

Had a quick look at Krabi which I saw being spoken well of. It costs $150, not entirely sure if it solves our problems better than what we have. We'd likely need to customise it still.  Not to say it isn't useful, but I need some criteria to choose, and I don't currently remember what those were...

Criteria being, including drop down and carousel etc so you don't have to spend so much time customising it @wu-lee

Ok. Drop down may be done now.  Carousel seems to be something one of the JS components in the theme might be able to do, but it comes with very little documentation. tiny-slider.js - it's just plonked in there, it may be this, but I'm not sure as it's not installed the usual way:
https://github.com/ganlanyuan/tiny-slider
I'm deferring this job, however, in favour of getting other things sorted out.
So overall, I think we've invested a lot in this theme, and the time needed to getting another theme working may blow our budget.


crockford.json: Enable requireSpaceBeforeObjectValues

Hey there,
I believe this rule is missing. Pretty sure Crockford always puts at least one space between the colon and the value.

Hey @jacksonrayhamilton. Thanks for contributing! Can you provide a few references to prove that this should be added to the crockford preset? Folks are pretty touchy about this preset, so we need to make sure the addition won't start a war :)

Crockford uses this style in a code example on his Code Conventions page. However, he does not mention whether one should use a space or not.
In his projects he uses the style throughout, e.g.:
https://github.com/douglascrockford/JSLint/blob/master/jslint.js#L287-L537
https://github.com/douglascrockford/JSON-js/blob/master/json.js#L388-L396
https://github.com/douglascrockford/JSCheck/blob/master/jscheck.js#L455-L467
I haven't found a single place in his code, where he is not using it. (But of course, I might have missed some.)
Therefore I think we can include the rule.

Thanks for the references @alawatthe.
We also add examples for each rule to our fixture file associated with the preset. Namely, this file https://github.com/jscs-dev/node-jscs/blob/master/test/data/options/preset/crockford.js should have additions for the new rule.
I'm also interested to see if https://github.com/douglascrockford/JSLint/blob/394bf291bfa3881bb9827b9fc7b7d1112d83f313/jslint.js#L307 breaks the tests.
Please update the fixture.

http://jslint.com/:
Try this snippet:
var a = {
    a:5
};

And you get this:
Missing space between ':' and '5'.
a:5

Coverage remained the same at 99.0% when pulling 32343e6eadfa58ab161814025469595481aca1b9 on jacksonrayhamilton:crockford.json into 69c1f72cf0d287118eb2f9edc98d3450376a820a on jscs-dev:master.

LGTM

Since next release should be 1.12 it's safe to landed

Thank you


DBeaver CE 6.0.4 - Error message and fail to launch after installation

System information:

Operating system (distribution) and version: Windows 10 Home 1803
DBeaver CE 6.0.4
Installing JRE with DBeaver / Version 8 Update 211 (build 1.8.0_211-b12) also installed
Additional extensions: No

Describe the problem you're observing:
Downloading and executing Windows 64 bit (installer + JRE), also installing JRE. Installation completes successfully. Error message when trying to start the application: The DBeaver executable launcher was unable to locate its companion launcher jar.

Steps to reproduce, if exist:
Download and run DBeaver CE version 6.0.4 Windows 64 bit (installer + JRE) including JRE. Then launch DBeaver application.
Include any warning/errors/backtraces from the logs
N/A

Seems to be duplicate of #5769.
Are you using 64-bit Windows?
Try to setup from zip archive. In some cases archive unpacking fails in installer.

64-bit Windows.
Tried uninstalling Java and reinstalling DBeaver, but no difference.
So I:

Uninstalled DBeaver again
Downloaded the Windows 64 bit (zip archive) and extracted to a folder in Downloads using 7zip
Ran the Executable, but got the following error message now:

Unfortunately, in case of zip archive you need to install Java separately.
BTW we going to replace current installer with new one after DBeaver 6.1 release (as well as bundled Java version).


Separation of the receiver from the CLI

Codecov Report

Merging #90 (78ab969) into master (318b25b) will decrease coverage by 0.37%.
The diff coverage is 84.61%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##           master      #90      +/-   ##
==========================================
- Coverage   61.94%   61.57%   -0.37%
==========================================
  Files          37       39       +2
  Lines         938      950      +12
==========================================
+ Hits          581      585       +4
- Misses        357      365       +8

Impacted Files
Coverage Δ

taskiq/cli/worker/run.py
0.00% <0.00%> (ø)

taskiq/receiver/params_parser.py
96.87% <ø> (ø)

taskiq/brokers/inmemory_broker.py
61.81% <75.00%> (-0.45%)
:arrow_down:

taskiq/receiver/__init__.py
100.00% <100.00%> (ø)

taskiq/receiver/async_task_runner.py
100.00% <100.00%> (ø)

taskiq/receiver/receiver.py
86.02% <100.00%> (ø)

... and 1 file with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

@s3rius already

But change brach to develop.


Deliver Container Image

Hey, AICoE-CI!
Please build and deliver the following git tag:
Tag: v0.10.0

Successfully built and delivered the image.
Image can be found at:quay.io/os-climate/aicoe-osc-demo:v0.10.0


Support GCE SslCertificate resource instead of using secrets

I would be nice if it was possible to use GCE SslCertificate resource instead of using secrets for certificate handling, fx. like it seems to be support with AWS:
https://github.com/kubernetes/ingress/issues/71
GCE SslCertificate resource:
https://cloud.google.com/compute/docs/load-balancing/http/ssl-certificates

It's supported. https://github.com/kubernetes/ingress/pull/291
@tonglil If you have some time, could you please add an example and mention it in the GCE readme?

/close


[FLINK-30332] HsFileDataIndex supports caching and spilling index entry

What is the purpose of the change
HsFileDataIndex is maintains in a list of treeMap(i.e. in memory), there is no problem in our 10T TPC-DS test. However, with the increase of job's data volume, the index will continue to grow, and there is a risk of OOM. We should support index data spilling and loading to avoid this problem.
Brief change log

HsFileDataIndex supports caching and spilling index entry

Verifying this change
This change added unit tests .
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no

Thanks @xintongsong for the review and fix-up~


feat(tpl): template object-store-creds to take environment variables

stuck with this bug
region = "us-west-1"
# Your buckets.
registry_bucket = "[ERROR] Template rendering failed: template: helmTpl:33:46: executing "helmTpl" at <randAlpha>: wrong number of args for randAlpha: want 1 got 1

Now Object storage creds will take environment variables if not set fall back to generate_params.toml

looks good. it could probably be cleaned up a little but LGTM

So now these env vars will override what the user puts in generate_params.toml? I think that's reasonable but it's worth asking if the opposite behavior would be preferable.
This needs a companion PR in deis/workflow to document how to use these environment variables to configure object storage.

I thought about the other way making generate_params.toml top priority but thing with that is every field has to be left blank, none of the files should say "your test goes here". So I gave envs more priority than generate_params.toml.

Apologies this PR needs some other templates to be changed like builder , registry , controller , database which sets <>_STORAGE env from generate_params.toml . Pushing again

requires https://github.com/deis/workflow/pull/240

@vdice corrected indentation

thanks, @smothiki ... code LGTM but want to ping @mboersma since he had checked this PR previously and might want to review before merge.


Python Home Config Value Relative Value

Hello,
I need to set the value in the Python/Home DefaultEngine.ini config value to be relative to the project. For example /Game/Scripts/python27. Currently it doesn't seem to support this and the editor will crash with no warning when Py_Initialize is called. What would be the best way to get this supported? Is there an Unreal Engine way of converting paths to absolute and leaving alone paths that are already absolute?
Also, is there a better way we can protect the engine from hard crashing when python isn't initialized properly?
Thank you!

If i remember correctly the engine starts with its cwd mapped to the path of the executable and does not change. What about using relative paths ?
[Python]
Home = ../Content/Scripts/....

@rdeioris that seems to work but unfortunately I am not distributing the plugin and scripts with the Engine but rather with the project. I am storing the necessary python scripts inside of the game's content directory.  Any other thoughts? I'm looking for a solution that will work for both relative and absolute paths so that this could be officially supported.

@rdeioris actually the files for PythonHome I currently have living in /Content/Scripts shouldn't live there anyhow. What I would prefer is to have them live in the Plugin directory. Is there any convention for getting the plugin directory in a config file? I've googled looking for info on any kind of tokens but I haven't found anything. What I was hoping was something like {CurrentPluginRoot}/...

No idea, i will check it soon

@rdeioris in the meantime I created a simple way to add in tokens if they aren't supported by default in Unreal. I tried to use curly braces {} but Unreal seems to strip them out. Perhaps there is some sort of token system I'm missing?


crash

https://mclo.gs/o7k6Fum

First off, this is on the wrong issue tracker. Secondly, update fabricskyboxes-interop.


Memory usage explodes during last moments of reindexing or resyncing

Usage goes back down a non-negligible amount after restart.

Previously related issue: #1133

https://github.com/BitShares/bitshares/commit/e070fa3a6ac0417096dc13965784a6ff1fa6447a


fix: coordinate identifier in README.md

In the Python example, the coordinate identifiers °N and °E were swapped.

Thanks for the correction!


Allow specifying workers to run on spot instances

This introduces a new cluster variable,
worker_on_demand_percentage_above_min, which defines the percentage
of instances that should be on-demand instances.  It defaults to 100.
But you can set it to (for example) 50, which means that the first
minimum_workers_per_az_count instances in each AZ nodegroup will be
on-demand, then half the workers beyond that will be on-demand and
half will be spot.
As a result, I expect this change to do nothing on its own, but we
could experiment with setting worker-on-demand-percentage-above-min
to different values in tech-ops-cluster-config.
Spot instances require supplying a list of allowed instance types to
use.  I picked instances based on the regex [mr]5a?d?.xlarge.  My
criteria were:

we don't need instance storage, but it won't hurt if we get some
we want instances to be at least xlarge so that we get 60 IPs per
instance
we want the memory profile of at least m5, so the c5 instances
are ruled out
we want guaranteed compute capacity, so t3 are ruled out
we don't care if we run Intel or AMD (I think?)

Much of the above is arguable - these aren't hard decisions but rather
just a way of picking something.
I think any of these instance types fit those criteria.  In terms of
on-demand pricing, m5a is cheapest and r5d is most expensive,
reflecting the fact that a) AMD is cheaper than Intel, and b) m5 has
less memory than r5, and c) instance storage carries a premium.

Rebased against latest master, and updated to remove requirement for instance storage.


FTPS_USER and FTPS_PASS (and others) required?

i tried out image ghcr.io/bfren/ftps:latest (sha256:b661eeed41e5d247bf9e09356fb14cf41d7e8150e3ca206da4adfbcba6dc3b43)
and was not able to start it.
first it claims for FTPS_USER and  FTPS_PASS variables to be given (in addition to the BF_ variables).
after setting these variables,  it claimes "13-vsftpd-conf: You must provide either an external URI or IP" .
is this the intended behaviour? are ther more variables to be set (addtional to the BF ones mentionef in the README)
probably i missused your (privat) ecosystem.
but if things work like described it would be a really convenient setup (for me).

Apologies, I know my docs leave something to be desired!  The run.sh file shows the minimum number of environment variables to get it running (it's what I use for testing): https://github.com/bfren/docker-ftps/blob/main/run.sh.
You need to define either BF_FTPS_EXTERNAL_IP or BF_FTPS_EXTERNAL_URI.  This is then used in the VSFTPD config.
Please also ensure you are using :latest from Docker Hub rather than ghcr.io - I haven't updated the GHCR images for a while due to GitHub problems.

the "run.sh" was my blueprint ...
the problem ist with the image from GHRC ...
the one from docker hub works fine.
thank you
matz
Am Di., 28. Nov. 2023 um 19:24 Uhr schrieb bfren @.***>:

Apologies, I know my docs leave something to be desired! The run.sh file
shows the minimum number of environment variables to get it running (it's
what I use for testing):
https://github.com/bfren/docker-ftps/blob/main/run.sh.
You need to define either BF_FTPS_EXTERNAL_IP or BF_FTPS_EXTERNAL_URI.
This is then used in the VSFTPD config.
Please also ensure you are using :latest from Docker Hub rather than
ghcr.io - I haven't updated the GHCR images for a while due to GitHub
problems.
—
Reply to this email directly, view it on GitHub
https://github.com/bfren/docker-ftps/issues/115#issuecomment-1830436146,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOQU6AUJDID35OJF556X73DYGYT4JAVCNFSM6AAAAAA76FCTECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZQGQZTMMJUGY
.
You are receiving this because you authored the thread.Message ID:
@.***>


Review push notifications settings for iOS

We've received a warning from Apple in our last release:

Dear Developer,
We identified one or more issues with a recent delivery for your app, "Arrival Advisor". Your delivery was successful, but you may wish to correct the following issues in your next delivery:
Missing Push Notification Entitlement - Your app appears to register with the Apple Push Notification service, but the app signature's entitlements do not include the "aps-environment" entitlement. If your app uses the Apple Push Notification service, make sure your App ID is enabled for Push Notification in the Provisioning Portal, and resubmit after signing your app with a Distribution provisioning profile that includes the "aps-environment" entitlement. Xcode does not automatically copy the aps-environment entitlement from provisioning profiles at build time. This behavior is intentional. To use this entitlement, either enable Push Notifications in the project editor's Capabilities pane, or manually add the entitlement to your entitlements file. For more information, see https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/HandlingRemoteNotifications.html#//apple_ref/doc/uid/TP40008194-CH6-SW1.
After you’ve corrected the issues, you can use Xcode or Application Loader to upload a new binary to App Store Connect.
Best regards,
The App Store Team

Basically it looks like we may need to setup push notifications for our App ID in order to appease Expo as it seems they may require it.
ACs:

Find out if Expo does indeed require a push notifications key
If Expo requires one determine if we should set up push notifications for our App ID or if we can just live with the warning

This was fixed when we decided to manage our own profiles. If it pops up again I know how to solve it, closing for now.


OverTheAir Update

I'm a bit tired of opening the Box every time I want to upload a new Firmware. So I started to implement a OverTheAir Update wich looks for a new firmware version and a corresponding version of my BIKE.CFG.
The data is loaded from an Webserver, port and path combination like http://raspberrypi:8575/ota/sensBoxBIke/. It then should try to find a <sensebox-id>-Vx.bin and <sensebox-id>-Vx.cfg. The CFG goes on the SD card, the BIN into InternalStorage the device should the load the new Firmware and restart. The Version x is to be maintained in the sketch, the update process looks for x+1.
This could also be helpful for mass deployment / update.
I would send an PR, once I'm done.

@goetzvr I saw that you are working on this feature in your senseBox-bike-Arduino/OTA branch.

What is the current state of your efforts?
Are there open TODOs?

Well in principle it works. (See https://github.com/goetzvr/senseBox-bike-Arduino/blob/OTA/README.md#upload-via-overtheair-ota)
However, I do not like the current versioning scheme which is a simple increment counter. One other issue might be to provide a simple http-Server to serve the files.
One potential TODO could be to provide a .cfg file for the local WLAN setttings.


The tab width should be resizable

The tab width should be resizable, sometimes it's too narrow to see meaningful information of the title.

Fixed in 9afa65e85b7dc02e5e759439e61db1a73715a752


add real-ip plugin failed， logs get error

2022/01/04 18:05:17 [error] 24003#24003: *79260034 [lua] real-ip.lua:103: phase_func(): need to build APISIX-OpenResty to support setting real ip, client: <IP_ADDRESS>, server: _, request: "POST /backend-auth/dept/query HTTP/1.1", host: "devapi.meomeopet.com", referrer: "http://localhost:8000/auth/department"
2022/01/04 18:05:17 [warn] 24003#24003: *79260034 [lua] plugin.lua:658: run_plugin(): real-ip exits with http status code 501, client: <IP_ADDRESS>, server: _, request: "POST /backend-auth/dept/query HTTP/1.1", host: "devapi.meomeopet.com", referrer: "http://localhost:8000/auth/department"
2022/01/04 18:05:17 [error] 24003#24003: *79260035 [lua] real-ip.lua:103: phase_func(): need to build APISIX-OpenResty to support setting real ip, client: <IP_ADDRESS>, server: _, request: "POST /backend-auth/dept/queryUser HTTP/1.1", host: "devapi.meomeopet.com", referrer: "http://localhost:8000/auth/department"
how to use  apisix-nginx-module  to  repair this problem

@ccwall3 https://github.com/api7/apisix-build-tools
you can take a look at this repo.


How to generate custom IDs?

EF7 does all the usual stuff about auto-generating auto-incrementing IDs. Now, I have some tables that require custom key generation on insert.

COMB Guids. i.e. Guids that get inserted (close to) sequentially so they don't wreak havoc with the clustered index.
One table has a custom GUID generated from the hash of some other values on the table, to ensure that the ID is consistent over all our environments.

I saw your video here, but it doesn't deal with the cases I mentioned.
How do you generate custom IDs?

Are values generated in the database, or in memory prior to insert? Also, it this an existing database, or are you using migrations to create the database from the model?

We could generate the COMB GUIDs in the database, but a good part of the reason why we chose to have GUID keys is so that we can generate them in memory and have the values available before we insert.
This is an existing database; we're migrating to EF7 from NHibernate.

@ajcvickers can you point in the right direction for using a value generator to do this.

@ajcvickers I will be most grateful for any assistance you can offer!

Bump.  @rowanmiller , @ajcvickers could you please point me in the right direction for this?

This is not very easy to do with the current bits. We need to add some sugar that will do most of the heavy lifting for you, but until we do that here are the steps to get custom value generators to work.

Implement a custom value generator. Something like:

public class CustomGuidValueGenerator : ValueGenerator<Guid>
{
    public override Guid Next() => // Logic for generating values

    public override bool GeneratesTemporaryValues => false;
}

Note that there is already an implementation to generate sequential GUID values on SQL Server (SequentialGuidValueGenerator) and this is actually the default value generator we use for GUIDs when using SQL Server.)

Extend the ValueGeneratorSelector for your provider to let EF know which properties need to use the new value generator. Using InMemory as an example:

public class CustomInMemoryValueGeneratorSelector : InMemoryValueGeneratorSelector
{
    public CustomInMemoryValueGeneratorSelector(IValueGeneratorCache cache)
        : base(cache)
    {
    }

    public override ValueGenerator Create(IProperty property, IEntityType entityType)
    {
        if (property["SpecialGuid"] != null)
        {
            return new CustomGuidValueGenerator();
        }

        if (property.ClrType == typeof(Guid))
        {
            return new SequentialGuidValueGenerator();
        }

        return base.Create(property, entityType);
    }
}

In this example the code looks for an annotation on the property (see below) and if present it will use the special value generator, otherwise it uses the sequential generator, otherwise it falls back to whatever the provider's default is.You don't have to use an annotation here; you can use whatever information makes sense (property type, name, etc.) to determine which generator to use.

Create a service provider that will use the new selector. The service provider should be created once and cached somewhere in your application. Normally EF does this for you, but when adding in a custom service you have to control it yourself.

private static readonly IServiceProvider _serviceProvider
    = new ServiceCollection()
        .AddEntityFrameworkInMemoryDatabase()
        .AddScoped<InMemoryValueGeneratorSelector, CustomInMemoryValueGeneratorSelector>()
        .BuildServiceProvider();

In your DbContext class (or in AddDbContext for an ASP.NET application) tell EF to use the service provider that you created:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder
        .UseInternalServiceProvider(_serviceProvider)
        .UseInMemoryDatabase();

Provide some metadata to tell EF that you want a value generated and how to generate it. For example:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder
        .Entity<SomeEntity>()
        .Property(e => e.SpecialId)
        .HasAnnotation("SpecialGuid", true)
        .Metadata.RequiresValueGenerator = true;
}

In this case the code adds the "SpecialGuid" annotation to the property that is then used by the selector code above. Also, for a non-key property, the RequiresValueGenerator flag should be set to true to tell EF that the property needs to have a value generated. Key properties already have this set.
Obviously, doing all this for a simple value generator is not very practical. I will assign this bug for re-triage to add some simple sugar to avoid all the selector and service provider stuff for simple cases.

@ajcvickers Thanks for that info!  Very happy to hear that COMB Guids are the default behavior for Guid keys; that will save me (and others) a lot of time and effort!
Meanwhile, I followed your example for a custom generator, but I'm missing one trick, and that is how to make the Id a function of other fields on the record.  The generator is basically operating from a static context, with no information about the object for which it is generating an Id.  Is there some way to get a reference to that object passed through to the generator, or at least to the values that it will need in order to generate the id?

@shaulbehr Is it that you want to use both some data from the entity and some static state? Or is it simply a property whose value is computed from other state in the entity? If it is the latter, then I don't think you need a value generator to do that. If it is the former, then I don't think that is possible at the moment but I am looking into how to enable it.

@ajcvickers It is generated purely from a hash of some data values on the record, nothing else.
How would you recommend we do this?

@shaulbehr Can it just be a computed property of the entity? Regardless, I have sent out PR #5423 that would allow this to work.

Thanks, I got it working using the ValueGenerator.  OOI, how would I have written a computed property?

@shaulbehr I think @ajcvickers just meant a getter-only property, that EF would ignore:
public string Hash
{
get { return ; }
}

Closing as I think we have done all the work needed here, but feel free to ask any follow up questions.

@rowanmiller I couldn't find any item on the backlog to track making it easy to set a simple value generator for a property. I was hoping we would triage this bug into that.

@ajcvickers good point, I thought we had one already on the backlog... but I couldn't find it 😄. Opened https://github.com/aspnet/EntityFramework/issues/5537.


Update reproducing.m, PTR-BCR-4

Update the PTR-BCR-4 part, Eq. 68

More details on discord!

Thank you so much @tiresias7! Preferably all communications about this Pull Request can remain here in this thread, rather than in private messages in Discord, because it will be much easier to find things that way.
I would also encourage you to do the following:

[ ] Test the equation in the "Summary" section for k = 6.
[ ] Test the equation in the "Alternate forms" section for k=6.
[ ] Expand the equation in the "Example" section and add it in a new line (with an equation number too). You can add this into the book's source code here.
[ ] Once you're done the above step, then add "LaTeX" to your resume :) Please don't send me a new copy of the resume though.
[ ]  The expanded version of the "Example" should also be tested in reproducing.m.
[ ] Once the added equation is in the book's PDF file, please show a screenshot of just that equation (not the full page) in a reply here, so that I can verify that the PDF looks good :)

If you need help compiling the book's source code, you can ask Eric Huang (ehuan2) in this thread.

@ehuan2 Can you write some advice here about how you compiled the book's source code locally into a PDF with only +10 changes?

@ehuan2 Can you write some advice here about how you compiled the book's source code locally into a PDF with only +10 changes?

Yeah so the issue that was creating a lot of changes that we don't need necessarily was the fact that my compiler created log files that looked very different because of different versions, different file systems, etc. So I just kind of ignored those changes when adding to the commit. Another thing is what you're using, I have TeXWorks installed on Windows, and that allows you to compile with lots of different stuff, which some didn't work until I compiled with just pdfLatex.
Another option is just to compile online using something like overleaf, and copying it back locally.

Hi @ndattani !
However, I'm a little bit stuck. In PTR-BCR-4, it requires k=2^(m+1). Maybe k=6 won't work for this?
Also, I'm wondering if I'm doing the right thing with Github. I first merged the current version of the whole branch to my fork, and then pushed the commits in this pull request to the patch-1 branch (I guess?). Am I doing the right thing?

Hi @ndattani ! I think I've done all the things. k=8 is really big, so I used the for-clause to avoid listing out all the products of b1,2,...,11.
I have changed the tex file. Hope it's good. I also fixed some typos on the same page - I couldn't believe it when I found that the original formula on the book has actually a typo. How did I make it last time?
Here is the formula:

Since I have done some other changes, I decided to post the whole page of pdf here.

Thank you so much for your help!
P.S. The formulas are really messy and the sum notations are unclear. I had a hard time struggling to find that the two sum notations start at different integers (1 and 0).

This is very good work all around @tiresias7 !

"P.S. The formulas are really messy and the sum notations are unclear. I had a hard time struggling to find that the two sum notations start at different integers (1 and 0)."

[ ]  I'm very impressed that you found those typos! Have you looked at "Remark 5" from the paper in the Bibliography section? That should make it clear where the indices should start and end.
[ ] By changing the starting indices to be from 0 instead of 1, the first equation in the "Example" section would have to change too. Can you make it so that all indices start at 1 (i.e. adjust the exponents accordingly)? This way the general equation in the Summary section doesn't need indices (it should be consistent that all indices start at 1 and go as high as possible, unless an upper index is explicitly stated).
[ ] For the first equation of the Example section, the a_1 and a_2 should have 1 and 2 as subscripts
[ ] The citation in the Bibliography section is showing up as a question mark. Are you able to get that fixed by compiling this way?
[ ] Please also push your .pdf file to your fork :)

@tiresias7
I'll be publishing the next version of the book soon.
If you want your name mentioned here: https://arxiv.org/abs/1901.04405 and here: https://github.com/HPQC-LABS/Book_About_Quadratization you would only need to fix the above issues so that this branch can be merged into the Master branch.

@ndattani I'm so sorry that I've left this task undone. Is it still possible for me to finish this now?

@tiresias7  yes for sure!

It has been a long way before I pick this up so it's a little hard for me to catch up. I've changed the comments for equations to be clearer and more direct. I also changed one of the formulas to become a more the readable and easy-to-check form (however very long) and check that LHS = RHS. If I'm going to do the same thing to the other formula, it would be 4 times longer than this current line, which is already 300 characters long. Should I do it or it is too long an example?

Besides this, do I also have to change the pdf file?

By changing the starting indices to be from 0 instead of 1, the first equation in the "Example" section would have to change too. Can you make it so that all indices start at 1 (i.e. adjust the exponents accordingly)? This way the general equation in the Summary section doesn't need indices (it should be consistent that all indices start at 1 and go as high as possible, unless an upper index is explicitly stated).

In my understanding, I'm going to change indices to 1. Is that right?


Added Get-AlertEntitiesEnrichment

Fixes #1037
Proposed Changes

added Get-AlertEntities playbook
contains two playbooks: one for user enrichment, the other one to consume this information and add it in the incident comments

The referenced item in this PR was another PR and not an issue. So that PR now got closed. @tianderturpijn


Please check CHEBI:27995

Hi Gareth and Steve,
Please check CHEBI:27995 3-methylbenzyl alcohol, as I need it for a a new IUBMB reaction.
Cheers,
Kristian

Hi Kristian,
Now done. Sorry it took so long!
Best regards,
Gareth


JSON Schema does not include extra fields, even after setting extra: "allow" in Config class

Bug
Output of python -c "import pydantic.utils; print(pydantic.utils.version_info())":
pydantic version: 1.5.1
pydantic compiled: True
python version: 3.7.3 (default, Mar 27 2019, 17:13:21) [MSC v.1915 64 bit (AMD64)]
platform: Windows-10-10.0.18362-SP0
optional deps. installed: []

Issue
Even though I set extra = "allow" in the Config class, the extra fields do not appear in the JSON Schema output.
Explanation
I created one model, Model, with one field, my_num. Then, in its Config class I set extra = "allow", because I want my model to accept more fields in the data than just my_num. The data I created, data, has the fields my_num, but also extra_field.
When I validate the data against the model, there is no error, which is great and expected. When I look at the instance of the model, it had both of the fields, my_num and extra_field, which is great and expected.
However, when I look at the JSON Schema, it does not include extra_field. I expected the extra fields to also be included in the JSON Schema.
Code Snippet
from pydantic import BaseModel, ValidationError, Extra, BaseConfig

class Model(BaseModel):
    my_num: int

    class Config:
        extra = "allow"

data = {
   "my_num": 5,
   "extra_field": "red"
}

try:
    my_mod = Model(**data)
except ValidationError as e:
    print(e)
# OUTPUT: no errors were outputted

my_mod
# OUTPUT
# Model(my_num=5, extra_field='red')

print(my_mod.schema_json(indent=2))

# OUTPUT: missing extra_field
#{
#  "title": "Model",
#  "type": "object",
#  "properties": {
#    "my_num": {
#      "title": "My Num",
#      "type": "integer"
#   }
#  },
#  "required": [
#    "my_num"
#  ]
#}

I also tried
I also tried replacing extra = "allow" with extra = Extra.allow.
I also tried removing  class Config: extra = "allow" and adding BaseConfig.extra = Extra.allow outside of classes.
They all give the same JSON Schema as above.
Last Remarks
This is my first time using pydantic, therefore, if I missed something in the syntax to have this work as expected, please let me know. I mostly referred to https://pydantic-docs.helpmanual.io/usage/model_config/ when trying to write the code.

I am closing this issue. I realized the output that I previously indicated that I wanted is not what I want any more. I think I understand now why applying extra = "allow" does not cause the JSON Schema to include extra fields, therefore, this is not a bug. You would not want all your data files that are being compared to the schema to start adding fields to the schema.


Functionality to have some tabs heriarchy

Would be nice to have some functionality in the package that allow us to order some of the tables: e.g. snapshot first, count second, attrition third...

this has been implemented


Failed_when instead of ignore_errors

Changed ignore_errors to failed_when so the output doesn't show in
red.

I'll test the stat module more intensively later. Sorry about that.
It passed on our initial tests.

Never mind, looks like you already took care of this.

Thanks!


Typescript dependencies missing

Prompted to install additional dependencies when running yarn start in app

Getting similar

Fixed issue with Mitch, does not seem to be a global issue

Updated the readme with instructions for

Only prompted to update expo-cli, but no dependency notification on clean install


Fix the build: Add cleo to tool.poetry.dev-dependencies

https://pypi.org/project/cleo/

Oh Thanks ! Just discovered that the build was failing due to CLEO was missing.

That broke the build :-(  Did poetry.lock need to be deleted in this PR?


[Screen Ruler] Multiple Measurements on Screen at a time (more than bounds)

Description of the new feature / enhancement
Often times when I'm measuring something in the UI, I'm trying to compare values of things (like margins).
For instance in this case with a control we're building in the Windows Community Toolkit:

I had to do a bijillion different steps to get these images...

Ctrl+Shift+M to bring up Screen Ruler
Select the horizontal tool
Get my measurement
Ctrl+Shift+S to grab a screenshot
Click close on Screen Ruler
Paste screenshot
Repeat steps 1-6

It'd be nice to be able to click the left-mouse button when the Screen Ruler is active to 'save' that measurement and keep it visible on the screen. Then I can go and measure something else to compare, switch tools to get a vertical measurement, etc... and keep clicking and placing them on the snapshot of the screen.
When I'm done I can get a screenshot (or PowerToys should just save off the buffer it has to the clipboard anyway for me) so that I can just paste it into my issue/document etc... with a whole annotated image of my various measurements.
Scenario when this would be used?
This would let me easily annotate an entire interface for comparison, critique, or review without having to do a lot of back-and-forth steps.
Supporting information
If measurements can be 'pasted' on to the image, then there should probably be a way to clear them, either right-clicking near a pasted measurement, or a clear option on the toolbar. Depends on how this works and if it's drawing to an image or actively drawing them on top of the screen.
That last part does factor into the option of continuously refreshing the image of the desktop vs. a static snapshot. Probably either make these mutually exclusive or involves a bit more work to implement this?

Well, multiple measurements feature is available, but only for "Bounds" mode, it would be really nice to see it available for all measurement modes

wondering how much effort this is, seems maybe low cost, adding to .71

is this still planned?

How many more times this is planned to be postponed? 🫠

I have a working change for this. Now I'd like to get some feedback before opening a PR.
A GIF says a thousand words, so here it is:

Essentially, I've made it work like multiple measurements for the Bounds tool - holding the SHIFT key while releasing the primary mouse button will keep the current measurement displayed instead of hiding it.
As for clipboard handling, as demonstrated in the GIF, I've made it such that all the active measurements are copied to the clipboard when there are multiple measurements. As a bonus, I've also updated clipboard handling for the Bounds tool to work in this way (it currently only copies the latest measurement even when in multiple measurement mode).
What do you all think?

@michael-hawker @ENCRYPTEDFOREVER @DracoClaw . Any thoughts on the above? Thank you :)

It took so long that I had time to fully move to Linux


Audit ES Translation of object-oriented-and-functional-programming.json

Closes #6506

@bugron I don't have so much time to review all the pull request related to spanish. Besides the process we have suggested from the spanish team is to announce in the channel for the spanish translators to review when a translator finishes a translation. I already announced there about this PR. @justinian336 thank you for your work, please when you send a PR translating to spanish announce in the channel for spanish translators.

@vtamara sorry that I forgot to announce it to the others! I'll do it next time.

Reviewed. Thanks @justinian336, good job. @bugron thanks for your work. It is possible to merge.

@justinian336 @vtamara thanks, merged.


Unnecessary counted variable in Api

These lines are unnecessary because counted is never changed from false to true.

https://github.com/sindresorhus/ava/blob/58e1c561296a409a9557ceb1c7684685404c4278/api.js#L184
https://github.com/sindresorhus/ava/blob/58e1c561296a409a9557ceb1c7684685404c4278/api.js#L187:L189

I'd remove them myself but there's some other stuff to get to. Writing it down here so I don't forget, but if anybody else wants to chime in please do :star2:

I'd like to give a try

@avivr cool!


FEDX-1479 Release gha-dart-oss v0.1.4

Pull Requests included in release:

Patch changes:

fedx_codeowners_file
FEA-4583: Support packages that don't utilize dart_dev

Requested by: @matthewnitschke-wk
Diff Between Last Tag and Proposed Release: https://github.com/Workiva/gha-dart-oss/compare/v0.1.3...Workiva:release_gha-dart-oss_v0.1.4
Diff Between Last Tag and New Tag: https://github.com/Workiva/gha-dart-oss/compare/v0.1.3...v0.1.4
The logs for the request that created this PR can be found here
This pull request can be recreated by clicking here

QA +1

[x]  CI does indeed pass

🚀 @Workiva/release-management-p 🚢

Security Insights
No security relevant content was detected by automated scans.
Action Items

Review PR for security impact; comment "security review required" if needed or unsure
Verify aviary.yaml coverage of security relevant code

Questions or Comments? Reach out on Slack: #support-infosec.


chore(DirectSum/Algebra): remove superfluous DecidableEq

Found by the linter in #10235.

Thanks! :tada:
bors merge


Make NIST PublicKeys conform to Equatable

Make NIST PublicKey's (P256, P384 and P521) conform to Equatable

Checklist

[x] I've run tests to see all new and existing tests pass
[x] I've followed the code style of the rest of the project
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary

If you've made changes to gyb files

[x] I've run .script/generate_boilerplate_files_with_gyb and included updated generated files in a commit of this pull request

Motivation:
There is really no drawback in adding Equatable conformance, as argued in #173
Modifications:

Make P256, P384 and P521's Signing and KeyAgreement PublicKey be Equatable, by...
... marking NISTECPublicKey to be Equatable and adding equals function in ECDH.swift.gyb
Add tests for these.

Result:
ALL NIST PublicKey's now conform to Equatable

As with #173, I'm marking this as Request Changes just as a visual note to myself to return to it.


Feature: Disabling wishlists

I know this was already discussed in https://github.com/Intracto/SecretSanta/issues/162 and I am sorry for bringing this up again, but I would like to know if it is open to a reconsideration.
My request and situation are similar to @ShadowXVII's.

At our organization, we don't want to use Wishlists at all: we don't want anyone even filling them out thinking that anyone will read them, and definitely don't want reminders sent (not even one) asking to fill out a wishlist.

Wishlists should be an option at the Party level, so that it can be disabled and not used at all. The emails would not mention it, nor would participants be notified

[...]

We just plain don't do wishlists. It confuses participants when they get asked to fill one out.

@tvlooy said:

Sometimes people ask for a specific feature that we don't have and won't do. If we have to add them all, our project gets bloated. The power of our solution is that it is simple and doesn't have too much knobs and buttons

If simplicity is one goal, I'd argue that an option to disable wishlists could make things much simpler for many groups. @ShadowXVII is right: wishlists (and the emails) often confuse people instead of helping them. I think this has been underestimated here.
It would be great if the party manager could simply disable wishlists. It would be an additional setting for the party manager only, who is usually more tech-savvy than other people in the group. If the cost of making things simpler for the majority of the people is one additional setting for one person only (the party manager), I think it's worthy.
I don't want to use wishlists, and currently I have to keep an eye on them (to make sure nobody is using them). I also need to check with everybody if they understood the wishlists are not supposed to be used, despite the email they received about it.
I know it's possible for them to unsubscribe, but they don't know it. And most of them will know it only after receiving the wishlist email. And when they receive it, it's too late, they are already confused. Most of them look only at the big red button, they simply ignore the unsubscribe link.
I love your work and I hope you can reconsider adding the option to disable wishlists.
Thank in advance.

If you can provide the code we will probably reconsider the feature.


HDDS-4236. Move "Om*Codec.java" to new project hadoop-ozone/interface-storage

What changes were proposed in this pull request?
Create a new module interface-storage and move Om*Codec.java (and necessary related classes) to interface-storage.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-4236
How was this patch tested?
CI

R: @elek

@elek  thank you for your review!


[qa] cleanup runflake8 and runisort & [qa] Added commit message style check

[qa] cleanup runflake8 and runisort #30
[qa] Added commit message style check #32
Closes #30
Closes #32

Duplicate of https://github.com/openwisp/openwisp-network-topology/pull/31


CFE-768 - FollowUp: Fix usage of registries.conf for OCI feature

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Unit and E2E tests
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

/lgtm

It looks good to me.

/assign @soltysh
Please can you take a look?
Thanks


State of WSL1

Your blog posts here and here shed some light on your new direction with WSL2. However there are some questions about the state of WSL1 that I am hoping to get addressed.

Is there new development being done on WSL1 or is it now in maintenance mode?
Do you intend to sunset WSL1 in the future?

I personally find WSL1 a fantastic effort that was pushing the boundaries of OS research. In comparison WSL2 feels like a copout. In your blog posts you suggest that file system performance was an issue and I have seen the same in some GitHub comments. Your blog posts do not specify if the performance improvements in WSL2 are related to what you call VolFs or DrvFs. I expect that WSL2 VolFs performance is better, but I believe that you could have improved VolFs performance in WSL1 by running it as a file system on top of a raw disk partition or a VHD rather than emulate it via NTFS. I expect that WSL2 DrvFs performance is comparable to the WSL1 one, because in both cases you have to go through the Windows file system stack and NTFS.
A well-defined future for WSL is important if you wish for platform developers to engage your product seriously. Recently I became interested and started researching the internals of WSL1 for a dual purpose: (1) to add support for WSL1 to my project WinFsp, and (2) to create a development kit for WSL1 that would let third parties write drivers for WSL1. My ultimate goal was to (possibly and eventually) develop a FUSE driver for WSL1. Obviously your announcement takes the wind out of these sails.

I am also hoping that you open up PsRegisterPicoProvider to allow third parties to write their own "library" OS'es.
The constant change of platform/API direction is IMO what contributed to MSFT's developer mindshare decline in the mid-00's. I was an MSFT employee at the time.

The honest response is:

Please use the following bug reporting template to help produce issues which are actionable and reproducible, including all command-line steps necessary to induce the failure condition. Please fill out all the fields! Issues with missing or incomplete issue templates will be closed.

The good sport response is discussion threads are left open for a while until they have run their course, in the off chance some actionable comes of it. n.b. I have never seen anyone at MSFT participate in a discussion thread on this github for the last two years (or maybe three, there were a couple of discussion-ish replies in the early days). Because, see, not a discussion forum.

@therealkenc understood and thanks for your understanding.
My hope is that even if nobody from MSFT decides to respond, the relevant people might still take notice and decide to eventually clarify the WSL1 status.

Take a look at https://mybuild.techcommunity.microsoft.com/sessions/77003 from about 18:00, the discussion of file system differences with regards to open file descriptors.
I get where @benhillis comes from when he says "we can't change this, we'd risk breaking existing Windows applications". As per discussion by @therealkenc in https://github.com/microsoft/WSL/issues/3451, and a whole host of related issues around how Linux and NT kernel handle file systems, some of these issues may not be fixable in WSL 1 without running into the app compatibility issues in Windows. The behavior is so fundamentally different that files inside WSL that live on a Windows file system cannot behave the way Linux expects them to, in every respect.
Maybe there's a solution where we get the option to mount an ext4 file system into WSL 1, so there's no conflict with the NT kernel about those files any more. Anything that relies on Linux-y behavior would need to have files in there.
If that's even remotely feasible, maybe it ends up the other way around: ext4 for most everything, with a mount point somewhere in /home/user that allows easy project file sharing between Windows and Linux.
I don't have a really clever idea on how WSL 1 would work in this scenario.
Time will tell whether this kind of heavy lift for WSL 1 is warranted. I think that'll depend on whether enterprises will adopt WSL at scale, and if so, in which version, and what features they want there.

The central arguments of WSL2 vs WSL1 appear to be that:

Full system call compatibility is hard to achieve.
File system performance is subpar in WSL1.

Regarding 1. Yes, I agree: full system call compatibility is hard to achieve. This is exactly what makes WSL1 an interesting and non-trivial project. But Linux is a finite kernel and they would eventually catch up. This is assuming that the internal funding was there, which is perhaps the real reason behind these changes here.
Regarding 2. Which file system performance? That of their root file system ("VolFs") or that of accessing Windows drives ("DrvFs")? They have not been explicit on this.
I find it likely that DrvFs (i.e /mnt/x where x: is a Windows drive) performance is comparable in WSL2 and WSL1. This is because WSL2 still has to go through the Windows file system stack and NTFS for /mnt/x file systems. (I cannot see a way around this and would love to be shown otherwise.) Also all the problems they mention in their talk about the differences between the Windows and Linux file systems will still be there.
So the performance improvements must be primarily with the root file system (VolFs in WSL1). My contention is that they could have achieved those performance improvements by writing a WSL1 disk file system on top of a raw disk partition or VHD together with a POSIX file system cache. I understand that is a non-trivial undertaking, but again this is what made WSL1 an interesting project and worth attention IMO.
Perhaps Microsoft might consider this: Do not sunset WSL1. Open source it. I find it very likely that the community will continue to build it for you.

I find it very likely that the community will continue to build it for you.

In the mean time, the community of NT kernel developers could work on making winfsp or dokany or zfs or ext23fsd or winpcap better. It is unfortunate that after 684 Windows NT kernel devs became available to work for free, those projects (and many others) didn't get more help.

I get where benhillis comes from when he says "we can't change this, we'd risk breaking existing Windows applications"

Been meaning ask over in #1529 about that part of the video.

It is unfortunate that after 684

Just voted for this!
Raees Iqbal wrote on UserVoice:

Windows Subsystem for Linux is a very awesome project. But I don't think Microsoft is going to allocate enough resources to this to meet the demands of the community. So, why not open-source it?

Can Raees Iqbal see into the future? :)

Just voted for this!

It's locked and can't be voted on AFAICT (count still 684). You probably voted on it in 2016. n.b. re-opening it wouldn't actually change the number of NT kernel developers (such as yourself! ❤ 💯) contributing to OSS projects, so it is pretty understandable why it was locked.

It's locked and can't be voted on AFAICT

I thought the behavior was somewhat weird. Once I clicked on the "Vote" button, it recognized the email address I supplied, but the vote count didn't change. I ascribed this to an aging/faulty brain and sensors attached to it, but turns out the signal was correct ("the vote count did not change") and the interpretation was wrong ("the vote count did change, you just missed it" :)

I would personally say kill WSL1 completely.   WSL 2 they are build a Linux kernel.
http://www.colinux.org/
Colinux here totally demonstrates that you can run a Linux kernel on Windows without a hypervisor.  Of course you need some windows drivers.   This could possible be just 1 linux kernel for the hypervisor and non hypervisor usage case.
Full system call compatibility is hard to achieve.
The reality from the start this was impossible to legally achieve closed source even if you could catch up.   The linux uses a lot of patented technologies that are only licensed to be used under GPLv2 behaviours of these technologies do show though to applications at times.
Multi groups have attempted Linux syscall emulation.     Reality is you want Linux syscall compatibility that is in fact correct you have to really bite the bullet and use a Linux kernel.

I would personally say kill WSL1 completely.

The earliest that could possibly happen is Jan 9th 2029. No sense fretting about it now.
The amount of resources WSL 1 will receive will be "based on user feedback" as per the presentations we have seen. Ability to run Virtualbox and VMWare Workstation has already been highlighted as important to enterprises. I can see a future where the Hyper-V hypervisor learns to "play nice" with other virtualization tech, and that in turn makes WSL 2 more compelling. Networking has been highlighted as another area that's being looked at.
I expect WSL 1 will receive diminishing resources, but not be "killed outright", as long as those big bugbear issues with WSL 2 can be handled, and enterprises adopt WSL 2.
And where we are in 2029, well, I wouldn't hazard a guess. I didn't think a Linux kernel in Windows would be a thing five years ago, never mind ten.

I can see a future where the Hyper-V hypervisor learns to "play nice" with other virtualization tech

There's been improvements as of the April 2018 update.  I haven't tested VBox or VMWare, but if they don't work already I am sure they will post haste. I had been (mildly) concerned about the scenario but turns out that's oldthink.

@therealkenc wrote:

I get where benhillis comes from when he says "we can't change this, we'd risk breaking existing Windows applications"

Been meaning ask over in #1529 about that part of the video.

I finally had the chance to review this issue.
This is of course an artifact of VolFs being based on NTFS. However I believe VolFs could perhaps have worked around this if instead of using HANDLE's to access files they were using FILE_OBJECT pointers directly. (Please note that I have not thought through this completely, but this is how I would likely approach the problem if I had to solve it in-kernel.)
The relevant code in FastFat appears to be this one: link. Oplocks make this code increasingly hard to read, but the crux is that if you have an open handle on a file under a directory and you try to rename it you will get STATUS_ACCESS_DENIED.
Notice that this is not true for memory mapped files without HANDLE's pointing to them:
Handle = CreateFileW(...);
Mapping = CreateFileMappingW(Handle, ...);
CloseHandle(Handle);
// ... use Mapping

A file that is memory-mapped like this can have its ancestor directories be renamed just fine.
Since the location of the VolFs backend storage was an NTFS directory that Windows applications were not supposed to touch, I do not get the "compatibility" argument.

However I believe VolFs could perhaps have worked around this if instead of using HANDLE's to access files they were using FILE_OBJECT pointers directly.

Yes, they need(ed) an indirection (of one sort or another, implementation detail aside). All academic at this point.

A file that is memory-mapped like this can have its ancestor directories be renamed just fine.

Yep. At least flying at 40,000 feet, an approach would be to forget all the NT reads/writes, map everything, make the WSL1 read/writes memcpies. At least for local filesystems. Maybe. But I suspect there would have to be engineering on the NT side to make it work (or make it work right), and NT changes haven't been real forthcoming over the last three years. Or that is the mostly uninformed impression from the outside, anyway.
The big thing we've lost with WSL2 is a shared MM. [We've also lost a shared network, but that's maybe a feature not a bug.] In WSL2 everything has to be marshalled with dmabufs. But you weigh that against having to rewrite Linux, I guess.

A file that is memory-mapped like this can have its ancestor directories be renamed just fine.

Yep. At least flying at 40,000 feet, an approach would be to forget all the NT reads/writes, map everything, make the WSL1 read/writes memcpies.

To clarify I did not mean to say that they could/should memory map everything. I do not think this would have been a valid approach. I was only pointing out that they could have build their own IRP's (which only require FILE_OBJECT's) to do file I/O and not rely on ZwReadFile, etc. which require HANDLE's.
Some file system namespace manipulations might still require HANDLE's. However I believe these could be done in a POSIX compliant manner through short-lived HANDLE's and the judicious use of shared/exclusive locks.

To clarify I did not mean to say that they could/should memory map everything. I do not think this would have been a valid approach.

Works in Real Linux. ;)
But yeah. Generally agree (don't disagree) with everything you said. When I wrote the linked post above I wasn't thinking mmaping everything either. The FUSE PoC thing I did marshals reads/writes.

I do not get the "compatibility" argument.

The video implies this is axiomatic.

I agree. This is not axiomatic.

I got a bit excited when i first heard that mircosoft would make use of a linux kernel with WSL. I really expected that the move was to go to open source with some parts of WSL and use the linux kernel to fix the holes in WSL.
To be honest I am pretty disappointed with this direction MS went, Obviously, it was too much to expect that we would see MS go though with this harder but much more intersting approach CS wise. IT enthusiants make nearly no markt share compared to companies. And i guess some of us got deceived about MS reasons to do such a step in the first place. MS does not love linux, it is simply that linux has become such an essential part of the IT world, that MS could not ignore it longer. A VM simply isnt new technology. Its just as MS adopting chromium (I wonder if that means that stock win10 now calls home to google). In the microsoft talk they said that this new approach takes less ram (or was it little idr). But essentially is is an VM and taken 500mb. should WSL1 take much less, especially if you run multiple instances (e.g. different OSes) at the same time. I was really waiting for the day that i could run a linux shell in WLS and have it completely integrated into win, just as good as the explorer shell. but i guess this will never come...
@therealkenc to me the way you responded to the thread seems as if you also are not happy with the way MS went, but probably because of company polices you are not allowed to express that.

@therealkenc to me the way you responded to the thread seems as if you also are not happy with the way MS went,

No I'm tickled pink. Excited. Delighted. [see thesaurus]
I was all those things about WSL1 in 2016 too.

but probably because of company polices you are not allowed to express that.

I don't work at MSFT. Pretty allowed to express whatever. Free country 'n stuff.
There are plenty of novel things that can be done with a VM approach. I am exploring one idea in particular on this otherwise quiet weekend. There is, actually, a contrarian argument that Windows integration with Real Linux is more (not less) novel. Because re-writing Linux wouldn't be novel at all, now would it. Been Done Before.

There is, actually, a contrarian argument that Windows integration with Real Linux is more (not less) novel.

I don't know. I am on macOS (I know, I know) and have been able to do this for many years now:
$ docker run -it ubuntu bash
#

That is containerization. The opposite of integration. You've been able to telnet from a Windows box to a Unix box since I dunno (checks) 1992 too. The novelty is making the experience integrated, which would have for example meant Microsoft shipping a VT340 terminal emulator with Windows 3.11. [Sadly, at the time, I was stuck with NCSA telnet.]
So, checkbox ttys (mostly, see unicode interop) coming 2020H1. Next up, filesystems and window managers. For starters.

The earliest that could possibly happen is Jan 9th 2029. No sense fretting about it now.

This is not exactly right.   Due to WSL1 still being in development it technically can be replaced.  The functionality has to remain to 2029 the solution does not have to.

Edit: I just realized I may haven taken your comment too literally. If by "kill off completely" you mean "remove the ability to run WSL 1 in some future version of Windows", not "stop supporting it entirely" then yeah, that could happen much earlier, subject to how well WSL 2 meets enterprise needs and what the uptake of each version is over the next 2-3 years.

I really did mean kill.   As in the current WSL 1 code base dies completely
Stage 1) Run WSL1 and WSL2 next to each other for a while to detect quirks.   If there are no quirks of WSL1 that users depend on that WSL2 cannot do move on to stage two.
Stage 2) colinux style version WSL2 to replace WSL1.
At stage 2 the WSL 1 we know today basically ceases to exist.   No longer needing to be maintained and syscall maintaining moved to the Linux kernel upstream so freeing up resources.
This from application point of view WSL1 is still in windows but from a implementation point of view with this part WSL1 is dead and replaced with WSL2.
This is the thing colinux has higher IO performance than WSL1 done the current way.   Ok still not as good as hyper-v version but hey that kind of expected thinking this is older kernel in colinux.
Basically now that Microsoft has bit the bullet on shipping Linux kernel they might as well use it in all places they can to give users the best performance and best compatibility.
Blackbery, Freebsd, many Unixs all have attempted the Linux Syscall wrapper solution to their native kernel all have hit roadblocks.   WSL 1 in it current form was always going to get to the point where Microsoft developers could not add the syscalls.
Yes killing off current form WSL1 and replacing it will mean WSL1 for those unable to user a hyper-v functionality will able to keep on improving in functionality aligned with WSL2.   Otherwise its going to be exactly how you said WSL1 will basically stagnate  and bit rot as it no longer gets the resources and the impossible problems remain in it for ever.
Basically lets plan to mercy kill the current WSL1 early and replace it so we don't have a bit rotten implementation.

@oiaohm I think we’re agreed, we are just talking past each other due to the inherent limitations of this medium.
Your roadmap for killing WSL 1 happens in future versions of Windows, not past ones, right?
If so, yup, could absolutely happen. We are agreed.

@therealkenc
“The video implies this is axiomatic. Usually when one says something like (paraphrased) "fixing the rename directory problem would definitely break things" ”
The way I parsed that was “if we changed the behavior of the NT kernel to allow this, we’d definitely break things”
And that I see in context of “millions of apps over several decades” - if the NT kernel is changed to make WSL happy (a niche feature) and even one app breaks that is in use by a corporation, all hell breaks loose.
I saw this as a risk management statement: “We cannot change the way the NT kernel handles files because the risk of an unknown unknown hitting us is unacceptable”
And that statement I get. There are layers of CYA before a change gets approved, and this change has no way of getting through those layers.
Or so I imagine. If MS functions like every other corporation.
Which leaves option 2, your indirection ideas. Keep NT kernel as-is, work around the problem on the WSL 1 side, while also working on all the other syscall items that need attention.
Or do what they did and change tack, let the kernel handle it. That’s a resource use decision, as in, where is time best spent.
I am with you by the way: Tickled pink about WSL 2. It could be everything WSL 1 promised to be. And it’s incredibly heartening to see that MS, when they ran into some “hard problems” with WSL 1 such as the “differently abled” file handling, didn’t just throw their hands up, but doubled down on finding a solution. Which happened to be a pivot to a different technical way of solving this because, as they stated, “hypervisors have come a long way since 2016”.
Last I tested by the way, full-fat Hyper-V did not play nice with VBox. That was on 1809. I expect they’ll find a way to “peaceful coexistence” because this is important for enterprises.

@yorickdowne

“The video implies this is axiomatic. Usually when one says something like (paraphrased) "fixing the rename directory problem would definitely break things" ”
The way I parsed that was “if we changed the behavior of the NT kernel to allow this, we’d definitely break things”

The problem is that this statement is misleading when it is used to justify the change from WSL1 to WSL2. This was not an inherent limitation of WSL1, but an artifact of the current implementation of VolFs.

Or do what they did and change tack, let the Linux kernel handle it. That’s a resource use decision, as in, where is time best spent.

I agree that Microsoft is a business and they choose how to best allocate their resources.
In any case if they kill WSL1 so be it. As a a kernel and OS guy I think something will have been lost, but I have no power to change it. I am simply asking that they come out and say: "this is our roadmap for WSL1 and this is our roadmap for WSL2".

Some great discussion here, I appreciate everybody taking the time to let us know their feedback.
I think it's important for me to call out while our deep dive went into a few specific examples, the picture is much broader and more complicated.  In fact, those examples were chosen because they were fairly simple and could be easily explained in a few minutes.  At the end of a day there are pros and cons of the driver-based approach, and pros and cons of the virtualization-based approach.  It is our feeling that the pros of WSL 2 outweigh the cons for a large percentage of our users, but as always, we are listening to your feedback.
At the end of the day, our goal has not changed.  We want to make Windows the best platform to develop on.  I'm optimistic that WSL 2 is that path forward and we have a great roadmap to making this a reality.  In the months to come we will be releasing more detail on those plans, but killing WSL 1 is not among them...

Question: Why did MS devs wait 6-7 months to show it? AFAIK, the "WSL2" showed up in build 18262. In those times, "WSL2" might become more mature.

@benhillis

In the months to come we will be releasing more detail on those plans, but killing WSL 1 is not among them...

This is good news to me. I would of course like to hear more about your roadmap, especially as it pertains to WSL1, but I am more patient than someone might gather from my posts.
Thank you for the response.

One thing that got me particularly disappointed about this move was essentially admitting that filesystem performance in windows is unfixable. We can't improve windows so here take linux. Filesystem performance (on many files) is something that has always been bothering me and i was hoping that this would get fixed one sunny day.
And using 500MB~1GB of memory for running a few command line arguments is significant overhead nontheless, compared to being unnoticeable in TaskManager in WSL1. I've run linux vm's in the past with less memory than that.
Also i can't use TaskManager anymore to kill vim if i get trapped in it :wink:
Supporting docker now is... lame in that approach, i (folks?) wanted WSL to support docker because docker for windows was a linux VM, now WSL is a linux VM, so i could have kept using docker for windows in the first place.
Also was quite fun to find my files that i was searching for with Everything inside WSL.
And while not an argument, it's technological coolness factor has dropped to zero.

One thing that got me particularly disappointed about this move was essentially admitting that filesystem performance in windows is unfixable.

Sadly this is more true than many people know.
Another (even bigger) issue is that the Windows file system is essentially "non-deterministic" in some of its namespace operations. For example, you call DeleteFile and it reports SUCCESS and yet the file may still be there. (An NTFS developer once described DeleteFile to me as follows: "DeleteFile returns success to say that it successfully told the file system to delete the file at some unknowable point in the future" [link].)
IMO Windows needs a fundamentally new approach in how it does file systems. And I do not mean a replacement file system for NTFS, I mean a new way for doing file operations where DeleteFile does what its name says.

And using 500MB~1GB of memory for running a few command line arguments is significant overhead nontheless

We'll see how that turns out (and will find out soon enough). This isn't a Type-1 hypervisor like you are (maybe) used to. MSFT wouldn't be shipping their own Linux Kernel if that were the case -- why would they. They'd tell you to spin up whatever kernel you fancy. Or FreeBSD or a Hackintosh or FreeDOS for that matter.
With WSL2 they have opportunities to use (share) Window's virtual memory (and by extension core memory) intelligently. To what extent they achieve that I can't tell you until around ten minutes after I get the update just like you. But to assume it is going to take a gig of core to spawn a bash script is, let's call it, premature.
Also worth observing that to achieve the feature parity with Real Linux, the WSL1 driver would asymptotically approach the size of the Linux kernel -- assuming a rainbow and unicorn alternate universe where every ask on this github over the last three years was fulfilled. I venture the driver is already bigger than a Linux kernel with no filesystems (save diskless nfsd) and no hardware drivers (save networking). Which is WSL1.
And the funny thing is, apart from the memory footprint, WSL2 is going to burn less CPU. Where do you think all those cycles are going struggling to make the WSL1 filesystem work.... slowly.

i (folks?) wanted WSL to support docker

"Support docker" has never been a well formed ask. The ask is: "I (folks?) want WSL to support all the Linux syscall surface."
Me too.
Docker on WSL1 works. What doesn't work right now are all the things docker containers like to do other than print hello world. Stuff like I dunno, say mounting an ext4 filesystem image on loopback.

so i could have kept using docker for windows in the first place.

For that to be a sensible conclusion, you would have to believe MSFT invested all the considerable  development effort that went into WSL2 (as noted in the video) when they could have done a one-line post that read: "For Linux on Windows, run Linux in a Windows Docker container."

Also was quite fun to find my files that i was searching for with Everything inside WSL.

You'll still be able to do that. In fact WSL2's whole shtick is that you won't be able to differentiate from the WSL1 experience. [Modulo bugs, and some edge cases.]

One thing that got me particularly disappointed about this move was essentially admitting that filesystem performance in windows is unfixable.

Maybe. Or admitting that there is a better way than trying to pound a square peg into a round hole. That plus existence real thing. And the whole "fix everything else", nvm the filesystem part. Or something.

IMO Windows needs a fundamentally new approach in how it does file systems.

Maybe. IMO what this country needs is a really good five-cent cigar.

Maybe. IMO what this country needs is a really good five-cent cigar.

If you are satisfied with five-cent cigars, you will never get to experience the $60 ones :)

I will also add that as you begin to play with WSL2 keep in mind there are lots of changes in progress. Improved memory footprint is on that list and something will get much better in the coming weeks or months. We have some changes to the the Linux kernel in progress that will make it behave much better as a guest in our hypervisor.

Where are the Linux kernel patches?

@therealkenc

This isn't a Type-1 hypervisor like you are (maybe) used to.
But to assume it is going to take a gig of core to spawn a bash script is, let's call it, premature.

I'd certainly fancy a technical explanation of how it differs, on the build talk, it sounded like basically waking a VM from hybernation (writing the kernel image directly to memory for fast startup). Also from the build talk, you can see, when he ends the VM powering WSL2, memory usage drops immediately by 0.9GB, just to show a second later: if i now open bash, it just takes a second to boot up again and you see memory consumption has risen by 0.5GB in an instant.

Also worth observing that to achieve the feature parity with Real Linux, the WSL1 driver would asymptotically approach the size of the Linux kernel

I disagree, writing a syscall wrapper around the existing kernel API is unlikely to be bigger than actually implementing it from scratch. Aside from it literally reusing all hardware drivers from windows.

You'll still be able to do that. In fact WSL2's whole shtick is that you won't be able to differentiate from the WSL1 experience.

I doubt that, Everything reads the MFT to provide instant searching across NTFS volumes. WSL2 files will live in a ext4 formatted VHDX, Everything could find the VHDX, not its contents.

Or admitting that there is a better way than trying to pound a square peg into a round hole.

I disagree completely, this is saying, stop improving windows, because it's not the right thing to do.
Improving filesystem performance is a core windows improvements that everyone would benefit from, not just WSL.

Some great discussion here, I appreciate everybody taking the time to let us know their feedback.

I'm glad you're not (yet) considering termination of WSL1.  If it's feedback, I'll give you my take.  This is based on my technical understanding of some issues I do not necessarily understand as deeply as you, so feel free to fill in what I might lack—on technical issues, not on strategy.
In the context of simply continuing WSL1 (i.e. if WSL2 hadn't come about), I would suggest the following:

Make cgroups work.  Windows has cgroups, and they're not yet mapped to WSL.  This would make docker work and, more importantly, makes systemd work.
Provide a WSL service to manage WSL.  The service creates a Windows cgroup, changes it to WSL, then runs init.  When the system is sent a shutdown syscall, it simply kills everything in that cgroup.  This allows you to install multiple Linux systems and run them side-by-side, booting at start-up as if a real VM.
Provide a /dev/auth and client library to communicate with lsass.  When logging in, pam should behave as if I'm logging straight into Windows.  This is just like sssd but without joining the WSL instance to the domain, and it also works with local users and groups on the host machine.

These things would make Linux boot, behave like a Linux machine, and have the users and groups of the host machine—even if they're domain users and groups.
So let's compare this to WSL2.
WSL1 with above enhancements:
Pros:

Network is local network
Operates like a full Linux installation
High degree of compatibility
High degree of resource efficiency
Applications run as if part of the host windows OS, in terms of network, user authentication, and domain membership

Cons:

File system compatibility issues still remain
General compatibility issues still remain
We need networking enhancements for full service compatibility (nmap doesn't work; docker services might not work at that point)

WSL2:
Pros:

It's a real Linux system with a kernel
Total compatibility
File system compatibility issues solved

Cons:

Separate VM
Additional OS overhead
Unused RAM is allocated from the host OS, consuming additional resources
Networking is separated
Authentication is separated
Tighter integration provides a place for malware to hide (not a running host system process, so is shielded from inspection by host tools; but can access file system, so ransomware can do things)

Given these, I tend to lean toward enhancing WSL1; WSL2 is an interesting approach and comes from the direction of integrating a HyperV VM more tightly.  WSL1 will always have the occasional unexpected and strange compatibility issue; WSL2 will stumble over integration issues now and then, while general compatibility will always be complete.
The degree of compatibility you've achieved with WSL1 suggests that it's actually viable and sensible.  That's a large part of why I'd lean toward the enhancements I suggested for WSL1.  You'll still have further consideration after that, which WSL2 immediately addresses:

Networking compatibility requires additional stuff
It may be interesting to create virtual network adapters and assign them to WSL1 instances, such that they get their own IP address (even by DHCP), configured by the host (ifconfig is never going to work, nor should it)
File system compatibility may involve some interesting contextual approaches, such as preventing locking for write when WSL processes have a file open (it's never locked for write in Unix), and denying open (for write?) of locked files by WSL processes (you can simply return EACCESS in any case:  Linux programs don't look at the access control system, but rather try to access and see what happens; we have additional RBAC systems that may deny access for no reason visible to the process—a program may not be allowed to know if it has access to a file until it tries to access it!).
You have volume shadow copy and can full well replace open WSL files, e.g. library and executable files, to fully emulate that behavior

The two approaches are strategically-different and carry different impacts.  WSL1 is not a VM; WSL2 is not nearly as light-weight.  Each starts with a different set of problems.  WSL1 will require significant work to be near-parity with WSL2 in terms of compatibility and workflow, although I believe it's close.

While I am compiling some code, vmmem (minimal process) and vmwp.exe take ~90% of total CPU and MEM usage. Is it normal/bydesign for WSL2?
WSL1 works fine with same workload and uses less resource than WSL2.

CPU usage sounds like a good thing when compiling, as long as that means faster compile times. Does it?
Memory - 90% of what? 8GB? Then you’re undersized. 16GB? 32GB?

I also faced random memory spikes at 90% of 32GB which seem to stop after closing wsl 2 and restarting it.

What I'd like to know is whether the recent WSL1 feature of being able to run Win32 processes from the simulated kernel will carry over into WSL2.  That's a pretty important feature to me, as I often construct pipelines with Win32 components, especially at the head of the pipeline.

@johnwcowan - yep, it already works with WSL2.

Personally I think Microsoft would benefit from incubating WSL1 and keeping it alive, while switching to WSL2 as the main/preferred platform for desktop.
 [HoloLens, Mobile Revival, Smartwatch, etc].

I sincerely hope that Microsoft continues to put effort into WSL1, especially because I am convinced that WSL1 can be faster and better integrated than WSL2, if Microsoft develops a new root file system for it that runs against disk-like storage (e.g. raw disk partition, or VHD) rather than NTFS.
As mentioned in the OP my motivation to understand WSL1 was to develop FUSE for it. I now have a FUSE driver for NTOS (i.e. a Windows driver that speaks the FUSE protocol via DeviceIoControl) and a Windows port of libfuse. The next step is to develop a FUSE driver for LXCORE (i.e. a Windows driver that interfaces with LXCORE and speaks the FUSE protocol via Linux /dev/fuse) and will likely do this if WSL1 remains alive and well.

With WSL2 they have opportunities to use (share) Window's virtual memory (and by extension core memory) intelligently. To what extent they achieve that I can't tell you until around ten minutes after I get the update just like you. But to assume it is going to take a gig of core to spawn a bash script is, let's call it, premature.

This is kind of a silly argument to be making when WSL2 has so many hoops. Like okay I can't have my code in /mnt/* so instead it's in the Ext4 mount but I can't access that from Windows so I'm running VSCode in remote mode which is itself such an insane memory hog that all the performance boosts you mentioned are essentially wiped out.
WSL is awesome cause I can pull a linux compile of say ffmpeg and maybe make a gif all on the Windows file system. Now that IO performance is gone there's very little utility left for it.
WSL1 was almost there. It could even be almost native performance wise. But WSL2 can never match that because it's a VM.

I don’t know about “WSL 1 was almost there”. The way that Windows deals with file handles meant that anything Berkeley DB or related wouldn’t run. I don’t think docker ever worked. Swift REPL never became functional. It’s a long, long list, and it all comes down to the difficulties of using a shim, on top of an OS that has some fundamental differences to Linux.
Accessing Linux files from Windows works great - ‘explorer.exe .’ or \wsl$. The latter works even when no instance of WSL is up and running.
I am glad WSL 2 is here. The things that just didn’t work in WSL 1 did not seem to get attention - I say seem because what was happening, viewed from the outside at least, was the pivot to using a full Linux kernel to solve them.
There are still use cases for WSL 1. Personally, I am getting more done with WSL 2.

My two cents on the discussion, being the author of coLinux:
I was not surprised when Microsoft took the approach with WSL2, as I've gone a similar path when writing coLinux. I've considered extending an existing project named LINE, which is more similar in architecture to WSL1. Not having the full resource of a development team, I took the easier cooperative VM approach. Re-implementing stuff is a pain. Integrating is more fun.
However I think both WSL1 and WSL2 have their added value being active projects. WSL1, is good for being more 'in the Windows domain of things' compared to WSL2, and not requiring a hardware-accelerated hypervisor behind the scenes. For WSL2, back when writing coLinux, I've imagined the things that could have been gained if I had had access to the Windows internals, especially regarding memory management. I believe that the Windows dev team has a much better chance to make Linux more compatible and smoothly integrated in a performant way with this approach.
Perhaps it's too late, but I wish that the two approaches would have had different names so to not suggest that one is entirely newer or better than the other.

Well, now, I am experiencing something in my daily job. I use WSL1 for things like ssh, use Linux terminals, and in general, bash things. WSL1 is perfect for this. I use Android Emulator and Virtual Box for a macOS VM. So for me, it is better don't have to install Hyper-V or Windows Hypervisor Platform to have WSL.
I think that WSL1 should keep evolving. I see WSL2 as a shortcut to this evolution, and for me, it is for special use cases. I see in the future that the two WSLs coexist may be renamed: WSL and WSl Pro. I don't see why in the future, WSL1 also has its ext4 file without being virtualized.
WSL1 needs time.

Let's be honest. At the point of requiring a VM you're better off just using Linux.

Not so, and that for several reasons:  Your corporate masters may require you to run Windows, and running WSL (plus Cygwin/X, if you need it) is much superior to dual-booting.  There may be programs you need to use that do not exist in Linux (the Gimp is not Photoshop, at least not on a professional level: it is what economists call an "inferior good").

@johnwcowan You guys do you. I can understand the low overhead of WSL1 comes at a painful cost in extensibility and the reasons for going the WSL2 route but a VM is the point where I say nah but thanks.

Note that that remark was invented (but not yet popularized) in about 1875.  The five-cent cigar would cost $12.79 today, allowing for the 53% federal excise tax that did not exist then.

Found this from an "Is WSL1 still being updated" search and I enjoyed the read.
Personally I use WSL1 because of the Windows-Centric integration and use the Host filesystem for coding and use WSL for compiling with MIPS Pro.
Glad that (If I read correctly) WSL is still being updated.

Glad that (If I read correctly) WSL is still being updated.

https://docs.microsoft.com/en-us/windows/wsl/release-notes#build-19013
Looking at the update page, about 98% or more of the development effort seems to go into WSL2. A few bug fixes for WSL1 showed up and the rest is cross integrations ( Windows - WSL1/WSL2 ).
But from the looks of this release information, beyond the occasional bug fixes, WSL1 is mostly a death project on Microsoft's side.
The best way to compare WSL1 is: 95% done, the last 5% is a lot of trouble, so ... lets puts all effort into WSL2. What then introduces new issues: Memory bloat, Slower startup ( plan9 windows path issues ), Constant changing IP's, Slow cross Windows/WSL copy jobs, At times slower CPU performance then WSL1 , ...  WSL2 fixes the 5% of WSL1 but it introduces a lot of new issues that will hound developers for years to come.
When you see that the WSL2 memory bloat got resolved after a year+, by simply slapping a 8GB limit on the VM, you have the feeling of the same level of care, like those WSL1 5% issues. Too hard to fix, slap something on top of it that does not fix the core issue.

Personally, those 5% matter and feel like way more than 5%. FS performance is actually decent now, Docker works, anything Berkeley DB works, Swift works, Raku works, basically all the stuff that refused to work before, now just does. Yay having an actual kernel.
It feels like a big step in the right direction. For those folk that prefer WSL 1, happily it's still around.

Personally, I really hope WSL1 still gets a bit of TLC and isn't outright dropped, even though I fully understand why WSL2 might end up being the future of the WSL story.
For my workload, the benefits of WSL1 are:

Local network is actually local network. This is the single biggest advantage by far. You can run a server or do an ssh port forward completely seamlessly. Localhost will actually be localhost. Windows applications will be able to hit the ports on localhost with no issues because there isn't any hacky network spaghetti behind the scenes desperately trying to make a VM network adapter bridge seamlessly to a Windows-land network adapter.

It works for all the tools I use in my workloads. This mainly includes vim, ssh, gcc + cmake, python, and haskell (ghci). All my other tooling (dotnet etc) runs in Windows just fine.

WSL1 starts up incredibly quickly, almost instantly. It even cold starts a bash shell significantly faster than native Powershell.

Raw IO performance is not important to my workloads. Compiling large-ish projects has always felt fast enough. I am not compiling the full Linux kernel in WSL on a regular basis. However I do still hope that NT gets the required augmentation to allow WSL1 IO performance to not be such a massive drawback for other users.

The low memory usage and pico-process task manager integration is pretty nice. Greater memory usage isn't a huge dealbreaker for WSL2 but the more lightweight the better.

So for my workloads and use, WSL2 brings absolutely nothing to the table, and in fact actually has the significant usability drawbacks with networking and startup latency. I totally respect that I could be an outlier as a WSL user, but from the feedback in this issue I suspect that I'm not. Even though WSL1 might be at 90% completion with the last 10% impossibly difficult to implement, I suspect that the current 90% of functionality is actually good enough for many, many developers.

I am very happy when WSL 2 comes and tried it with a so much enthusiasm, however I found it is not good as it is described or as good as what i expected in the end.
I worked with WSL 2 for more then one week with those issues found:

very bad performance accessing files in windows file system, which are files under /mnt/x
network issue. It has different ip under WSL2 from the host Windows, which makes it hard to use.
High memory usage.

I switched back to WSL and i felt better. I am glad that wsl will not in sunset and I hope it will be in development continuously.

Further to my earlier messages about working on FUSE for WSL1: it is almost baked. Public release will follow soon.
In the screen cap below you can see unmodified Linux SSHFS running under WSL1 and used to browse the source code of WinFuse (the project that makes FUSE for WSL1 possible). The file system is presented as the Windows drive Z: and also mounted on mnt (so you can use a FUSE file system to make a drive available to the rest of Windows).

FUSE for WSL1 is now available: https://github.com/billziss-gh/winfuse/releases

I am very happy when WSL 2 comes and tried it with a so much enthusiasm, however I found it is not good as it is described or as good as what i expected in the end.

When I watched the original presentation, the only feeling i got was: We have to try to sell that we pulled the plug and have to replace it with something that is not even innovative. Honestly WSL1 got me excited, WSL2 just brought me back to capitalist reality.


Fix issue with video durations missing

@mikekatz please review

:+1:

Merging since this isn't what's causing the test failure.


Potential bug in poll job

What if in between fetching the STH and comparing the computed STH, there are new leaves appended to the log?
This poses a risk for very active logs because in between these operations, we fetch leaves and compute the root hash. Right now, this scenario will make the code return an error that suggests the log is malicious or not correctly operating.

Removing the mirroring functionality, so closing issue as outdated