I have a source code which i want to make publicly available but the source code shouldn't be downloadable in their local systems.
1. Is this possible using VM or docker. Which one is better ?
2. Can changes to the code by any client be added to the version control system or git from docker.
Yes the source code will be available, and no it is not possible to directly prevent that. Anyone who has access to the VM or the docker image will be able to extract your source code from either of them. For the VM you can typically mount the disks directly and just view them, and for booth a VM and Docker you can't stop someone from directly logging into the running vm or container and initiating a transfer themselves.
If you're concerned about source code you'll want to use a compiler or obfuscation tool, and which one makes the most sense will depend on the language you're using.
I am trying to follow directions from the book Exploring Beaglebone. I have also viewed this video which is wrong OSes. I have also read some posts (one, two).
Observed anomalies:
Network Preferences shows a warning of a self-assigned IP address and inability to support internet sharing:
macOS Network Preferences
Debian does not have a 'udhcpc' command but the following was executed:
Screen output
Has anyone been able to do internet over USB on macOS 10.13.2 and Debian 9 IoT?
tnx,
Jon
So a quick intro to what options you have:
Manually enable routing + NAT (No idea how to do that on OSX)
Configure the board system to use DHCP client functionality instead to talk to a shared connection from e.g. OSX.
Permanently disable the script (should be in /opt somewhere) that assigns the current network settings and enables DHCP serving. Might also just be a part of a larger script.
Enable DHCP client (e.g. in /etc/network/interfaces or by using Connman or Network-manager)
The default Debian image should also expose a serial console over USB. You can use this to gain access to and configure the system even when your network connection doesn't work. Of course, the debug-UART should work as well, by using a USB-serial converter.
Another note: the DHCP client on Debian for manual execution is usually dhclient. The interface on the Beaglebone side will be named usb0 or usb1 (as newer images use two types for increased compatibility e.g. with OSX).
A good place to ask questions is usually the Beagleboard Google group
I need to detect a file being created on a NAS drive. The system that needs to be notified is running Windows. I first tried Watch 4 Folder 2.5 but it did not work. The author reports it does not support network drives.
So I looked for ways to develop my own utility. I found the ATFileNotification Component for Delphi.
It can detect changes if the Windows machine that is running the notify utility creates or deletes the file on the network share. However, if the file is created by any other machine on the network, the utility does not notify.
The ATFileNotification component encapsulates the Win32 FindFirstChangeNotification function. Is the inability to detect changes on a remote drive not caused by the system where it is running a fundamental shortcoming of FindFirstChangeNotification, or is there some type of parameter I need to set or other workaround?
If FindFirstChangeNotification is unable to perform this task, is there any method to detect remote files other than polling the remote directory on a timer?
Are there any known delphi components or code that creates a simple virtual drive that links to a single file. example ISO file? but this time, can be read and write.
Writing a "virtual drive" requires writing a kernel-level device emulation driver (a "SCSI miniport"-based drivers seem fairly popular), which generally means C/C++ -- and that is just the start ;-)
Not a trivial task. There may be some existing [open source] code solutions that get at least some of the way there...
Here are what I have been able to find with some quick google goggles:
Wikipedia article on ISO software
WinCDEmu
WinCDEmu is an open-source utility for mounting ISO image files in Microsoft Windows. It installs a Windows device driver which allows a user to mount an image of a CD or DVD ROM and access it as if it were a physical drive.
TrueCrypt
Virtual Floppy
However, if all you need is a tool to create an ISO/VHD from a directory and not a real "virtual drive" (or, at least a virtual driver someone else is providing), then that might be a far simpler integration task...
Happy coding.
Is it Possible to create bootable (Applications for MBR )application using Delphi or Pascal (I know we cant use vcl , RTL and other stuffs because they depend on OS), but can i use at least Readln and writeln.
If it is true !!! Can we run the program under other OS.
but i know that PE (windows) and ELF (Linux ) formats are different. but at least with some small modification can i do it.
It's worth saying that PE is a very diverse format than ELF.
Not only a few bytes to modify... the whole layout and library access is diverse, and binding is totally diverse.
In order to boot Delphi application in console mode, you can put a small DOS system (take a look at FreeDOS, for instance), then run your Delphi application using for instance DWPL. DWPL allows to run native 32-bit protected mode DOS programs with Delphi 5-7 using the WDOSX DOS extender as the core. I used this in some old hardware with a network adapter, and it worked like a charm. If you are interested in it, I could post some updated code of DWPL.
For such targets, you should take a look at Free Pascal. By nature, you can customize it to whatever target you want. There is even diverse draft Operating Systems written using FPC. See for instance Toro or ClassiOS - the latest uses Delphi executables as source.
You can see the boot code of Toro from here, and a "main program" source code created with it.
But for direct booting applications, booting is not so difficult. The real problem is the hardware layer.
The BIOS gives very little access to it.
Just for the network layer, you'll have to take a look at EtherBoot sites and such to get some low-level network access... but it could be very time consuming to rewrite all those drivers by hand!
In short: all those "pure pascal" OS are only theoretical, running a console and some low-performance network (emulating a poor network adapter like NE2000 or such). So those "pascal" OS are only proof of concept. FAR away from a working solution! But very nice technological challenge, in all cases, very inspiring.
Why reinvent the wheel? If you want a light and fast system, use a custom Linux kernel.
Then use CrossKylix to compile your Delphi application (with no User Interface) into Linux, or even better Free Pascal.
You don't really place "applications" in the MBR.
The entire size of an MBR is 512 bytes, of which you can only use 446 for code.
Good luck creating something useful in that if you don't even have an OS to delegate functionality to yet. Basically all that you can do in the MBR is place code to start a boot loader.
Here's a page with disassembly of an MBR:
http://www.dewassoc.com/kbase/hard_drives/master_boot_record.htm
Why must you write the boot loader?
You could use a ready-made bootloader like GRUB and chainload your PE executable, from it.
Of course, this is very ancient and hairy stuff, but in the good old days, people did this win PE format executables, and a DOS Extender.
For something a little more this-century, why not make your own bootable REACTOS disk, and add your own PE executable written in Delphi to handle the "user shell"?
You could also (but this would require licensing) use the Windows PXE. I think that projects like BartPE probably fall on the gray side of legal, or are at least, unlicensed. Thus, a completely MS-free solution (reactos) for a completely self-contained kiosk PC, with ReactOS, might be more what you are looking for.
Can you write your own operating system? your own UI layer? your own video device drivers? I didn't think so. So use DOS and TurboPascal, or ReactOS and a PE win executable. Or you can use FreePascal and just build your app on a very lightweight portable Linux kernel and root filesystem.