Hacker News Reader

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...

> It'd be nice if there was a way to create a local distribution point

There should be. Choclatey "uses the NuGet packaging infrastructure" and NuGet has that.

IME "root of C: drive" default install location is often a sign that software has bugs when run from paths containing space characters.

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.

I have no idea what capturing and redirecting writes mean.

All explained here:

http://superuser.com/questions/384107/why-cant-i-edit-a-prog...

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.

> That is YOUR definition of where to write data files

Well, Him and the designers of the operating system.

My point is they changed the definition. It wasn't always that way.

You'd prefer that nothing changed? OSs evolve. Deal with it.

like c:\oracle?

and C:\Python27

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.

Yep. That's old-school though, you don't see much of it these days.

I never understood what is so hard in treating the space as just another character.

Because space is not just another character. Space separates args.

But an installer talking to the operating system shouldn't need to separate arguments anywhere.

Which is why escape characters and quotations were invented

It is an abject failing of software that perfectly reasonable characters are barred from filenames.

which is why most arguments tend to have a way to be recognized like -, -- or /

Those are how one differentiates flags from arguments, which is a separate problem.

Kind of.

If your flag is for a path, you can assume everything up to the next flag is a path name.

myprog -filename here is my path with spaces -another_flag

Of course this depends on how the shell gives the arguments to the program.

On the other hand, there is no excuse why some GUI programs cannot handle spaces.

cp path1 path2

So, that's just one file?

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.

Chocolatey is not old software

No, it does not have that excuse.

But the packages it installs may.

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.

Couldn't you do PROGRA~1 for "Program Files" or PROGRA~2 for "Program Files (x86)"?

If there were another directory like "Program Aardvarks", then the DOS names wouldn't necessarily be PROGRA~1 and PROGRA~2

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.

Does install location matter to the CLI? The install location will be on path, so it will be usable from anywhere.

Well rather, if you want to muck about in the installation folder, typing "C:\choc<TAB>" is easier than "C:\Progr<TAB>\choc<TAB>"

Show me a CLI that doesn't auto-complete paths with spaces. I don't remember when I last had to type “Program Files (x86)” out in full.

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.

Really?

    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

Do you mean "language x" on .NET?

VB.NET shows the behavior with

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.

> I've put my programs in C:\ since my pre-Win95 DOS

I see your problem, you're confusing WinNt from the Vista-and-after era with MSDOS.

> 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.

I disagree, the default is in C:\Program Files. Oddly, windows agrees with me. You are welcome to change that on your system, however.

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.

> Technically, you agree with Microsoft, not the other way around.

shrug that's much the same.

> Also, I don't see what the big problem of chocolatey installing where it does. Cygwin, MinGW, Python, Ruby and others do it, too?

They're wrong too, as mentioned in this thread http://news.ycombinator.com/item?id=5176323 and this one http://news.ycombinator.com/item?id=5176685

Maybe it would be better to call it, or actually make it, a portable install?

Imagine making it install to a folder in your Dropbox - then any machine you put your Dropbox on you can run those apps?

(Disclaimer, I pay for the 100GB Dropbox, so I am not concerned about space)

Over at coapp.org, we are (were) doing this the "right way", with MSIs that install into Program Files and dependency management.

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.

I don't understand. What would be the correct default install location?

c:\Program Files, like every other program since Windows 95.

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.

This is just wrong. See

http://news.ycombinator.com/item?id=5176817

As a followup, what is supposed to go into C:\? I've always thought it was awful that Python gets installed into that directory.

I don't think that the user or an installer should put anything directly in C:\. I agree, it is awful that python goes there.

It's the same as going "I'll just save this folder on / so I don't have to remember the path later".

It is not awful.

I've put junk in the root of my drives since before Windows 95. Installers that default to putting junk C:\Progra~1 are what's awful.