I want to know how to change "engine-path" in 'InfluxDB' version 2.X or later.
How to change "engine-path" in 'InfluxDB' version 2.X and higher?
The OS is Windows.
I read the document of "InfluxDB".
"engine-path" modification method "influxd --engine-path=~/.influxdbv2/engine".
The modification of "influxd --engine-path=D:\influxdb\disk" was successful.
However, restarting "InfluxDB" or rebooting the PC will restore the default value.
I want to maintain the modified "engine-path".
Related
I use TOSVersion.ToString function (uses SysUtils) to detect Windows version. However this is what I get in Windows11:
Windows 10 (Version 10.0, Build 21996, 64-bit Edition)
Is there any reliable way to detect Windows 11? I'm using Delphi 10.3.3.
UPDATE: Windows 11 is officially released and I tried again.
Here is what I get:
Windows 10 (Version 10.0, Build 22000, 64-bit Edition)
As Remy pointed out: using the WinAPI you risk of being in some compatibility mode, resulting in getting a version reported that is lower than the actual.
One alternative is to check the file version of expected files, i.e.
%windir%\system32\ntoskrnl.exe or
%windir%\explorer.exe
using GetFileVersionInfo() and VerQueryValue() - the HiWord(dwFileVersionLS)
should be 22000 or higher (according to Windows NT build/release number).
Another is to look in the Registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ at the text values CurrentBuild and CurrentBuildNumber, checking if the highest of both is 22000 or higher.
David already wrote a detailled answer in Checking Windows version on W10 with even more alternatives, although concentrating on the high/low version numbers, not the build. But WMI might help.
(This only works in retrospective with confirmed knowledge.) Check which API exports are available: the idea is that specific functions were introduced with specific Windows releases/versions, so if importing fails for one you know you're on a version below. An outdated example and an outdated list of minimum versions per function will give you an idea. Now you "only" have to find out which new functions are introduced with Windows 11.
Those are all not bulletproof, but you could combine them and then draw conclusions. And after all that you can still try your approach to parse texts instead of relying on numbers only. It also shows how easily you can manipulate your system into reporting different versions as per which method is used.
Official major version number for Windows 11 is 10.
The official build number for the public preview of Windows 11 is
10.0.22000.168
Earlier builds:
10.0.22000.71
10.0.22000.65
10.0.22000.51
Microsoft Windows 11 FAQ
If you want to detect Preview versions, earliest build number was 10.0.22000.51 Windows 11 version history
TOSVersion relies on some hard coded names and logic to return OS name. You will have to implement your own detection, copy and modify TOSVersion record or make wrapper around it, where you can use existing logic for older versions and implement check based on Windows 11 build number to detect Windows 11.
For other general issues and approaches in detecting OS version you can refer to AmigoJack's answer
Except the very weak, atleast for me, solution of considering Windows 10 builds greater than 22000, such as Windows 11, the only solution I found which is actually working is the WMIs Win32_OperatingSystem class - Caption property.
On my dev Win10 machine, it gives the following string: Microsoft Windows 10 Pro.
On my another dev machine, with Win11 installed, the same function gives: Microsoft Windows 11 Pro.
The difference is in string values - "10" vs "11"- but this is at least something far better than the "build greater than" solution.
C# and C++ work well.
The simplest way is to get the version of Kernel32.dll and if Major Version is 10 and Build Version is >= 22000 then you have Windows 11.
See my code here: How can I find the Windows product name in Windows 11?
Let’s imagine I have an iOS app. In version 2.0, I added a bunch of new features, but to implement them, I had to drop support for an older iOS version which is still in heavy use (remember, it’s a hypothetical scenario).
Later, I discovered a super critical bug in version 1.0 of my app that needs to be patched.
What are my options in terms of distribution?
It seems that it’s not possible to release version 1.0.1 if version 2.0 is already on the App Store. Adding back support for the older iOS version and fixing the bug in 2.0.1 is not feasible because that would require removal of the new features.
The problem here is that I can’t think of a way you could submit a version that updates version 1 without letting your version 2 users download it. So if you want to update version 1 you will just have to bite the bullet and meld your versions together. Use availability so that the new features are not present for your version 1 users.
I am running gitlab-ce in docker containers. I am currently using version 10.5.4. I want to update because of a few bugs with kubernetes in this old version.
Reading the documentation Here the advice is to "first upgrade to the latest available minor version within your major version."
But reading other docs Here says I should update through each minor version. Is that just to avoid downtime?
What is the simplest Upgrade path for me to 11.8, if we're not too worried about downtime?
For anyone else reading it, the quote from the first link is:
We recommend that you first upgrade to the latest available minor version within your major version. By doing this, you can address any deprecation messages that could change behavior in the next major release.
Based on the table below that, the GitLab upgrade path would be 10.5.4 -> 10.8.(latest), fix the deprecations, then 10.8 -> 11.8. The page makes clear that one can (probably) jump between any patch/minor versions without going through the intermediate steps:
It is considered safe to jump between patch versions and minor versions within one major version.
The second source is presumably the Upgrading without Downtime section immediately below the one linked in the question.
Starting with GitLab 9.1.0 it’s possible to upgrade to a newer major, minor, or patch version of GitLab without having to take your GitLab instance offline. However, for this to work there are the following requirements:
You can only upgrade 1 minor release at a time. So from 9.1 to 9.2, not to 9.3.
It then provides details on background processes required for migrations. These are substantial, so it makes sense that jumping multiple minor versions could be a bit much is not recommended. One minor version at a time for upgrading without downtime. Useful once you are up-to-date, but may be worth skipping with so many minor versions to get through.
We have a Firefox extension that was recently ported from the Firefox add-ons architecture to the "new" WebExtensions architecture, however, we have a couple problems:
There is a bug that prevents our extension from working in FF49 using WebExtensions.
We want to keep support for the old add-ons version on https://addons.mozilla.org to support customers using older versions of Firefox, including Firefox ESR, but also want to make the WebExtensions version available to those that prefer the latest and greatest browser version.
My question is: Can I have multiple versions of our extension available on http://addons.mozilla.org/ that are supported for specific versions of Firefox? i.e., Version 1 of our extension supports FF <= 49; version 2 supports FF >= 50.
Yes, you can have multiple versions of your add-on available which are compatible with specified ranges of Firefox versions. This capability has existed for years.
Within your manifest.json file you can specify a strict_min_version:
"applications": {
"gecko": {
"id": "addon#example.com",
"strict_min_version": "42.0",
"strict_max_version": "50.*",
"update_url": "https://example.com/updates.json"
}
}
However, that manifest.json key requires Firefox 45 (for WebExtensions). Specifying a minimum and maximum version for the application has been available for years for other types of add-ons. You will also need to manually manage the maximum compatible Firefox version for each version of your add-on from AMO Developer Hub.
On AMO Developer Hub, in the control panel for your add-on, select "Manage Status & Versions" (bottom option in top section of the colored left menu list):
On the page shown when you select "Manage Status & Versions", select the version you are concerned about.
On the page for each version of your add-on, you can change the Firefox versions with which the selected version of your add-on is compatible:
Note: While it is my experience that version compatibility selections will affect which version of your add-on is installed automatically, setting the maximum version will not prevent users from being offered to install, and installing, the most recent version of your add-on in versions of Firefox which are later than the maximum version specified for the most recent version of your add-on. In addition, AMO will automatically increase the maximum Firefox version of the most recent version of your add-on based on automated testing, even if you have manually set the maximum version.
However, in other types of add-ons, this should be able to be controlled via the strictCompatibility entry in install.rdf. In my case, I was not aware of the incompatibility with a future version of Firefox at the time the add-on version was uploaded (prior to the incompatible version of Firefox existing). Thus, I had not set that option in my install.rdf. For a WebExtension, this should be able to be controlled with the strict_max_version key in your manifest.json.
If you have a newer version of your add-on uploaded to AMO, you should not need to worry about this. The version of your add-on which is compatible with the version of Firefox being run by the user, based on the information contained in the add-on's .xpi and/or as specified by you in the AMO Developer Hub control panel for each version, should be automatically selected for download and installation. New versions of your add-on which are declared as not compatible with an older version of Firefox should not be used for automatic upgrades.
Side note on transitioning data:
You should consider releasing at least one version of your add-on which uses an Embedded WebExtension to be able to transition any data you have stored in the old add-on version to WebExtensions.
I asks these questions because I assume that the main page www.dartlang.org is similar to "download page" because possible direct DOWNLOAD DART (without redirect to download page) from this page without requirement to read additional information.
When I want download Java I can read similar information on the download page.
Version 7 Update 45
This means that this is a version 7 with the 45 update. I assume it last stable.
When I want download Dart I can read similar information on the download page (www.dartlang.org).
CURRENT STABLE VERSION OF DART: 30188
How I can get information how many updates released after major version?
Is this means that Dart has 1.0 rev 30188?
In my Editor (that I use) version is version 1.0.1_r30657 (DEV). It downloaded automatically.
Which version I use?
I think it is not stable because CURRENT STABLE VERSION OF DART is 30188.
How to avoid in Editor to download unstable versions?
How to allow the Editor to download latest stable versions?
Or I must use two systems (possible virtual) separately. One for the production and another for the development?
How I can get information how many updates released after major version?
You'll have to ask Google, they're not really doing comprehensive release notes right now because it just went to version 1. In the future, major version changes might be tracked on the language spec page.
I think it is not stable because CURRENT STABLE VERSION OF DART is 30188
Well, your version isn't considered stable because it's a dev release. A release can be stable even if it's not the most current.
How to avoid in Editor to download unstable versions? How to allow the Editor to download latest stable versions?
Only download the current stable version provided by Google. Not sure how your editor is downloading something automatically, the Dart Editor downloads directly from dartlang.org are packaged with the specified version of the language.
For older builds, check this out - http://gsdview.appspot.com/dart-editor-archive-integration/ .
Updates are not counted in Dart the way they are counted in Java
30188 is a continuous build number. Not every increment is a release. In fact between two updates differ usually by more than one build number.
A stable version is never the most current. The most current are builds from source (bleeding edge) from the development branch.
If you download the development version it updates itself with updates from the development channel. If you download a stable version it updates itself only with stable updates.
You can change the configuration so that the editor doesn't download updates automatically.
Hope this helps
Additionally to the other answers: If you want to use the stable build, you have to download it from dartlang.org. You probably have the DEV version because you used the Editor before Dart went to 1.0:
All existing users that has been with us from pre 1.0 days have been automatically updated to the dev channel.
https://groups.google.com/a/dartlang.org/d/msg/misc/UXRMVmX_6EQ/CSEHZ5c_HBYJ
I guess you have downloaded Dart Editor before the release of the first stable and you are updating it right from the Dart Editor environment. The version 1.0.1_r30657 (DEV) you wrote is the unstable dev release (as it was before the release of the first stable) and it automatically updates only to the dev releases.
For the latest stable release, you should download the current stable version of Dart 1.0.0_r30188 (STABLE) on the Dart Editor website https://www.dartlang.org/tools/editor/. It automatically updates only to the stable releases.
P.S.: If you want to get back the dev version, the link is right under the stable download link on the Dart Editor website