I have updated to a new bios version which is probably corrupt. Now I can't fall back to an older bios version because the build date always has to be newer than the currently installed bios.
Is there a safe way to manipulate the build date? In windows it is called "Date modified"
Okay never mind I just figured it out by myself. I just had to re safe it.
Related
I would like to use immutable.js, and see that v4.0.0 is at rc.12. That version string seems to indicate that v4.0.0 is not yet released. Is that because there is a problem with v4.0.0, and we should use 3.8.2, which is three years old? Is there a good fork that publishes v4.0.0 (or higher), so I can depend on it without raising questions about depending upon pre-release packages?
Last autumn a new group of devs have started work to finish 4.0 at the immutable-js-oss repo. It's not clear yet whether (or when) we can merge it back into the main repo (otherwise it will be released as a new package).
There are only a few things left to do for a final 4.0 release, 99% of the issues are already finished. If you are curious, have a look at the issues of the 4.0 milestone. The changes are mostly for compatibility with version 3.x and a few cases for handling very special data (e.g when passing nodejs objects to isolated sub-processes).
Our electron app uses RC12 since 2019, before it was on RC9 for a year. So far none of the 10'000 pilots using it crashed a plane, so I would say it works quite well.
I'm working on upgrading our product's MySQL version. MySQL documentation states that Upgrades between milestone releases (or from a milestone release to a GA release) are not supported
I'm trying to determine if the version path we're traversing is not supported (5.5.30 to 5.6.26).
It isn't clear on their archived release page how to distinguish a GA from a milestone build. Is there a place with additional information about each release? If not how can I tell the difference?
Check the Release Notes.
Version 5.5.8 and all later versions are GA in MySQL Server 5.5.
Version 5.6.10 and later versions are GA in MySQL Server 5.6.
Non-GA releases are the versions prior to these, which shouldn't be used in production, because (among other reasons) there are sometimes breaking changes prior to GA. Once the series goes GA, these are not supposed to happen.
Note that there's a difference between "not supported" and "impossible." In MySQL compatibility parlance, "not supported" sometimes means "if you read and understand the release notes for each and every intermediate version, know exactly what you're doing, proceed deliberately, and take appropriate precautions, it might work just fine, but don't say we said it might work just fine, because we didn't say that." In other words, it's literally not supported in the sense that failures on such paths will not be considered to be something that merits a remedy or fix or workaround.
I have been using mysql-devel-5.1.69-1.el6_4 from yum, and in the last day the only available option I can now see is mysql-devel-5.1.73-3.el6_5. Is there a way to get the older version from yum? Is this a regular thing to remove older versions? I would prefer to use the older version because I know it will work with my other libraries/code.
Many repository mirrors only mirror the most recent updated packages because that's what most people need and the disk space for older versions can be high.
If you really need a specific version (and I would generally suggest that you do not and should not rely on a version like that whenever possible) you should be able to get the older package from http://vault.centos.org .
I've been iterating versions of my application trough beta and install4j auto-updater was updating successfully trough versions (2.1 -> 3.0b0 -> 3.0b1 -> 3.0b2). Now I've published version 3.0 and auto-updater is refusing to recognize the new version.
Now, I know that there is an option that allows you to customize update scheme but it's too late now since I didn't know that when I was publishing older versions.
I've played around with it and it updates to 4.0 and 3.0b3 but fails to recognize 3.0, 3.1.
So, is there a way to force auto updater to update by manipulating the new update.xml file?
EDIT: I have version 4.2.8 of install4j installed.
Unfortunately not. install4j 5 will correctly update from 3.0b2 to 3.0, but in install4j 4 you would have to modify the updater logic, so you would first have to release a 3.0b4 to do that.
-How can I check for a new version of my application upon installation?
I feel like I remember installing an AIR application and during the install being alerted that there is a new version, and a prompt as to whether or not I wish to update.
-How do I alert the user, via textfield, that there is an update for the application and to run the "Check for updates" option?
I do not want to force the check for updates, ApplicationUpdaterUI, I want to notify users that there is a new version, and then allow then to bring up the ApplicationUpdaterUI.
Currently, upon initialization the application is popping the "Check for updates" dialog box. I would greatly appreciate some insight on either of these two questions.
I would like to note that I am developing using FlashDevelop3 RC2 and Flex 3 SDK which contains the AIR SDK and the AIR Update Framework.
Brian Hodgeblog.hodgedev.com
I don't think you can check for updates during installation. What you could do is install a basic shell app that always loads in the actual application as a swf file. You could even download this swf file the first time the app is run. After that you can always check for a new version of the app (swf) and download/update accordingly.
Hope this helps... During install - NO - you really can't run anything if you're using the standard AIR installer. You can move to a custom installer - but that's a much more work.
However, when you're first invoked - when your application starts - you can check then (and you can check as often as you want thereafter ).
The guy you want to see is ApplicationUpdater instead of ApplicationUpdaterUI. Using ApplicationUpdater you can get all of the checking / downloading / etc... But then display ANY or NO UI - of your own.
For example - you can check for updates, download them of you determine they are needed and on next 'start' of your application - you can literally 'install' all without asking the user.
I don't recommend this... But it's possible.
Fitting the scenario you asked above - you can check for updates, determine if the update is needed (comparing version or whatever) and then notify the user any way you want - as subtle as you want - to ask the user to update.
You can also do this with ApplicationUpdaterUI - you just need to turn all of the UI stuff OFF (which sort of defeats the purpose of using the UI guy) and just catch the events and display your own UI --- like:
_applicationUpdater.isCheckForUpdateVisible = false;
_applicationUpdater.isDownloadUpdateVisible = false;
_applicationUpdater.isDownloadProgressVisible = false;
Hope that helps.
I think your best bet here is to either:
a) Make sure the .air package that people are installing is always the latest version (this may not be possible if you're distributing an app on solid media, like CDs)
b) Make the update process the first thing that happens in the application (i.e. don't show your primary UI until you've checked for an updated version / shown them the update UI)
However, if you contact Adobe, you can get permission to use a bundled installer which can install both AIR and your application in a non-standard way (e.g. through InstallShield). With this method, you could do pretty much anything you wanted when the app installed, including running a simple script which would check whether they have the latest version.
You can check out http://www.adobe.com/devnet/air/articles/distributing_air_in_enterprise_02.html for a bit more info about bundled installation.