The problem that I have with chocolatey is: It's all about the installs. You'd hope that the people doing it would know how installs work.
But the default place where chocolatey installs is "C:\chocolatey", and "C:\" is where people who don't understand windows file system layout put things.
The docs ( https://github.com/chocolatey/chocolatey/wiki/DefaultChocola... ) make a plausible case that this option might be justified sometimes. Saying "we'll always put it somewhere nonstandard because some people might sometimes want to install it when they don't have permissions to put programs where they belong" is unconvincing.
The other argument put forward "It's not installed through the registry" (so?) and "it's a Special core component tool" (it's not special to anyone who hasn't installed it yet) are equally weak.
This choice of install folder should arguably be allowed. But it's a rubbish default, a poor first impression and undermines confidence that they know what they're doing. It is inexcusable that "C:\Chocolatey" is default and "C:\Program Files\Chocolatey" is a set-up that one does manually.
I have tested Chocolatey, it's definitely not perfect but does its job.
Anyway, I can recommend it to anyone with a Linux background who plans unattended/automated installations on Windows Machines in small scale. It's easy to script and if you want to add registry entries yourself in a post-install script, it's dead easy.
In this context I absolutely agree to the argument "nonstandard because some people..." A common use case for Chocolatey is probably the installation on computers of users who cannot manage the systems for themselves. I think it fills the gap for small scale (semi-)automated installations. I bet for large scales Microsoft has some kind of solution.
Yes, the large scale solution from Microsoft is System Center Configuration Manager, which I use extensively at work. SCCM has a lot of strengths, but it's not really suited to small operations: it has a lot of complexity that smaller orgs simply wouldn't use. Doing something simple like pushing out the latest version of Firefox without customizations, aside from the time it takes to find and download the file, still takes a good number of steps afterwards. It's a sledgehammer when some people just need a mallet, and it also costs a good amount of money!
Active Directory users can utilize Group Policy for software deployment, but that has its own share of caveats (I haven't used it in a while, but last I checked deployed apps have to be an MSI).
The thing that appeals to me about Chocolately is that it does the work of going out and getting the package for you. If you're in an environment where you don't need to do any customization of packages, this seems like a way to save time and energy over using Group Policy. However, there doesn't seem to be any reporting capability nor is there a way to initiate deployments from a central server (I guess the idea is to designate a startup script in Group Policy or just have users type commands themselves). Even in a small environment, those two features really help with management.
It'd be nice if there was a way to create a local distribution point in order to minimize bandwidth usage. But that would be a big project in itself...
If the app writes files into the installation, then you can't install in "Program Files", because Windows will capture and redirect those writes.
Cygwin goes to c:\cygwin because it's normal for all sorts of files in that directory to be written/changed. If it were in "Program Files", it wouldn't work at all.
To call this a bug is just absurd. It's Microsoft that changed the notion of what was valid and forced everyone else to conform. Some software isn't able to conform.
Well written software follows guidelines from the NT age (%APPDATA%, %PROGRAMFILES%, etc). I have no idea why people still think its the dos age of just making arbitrary folders on the root. Heck, this is currently a huge problem in android. The root of my /sdcard is a mess. Are we forced to relive every mistake with every new platform?
I have no idea what capturing and redirecting writes mean. If you want to write, write somewhere you have permission to write to. I deploy software and sometimes need to changeup permissions for badly written software that likes to write to its install folder. I don't know why people excuse developer laziness like this. Imagine if your linux configs were written to /bin/ instead of /etc/ or stuff that should be in your profile is written to /sbin/ or if your logs were put in /etc/. Thats the linux equivalant of what lazy developers do to Windows.
Yeah that's still a permissions issue. The user/account did not have write permissions so instead of just erroring out its trying to preserve legacy software by taking the change and ignoring it silently. Who knows why MS chose this path but the fault is still on the installer.
The fix is either use the proper locations for app data OR change permissions on that folder. its not some insurmountable hurdle that forces you to use weird locations. If permissions were correct then it would be fine. Heck, install Apache on windows. Everything just works in the proper locations because they didn't half ass everything.
Its also worth mentioning that this change came along when Vista was released; prior to that this didn't happen, yet crappy installers pulled the same shit: install to c:\, attempt to write to c:\windows\temp, etc and other DOS/Win95 legacy habits.
Ironically, Vista helped fix all this. Now I see installers for open source or community projects uses proper locations much more often than not. I guess people got sick of the UAC prompts and corporate admins were complaining about how all these arbitrary writes weren't compatible with their limited users.
Apps should write data files to %APPDATA%, not Program Files where the executables shall reside. The only excuse for installing to c:\chocolatey is lazyness
In this case, Chocolatey's data files are actually program files for the rest of the system.
It's just a simple consequence to the fact that Chocolatey is not 'a program' with clearly defined 'data files', but a general purpose software manager (and one that should really be a part of Windows).
The Von Neumann architecture won over the Harvard architecture for a reason. You should learn about it.
> The Von Neumann architecture won over the Harvard architecture for a reason
And then we placed restrictions on it for another reason: security.
See Data Execution Prevention http://en.wikipedia.org/wiki/Data_Execution_Prevention
Which, like these file system permissions, attempts to divide storage into things that you can write and things that you can execute, and the two only meeting in special cases.
You're saying that Chocolatey needs elevated privileges to do it's special thing. Sure. Then it shouldn't be designed around the needs of users who can't get those permissions.
This is just plain naive. See Shorel's comment, and to that I'll add:
That is YOUR definition of where to write data files. Not mine and certainly not everyone's idea. Saying that all apps should fit this model is just absurd.
For Python what may be happening is a good piece of software that is not native to Windows. It works well enough on Windows, but the windows installer is very low on the developers' priorities and expertise. So the windows install experience ends up an afterthought that just barely works.
It also shows how anyone claiming "my tool is special, unlike others it's better to install this under C:\" is not showing good neighbourliness. It just encourages others to make the same mistake.
For Oracle, that probably also holds ... except maybe for the "good software" part.
Treating the space as just another character in a path means that sometimes paths have to be placed inside quotes so the space isn't taken for the end of a commandline arg. Some old software didn't do that.
The tilde file names in windows harken back to ye olde days of MSDOS, where file names were only allowed to be 8 characters long, and the extension was only allowed to be a dot followed by three characters (aka: the "eight-dot-three" file naming convention).
Like, if someone generated several thousand files, all named: "New Text Document.txt"
In the background, some versions of Windows will also record an alternate file name for ye olde backwards compatibility, such as:
NEWTEX~1.TXT
NEWTE~10.TXT
NEWT~100.TXT
NEW~1000.TXT
NE~10000.TXT
N~100000.TXT
It's not really about the space characters, so much as it is about length constraints from back when 640KB should've been more memory than anyone will ever need.
From their FAQ, it says that chocolatey is "CLI focused". So, "C:\chocolatey" makes sense. Paths with space are definitely less CLI-friendly than those without.
When you write CLI apps in .NET, for example, handling paths with spaces is a mess (argv splits on " ", even if you wrap arguments in quotes, so "C:\Program Files (x86)" is seen as 3 tokens.
C:\Users\andrewj\Desktop>type test.cs
public static class Test {
public static void Main(string[] args) {
foreach (string arg in args) {
System.Console.WriteLine(arg);
}
}
}
C:\Users\andrewj\Desktop>csc test.cs
C:\Users\andrewj\Desktop>test.exe a b "C:\Program Files (x86)" d e
a
b
C:\Program Files (x86)
d
e
Class Test
Public Shared Sub Main()
Console.WriteLine("GetCommandLineArgs: {0}", String.Join(", ", Environment.GetCommandLineArgs()))
End Sub
End Class
I hate programs that always put junk in C:\Progra~1. I've put my programs in C:\ since my pre-Win95 DOS and OS/2 days. IMHO there's nothing wrong with installing in the root of the drive, especially if it's only a default that you can change if you want to.
In fact, as far as I'm concerned, InstallShield(R) Wizard -- and the idea of installers in general -- is a piece of crap. I want my installer to be an editable batch file that just copies the files to C:\ -- and does any other setup if necessary. Not that other setup is usually actually necessary, but a lot of apps feel a need to call home over the Internet, install a ton of stuff on my desktop, my Start menu, my Windows directory, all over the Registry, etc., as well as transfer the damn executable from the CD-ROM to my hard disk, which is all a well-written program should really need to do.
I want to actually see what the program's doing, so I can keep track of the pieces. I can't count the number of times I've had to delve into C:\Users\Whoever\Applic~1 or C:\Progra~1 or C:\Progra~2 (on 64-bit Windows) or C:\IDontEvenKnowWhat\Users\Whoever\Whatever\Profiles\Roaming\TheCompany\TheApp to find my saved game so I can continue my adventure on another PC. Or had to regedit.exe into HKEY_LOCAL_MACHINE\Software\TheCompany\TheApp\TheSetting and edit some hex value when a plain-text configuration file in C:\PROGRAM would have been perfectly adequate.
I've been using Linux for years now, and frankly it isn't much better -- install $PKG and you might get /usr/bin/$PKG, /usr/lib/$PKG, /usr/share/doc/$PKG, /usr/share/$PKG, /var/$PKG, /var/log/$PKG, /var/run/$PKG, /etc/$PKG, /etc/init.d/$PKG, /var/www/$PKG, /home/$USER/.$PKG -- part of the reason for having a package manager is to stay in control of this sprawl. The simple and obvious solution of putting $PKG in /$PKG or /opt/$PKG is too much to ask, of course, since it breaks compatibility with the first UNIX where /usr/bin is different from /bin because the system outgrew the specific hard drive the developers were using, so they had to split some things off into a second drive, which was mounted at /usr.
Technically, you agree with Microsoft, not the other way around. Also, I don't see what the big problem of chocolatey installing where it does. Cygwin, MinGW, Python, Ruby and others do it, too?
The default is in c:/chocolatey/. Oddly, chocolatey agrees with me. You are welcome to change that in your configuration, however.
To be clear, that is exactly what chocolatey does as well. The "package" is placed into the C:\Chocolatey folder, but the MSI installs to it's default location, which is typically the Program Files folder.
And technically you should just use the 'ProgramFiles' environment variable, since the folder might be called something else if your install is in another language.
And Windows allows side-by-side installs of 64- and 32-bit versions of the same software; so installers should be aware of 'C:\Program Files (x86)' and 'C:\Program Files'; the first is for 32-bit programs on 64-bit machines.
Seems to me like having the infrastructure in place is only a first step. It's only as valuable as the packages available within the infrastructure. And having a useful set of up-to-date packages is a huge amount of continuous (!) work. You need a lot of volunteers for that, or, ideally, the cooperation of the upstream developers.
It works very well for Ubuntu (and mostly, I think, plain Debian), as the Debian package archives are very good in the first place, and beyond those there is an ecosystem of volunteer or developer maintained PPAs, and beyond those there are individual .debs released by volunteers or devs that you can plug in, sidestepping the server requirement.
It's a cultural difference. It took me quite a while to adapt to it when I switched from Windows to Ubuntu; I was extremely sceptical at first, though now I love it.
Apparently they are relying on upstream binaries and installers to reduce the package maintainer workload. In my opinion that is a sub-optimal solution.
I do not think apt-get means what you think it means.
Chocolatey seems to implement a subset of the functions that apt-get is useful for.
On Windows if I want to look for system updates, I use Windows update. On Debian I use apt-get.
On Windows if I want a library to use on a project, I use NuGet. On Debian I use apt-get.
On Windows if I want to install a bunch of free applications, I probably will use ninite, but chocolaty looks like a nice replacement for this. On Debian I use apt-get.
That said chocolatey seems like a nice tool for windows.
No need to be pedantic. The OP used apt-get as a good enough analogy and got the point across quite clearly. It let's you install things quickly, just like apt-get.
"But with apt-get you can perform searches not just exact name ma-"
Nope. Don't be pedantic. You got the point, that was the intention.
I don't think you understand what the word "like" means. It is a word used to convey similarities, and not exact sameness. The OP states that chocolatey is LIKE apt-get for Windows, he does not say that choclatey IS apt-get for Windows.
What's the difference between "git" and "git.install", or between "7zip" and "7zip.install"? It seems that there's a dependence between the bare-named package and the "install" package, but the package description doesn't explain which one I should use if I just want the familiar app.
I've had to do some Windows development recently and as someone who switched to Linux 4-5 years ago, package management is what I miss the most (although I miss a whole host of things). I can't believe how much time I lose browsing web sites, downloading packages, unzipping, and click installing them. I look forward to trying this out.
Setting up the system once is only half the problem. Most power users have a whole host of links of tools that they will usually need and install on a new machine, but things get really ugly when your stuff gets out of date and the applications don't update themselves. IMO this is the much harder problem that is solved by package-managers. The Windows Way requires each application to replicate some auto-update process which is a great recipe for disaster.
Why is there a git.install and a git? The descriptions don't seem different. notepadplusplus also has two flavors. That should be explained in the description.
Awesome. The closest thing before this was ninite.
Windows really needs a good, clean (and usable for the average computer user) solution similar to apt-get that isn't controlled by someone like Microsoft.
Also interesting is Ninite [1], which lets you create a lightweight installer .exe to download and install multiple applications (e.g. Skype, Chrome, iTunes). Whilst along the same lines as Chocolatey, Ninite seems to be aimed more at "apps" than "packages" and is something you could save on a USB stick or send to less tech-savy people.
Just read the Chocolatey vs Ninite comparison [1]. For me, the biggest selling point of Chocolatey is its decentralized nature, making it useful for enterprisey deployment.
PowerShell's a massive improvement, but the terminal itself hasn't changed in ages (barely any change since NT4/W95 if I had to guess). There's replacements, but you can't count on arbitrary servers having them installed.
Any advice on how to make these 3 tools work together? I scanned the web and experimented today for approx 1 hour but didn't succeed. My general efforts were: (i) injecting clink into the Console2 process (ii) hosting the injected cmd process in Console2.
I actually did nothing special, I just installed clink as executable. Tested it in cmd.exe (you will get the message about running clink). Afterwards added a tab for cmd.exe in console2 and it worked.
Whas seems to be a problem for you?
Hi, thanks for the info. The initial difference is that I cannot use the installer due to Windows group policies associated with my account (the PC is not mine to administer). So I've downloaded and extracted the v0.3 zip archive.
I manually start clink by running "install_dir\clink inject" in a cmd session and this procedure works correctly. Problems arise when running the same command in a cmd session in Console2. The Console2 process disappears (crashes?) after approx 1 sec, then 10s later the clink executable disappears. Strange behaviour and I may simply drop this and perhaps try again in future once the tool(s) have matured.
I hadn't used either Console2 or clink before now; I can get by without them as I'm not a rabid user of the Windows command line. I'll likely casually experiment with them separately.
It's better but not really great. I just don't understand why it has to run within the cmd environment, which is horrible. I use Git++'s shell as my go-to cmd in windows but that's about the same. Why can't it be a complete application that would emulate the "cdm" under the hood? So I can get the feel of a real (as in anything you install on linux) terminal application.
I think it's problematic that the package list on the chocolatey website doesn't show the version numbers of the apps. If I install that Python package, would it be 2.7.3, 3.2, or another one? Ninite does this well on their website.
What if the user installs VLC (which is horribly outdated there) and then, installed VLC, using internal update mechanisms, gets updated? How will that "system" behave then?
But the default place where chocolatey installs is "C:\chocolatey", and "C:\" is where people who don't understand windows file system layout put things.
The docs ( https://github.com/chocolatey/chocolatey/wiki/DefaultChocola... ) make a plausible case that this option might be justified sometimes. Saying "we'll always put it somewhere nonstandard because some people might sometimes want to install it when they don't have permissions to put programs where they belong" is unconvincing.
The other argument put forward "It's not installed through the registry" (so?) and "it's a Special core component tool" (it's not special to anyone who hasn't installed it yet) are equally weak.
This choice of install folder should arguably be allowed. But it's a rubbish default, a poor first impression and undermines confidence that they know what they're doing. It is inexcusable that "C:\Chocolatey" is default and "C:\Program Files\Chocolatey" is a set-up that one does manually.