I want to pick up the rc.boot script file & modify something in AIX system.
How to find it out? Thanks
I would suggest not to modify the rc.boot script on AIX.
Not very many services are started at that point in the boot process - very easy to introduce something that may result in the system not fully booting.
May be replaced by updates from IBM without warning - thus wiping out your changes.
Follow the method from comp.unix.aix . This set-up or something similar to it has been used at all the AIX shops I have worked at over the last 20 years. I currently use this on 50+ servers (except it is called rc.server instead of rc.local). Placing it in the /etc/inittab as illustrated (after rc.nfs) ensures that NFS services are up and running when your script(s) are run.
Cheers
I Googled rc.boot and the first result was documentation from IBM.
It is located at /sbin/rc.boot.
Related
My problem is that I can't use R-studio at my work place as the IT does not support it . I want to use R and R-studio that installed on my personnel laptop on my company laptop ( using a modern browser which is behind firewall ) . Some of the options I am thinking of two two things
should I need to build a docker for R and R-studio (I see base images are already available) , I am mostly interested in basic R , Dplyr (haven ,xporter, and Reticulate ) packages .
Should I have to use a binder . I am not technical person and my programming skills are very limited can any one suggest me way .
What exactly are the difference between using Docker option vs Binder ?
I know I can use R-Studio online and get my work done but with the new paid account I am running out of project hours and very slow sometimes . Thanks in advance
Here are some examples beyond the modern RStudio MyBinder example:
https://github.com/fomightez/pythonista_skewedf
https://github.com/fomightez/r_phylogenetics_worshop
https://github.com/fomightez/chapter7/tree/master/binder
The modern RStudio MyBinder example has been set as a template on GitHub so you can use
The first one is for a special use of a package not on conda. And I started that one from square one.
The other two were converted from content by others to aid in making them Binder-ready.
You essentially list everything you need from conda in the environment.yml along with the appropriate channels. If you need special stuff not on conda, you need the other configuration files included there.
Getting everything working can take some iterations on adding things, letting the image get built, and testing your libraries are available. Although you seem to think your situation is not overly complex.
The binder launch badges you see are just images where you modify the URL to point the MyBinder federation site at your repository. Look at the URL and you should see the pattern where you put studio at the end of the URL pointing at your repo. The form at MyBinder.org site can help with this; however, most often it is easier to just adapt a working launch badge's code copied from elsewhere. The form isn't set up at this time for making the URLs for launching to RStudio.
Download anything useful your create in a running session. The sessions timeout after 10 minutes, although RStudio usually keeps them active.
Lack of Persistence and limited memory, storage, & power can be drawbacks. The inherent reproducibility and portability are advantages.
MyBinder.org doesn't work with private repos. If you have code you don't want to share, you can upload it to the temporary session, using the repo for specifying the environment. You could host a private binderhub that does allow the use of private git repositories; however, that is probably overkill for your use case and exceed your ability level at this time.
GitHub isn't the only place to host repositories that can be pointed at the MyBinder system. If you go to the MyBinder.org page and click where it says 'GitHub' on the left side of the top line of the form, you can see a list of the sources at which you can host a repository and point the system to build an image and launch a container with that specified image.
Building the image from a source repository takes some minutes the first time. Once the image is built though on the service, launch is typically less than 30 seconds. Each time you make a change on the source repo, a build is necessary. Some changes don't cause the new build to be as long as the initial one as some optimizing is done to only build what is necessary after a change. Keep in mind there are several members of the federation around the workd and if traffic on the internet gets sent to where the built image isn't yet available, it will be built from scratch again first.
The Holepunch project is out there to offer some help for users working in the R ecosystem; however, with the R-Conda system that is now integrated into MyBinder it is pretty much as easy to do it the way I described. Last I knew, the Holepunch route makes a Dockerfile that isn't as easy to troubleshoot as using the current the R-Conda system route. Dockerfiles are essentially a last ditch configuration file that MyBinder can handle. The reason being the other configuration files are much easier and don't require knowing Dockerfile syntax. MyBinder aims to offer the ability to take advantage of Docker offering containers with a specified environment without users needing to know anything about Docker.
There is a Binder Help category for posting to get help at the Jupyter Discourse Forum. Some other examples of posts already there may help you troubleshoot.
Notice of a common pitfall
Most of the the configuration files for making a repository Binder-ready are simply text and can be edited right in the GitHub browser interface, without need to git or even cloning the repo locally.
Last I knew, there are two exceptions to this. The postBuild and start configuration files have settings that allow them to be run as scripts and these get altered in a way they no longer work if you edit them via the GitHub browser interface. (This was my experience when last I tried. Your mileage may vary or things may have changed now.) To edit those, you have to have git available on a system you have and pull one from some other source. Then edit that on your machine that has git working & add it your repo and push it back up from your local computer.
(If this is a problem, you can post in the Jupyter Discourse Forum Binder help category and you and I could coordinate where I fork and edit those files in your repo to your specifications and then make a pull request to update your source of the fork with those changes.)
If you are using Jupyter notebooks extensively then it may make sense to use Binder
But if you simply want to use R and Rstudio, then all you need is docker. A good resource is
https://github.com/rocker-org/rocker
When I apply the dotnet publish command I see three folders created in the bin folder: Debug, Release, and MCD.
What exactly is the MCD configuration, and what is this configuration for?
This is likely a result of the environment variable Platform=MCD existing, as it often will on a machine configured by HP.
See this article and this github discussion for more detail:
The issue you are seeing might be related to the way HP machines are setup -- they have an environment variable called Platform, set to MCD which is why you are seeing this...
If it is causing a problem, there is nothing wrong with removing this variable as far as I know. This blog post from Chapman World agrees. And if it did break something it's easy to put the variable back. So the risk is small.
Alternatively, you could safely ignore or discard the unwanted build output now that you know its origin.
I have R Studio on Windows. It works fine before I connect to the internet through my VPN. After I connect commands start to hang, autocomplete can take forever, and simple operations like 4 + 4 can take one minute or more.
I have a feeling the studio is making connections under the hood. I would like to disable all of these connections no matter what.
I have experienced the same thing - I am assuming your actual work is on a file server and not local. I found the culprit in my case to not be RStudio directly, but rather the RStudio project file. RStudio will create a generally small, hidden folder in the directory named .Rproj.user with some settings. This, living on the file server, caused constant read/writes through my VPN connection.
I unfortunately had to either (a) move projects off the file server into a local copy (not bad since I can use a company GitLab), or (b) delete the .Rproj and .Rproj.user folders from the project directory on the server and use here::here() or something like that as a work around in my workflow.
As another possibility, I have seen installations of R itself done onto a personal server drive instead of locally. This has been done to avoid needing administrator privileges to install. This is not a great idea and can also result in extremely slow performance through a VPN connection. You can check to see where R is installed as well. Sounds like this is not the problem though based on what you described.
Maybe it is something else, but this is what I found last week for me based on a very similar experience.
On Monday i have to send in my Master-Thesis.
The codes are now on an USB-Stick.
Are there any things i have to be careful about, so my supervisor can replicate my codes easily?
Are there differences between the working directory i choose (on the stick and his PC)?
2nd question would be: How do i find all packages i used.
I already made a script with all packages i used, however, how can i be sure i haven't forgotten any package.
Do all files (codes and data) have to be in the same folder or can i set a folder as working directory and split that in other folders so its structured?
Thank you very much for every answer !!
I'm not exactly sure what kind of application you're building, but you can easily test your application on a USB drive before providing it to your professor.
Properly package your project onto the USD drive.
Verify that you can run it properly from your machine.
Verify that you can run it properly from someone else's machine.
If steps 2 or 3 fail, you must retry step 1 because something was obviously done incorrectly.
I cannot get phabricator to display the changes in using the file context. I got the "Context not available" on every file.
Does anyone know why is this not work? What should i do to debug this problem?
This seems a problem related with SVN only because its working with GIT.
Thanks.
I bumped in the same problem recently and googled this question. I found out that the context is available only when diff is created via arcanist command line tool (arc diff) in Linux or Mac OS.
It won't work if you create a diff directly by pasting it in Phabricator/Differential or by using arcanist tool in Windows.
I tested this with arcanist on Ubuntu 14.04, Mac OS 10.10 (those two worked) and in Windows 7 (didn't work).
You didn't specify whether you're using the arc diff command line tool, or manually uploading a diff via the Phab. web interface.
If you're not using arc diff, I have an answer for you: It's up to you to include the context yourself. Phab. only knows what's in the diff/patch that you give it. If you can't get the full context, that's a fault with your diff/patch, not with Phab.
If you're using a standard diff utility, like GNU diff, you can use the command-line arguments to dictate how much context to include in the output. I usually use some obscenely large number, like 500 or 1000, to ensure that the entire file ends up in the output.
I just took a quick look at the svn command-line documentation, and it seems that there's no way to control how much context goes into the output. ...but maybe I'm wrong...
In any case, shortboy is correct that the easiest way to get the full file context is to use arc diff.