Slashdot Mirror
A Windows-Based Packaging Mechanism
FishWithAHammer writes "As part of my Google Summer of Code project, I'm working with WinLibre to develop a Debian-like software download system for free/open source software on the Windows platform. My reasoning is that open source software suffers from poor presentation. Most computer laymen, even those aware of open source software, often don't have any idea how to go about looking for it, but would use it if it were easier to access. What I have proposed is both a Debian-style packaging mechanism (capable of using Windows Installer MSIs or not, as the user wishes) and a software 'catalog' that takes the best aspects of Synaptic and Linspire's Click-N-Run system. Seamless, simple installation and removal of programs in as straightforward a way as apt-get (there will be a command-line tool as well). I'm posting to Slashdot to get the ideas of you lot who, while you may not be the target audience, can certainly provide insights that can be of value." Read on for more of this reader's ideas and questions.
There are areas that I'm personally not familiar with, and while I have done some research I would like the opinions of Slashdotters on some others. While at first I intend to set it up so that WinLibre (and I) run only one repository, I am curious as to how this sort of tool could be most useful to network administrators. Customizable repositories will be available; the code will be under the GPL, after all, so it'd be a little hard for them not to be available.
I'm also interested in the ideas of those who might be in a position to roll together packages. I intend to package a number of open-source language interpreters with the core software to allow special pre- and post-install scripts, as well as removal scripts. C#Script, Perl, and Python are definites, as is a Cygwin sh interpreter. We will have some program requirements — chief among them that no registry changes may be made by the program — but some of them, I fear, will require some flexibility; some programs really do require a way to edit the registry, for example, and I am considering offering some sort of tracked way to make registry changes so they can be rolled back on uninstallation of the program.
I'd love to hear what Slashdotters think of this. Think of it as a wishlist, but you don't get any damn ponies.
Ed Ropple (FishWithAHammer)"
There are areas that I'm personally not familiar with, and while I have done some research I would like the opinions of Slashdotters on some others. While at first I intend to set it up so that WinLibre (and I) run only one repository, I am curious as to how this sort of tool could be most useful to network administrators. Customizable repositories will be available; the code will be under the GPL, after all, so it'd be a little hard for them not to be available.
I'm also interested in the ideas of those who might be in a position to roll together packages. I intend to package a number of open-source language interpreters with the core software to allow special pre- and post-install scripts, as well as removal scripts. C#Script, Perl, and Python are definites, as is a Cygwin sh interpreter. We will have some program requirements — chief among them that no registry changes may be made by the program — but some of them, I fear, will require some flexibility; some programs really do require a way to edit the registry, for example, and I am considering offering some sort of tracked way to make registry changes so they can be rolled back on uninstallation of the program.
I'd love to hear what Slashdotters think of this. Think of it as a wishlist, but you don't get any damn ponies.
Ed Ropple (FishWithAHammer)"
C:\>apt-get install bsod
That's great of course, but it's the community and a selection of packages with mutually consistent packaging metadata which make systems like Debian and their derivatives so popular. The packaging system itself is an enabling technology.
An interesting project. I've always believed that if you HAVE to use Windows, there's nothing wrong with giving it the functionality other operating systems have enjoyed. Good luck dude.
Do not let this become a new attack vector.
--- These are not words: wierd, genious, rediculous
interesting but for it to be popular on window IT HAS TO HAVE a user friendly interface not just a command line tool (btw look into new powershell for windows ;) )
I would say the big thing that I would look for in such a product would be a consistent (or even better, non-existent) use/removal of registry entries. I have dealt with so many so-called "professionally" done software pieces that upon uninstallation would leave several dozen registry entries. This seems terribly unnecessary, and if the so-called apt-get method could circumvent the registry (much like the run from USB flash drive programs) altogether, or at least make it a sure-fire thing to remove, instead of wipe-and-pray.
Good on you for trying to better the system man, I wish you the best of luck!
He's not trying to solve problems of Windows. After all, it's for Google.
I like what you're doing, and I personally don't have any particular suggestions. I would think that the people this would be aimed for are the same people that use apt-get on Debian. So focus on the audience of apt-get and that should guide you for this sort of application for Windows. Good luck.
-Bob
Is it really that hard to find open source software for Windows? I've never had a problem. Windows already has a decent way of installing and uninstalling software, so adding another way to do it, seperate from Windows's own, seems rather pointless, not to be rude.
For user-specified (or multiple fallback) repositories, you need nothing more complex than reading your base path(s) from a config file. Prepend that address to every file you download, and it will all go well.
For the bigger project, basically you just need a set of per-package install/uninstall scripts that check for dependancies (or no-longer-needed dependancies on uninstall), do their thing, and write themselves to a standardized catalog of installed software. Whether or not you can adapt Windows' list of such software, and the MSI interface in general, to your needs, I can't say offhand. I would think you can at least list the package therein, but I don't think that handles dependancy information quite as elegantly as you would want.
I see the biggest problem you'll have as coming from the poor regression testing done for Windows ports of FOSS - You may well need multiple (version-specific) instances of some dependancies installed at the same time, for different packages that use "working until version 2.8.10.4" features (or more of a nightmare, "working until KB935356").
Overall, I wish you luck with this. I think the Windows world has needed something like apt-get (with a mind-numbingly simple GUI) for a loooooong time.
Strikes me as a chance to write something that can also be refitted to run on Linux. Write as .net objects, that opens up the PowerShell and the inevitable GUI back end.
Me I would keep is simple and start with the commands I most commonly use with apt-get, (install, remove, update, upgrade).
Question is how complicated you want to be getting. Will it be pulling in source, checking the environment and building things? Look at CMake.
I guess that is three pennies worth.
If something like this were widely used in Windows, the "package" system used by many linux distros wouldn't be so incomprehensible to the typical user. And, when people find out how much more free (libre) software there is on the Linux side, there would actually be a reason to switch.
The only issue I see here are with licensing. There is a ton of free windoze software out there, but a lot of it has strings attached.
And, as mentioned, there's the security issue. Packages would have to be validated in some way. I don't think that trusting the maintainers would work so well like it does for Debian.
One of these days, I'm going to cut you into little pieces.
That packages provide functionality. This is already done in the form of virtual packages like web-browser, but I'd like to go further.
.pcx file, and have no clue what is it, what can I open it with?
.s3m files?
.s3m files) and "fully implements" (can create .s3m files).
For example, the current system is that OO Writer and KWord are in the "word processor" category. But what if I want something that can open AmiPro documents? What options do I have there? That's generally not included anywhere in the package's description.
I found this weird
Or, what music player has the ability of playing
What mail clients can I choose from if I'd like both NNTP and IMAP support?
What programs are available that do some function that is related to an HP nx5000 laptop? (this would match programs controlling LCD brightness, support for the onboard bluetooth, etc)
A nice thing would having these capabilities roughly grouped as "can access" (can play
"My reasoning is that open source software suffers from poor presentation."
Definitely true. Part of the reason is that programmers often just like to program, not make things easier for the user. Writing a manual and making things easy can take 90% of the development time.
There is a mechanism for doing this kind of thing already in Windows, via Add/Remove programs and Group Policy. Surely it would be a good idea to try and re-use this rather than re-inventing the wheel.
How will this cope with Vista and it's increased security? I'm all for this as an idea but it would be a shame if it takes a couple of years to get up and running but by then Vista is mainstream and, for whatever reason (FUD?), breaks compatibility with the packaging system.
No, it would be a wonderful thing, although I don't think it'll fly.
On Windows one of the most annoying things that that things install themselves -- which gives them full control over what goes where, up to modifying obscure registry settings and overwriting files. That means you can never be sure you can uninstall something.
Package managers solve that: When I install say, kword it doesn't install itself. The package manager knows exactly what went where and can remove it. KWord itself runs as a normal user account and doesn't have the privileges required to make itself not removable.
But for working well this sort of thing needs everything to be packaged, and I doubt that'll ever happen except in a very few controlled environments.
Good initiative, I myself tossed around some ideas for such a system a long time ago but never got started on actually doing anything about it.
IMHO some things to keep in mind are some kind of authentication of packages, an extensive system for deinstallation that cleans out crust, backwards compability with existing package systems (rpm, apt-get), option of building from source if all available packages are sorly out-of-date, local and remote installation with as few requirements for previously installed programs. These are just a few of the things i thought about before, lemme know if you want me to dig out my old document with ideas.
Oh yeah, this is my first ever post on /. so be kind^H^H^H^Hless of an ass to me :P.
Harsh, but you have a point.
One of the problems I have using linux (not that it interferes with my use, just is a minor annoyance) is that I don't know where anything is. Part of this is just because I'm used to windows, and used to the way it works (or doesn't) but it's partly the way linux works. When I install a program with synaptic/apt-get or whatever, it's completely invisible to me what it's actually doing, where is it putting all the files? Sure I can browse to / and see the whole filesystem if I want, but trying to find anything manually is worse than needle-in-a-haystack land.
It'd be nice if the installer could ask you where you want it installed, or even just tell you where its files are going.
So, in theory this should work with ReactOS when they are both finished, right?
I hope you're planning on making it interoperate with the cygwin packaging system. Cygwin's a great piece of software which is, IMO, let down by its obscure and difficult-to-use setup program. A new, friendlier way of installing and updating cygwin components would be a great asset. And if it worked with other OSS stuff as well, that would be a huge asset.
.exe that doesn't require your system, but which can interoperate with your system easily -- perhaps by having a version of your system that can wrap up a package with a copy of the relevant parts of itself in a .exe file.
One thing I would suggest is that you make it easy for somebody to package a standalone
I would actually love something simmilar to java web start... i.e. a little application that lets you browse through the open source applications on your PC. It would be great to remind people of how many (good) open source apps they have.
It would also be nice to let users look for alternative applications or do a keyword search/browse for new applications. A nice web-like interface to the app would be great.
It should also prompt the user of an update to the app when its run (ala click-once).
Most people download apps like Firefox because they are good. But most people don't know where to get more simmilarly good free apps. This package management tool needs a pretty UI, a slick name and a funky logo. People need to associate the package management tool (and open source in general) as providing software worth installing and using (i.e. create a brand).
Synaptic can list a package's file locations. In the console, dpkg -L package_name does the equivalent.
Thanks.
I guess I'll get used to where things are, and it's just that I'm so used to seeing 'Program Files' and 'Documents and Settings'.
I'll give you dependency hell, but linux scattering files all over the file system? I think not.
/usr, /usr/local, sometimes /opt/kde and /opt/gnome) and directories within each of those (bin, doc, etc, man, sbin, share). If the software doesn't have special needs (e.g. a database, the kind of thing users don't install), you know exactly where crap goes: Binaries are in prefix/bin, libraries are in prefix/lib, images and whatnot go in prefix/share/appname/. Where user stuff goes is admittedly lacking in definition; It's usually either ~/.appname or ~/.kde/share/apps/appname for user-config. But the point is, if you tell me "I installed foobar," I know of maybe 4 places to look for any given file that goes with foobar.
In Linux/Unix, you have a set of prefixes (/,
Last time I used Windows, the installer suggests an install directory (following no particular standard), puts most of itself there, and is then free to put some random files into c:/windows/system32, or wherever it feels like.
You may want to look at wpkg (http://wpkg.org/)
It is a windows package management system based on dpkg.
We use it at work and it appears to work fairly well. Although I don't know for sure, as I'm not the PC admin and I don't run a Windows desktop :)
I just get to hear him saying how much easier it is to manage the PCs with it.
Ever stop to think
Slightly OT, but did you noticed on the download page that it says "Due to the french DADVSI law, we are requested to remove the following legal BitTorrent links...". I read the Wikipedia article, but it's still not clear to me what this might mean. Anyone have insight?
The first issue that occurs to me immediately is that Windows has no single suitable native package management system that you can hook onto. Because of this, program installations tend either to (i) include whatever prerequisites they need and check whether their installation is necessary; or (ii) list the prerequisites in the installation instructions and leave it up to the user to ensure they are satisfied. Now, you might say that the whole point of the project is to resolve this, but I think you are going to run into licensing problems when you try. Let's say a particular open source product relies on .NET Framework 2. Are you then going to include .NET Framework 2 in your repository? Are you going to download it from Microsoft, using Microsoft's Download Center as a kind of adjunct repository? Are you going to talk to Microsoft to see if they will cooperate in working out a solution? This seems hard.
I do think that a single starting point for finding quality open source solutions on Windows has merit. Right now there is a bewildering mass of products out there, and no easy way of sifting the gems from the dross. If nothing else, you might be able to provide a good menu of open source products that are deemed worthy of consideration.
Good luck!
I like the goal, but I'm not sure it's going to work. People have tried hard to make this work on the Mac, where you can get MacPorts and Fink. Neither of them has caught on at all among general Mac users. Even as someone who loves the Linux package managers on Linux, I don't use either MacPorts or Fink on the Mac because I find them to be more hassle than they are worth.
At the very least, have a look at MacPorts and Fink and try to understand who uses them and how they are being used.
So is this going to be like Cygwin, with a nicer user interface?
Follow me
I sort of agree that the filesystem layout on linux tends can be difficult. However, package management on windows could be benefits. Reducing the number of updaters that run every time the system starts would definitely be a step forward.
"Welcome to our world. We are the wasted youth. And we are the future too." Yes, I know these are stupid lyrics.
Microsoft already has an open packaging format for installers, it's called Windows Installer (formerly Microsoft Installer), or MSI for short. MSI 3.1 supports Windows 2000+. http://msdn2.microsoft.com/en-us/library/aa372866. aspx
Why re-invent the wheel? This is open to everyone and well documented on MSDN and countless forums all over the web.
This is why, for Windows or Linux, I much prefer programs that don't need installing. I like something I can just unzip/untar and run from there.
And I've often thought that the way windows works for programs is entirely stupid. Why does my program need to store DLLs in system32? Why not just store them in its own program folder. Why does it shove stuff in the registry? What's wrong with an INI file, like we used to have in W3.1 days.
One of the really annoying habits of windows programmers is to put dozens of different entries in the start menu: the readme, uninstall procedure, another readme, a seperate update routine and - very important - a link to the developers web page.
Could you introduce a debian-like menu, where each program has exactly one entry and is in the right category?
Agreed. This is just begging for the slogan "the reliability of Windows combined with the user-friendliness of Linux".
He who lights his taper at mine, receives light without darkening me.
One thing I think shopuld be considered from the beginning is how to handle multiple archives, which may be independently maintained. Sure, the basic operation is simple: You add a new URL to the list of archives to search, and then you can see the contents of those archives. However that's not all there is to archives:
1. How do you find additional repositories?
2. How do you find out if a given repository is trustworthy?
3. What to do if several repositories contain packages for the same application or library?
4. What about version inconsistencies?
Points 1 and 2 can IMHO be (mostly) solved together through a "repository web": Repositories not only contain packages, but also links to other repositories. Those links should also be rated, so you get a web of trust for repositories: You can mark several "root repositories" as trusted or untrusted (those settings should, of course, be user-changeable). Then trust would "propagate" through links marked as trusted, or "anti-propagate" through mistrust-links. One could even imagine "repository hubs", repositories which don't contain files, but only links to other repositories together with trust ratings. It might also be a good idea to have several trust ratings for the contained files, and for the contained links (after all, you can well imagine an excellent file repository where the maintainer isn't able to accurately rank the trust on inter-repository links).
For points 3 and 4 I don't have a suggestion right now, but they definitely should be considered (note that separately maintained repositories will almost certainly cause inconsistencies at some point).
Of course you can just pretend that there will always be only one repository, or that all repository providers will work together to avoid inconsistencies, but I think that's not really a good idea. Additional independent repositories will eventually come (assuming the project is a success), and therefore the problems caused by those should definitively be anticipated, even if originally there's only one repository.
The Tao of math: The numbers you can count are not the real numbers.
I want to highlight some differences between dpkg/yum/whatever to the Windows platform. You may like to carry some features of *nix, but doing so will require you to re-educate the users, and thus your package management will not get adopted.
1. Windows users expect the Next->Next->Next->Finish paradigm. *nix users expect the "silence is golden" rule.
2. *nix advocates dynamic linking. Windows has DLL-hell. This is because the distribution can suggest the library versions and the user can choose a difference library version by recompiling dependants. This is not possible in binary only distribution.
3. Windows software comes from multiple sources. You must allow others to host their packages and only link to other places. Don't try to make one large repository. You can however, maintain one large catalog and allow others to edit their entries in your catalog.
4. If users will be able to add entries to your catalog, they will add bogus software. A later version will have to allow the users to rate the packages. Use the users to make your content, you only supply the means.
5. Interaction with MSI is non-trivial. Start with a prototype of your system that use zipped packages (optionally with a manifest file). Once all the pieces is in place, start adding support in msi packages.
It's a stealth feature. Get people installing applications that way, because then the Linux desktop will be more familiar.
Something really is needed. I keep coming across people who really need no more than Wordpad who are buying Office because they think they have to. I recently came across a guy who has bought Office 2007 and writes nothing but letters and the odd email. He thought that somehow saving his letter to Auntie Flo in Office 2007 format (docx) was "better" than saving it in Office 2000 .doc, right up to the point she couldn't open it as an email attachment and he had to "downgrade" his document. Microsoft is exploiting numskulls like that. (I'm only jealous of course - I'd love a list of 100 or so gullible people with money but, as I'm not a corporation with deep pockets, I might get into trouble.)
These people don't know OOo exists, and even if they did would never be able to find it. But a simple little packager that has a "Top picks" with something like "Open Office 2 - for all your home office needs" and a "click here to install" button - well, at least we'd be trying.
Pining for the fjords
Please don't make your project any harder to use than rpm :)
[ http://jengelh.hopto.org/linux/adm_pack.php ]
BTW, why reinvent the wheel? Just port an existing system (that is, libxyz and its xyz gui) over there.
Basically, this is a good enabling technology, with many long-term benefits. This, of course, means someone has already thought about it -you might want to consider joining forces, instead of rolling your own. .NET). IANAL, but I don't think such deployment breaks any laws -after all, what does it matter, whether you've downloaded such software via a web browser, or from any other application .NET 3.5)
Either way, here are some features, which such product must have to gain the critical mass (among others):
-Automatic recognition of the currently installed softwares, along with it's version numbers. Ability to upgrade them.
-Support for stealth installation of all the current major software deployment methods: MSI, NSIS, installshield (among others)
-Support, and database for automatically downloading, showing license, and stealth installing non-GPLed, but freely available softwares (such as
-Dependency tree (with version information), and automatic dependency analysis&deployment for each installed software (my mom doesn't really wanna know, or care if the latest solitarewarez needs
-Category tree, tags, user comments, rate, number of times downloaded... etc, the basic meta-information required to make an informed decision whether you'd like to try it out, or not.
-Seperated repository for freewares, sharewares, etc.
That said, I think the biggest challenge is putting together a community-based, but still trustworthy database of applications, and figuring out a way to make it convenient, and secure enough for large-volume administrators to use it.
On a complete tangent - what software submission sites/distribution channels can people recommend (like fileforum/download.com etc) for getting your own freeware/shareware listed? I've got a guitar tutor thingy at http://www.webprofusion.com/scalex that I want to finally get rolling out, it's been sitting around for ages and I've another update in the works.
An apt-get equivalent for windows would be a very cool thing, I hope you succeed.
You might want to reconsider the decision not to use MSI as a back-end. I am not familiar with the details of the technology, but some of the supported features are command-line and GUI installs, and administrative network installs. And if you don't already know, Microsoft has released some open-source (!) tools for generating MSI packages: http://wix.sourceforge.net/
> Are you then going to include .NET Framework 2 in your repository?
> Are you going to download it from Microsoft, using Microsoft's Download Center as a kind of adjunct repository?
> Are you going to talk to Microsoft to see if they will cooperate in working out a solution?
Interesting question. What occurs to me naturally is to make a metapackage that provides dotnetfw2, that looks to see whether it is installed, then attempts to download the package from the official location - I'd try to implement this as semi-interactive browser use, so that user could enter login credentials or intervene in other manners in case the web pages do not answer in ways known to the script - or inform the user how to achieve installation of dotnetfw2 and fail.
Bigger question probably is whether this project will get enough contributors to achieve sufficient quality to pass as the premium choice for end users. I think there are probably plenty of software professionals who have to work on said platfrom, either permanently or every now and then, and thus likely no shortage of potential contributors - and power users.
> If nothing else, you might be able to provide a good menu of open source products that are deemed worthy of consideration.
There's a lot of that stuff that I'd love to see so easily available. Just yesterday felt kind of lost without grep. Luckily, Active perl is easy and familiar.
I was the real korpiq until I woke up clowned.
I have been thinking about this recently.
I have lots of applications, both OSS and commercial, that have some kind of update system built in - the application checks for an update when you start it, for instance, or when you select the option from the help menu. In fact it is getting to the stage where practically every app. has this.
What I would like to see is a single open method of doing this which could work for all applications (so even commercial software providers could opt into it if they wanted), which would be simple and secure. It would be great to have a single application open that ran at start-up that said: "The following applications have updates available:" and then lists the applications, and two buttons "Update all" and "Advanced" which would allow you to see details about the updates and select just the ones you want.
For instance on my Mac I have:
1) The Official Apple "Software update" that updates OSX and Apple Apps.
2) The Adobe updater for Photoshop, Dreamweaver etc.
3) The Firefox/Thunderbird updater
4) Dozens of updaters for individual apps like TextMate and OSS software
5) Updaters for OSS packages (Fink/darwinports)
(Yes, I know about the App Update widget but that only addresses part of the problem, and it does not provide a technical solution that can be used across platforms and projects).
And on Windows, I have the same kind of mess of updaters.
I'm sure there could be a simple, elegant technical solution for this, a kind of RSS-type standard for application updates - you could then choose your prefered updater just as you can now choose your preferred RSS reader.
What makes apt and rpm repositories so great is not that they contain loads of software, but that the software packages depend on each other so that each package contains as little as possible. In contrast, most Windows applocations are self-sufficient. If it requires external libraries, those will be bundled with the installer.
To make a functional package repository, you'd have to first build the supporting libraries all those programs use, then build all the programs and create dependencies. As this is counter to the current windows philosophy, you'll likely have to change the build scripts of all the programs involved. Good luck.
If you are going with the binary approach (basically creating a more managed download.com), be sure to fully support NSIS installers. The NSIS installer is by far the best installer out there for open source projects, and also one of the more popular ones.
And that is exactly why packaging could be a boon for the average Joe. How many people really care where the stuff is installed?
Having said that, I feel that it's too late in the game to try to introduce package managers to windows. People are just so used to doing things one way that they're very unlikely to change.
Freedom is not worth having if it does not include the freedom to make mistakes. - Mahatma Gandhi
That would actually be real work though :)
/Applications and applications are packaged with all they need right in the application's folder which looks like a normal executable. Preferences are in the user's prefs folder.
It is amazing how robust OS X is when it comes to applications.
I can drag an application anywhere and just works. OS X performs the housekeeping all automatically. It handles file type registration automatically.
The usual unix directory layout is nicely hidden on the desktop but unchanged for people working on the command line.
Applications are are almost always in
Deleting an application is trivial, just drag to the trash. You can't screw up the system in anyway other than potentially leaving some harmless libraries or data files still in the filesystem.
Moving all your old apps to a new system is as trivial as copying the applications over and if you want your old preferences.
For Linux or Windows to do anything comparable would require massive amount of rewriting and the ability make basic sane choices that only Apple appears to capable of.
It is much less work to pretend to like the Linux packaging system than to actually make the tremendous effort required to implement something as elegant and user friendly as Apple has with OS X.
That's only a problem for software you don't trust. Furthermore, you don't actually need an installer at all in Windows (or Linux for that matter). You can simply distribute an archive, containing a directory, containing an executable, which is the program. This is what all the best freeware does. This is also how both Firefox and UT2004 are installed on my Linux system.
Without writing an easy here I really do think that this is one of the key ways to dramatically increase OSS desktop presence.
However, the problem is not the package manager, windows installer packages are good, or there are already ports of some of the more popular OSS package managers. The problem is managing the packages.
You are suggesting establishing a 'distribution', the fact that it is based on the Windows kernel isn't going to make this easier to maintain then a Linux kernel based distribution. Distributions are social engendering problems not a coding exorcise.
If you want to do some useful code promoting OSS on windows then fix the CYGWIN installer into something less ungainly.
If you are serious about starting a new distribution and recruiting the large community it would need to sustain itself. You should look at Gentoo. I am not trying to start a distro/package manager flameware, but it would have some clear technical advantages:
Why bother? Software is easy to install on Windows. click, click, click, go.
OSS is NOT easy to install on Linux, usually requiring package management and then recompiling something with the gcc and the dev libraries installed.
Yeah there are package managers but seriously, they are not the panacea that people make out. For example, using Synaptic on Ubuntu. They never have the very latest release of Firefox in the repo's, therefore, if you want to install it you have to do it manually or wait 6 months for the repo to be updated. People want to use software when it's available not when someone else updates the repo's and they don't want to compile source code. This is why people say installing stuff in Linux is hard.
Another example, is if you wish to install something that is not in the current repo. You then have to add a "cryptic" url (for a noob) to the sources list to be able to download. This is a lot more complicated that just browsing to a web site and clicking download.
If anything, I'd like to see an FOSS version of Microsoft's SoftGrid application virtualization software.
http://www.softricity.com/
C:\> apt-get remove iexplore
I'm posting anonymously to protect the guilty.
I worked at a company that needed to be able to manage software installs. We tracked them, created scripts to install and uninstall by calling MSI or the uninstaller respectively, and repackaged them when we had to.
In order to repackage, we had to provide a log of changes to the system from the installation of the package. We used an embedded sqlite database per package to dump before and after states of the filesystem and registry, environment variables, etc.. Then we diffed the two to get the install contents based on a manual installation. Special attention has to be paid to special directories (e.g. C:\Documents and Settings\myuser must be converted, "Program Files" as well, WINNT must be specialised, temp directories shouldn't be tracked, start menu items need to be logged...). In addition, you need to be able to read shortcut files and .pif files (DOS shortcuts) to recreate them. For MSI, you can read package contents (though it's a real bitch to actually decipher it), but change tracking was the only reliable way to get changes from ALL types of packages. Don't forget to track changes of the list of services as well. In the registry, remember that we can stock binary data... Etc. etc...
This is an argument for having an apt/synaptic type service for Windows (though this could just as easily be served by a web page indexing software sources, particularly for software which keeps itself up-to-date). This is not an argumnet for introducing package management. That is only necessary if dependency hell exists. The lack of package management in Windows has done a pretty good job of preventing that among Windows-based free software.
Unlike you I value my time and wasting it on pointless activity doesn't appeal to me. To download an open source program now I need to google for a program,
I tend to google for what a program does. Not its name. Usually google takes me straight to a download page where I just click the windows version to download. Not quite as easy as apt-get but a few extra clicks doesn't really strike me as worth the effort to install yet another package for the few times I need a new application.
use the registry like everybody else. It's already miss used and messed as it is. Use log files. The registry is just an artificial construct that ends up being a file anyway, this will save you layers and make porting to non-registry operating systems easier.
My 2c anyway.
RubyGems is a package manager for Ruby that runs windows too. Most people haven't heard of it because it's used for installing ruby apps and libraries.
I use Cygwin daily at work, as I cannot dual-boot to Linux. It is more than enough for my work, but for the general public, it's packaging system is sadly lacking in bells and whistles, and the available library is way short of your objective.
Nevertheless, isn't it a good start?
Misleading titles? Inflammatory blurbs? Keep in mind that Slashdot is a tabloid.
Some of the ACM guys at UIUC had the idea already: http://www.acm.uiuc.edu/projects/Wipt
But hopefully there's, well... Hope!
.rpm or a .deb.
.rpm or .deb on said system.
.rpm and .deb do: it makes no sense at all to mandate root for package to be executed by non-root user in a single-user setup. And even on real multi-user systems, the admin should have the choice to install a package system-wide or "user-wide".
:)
First I emphasis that I'm a Linux fan, since last century (started with Slackware in 199?, you youngster!)... But I'll still explain why I find the two main Linux package management systems completely, utterly, broken: you must be root to install a
Think about it for a minute. This is completely broken. Sure, in some case it makes sense, for example when an Unix admin knowing what's he's doing is installing packages that several users will need. But for a personal desktop and/or workstation it is simply broken: why do I need to be root to install, say, Sun's Java JVM when it can be installed fine in a user account? Why do I need to be root to install, say, video codecs, from a site I don't trust more than that? Note that I'm not saying I'd be totally immune by installing packages from websites I don't trust: of course there could still be a nasty package exploiting a local exploit to gain root privileges... But this is way more complicated than "rooting" when you can execute your malwared
Ian Murdock wrote on his blog a two-parts article called: "Software installation on Linux: Today, it sucks". Enlightening read also highlighting, btw, other problems.
And of course some guys, after more than 10 years, start to get it... "Klik" is an interesting concept: one of the key features is that you don't need to be root to install packages containing programs that don't need to be run as root: http://klik.atekon.de/
Crazy idea uh!?
So if you want to copy some of Linux's package management feature, please don't reproduce the same errors that
As a funny sidenote Sun's JAVA JVM / JRE / JDK can be installed fine in a user account, by a non-root user, on a Unix system (using the tarballs provided by Sun) but, on Windows, it is, AFAIK, impossible to install JAVA without using the administrator password
Installing software from a public repository always requires that you are able to trust that source. This problem has become even worse here in the Germany now that our government wants to install trojans on computers. Being able to decide yourself whose packages you trust and verifying that source is essential. ALso I thinmk the registry is a great thing if used properly. I wouldn't mind if evry program registered there as long as it gets completely remove from tere on removal.
Installing apps on Windows is good as it is. Dont kid yourselves - package management is one of the worst aspects of the Linux OS. People already know how to look for software: You google for it, then look for a download link on the webpage you find. Package managers are almost worthless when you try looking for software to install. The search is restrictive and the descriptions minimal. Applications get lost among the countless number of small useless apps and cryptically named support files. Unless you know exactly what you are looking for, the chances of finding anything among the huge number of packages is almost nil. And don't forget most users don't even know what packages are! And why should they? All they care about is applications. Nobody wants to know what shared libraries they need or can install. And with today's hard drive sizes, there's really no point in sharing resources between applications. that just makes for more complications such as dependency conflicts.
In reality, it tends to work the other way around. Take the Amiga emulator, UAE, for instance. I think, among other meanings, the U once stood for Unix. Yet, most of the best features are in the Windows version now, and they're developed in a non-cross-platform manner, by people who don't care about OpenGL's standardisation over DirectX, etc. Same with other emulators, and probably lots of other tools.
Unfortunately, Free Software is a victim of its own generosity, when parts of it are ported to windows. Especially given that the initial ports tend to be half-hearted, and half-working compared to the Unix versions, so that people think Free Software sucks, until it's had a while to become windows-ized through its that community.
STILL... it seems obvious to me that something like a usuable, popular, apt for windows could literally beat microsoft's monopoly. When you can browse to the office section of your package manager, and you're immediately presented with a choice (Install OpenOffice now, and lots of extra, compatible software) or run install the wrapper package for Microsoft Office, after buying the CD, proving you didn't steal it with a 98-digit code, etc.)... well, it would really level the playing field.
I actually thought this was the point of Google Pack -- to beat microsoft by taking over and opening up the distribution channel. It's a shame (no, literally, a SHAME) that they didn't do a better job on that, by making apt for windows then. I'd be glad to see a real APT for windows. Unfortunately, I'm not sure it's possible, without the mass of a debian-like project behind it, a very easy and presentable UI, and open, usable APIs that encourage developers to use it. Hint: it has to work as well as apt, but not be half as hard to make packages for. Good luck, I say.
I'd argue that apt-get is less intuitive and harder to admin. Few Windows users are going to want it. Good luck finding that out the hard way.
These posts express my own personal views, not those of my employer
Packaging is a band aid on deeper problems with library incompatibility problems, the braindead scattering of software files all over the file system, and the completely pointless minor differences in Linux distributions.
You make it sound like package managers are hacks. In some cases, that might be true (e.g. Slackware) but some package management systems (e.g. APT) have been very carefully engineered to control exactly the problems that you specify. A good package manager will handle all your dependency, update, installation and removal needs, so that each application does not need to do all of these things on an ad-hoc basis (as in Windows). All you have to do is trust the package manager to do its job.
An online repository of free software for windows is trivial, considering that systems such as NSIS and MSI already have the capability and can be used at the command line.
.... get it?
However, the cost of hosting such a repository is well beyond the budget of a student. Should it become popular, the cost is well beyond that which many successful corporations could afford.
Thus NSIS, with its ability to use the superior LZMA compression should be the system of choice, as bandwidth costs of such a system will be prohibitive.
I cannot emphasise enough, bandwidth costs are the only challenge here. Find a sponsor with really deep pockets. (Someone stronger than WinLibre , who's page would not load at all for me this morning)
Bandwidth, bandwidth, bandwidth, $$$$$$$$$$$$$
Well, TFA is slashdoted, so, I didn't RTFA and will coment on the sumary.
What you seem to be doing is more like repository managment than package. You can go only so far with a repository without a custom packaging system (.msi won't make it), but even limited, it can be very usefull. A repository as I see it must be:
1: Centralized (but not too much): There must be 1 central repository that you'll maintain. People must be able to mirror it, but not change the contents of your repository. Make mirroring easy is very important, and partial mirroring is a plus.
2: Autoritary: Everything signed, and the certificates must be both distributed with the application that'll access your repository and available within the repository.
3: Free: Really, you don't want to mess with proprietary software unless you have a workforce of the size of Debian's.
Optionaly, you can permit people to access several different repositories from the same application, and require hight quality from the code in the central repository.
Also optionaly, your software (that will access the repository) can export the list of installed programs and synchronize the system when inporting such list.
Rethinking email
As a PC gamer, are you sure you don't mean "mainly do to games?"
Please stop stalking me, bro.
Dude, one time, I did that... registry exploded...
word of honor.
Please stop stalking me, bro.
I know it's trendy, but I've often thought that tags would help a user navigate through the massive lists of oss software that you can find out there. You could integrate some sort of moderated tagging system that would allow the repository manager to approve tags before they are displayed...
You must be new here...
This is actually something I have been looking into as well, and have discussed with members of my team (I'm a PHB) as a way to get more acceptence of open source software.
Right now, within our organization, we have to go through a rigorous review process before a piece of open source software is allowed. Everyone from helpdesk to operations to security to legal weighs in.
One of the biggest arguments we get is that there is no way to manage the updates. Some software like Firefox has a builtin update check, but others do not.
Like it or not, one of the big reasons corporations tend to stay Microsoft focused is the availability of tools for managing large scale deployments. It may seem counter intuitive that managing hundreds of Windows desktops is easier, but Microsoft put time and effort into simple tools that provide for automatic updates and patch distribution.
I believe that if there was a consistent mechanism for keeping open source software managed and up-to-date on Windows boxes, then there would be more likely hood of corporate adoption of those same tools.
These projects truly are a testament to the true flexibility and power of apt-get, even within a Windows context. Side efforts, such as an ncurses based implementation of Mac OS X's Expose feature for dealing with multiple apt-get sessions, a SIMD/MMX accelerated apt-get, interplanetary control software with apt-get, and last but not least, a dselect-based implementation of iTunes.
While I applaud the efforts of those seeking to bring a more GNU/Linux-like package management experience to Windows, we should not forget the efforts of the early pioneers.
GNUstep does this on *NIX. You need to launch the apps using a file browser that knows about them, or the command-line 'openapp' tool, but it works beyond that. There are some really nasty hacks required to make up for deficiencies in various linkers though...
I am TheRaven on Soylent News
You're a little late. You can already get auto installers for any number of spyware and virus packages.
But Windows is far more advanced than Linux. In Linux you have to type "apt-get " or "yum install ". In Windows, you don't even need to do *anything*. These uber advanced spyware packs just install themselves! How cool is that?!
Without installing, there is no way to ensure that any dependencies are already installed. You cannot depend on anything other than the most basic system services, unless you keep a local copy. Then 100 applications could keep the same local copy of a certain dll file, which wouldn't really be efficient. It would solve version incompatibility problems though.
And I've often thought that the way windows works for programs is entirely stupid. Why does my program need to store DLLs in system32? Why not just store them in its own program folder.Windows programs can store their dll files in their own folder, and many do. The reason to install them into system folders is so that other programs can also use the same libraries without installing their private copy.
Why does it shove stuff in the registry? What's wrong with an INI file, like we used to have in W3.1 days.Cause that's old, dude. The registry is the way to go, since text files are sooo obsolete. It just shows that Linux is stuck in the 80s, still using text files for its settings, when they could use a marvelous binary database like the registry instead.</sarcasm>
Watch out if you use this.
Don't set your repository list to 'stable'; cause it will only leave you a notepad and a calculator.
If you mod this up, your slashdot background will turn into a beautiful sunset!
Please, please have a look at 0install. I don't think centralised repositories are the answer, and I've been wanting something like 0install for windows apps for quite a while.
Is this an attempt to make Windows more familiar to the Debian user (hoo boy, how about *that* for a turn around!), or solve a real problem with installing programs in Windows? Most of the commercial software development systems I've used came with a free entry level copy of Install Shield, which in my experience is one of the easiest to use, most powerful ways to install Windows apps -- no matter what twisted logic you need to use to get your program working on a user's machine. And the installations created are easy for people to use, too. You just look for "setup.exe" and run it. Yes, there's still DLL Hell, but it seems to be less of a problem these days than it was before.
This is a solution looking for a problem. What problem does this new installation mechanism solve, anyway? How does this help the Windows user? It seems to me like it's targeted at helping the Debian/Ubuntu crowd work with Windows in a manner more familiar to them.
Programs need to install and operate like the OS they're running in. A Windows application shouldn't look and act like Debian or Mac or a Mainframe, or anything else. Same is true of a program in those operating systems as well. Native look and feel, from installation to interface.
Sorry, but I don't see this thing as serving any useful purpose. It would be like me writing a version of Install Shield that ran on Debian. It's alien to that environment, and just doesn't make sense.
"My country, right or wrong; if right, to be kept right; and if wrong, to be set right." --Senator Carl Schurz (1872)
Forgive my cynicism, but I can hardly see instructing my mother or younger sisters like this as being easier to access:
"Okay, load up a terminal window."
"What?"
"Click Start > Run > and type 'cmd'."
"OK, now what?"
"Type apt-get install open-office -s -d -565"
"What was after the second dash? Look, can't I just use Word?"
The registry is a pain in some ways, but good back up habits can deal with that. Can't you just make a backup of the registry regularly to alleviate this issue?
Right off the start you have to decide if you are going after home users who need to update one system or corporate admins who need to update many. Home users will be looking for something simple like MS's Windows update feature. They don't have to do anything except restart after the system informs them that an update has been done. Corporate admins will need lists of exactly what files are updated, what the dependencies are, a test sequence and then a mechanism to push these update out to multiple users. They are very different types of systems and you need to either pick one OR at least keep both needs in mind.
A similar project, using the GPL license, in that it wishes to bring Linux software to the masses.
http://www.openlina.com/
You're talking about making a software installer for "the common man", and you think that this person will actually care whether or not the system uses MSIs? You may as well ask the person to go and write a doctoral thesis on quantum physics instead of make that choice because both options will have about the same effect on the user.
It's great to have a discussion among developers about whether or not MSIs are the best way to implement this system, but for goodness sake, don't go rubbing the poor users' noses in the issue--most of them will neither notice nor care that the option is missing.
Don't get me wrong: users love to have choices, but they don't want to have those choices. Here's a good rule of thumb: if your roommate at university who is a Computer Science major, plays video games for 20 hours a week, and thinks that Magic is a card game that they made for people without enough imagination to play D&D would want the option, leave it out. On the other hand, if your mom would want it, put it in.
Linux will gain market share over Windows by being better than Windows. My experience with open source came through open source applications on Windows. I use those applications because they are superior, not because they are free. I think those apps will work even better if I replace Windows with Linux. So think of open source apps on Windows as a gateway drug to Linux (or *BSD).
http://windows-get.sourceforge.net/
Why not persuade Google to release their Google Updater under GNU and let OS communities include their own repos with it? Just my $.02
I'm not suggesting that your software be cross platform, but that your software should help developers who want to distribute cross platform software.
Could you support something very close to deb packages?
Could you support LLVM (http://llvm.org/)?
Unattended (unattended.sf.net) is a great tool for such things, but more geared towards initial setup. I used it for software deployment at a company with ~150 employees, admitably not a lot, but enough to save me a few moments everyday. Take a look at the CVS repository for their install scripts. They use perl, but if you're comfortable with it Windows Scripting Host (*gasp* I suggested using VB scripts) makes it immediately accessible for people who may not, can not (some policy), or do not want to install something outside of what is required on their harddrive. Personally I think replication of the repository would be nice. If you structure it nicely you won't have to replicate parts you never use, such as "games". Nathan
Wipt is an apt-like tool that uses MSIs and a repository; might be useful as a starting point.
I'd say as a rule, don't allow apps that require a reboot after install or uninstall. That's one of the most annoying things about Windows! Microsoft actually recommends to developers that installers not require a reboot after install or uninstall, but they seem to have a hard time following their own recommendations.
When I got my last Windows box, the first thing I did was go in and uninstall all the junk I didn't want that came pre-installed. It took 5 times longer than necessary because every time I uninstalled something, I had to reboot the machine. Also, I generally have stuff running all the time that I don't like to stop, if I don't have to. Having to reboot the machine is just a huge interruption for me.
If I remember correctly .msi files (also sometimes embeded in .exe files) are some basic form of a packaging system. It may be useful to latch into that to extract the relevant data and to convert it to .deb or whatever format you are planning to use.
Also: Is this project the actual packaging system (dpkg), the distribution system (apt-get + repositories) or both?
You're missing most of the point here, which is not about failure and backups and recovery: it's about independence and flexibility. As I said, we *should* be able to pick up an app with its configuration and all our customizations and simply move it around, whether that's within the same OS and FS or to another system entirely. We *should* also be able to do that with UI and GUI customizations to the OS and OS utilities, as well.
It's precisely because of the Windows Registry and developers' utilization of and dependence upon the godforsaken thing that we can't do that. Once upon a time, pre-Windows 95, it actually was possible, and still is with other operating systems.
It's precisely because of this Registry stupidity that utilities like PC Magazine's COA and Vertisoft's RemoveIt (which actually had awesome app archiving and migration abilities) came into existence. In the absence of the Registry they wouldn't have even been necessary. They have no Linux equivalents at all.
You've been so blinded by the 30-foot-diameter Registry tree blocking your path that you've been completely missing the entire forest of possibilities beyond it.
You're targeting the Windows platform. So you should hook your management system into the Windows Installer system (MSI). There are a number of documented interfaces (see msdn.microsoft.com) that can be used. This will provide (a) the ability for programs in your system to appear on the Add/Remove programs list (it'll still go through your installer if you get the scripts hooked right), and (b) you may even be able to manage programs already installed through native (MSI) or other installers as well.
Also, I would recommend you follow a path more like SubVersion when it comes to the scripting side of things. For example, do not define the "CygWin Sh" as being part of it. Rather, define an interface in a language like Python (no, you do not have to use python itself - you could use Perl or Windows Scripting Host or whatever). This will give you (i) a bit more portability, and (ii) the ability to do more stuff. As awesome as bash shell scripting may be, it's just not for the Windows environment, and you will not get as many users of your system if you use it.
Try to make your system as native as possible with as few dependencies as possible. Subversion, for example, will typically bundle a library for the python engine with their Win32 releases. So you don't have to install python yourself. Fewer dependencies means better, more portable functionality. And when it comes to Windows, the more native you are the more users you will attract.
As an example, I ran a program that required 100% native Windows functionality. Even putting our build system under MingSYS to get environment portability (so we could port to Linux/Unix using the GNU AutoTools toolchain) was not allowed. This was especially true when it came to the installer. We could not tell someone to go install another program so they could install or use our program. I am now looking at CMake as a replacement for the GNU AutoTools toolchain as it provides native support on the platforms I need. So please, please, please do yourself and the rest of us a favor and build native tools that do not have much external dependencies. Subversion does it. CMake does it. KDE is even moving that direction and providing Windows support (with CMake, btw).
And - fyi - you don't need Cygwin to do it.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
First off... before reading the criticism below, understand that i use gentoo, (k)ubuntu, mac and windows at home. I love the package system describe above, and i FULLY support this project... but...
As a web / software develloper myself, i fear i run into the age old question with this. Who would even use this? The /. community who already mostly looks up open source software? Users who already use gentoo / debian type software? Not likely... why would they be using windows in the first place (other than for gaming)? =) I have mac,linux and windows systems at home, and i run vlc / firefox / open office on my systems. I'm already converted. The problem you have is that the people this NEEDS to get to is the people who don't CARE. My parents for example. They just want to check their mail... or check cnn / reuters for news. They don't care what browser they use. Windows "conveniantly" gives them a browser already. While i did install firefox for them, if i hadn't... they never would have downloaded anything new. This type of software also has the problem of potential information overload. if i just want a "mail program" ... which one do i use? The default windows one? The one from Office? Thunderbird? Eudora? People like my parents... who sadly make up a HUGE portion of the population don't care to look everything up and choose the "best" (best suited for them)... they just want anything that is there and will give them their mail. As a result, they will use the first thing they find (usually office products that came with their ridculously overpriced HP / Dell / Compact computers). They don't want to have to look at a list of stuff.
The only suggestion i would have for this system to work... and to achieve the goals that many described here on the /. forums... is that you have to make this "Macish". What do i mean by that? Make it pretty... make it so that it by DEFAULT only shows the "featured" .. or "most downloaded" items... no more than say... 3 on the beginning list (per section) .... show pictures for EVERYTHING (show off how pretty the products can look / be)... descriptions... etc... but the key here is to make it PRETTY and do NOT overload the information. If you show everything at once like the file managers in ubuntu where it lists EVERYTHING you can download (by default it shows a ton of stuff per section) ... that would be a garunteed way to get people to NOT use the the software (understand, i'd want an ADVANCED mode where i can do just that...see all options type thing...but not by default... aim for the weakest link). Someone who already accepts the idea of open source (like me) will be using this software from day one .... someone who is new, or doesn't think they NEED to change, or doesn't know about open source... needs to be persuaded by "Save money" and "easy / friendly gui" things. All achievable by this project... Especially with someone like google helping to advertise it! Port this GUI program over to mac / linux (same look and feel, but different backends per os/distro)... and you have a cross-platform open source godsent program.
The details in the background can be read by most of the other posts on here =)
I would love to be able to use OpenBSD, I have a server running that X working and firefox installed, the problem is that I can't switch because I need outlook.
:(
I have an axim that can only sync with outlook or windows contacts
That was amazing: parent's comment got modded-up as "insightful", even though the "insightful" comments he referenced were completely fictitious and meant to be funny . People moderating are just skimming the comments and not even fully investigating before they mod it this way or that?
I wish there were a relevant Snopes article I could quote.
But is absolutely fucking hilarious. Read those links!
I quit!
It'd be nice if the installer could ask you where you want it installed, or even just tell you where its files are going.
Joe User won't care, but you'll easily be able to find it.
X:\path\to\WPM\packagename
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
http://www.theopencd.org/ TheOpenCD.org
While I think this is a very nice effort in general, it's more or less useless as long as the included software is several years old:
OpenOffice 1.1.3
Firefox 1.0
Thunderbird 1.0
etc...
This needs to be up to date if it's to be useful.
The packaging mechanism is a method of delivery that doesn't munge the registry and facilitates easy installation and removal.
:)
Just a clarification.
-Ed
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
It's not enough to create a package repository system; that much has been done before (Cygwin uses one, for example, and you could pretty easily port apt-get and throw a GUI on it.)
The hard part is creating the package repositories and keeping them up to date, and that's a job that just requires a lot of manpower. A repository system without any repositories is pretty worthless.
See ubuntu default desktop for example. It periodically polls update server without the user intervening. When updates are noted, a little tray icon appears. Then the intuitive update-manager runs when they click, providing further tray icon/icons with any instructions to make sure the updates go into effect (i.e. reboot or restart firefox, etc...). Updates is easy and every modern desktop platform including OSX, MS, and most desktop-oriented distributions tackle it for the core product.
/usr/bin, /usr/lib, et cetera. Rather than change the traditional layout to sanely accommodate application distinction, they went a path that ultimately was more flexible in many ways.
Now, the areas where Windows falls short. The core product is pretty small in the scheme of things. Only Microsoft first-party software is really managed in any meaningful way, and last I checked, only stuff that ships on the Windows install media and some downloads are part of that unified 'Windows update' (i.e. any MS games, office are handled separately). Every big third party software that wants to deal with updates intelligently, rolls their own. In the linux distribution world, the 'core' product is a much broader set of things, to the point that 99% of people can operate entirely within the context of what their default package repositories provide (office applications, games, even installers for promiment third party apps).
Let's presume this is an anomaly associated with the relatively low user-base (which to some extent it may be) and that if in Window's market share position, there would have to be more worries about software packaged outside the distribution. The beauty for both yum and apt is all that third party software has to do to get integrated to the distribution single update manager infrastructure is provide a repositories amenable to the target distributions and have their installer put a file in either yum's repos'd or sources.list.d for apt. This won't preclude third-parties from writing terribly packaged software that choses to roll their own crap, but it makes it more convenient to piggy-back on the distro update system than roll your own.
All this is putting aside the most obvious benefit, the searchable library of software you can install that you have yet to touch containing what is known to be packaged for your system. This is beyond updates, this is new software without the guesswork. In the Windows world, there is little guesswork (it probably is packaged for them), but there is still some (software that was written for Win9x, won't work in 2k-based systems, or would work but needs workarounds that could be described by the packaging software rather than documentation).
Desktop *nix systems by necessity developed far more advanced packaging and by extension package management systems than Windows has. Windows has to an extent banked on the application directory concept ('C:\Program Files\[AppName]', which I like in theory), but did it poorly (not really enforced/flexible enough, files in practice still end up all over the place). *nix systems developed an alternative index and had to absolutely rely on it since most everything ends up in
XML is like violence. If it doesn't solve the problem, use more.
Mind you, I'm not going to go demand that a program in the WPM repositories excise all external libraries. This is much less important on Windows than on Linux, as programs can more easily just use their own internal libraries. In many ways this is simply a way to develop a prettied-up, far cleaner program-fetching and install process that doesn't spew shit all over the Registry.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
I will say it isn't a matter of 'catching up' to other Windows software, this would be well above and beyond the current commercial windows application world, where you have to google in random ways to find the software you want, then run the software's installer (which inevitably each software thinks they are so special as to need an interactive installer).
/usr/bin, others in /usr/lib, some in /usr/share, and the breakdown is obvious. Your storage is architected to accomodate this (in, say, a ZFS enabled world, your filesystem would simply grow as you added fixed storage), so you don't have to ask questions. Inevitably, software managed by such a system would likely not mesh well with traditional windows applications.
/usr/bin and such.). Of course, for the reasons pointed out above, this may be the only sane way of achieving these goals under the restriction of trying to base it on Windows.
As many have pointed out, you don't want a new 'packaging' system (i.e. msi replacement), you are looking for a sane repository system to architect (which may need something other than msi depending on msi functionality). It would be nice to run an application that knows absolutely you are looking for apps to install, that groups them in sane ways (someone mentioned tagging system, which could be a nice add to traditional repos), and when you click to install, it simply installs it without asking questions unless something really important needs be asked by the package.
A difficulty in Windows is that chosing where to install software is not as straightforward as *nix systems. In *nix world, you know you put certain bits in
And finally, I would also like to mention that Cygwin has already started down this path, though they aim to be a more purist reproduction of a *nix environment (i.e. graphical apps require X to run, for the most part it 'pretends' to be in a unified filesystem space with everything in
XML is like violence. If it doesn't solve the problem, use more.
Even better, use the version of the library in the filename, and symlinks to the latest version. The old version continues to exist (or can be removed without conflicting) while the new version is available as the common, unversioned named to new programs that are started. You can even keep old versions around for compatiblity's sake (compat-libstdc++, for example).
Setting this up is what ldconfig does. Why doesn't Windows have this capability (or is the answer the 8.3 limit on filenames still: I notice that most of windows\system{,32} is composed of 8.3 dll names)? Admittedly, this isn't used as often as it could be with Linux library packaging (because of other development compatibility issues (witness packages like libgnomeprint22), and the lack of a "release" version field that ldconfig knows about), but the capability is there.
"even Microsoft suggests that developers put that dreck in a folder in X:\Documents and Settings\Username\Application Data or \Local Settings."
./System32, and other dependencies randomly scattered in X:\Documents and Settings\Username\Application Data or \Local Settings.
A suggestion isn't much of a standard, even coming from Microsoft, is it? Especially not when developers have an economic incentive to continue using the Registry. Use of the Registry by applications makes less coding for devs and makes the apps harder to pirate or "migrate".
That last isn't talked about much, but think about it: if the entire app and all its dependencies was located in a single folder, "pirating" it would be as easy as copying that folder. Once upon a time, in fact, that's exactly what people did. Now we have this Registry and all these "shared" DLLs (which in fact are rarely shared) in
Wonderful layers of obfuscation.
Look at MinGW.
The main web page says to install outdated broken versions.
The more explicit howtos say to install packages which are not listed on the sourceforge download page.
Everyone who gets it working, says they ignored the web pages and all the directions for newbies, and did a custom install of individual pieces.
What a terrible system, when the main directions and the "newbie" directions are so broken that noone can make them work.
It's humor by farce, but, one wonders what it could be if it were not such a farce...
apt-get install debian-etch
A computer once beat me at chess, but it was no match for me at kick boxing. Emo Philips
After a short twelve years of chasing Windows 95's tail lights, someone finally figured it out.
Now if only he could influence how Lunix people think.
But as you can't (or don't want to) change the registry, use Portable Apps instead. There are portable apps for a number of FOS apps and as they're designed to be run from a USB key they would all work quite well :)
Sure we wang, can.
What about a special license to do so?
A license that:
This could restore the "killer apps" incentive to move to a Free OS.
don't have time to read the article, but if it could keep track of the installed version and notify the user of updates (for apps that dont already support it). even download the available update
FishWithAHammer,
I think this is a grand idea and it does appear to already be seeing some progress and attention. As a Debian/Ubuntu user with a need for Windows for work and a need to support Windows machines on many friends and family systems, I am thrilled at the support possibilities this could present. Even just *another* and possibly unified place for friends and family to update all their FOSS software. However I do already see a problem with this grand plan... The inability of the hosting service to support slashdot traffic and the apparent inability to host torrent links is going to be a huge sticking point in getting people to even try WinLibre much less be willing/able to access a WinLibre maintained repository.
I am sure there are solutions to this beyond attempting to buy larger and larger collections of servers to support said downloads as that is going to be a large expenditure. Perhaps having a sister site hosted in a "legal torrent" friendly country would be a start, for both the full and mini installers. Supporting transparent torrent downloads of install packages within the mini installer. And creating an "official" mirrors list including update times and possibly even a special "repository" which actually just references and updates a store of referential origin URLs.
All but the last of these has been at least attempted if not established already within the Debian/Ubuntu user base, the last only hasn't because of the different nature of package origination.
Best of luck,
-i
http://piratepenguin.is-a-geek.com/~declan/freecd
I'm pondering a very elaborate (much more so than apt, more like Conary) cross-platform package management system that I would use as a part of that FreeCD project of mine.
Over the Summer, I might get a good move on with it.
Volunteers - people interested in package management on GNU/Linux and Windows (with understanding of Windows concepts such as the registry, services system, etc), would help speed things up considerably! Mac OS X and other OSes we're also interested in.
So yeah, I help admin the CPAN, and I'm currently working on upgrading the CPAN packaging tool-chain, in part to help people like you automate the process of generating operating system-specific packages.
:)
And I also kicked off the new Vanilla and Strawberry Perl Win32 Perl distributions and created http://win32.perl.org/
I really think we should talk
Wow, I had to stop and giggle for minutes about this. A lot of postings on slashdot are marginally funny, but this one goes down in history IMO.
First off, i would say that this would be a great asset and a system I would use.
I would hope that with Google behind it we could see a big uptake from the developer community.
I would love to see all my favourite freeware programs use (this?) one central installer system.
One featuree I would love to see if - when reading here or on other site about a new freeware program there could be a link you coudl click that would open up the installer and the "about" section of the program being "promoted", ready for you to click install.
One thing that concerns me is so many programs these days have partnered with other organisations such as Mozilla or Google to also "advertise" and encourage you to install a browser or toolbar at the same time, do the freeware developers get some kick back from this? Would this new system be a deterrent for freeware developers to join if they could not longer be associated with the additional installs?
What about all the install options a typical windows program has? Shortcuts on desktop, quick launch short cuts, start menu group, associate/integrate with windows explorer and/or web browser, registration, emails of news, bookmarking of the devleopers www site? - It would be great if this installer project could standardise these options and allow the user to express their preference once.
what?
-- @rjamestaylor on Ello
I usually know the name of a program that I wish to download, it's easier to google a program than try to find what horrid butchery of its name was used for a url.
I think it'd be nice if such a system had a "similar to:" feature. For example, lets say Joe User has the package manager installed. He goes to it and looks for "Photoshop". Well, he's not going to find Photoshop, but if setup properly he would instead find "GIMP".
This space for rent.
why do we have to push Linux on people?
...")
...
Because Windows is a plague pit. Its broad deployment and fundamental insecurity has spawned two multi-billion-dollar industries:
1) Exploiting its bugs (initially for fun, then profit, as a criminal enterprise.)
2) Patching its bugs (inadequately - both because it's an impossible job and, if it WERE possible, so the customers must keep paying fees and coming back).
Windows security problems (and their inadequate active-immunity workarounds) have resulted in:
- Viruses that spread broadly and destroy data, including:
- TARGETED viruses that attack particular products or institutions.
- Spyware, that:
- profiles users' activity
- steals their personal information and
- cracks their financial accounts, enabling massive theft-by-fraud and "identity theft"
- TARGETED spyware (not widely deployed and thus not caught by reactive defense tools), used for:
- corporate espionage
- governmental espionage
- political espionage
- MILITARY espionage
- "Botnets" of compromised computers, that:
- Conceal their operators, insulating them from traceback and aprehension
- Amplify activities, enabling:
- DDOS attacks - for fun, for extortion, and now for war
- An indunation of Spam email that has practically destroyed email as a communication medium and placed a further strain on the network infrastructure.
- Massive initial releases of revised malware to bypass reactive anti-malware measures.
But worse, it has created the perception that this sort of computer misbehavior is normal, acceptable, and perhaps inevitable.
(Which it may have become. Now that the malware infrastructure is so well developed and the business models are in place, much of it can be ported to other systems. Thanks, Microsoft.)
This is not just a matter of the trillions of dollars Microsoft's bugs have already cost. It's become a tool of politics, espionage, and war. Microsoft's products are pervasive in industry and government - the complete infrastructure that supports and defends our lives.
It's not enough to secure the weapons systems themselves. Come wartime virtually any information leak can expose troop locations and movements. (The quantity of toilet paper shipped to a port, for instance. A classic example was the time an officer training academy's war games were swung because one color-army located, attacked, and captured the other's field headquarters. They had used a scanner to find where a local service had delivered a porta-potty to serve the fastidious commanding officer of their opponent.) Even a tiny disruption of the supply chain can lead to an event-cascade that can swing an entire war. (This has been known for centuries. "For want of a nail a horseshoe was lost
How much of the current problems in politics, war, and the economy are the result of exploitation of Microsoft's bugs?
Until it can be rendered sufficiently secure (if that's even possible), Windows, Explorer, Office, and a host of other Microsoft tools (and the expectation of flakeyness they create) need to be displaced. In government, industry, and homes. In health care, device automation, inventory control, banking,
The replacement doesn't HAVE to be Linux. But it DOES have to be MUCH harder to exploit.
OTOH, just how portable are you expecting configuration to be? Do you expect to be able to copy a the
In short, the registry is a hierarchical database optimized for large numbers of small entries. A filesystem is a hierarchical database optimized for a smaller number of large entries. Problems with people abusing the registry aren't going to be fixed by moving to a more general hierarchical database with unique sub-formats. If anything, the registry is better because it is more specialized.
It's just marketing from Apple. It intentionally positioned its computers as expensive/exclusive devices.
And will go further to say that Firefox and OOo have enjoyed this level of success (from Windows) BECAUSE users didn't have to wrestle with a bloody package-manager to get the software installed. Windows and Mac users always get the earliest access to the latest FOSS updates, while Linux users must wait for their repository to catch-up or learn how to fight with the package manager.
In fact, Mozilla is so fed up with *nix package managers and umpteen different repositories, that they no longer even distribute their Linux binaries in RPM nor will they self-update.
Repository "priests" insert themselves between the end-user and the application developer, making things more complicated in the end for everyone except the thin-client sysadmins.
The respository/package manager paradigm cuts across the grain of personal computing culture. Very few Mac or Windows users would put up with what amounts to thin-client management methods for long. Note that ports and fink have been available for the Mac for some time, and only a sliver of the Mac techies ever use them.
why not just make a TVUnderground -style website that contains all open source software? You submit your software, it is added to the list, people download and rate it. be sure to have a page that has the info for each program, explaining what it does, etc
http://www.sourceforge.net/projects/appupdater
Unlike most Windows package managers, this will automatically find programs already installed on your system and keep them up to the newest version.
On Windows one of the most annoying things that that things install themselves -- which gives them full control over what goes where, up to modifying obscure registry settings and overwriting files. That means you can never be sure you can uninstall something.
He said he was making this package manager for free/open source software, not all windows software. Given that the source code is probably available, it would be possible to determine what files/settings the software requires to allow safe installation and removal. How he would deal with MSIs, I'm not sure since I don't know how those work.
It would be interesting that you keep an eye in compatibility with some solutions which build upon the debian package system, such as debtags: http://debtags.alioth.debian.org/, for instance.
...
But really, no ponies? Awwww
...some time ago, but didn't really finish it. It was planned as a universal updater, so that not each and every software has to implement its own update routine, and bother the user the moment it's supposed to start with "new version available". Here goes:
http://sourceforge.net/projects/usus/
It actually runs, but the demo XML that lists the avaialble software versions is way old, and the list is small, so no practical value ATM. Anyone wants to beef it up, be my guest.
Magnus
I am the author of WinPackMan (http://www.winpackman.org/). And let me tell you, it's harder than it looks. Initially, I was going to use the whole "use NSIS, or the normal developer's installers" approach. It's just not practical. A normal program installer spreads things so far over the entire system it's incredible:
r rentVersion\Run, HKEY_USERS\*\Software\Microsoft\Windows\CurrentVer sion\Run)
*Main folder (C:\Program Files)
*Libraries (C:\Windows\system32, etc.)
*Some "common files" (C:\Documents and Settings\All users\*)
*User specific files (C:\Documents and Settings\User\*)
*Start Menu (C:\Documents and Settings\User\Start Menu)
*Program Specific Registry (HKEY_LOCAL_MACHINE\Software)
*User Specific Registry (HKEY_USERS\*\Software)
*Run Registry (HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Cu
*Start-Menu Startup (Documents and Settings\User\Start Menu\Startup)
*Environment Variables (of course)
*Any other misc things (fonts, etc).
*Of course, these vary somewhat between versions of Windows. And you have to keep track of everything for uninstall. As well as any created during the course of running the program (firefox profiles for each user, etc). I mean, good lord. With WinPackMan, I've tried to standardize it a little with ZIP packages, but it is EXTREMELY difficult. The current idea seems promising, although my time is limited at the moment. But I can't even imagine something like firefox being distributable that way in the forseeable future. If your starting out, try learning from past mistakes. Or have an epiphany.
Really?
Last time I looked for an application, I wanted something that would allow me to copy the full path of a filename from explorer to the clipboard. I googled for "copy filename to clipboard" or something. What would you do with a windows package manager?
Not quite sure what your point is about a url.
Please drop the "no registry changes" requirement. A "no registry changes outside appropriate application-specific areas" rule is much more appropriate.
/etc, including adding them to config.d directories for other packages, but may not overwrite or modify config files managed by other packages.
A program can quite reasonably create its own software configuration tree in HKLM\Software and/or HKCU\Software . It's even reasonable to have a dpkg-like --purge that deletes that tree, though it might be preferable to only do that to software in a subdir like HKCU\Software\WinPkg and patch all your apps to put their config in there. Not sure.
What programs should not be doing is poking around in other apps' registry entries or changing system registry settings.
It's a bit like having policy that packages may create configuration files in
You're missing most of the point here, which is not about failure and backups and recovery: it's about independence and flexibility.
In that case, how is the Registry any different ?
As I said, we *should* be able to pick up an app with its configuration and all our customizations and simply move it around, whether that's within the same OS and FS or to another system entirely. We *should* also be able to do that with UI and GUI customizations to the OS and OS utilities, as well.
You can. It's called a user profile, which stores a copy of the user's Registry Hive, which is where applications *should* be storing their per-user settings.
It's precisely because of this Registry stupidity that utilities like PC Magazine's COA and Vertisoft's RemoveIt (which actually had awesome app archiving and migration abilities) came into existence. In the absence of the Registry they wouldn't have even been necessary. They have no Linux equivalents at all.
The problem here is not the Registry, it is the broken applications. The Registry, in an dof itself, is not causing the problems you are describing.
You've been so blinded by the 30-foot-diameter Registry tree blocking your path that you've been completely missing the entire forest of possibilities beyond it.
I say the same thing about people who think the best solution to configuration and runtime data is text files.
The problem with Linux as a desktop is it's lack of quality software in many key aspects that people use on a daily basis not the lack organization, though this will help, ultimately the problem is much of the software is not funded and suffers compared to profitable platforms. It's unlikely you will ever make a case that will draw a majority of quality developers to a low profit platform. Developers already get paid too little. Open source just makes this worse and the quality of most open source software is reflected in this quite apparently. At least as far as desktop apps are concerned. Users are not looking for minimalistic programs like administrators might be. They will not like or use a command line program simply to save resources. 3d desktops and widgets are getting Linux nowhere compared to what higher quality desktop software might score them. Take a not from Apple. The way to do it is to make few, but high quality applications. Linux in most cases suffers from the overly diverse nature of open source. It is highly versatile but not focuses enough to grab users with any common experience. It's more like a pile of applications with many duplicate interfaces. Not that win32's interface are exceptionally standardized but the fact of the matter is that people have learned that interface and a low cost OS isn't nearly enough to switch them over.
.. since it's source code is available, but it's not reallying making a dent in the desktop market beside the few and random I hate MS enough to limit my computer with Ubuntu. Most people would not only pay 50-100 dollar MS tax, but they would pay 300 dollars or more for a quality OS. 100 dollars a year or such is not a lot to ask for something than needs such constant support and plays such a central role in so many lives. Think about how much more so many other things that accomplish so much less cost per year and it really shows the direction of where the PC should be going. We don't want a crap PC Lindows revolution and getting people PC's that can't remotely provide the same multimedia/gaming experience to save 50 dollars is stupid. We should be pushing for better OS's not cheaper ones. The more people become reliant on computer the more willing they would be to shell out 100 dollars or more a year. Some people pay that much a month just for bandwidth if a quality OS offered a better experience and/or increased overall productivity people would pay it happily.
WORK ON THE SOFTWARE. Apple is easily taking Linux's market share, and they aren't interested in sharing. If any major OS company is looking for form a monopoly it is Apple, just as they tried to and failed in the 80s. Linux has everything apple has and more yet it's vastly less appealing to a majority of users because it's unorganized and lacks those KEY programs Apple has basically handcrafted to more of less make their NIX distro vastly more popular. If Linux had intuitive interface ideas and a better feeling of completeness as everything is actually made to work together it could have been a real contender in the desktop market YEARS ago. It's too much of a piecemeal platform and has been suffering from that problem for quite awhile. The lack of centralization is admirable, but ultimately not very marketable. If the world falls into mass chaos perhaps Linux would be the best suited OS
Asking them to downgrade to a harder to use OS that support less software and calling that a good PC experience is not good marketing and that's why Linux desktops don't sell. Windows was NEVER that expensive when you consider your using it constantly AND the updates are free. It's office and other business servers and apps that low cost OS's have an edge because that's where MS overcharges the most, such as Office and Exchange. However even then ultimately I don't think most businesses mind spending a couple thousand dollars more for what almost always amounts to increased flexibility in their business. Maybe it's not as secure or fast, but it's still the easiest OS to use and supports vastly mo
You should take a look at other installation systems. This is a well-studied problem on Windows. In particular, try looking at what the Nullsoft installer does. It's a pretty lightweight installer, very powerful, has lots of Windows-specific things (like rollback-able registry updates) too.
It might be your best bet to try to build off of something like this system to include versioning and dependency meta-data. Then all you need to do is solve that piece of the puzzle, rather than reinvent the whole wheel in the process.
There are Portable Apps: http://portableapps.com/, now profiled as something you can
carry with you on your USB memory-stick. These are applications like firefox, gimp,
etc etc, which do not need "to be installed". They have been modified to ignore
as much as possible all that MS-registry nonsense. You can guess: when I need to install
firefox on some computer, I just simply copy the portable one to some suitable place
on the disk, and I do not need to be "Administrator" or whatever they call it.
So instead of inventing installers, one should be "inventing" "portable Applications".
Be it on windows-whatever or even on linux
You know, the way that windows-install/removal programs _should_ work.
http://ifcx.org/wiki/AntAnywhere.html - not quite what you are doing, but might be relevant.
thanks
vice chair orange county java users group (ocjug.org).
Nice project! It will enhance the acceptance of free/open source software on windows platforms. Have you considered to build a system like gentoo linux portage for maintaining the packages and their dependencies among them? The portage is already ported to MacOSX and Solaris. Some Problem maybe the bash script parts of it. But the core is written in Python.
A web browser executable (and all its other files) belonging to an ordinary user, sounds like great security practice!