I was asked recently to install Hubstaff (a famous application for tracking your data, like screenshots, URLs, etc., on your computer and reporting it to your management team) on my Debian machine. After checking their download page (https://app.hubstaff.com/download) I found out that for the Linux version, I have to download a .sh file and run it (so no package manager, not a .deb file) This app tracks almost everything from my machine (https://hubstaff.com/how-tracking-works), but they don't explain how it follows them. Like they can track the URLs I visit (and no matter what browser I use), how do they do that? Are they checking my network packets?
Do you guys think is it safe to do such a thing? E.g., they say they don't track my keyboard, but they can find out if it's used or not (for idle purposes). Well, they might be right about it, but what if somebody hacks them? I feel like if I use this app, I am making my computer public. Please help me learn about it.
Related
Hello!
My predicament is as follows:
I am a student at a project-based learning high school, we are trying to create interactive art using Processing and Kinect, but the school internet is restrictive and does not let me use Processing's built in library downloader.
My question is as follows:
How do I manually install libraries, and how exactly do libraries work? Are they global as in once installed I can use those libraries for any other project on this computer or must they be re-installed for every file?
Also, bonus question -- which kinect libraries need to be downloaded to get it to work on a 64 bit Dell laptop running Windows 7?
Your best bet is to contact an admin at your school and ask them to install the library for you. That being said, I'll try to answer your questions:
How do I manually install libraries
You can manually install a library using the steps listed here. Basically you just need to obey the library directory structure.
What I would do if I were you is install the library at home, then look in the Processing directory on your computer, and then use a flash drive to copy those files onto the school computer.
Are they global as in once installed I can use those libraries for any other project on this computer or must they be re-installed for every file?
You're talking about two steps. First you have to download the library onto your computer (see above). Then when you start a new sketch, you still have to "install" that library into that sketch (which really just copies the library into your sketch's directory).
This might also depend on how your school computer is set up. You might have a different directory then somebody else with a different account, or the computer might be set to rollback to a previous state every night. Like I said, your best bet is to contact an admin.
I know on windows there are a bunch of installer tools you can use to create an installer, but on Mac OS I've seen two ways to install apps:
A DMG file which you download, double-click, then run an application inside - the application typically has you drag an icon to another icon (representing the Applications folder) to install the app
Another type of file which launches an apparently standard installer, which sometimes brings up a warning like "This installer may run a program to determine if you can go ahead with the install"
What's the "standard" way of packaging an app for install on Mac OS? Is one of the above the Apple-recommended way?
Thanks.
Apple is very clearly making the "standard" to be downloading a program from the App Store. This has the benefit of making application installation transparent to the normal user. And, believe it or not, normal people have a lot of trouble with the concept of installing a program. Of course that benefit comes with some costs, but this isn't the place for that debate–there are plenty of other places for that.
Assuming you don't want to or can't go the App Store route, both PKG and DMG are common ways to distribute a program. Use a PKG if you need to install files aside from your application bundle (which should not be a common use case). In all other cases use a DMG that prompts the user to copy the application into the Applications folder. But a lot of your users will not understand that they need to do that (unless your target audience is solely knowledgeable computer users). They will run your application from the disk image. Ideally in this case, your program will detect that it is running from a disk image and offer to copy itself into the Applications folder.
Packages works well. If your deployment process must be kept simple, it is great.
The Quick build consists of dragging your .app onto Package and it is done.
For advanced packaging, you can also provide a certificate.
http://s.sudre.free.fr/Software/Packages/about.html
We're discussing two things:
first and most importantly, the standard method by which the bits of an executable get laid on the disk in a way that's accessible and properly registered by the system
second, the mechanism for preparing the .app, as recommended by Apple
An older marketing page on Apple's site says it's recommended to create packages (so the Installer application can move the bits in place) with the PackageMaker application.
Its usage is described here: mactech.com/articles/mactech/Vol.25/25.03/2503MacEnterprise-PackagingforSystemAdministrators/index.html.
But as others have mentioned, the elephant in the room is the MacAppStore(MAS for short). Until it's debut, what was standard for large companies was their own custom scripts rolled into an older-style 'bundle' package or using an executable like the VISE installer. Smaller developers usually tried to make their app installable via drag-drop, distributed in zip archives or disk images(for simplicity's sake).
The MAS is different: as of 10.7 it uses a package format (which debuted in 10.5) referred to as a flat package (really a xar archive, explanation here)
which is transferred over http to a hidden folder, installs directly to Applications(after which the temporary folder it is downloaded to is deleted). It drops its receipt and a bill or materials file into /private/var/db, and is therefore audit-able by the built-in command line pkgutil tool, described here: mactech.com/articles/mactech/Vol.25/25.12/2512MacEnterprise-PackagesReceiptsandSnow/index.html
A benefit of using the flat package format is you can pull things over the network more safely and efficiently, but it isn't as easy to work with as bundle packages if you are testing and modifying the package regularly, or iterating to ensure scripts that perform actions or checks work well. Even when flat, putting the pkg in a archive or disk image is recommended for flexibility. More distribution tools expect DMG's than zip's, so there's that as well.
Besides what Apple recommends and what is standard, common practice, there's this article: https://www.afp548.com/2010/06/03/the-commandments-of-packaging-in-os-x/ which discusses the why's and hows (although mainly for system administrators) of packaging for wider distribution. It is greatly recommended to get more of a feel of how and why things go wrong, and what to avoid.
Try Iceberg!
Another one package creator.
In OS X, many applications are just created as a Relocatable
application bundles that the user just need to copy to the
/Application folder (or any other location). In other cases, when you
need to perform some operations over the machine (such as adding users
or changing permissions) you can use a PKG installer (for example built using PackageMaker), which allows
executing some pre and post install scripts and support some basic
installation configuration, like selecting the installation drive.
Sometimes, as with complex server software, you need more flexibility, for example to show custom pages to
the end user requesting information required to install your
application, like the MySQL port and password or proxy information to
download requirements on the fly (or simply to make it look fancier
:)). For this cases there are other installer solutions like our BitRock
InstallBuilder (disclaimer, I'm one of the developers).
InstallBuilder also has the advantage of generating multiplatform
installers using the same project with very little customization per
platform.
I'd like to get a copy of the following open source code:
http://www.osxcrypt.org/release/OSXCrypt-6.2A-source.zip
The above site is gone, couldn't find any archives googling. So I come here to ask your help. I need some source code to do a virtual disk kernel extension on Mac, so Mac OS X can boot from a virtual disk file, as what we have done for Windows via our VBoot (http://www.vmlite.com/index.php/products/vboot) software.
If you do have a copy and can share with me, that would be great!
Or if you have other ideas on how to develop a virtual disk driver on Mac, that would be useful too. We have done that for Windows/Linux.
Thanks,
Executable download: http://www.apponic.com/free-downloads-327/osxcrypt-6.2a/
As for the source, a Google search constrained to the past year reveals nothing at all. The last post here isn't promising:
In 2008 some fellows took the
Truecrypt source code and wrote their
own Mac version (this was before there
was a Mac version of Truecrypt). It
was called OSXCrypt. It had potential
because it was a kernel extension, not
a user-space implementation like
Truecrypt is. They asked for and took
donations, but once Truecrypt was
released for Mac, these guys took the
money and ran. No one to my knowledge
has heard from them since. Pity.
Google search 'osxcrypt' gives numerous sites from which the binary can be downloaded. However, they all seem to lead to dead-ends - the osxcrypt.org domain is defunct (which is probably indicative of problems with the software; I'd certainly not recommend using it at the moment). Using the WayBack Machine at http://web.archive.org suggests that the website was always rather minimal - there's no evidence of the source being available there for the 2 one-page entries that are available. There were plans to put the material onto SourceForge; the project exists but there are no files available there.
There's a contact email address available via whois osxcrypt.org - maybe you should try that.
After searching in the waybackmachine it was authored by Orlando Bassotto and Matteo Flora.
Maybe someone can ping them.
I was wondering if there was a way to make a *.dll that mounts archives in Windows without the need for installing drivers. I've tried mounting *.isos (and was successful), but I needed to install drivers, which was not something my intended audience wants to do (or can do). The other relevant alternatives were for Linux (fuse-zip) or dead projects (zipios++).
Something along the lines of this...http://mountziplibrary.codeplex.com/
Oh, and it'd be great if the solution was GPL v3'd or at least open source.
Thanks.
Have you looked at Dokan? It looks like a Windows equivalent to Fuse.
What you're describing is called an Installable File System (IFS). It theory you don't need a driver: implement a SMB server in application space, and let the existing kernel network client talk to that. It's just TCP/IP at that level.
The proper solution is indeed an IFS driver. Fundamentally, drives are objects in the kernel namespace. As such, the code for them should be part of the kernel, and an application never is.
There was a hobbyist project called WinFUSE once, which worked as an SMB server and redirected FS requests to your .NET code. But it's gone, as far as I know. Proper way is to use a driver-based approach. The driver can be installed and removed on-the-fly if the user has admin rights, and if he doesn't, installation of the application requires admin rights anyway. In Unix/Linux it's the same - you can't mount a disk (not saying about the driver now) if you are not an admin. Could I not mention that Callback File System is the only professional supported solution that lets you accomplish the task?
I've decided to Google around for some answers.
One of particular interest was zziplib. It's for C and transparently accesses archives, just like Windows does, treating it as an actual folder.
Of course, the other implementations given by users work too. This one just fit the bill for me.
Maybe this one helps you: ZLib
We have an app that currently installs itself into 'program files\our app', and it puts the internal data files into the common Application Data folder. This means the program is available to any user on that particular PC.
Now we want to make a multi-user version of this program, multiple PCs accessing the program at the same time across the network.
In the bad old days, under XP, we'd just have the user who installed the app 'share' the app directory and off we'd go. In principle, is this still the 'right' way to do it under Vista/Windows 7?
We'd like to do this 'properly' and be as compliant as possible! Is there a recommended 'Microsoft' approach for doing this, or is it largely down to whatever we can get away with and subsequently support (hah!). I've tried researching this on the MS websites but not found anything too helpful at all - it'd be really useful to have a 'if you're trying to install this kind of thing, put it here' type guide for developers!
I think the recommended way to deal with this is one of the following:
Package the application as an MSI and distribute it via group policies to all machines on the domain. Yes, this will install it on every machine but that's usually how it should be done.
Install the application once on a server with terminal services and push a shortcut for running the program on that server to every client machine. You can transparently use single applications on a terminal server. Afaik you can even associate file types with those on the client machines.
Reading between the lines from other resources, and trying to make sense of it all, I've decided that the 'right' place to put the program data for this stuff really will be in the AppData (Roaming) folder, and the right place to put the program binary files themselves really will be the Program Files folder of the host computer, which I can then share out.