Slashdot Mirror
A Gentle Rant About Software Development and Installers
Nerval's Lobster writes "This is the story of the comparison that just wasn't meant to be. It's a story of everything that can go wrong in the customer end of the software world, and some thoughts on what needs to be done, especially in an area known as Installers. I'm a software engineer with 25 years of experience, and for years I've wanted to point out some of the shortcomings of my own industry to help make it better for everyone involved—not only for the end-users, but also for the IT people who have to support the products; the salespeople who have to sell and later, possibly, apologize for the software; for the executives whose hands are tied because they don't have the technical knowledge to roll up their sleeves and help fix problems in the code; and for the programmers themselves who might get stuck with what some consider the absolute worst position for a programmer: maintenance of crappy code written by programmers who have long since left the organization."
Problem solved. I will come by later to pick up my consulting fee.
apt-get and checkinstall.
Do we need anything else?
Not as a user, the guy has been writing software for 20 years and complains about poor design and bugs? Nerval's Lobster should clean up his own house.
I wonder how the UNIX SAP software fared; Windows is not a robust OS. Flaky hardware will make Windows and its software crash every time, while apps running Linux on the same flaky machine work fine, as I've seen on two different occasions.
Part of the problem is the tools. A poor workman always blames his tools, but a good workman doesn't use faulty tools. The tools I'm talking about are compilers, 3rd party installers, and OSes.
There really is no excuse for today's shoddy software. Why should an automobile last longer than an OS?
Free Martian Whores!
Instead of creating single exe. Memory and disk space are cheap. Portable application creators are easily and cheaply available (e.g. Cameyo.com - both free and excellent at what it does). It's easier to copy a single file than to go through the hell that is installation for most apps.
Please do not read this sig. Thank you.
As long as you can incrementally improve the design and code, maintenance isn't a bad position to be in. I've seen far too many programmers who whine and whine about how much the code base sucks, but they never do anything to make it better. They insist that the only way to go forward is to rewrite the whole thing, a project that is almost inevitably doomed to failure. If you actually design new code, implement policies if the company doesn't have any in place, and clean up the old code while you're hunting bugs, it can be every bit as rewarding as new development. ANY programming project can be a joy to work on, or a nightmare to work on, and it's entirely the discipline and ability of the team and its management that makes all the difference.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Disclaimer: My head hurts too much to read the article, so this may or may not be on topic.
A former colleague of mine likes to define "professional software" as "you need a professional to get it to work". Makes for a nice soundbite, but it's also very often right on the money.
That, however, isn't a problem with installers. It's just a general lack of quality and polish.
I do also have a problem with installers as they are commonly found in Windows software. Too much human interaction required. Obtain the software, launch the installer, click to actually start, oh wait, have to click acceptance of the license agreement, click to accept where it wants to install stuff, click once more once it's done. That's about the lowest number of steps I've seen. With aptitude, it's one command.
Please correct me if I got my facts wrong.
Why does every windows application programmer think their program is so special or important that it needs to run in the background? The first thing to speed up any computer is to kill all the crappola trying run at start up. A program should run when started and when exited from it should completely shut down and even delete any temp files it created. I did a cleanup on a customers machine once and deleted over 10,000 temp files. That is lazy and stupid programming.
Professional Politicians are not the solution, they ARE the problem.
Because most Enterprise software (and I manage a product line which is definitely in this category) isn't something so simple that you can install it with RPM or Installshield (or whatever the heck MS calls it now). There are multiple interacting services, very specific dependencies for things that are often not packaged at all for the target platform and usually cannot be distributed, etc. Complex databases, usually on other machines, have to be set up, XML files edited, etc to even create a basic working environment for our software. Now, MOST things might not be quite this complicated, but I suspect most software that you have to install largely by hand has many of these kinds of issues. Most of this stuff has to integrate fairly deeply with the client's IT infrastructure and setting up the basic applications is only a small part of it.
In our case we have some installers for some specific tools, but the main product? No, it wouldn't materially assist in setup and would just be yet another task to maintain when some tarballs/zips, thorough instructions, and heavy tech support works fine. You're already typically paying from 10's to 100's of K up front and 1000's a month to even run real Enterprise class software anyway. Surprisingly installer tech that was designed around simple desktop apps is just not that helpful. Our installer is a guy that shows up at you office, lol.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
The problems will be the faults of everyone except for the developers and software engineers. Problems are always the caused by the "other guy", including previous developers. According to the developers, they should be the supervisor, the team lead, the manager, the lead salesman, the system engineer, the network engineer and every other position higher than what is beneath them. In their minds, problems only happen when they are not in those positions controlling it.
The funny part about this attitude with developers is they always feel there are two distinct groups of themselves, ones that are awesome and ones that suck. Every developer thinks they are in the group that is awesome and thinks just about every other developer sucks. Just about every developer I have ever known has complained about the existing code, previous developers, and work flow processes, and his/her eventual replacement will do the same about them, it is a predictable cycle and trait. It is a field of work where everyone thinks they are the best and can do no wrong and everyone else does it wrong.
Mod me down but analyze the comments from this story and previous stories and you will see this pattern.
Bullshit. There's not one thing in your list that cannot be handled with an installer. You just don't care to automate the process, and are making up excuses to justify that after the fact.
I have a wide screen monitor. The article uses about 1/4 of the total screen width. The column on the right a little bit more. The rest is whitespace. Resizing my browser window has no effect - just more or less whitespace. I skimmed the article but didn't read it because it is annoyingly narrow and I balk at zooming in or increasing the font size to fill more of the screen. Fixed width content needs to go.
I frequently remark to my colleagues how bizarre it seems to me that after 50 years or so of software engineering, we're still building awful crap. If we were architects, we'd be unveiling skyscrapers built using favela techniques of plugging any old crap together, in the mud, next to a river.
There are lots of reasons, but the two big ones I'd say are time pressures (which we as programmers will never be able to resolve) and a lack of code reuse (which we can resolve). For example, the constant churn of technologies to me is simply a failure to reuse code.
I would start by trying to engineer whole classes of faults out at the language level, as has been done with buffer overflows and garbage collection.
Make static analysis much more anal, forcing the programmer to express their intent up front - static types, constraints, etc. Make the compiler a totally pedantic Nazi. Sure, it's nice to be able to hack shit up in an afternoon in Python or whatever, but then it ships, and the bugs come in, and you end up adding a pile of asserts and whatnot that should have been caught way before the product shipped.
Make unit/integration testing a mandatory part of the build, i.e. the compiler/linker refuses to link with code that hasn't been marked as tested.
If we learned to put the hard thinking and effort into designing APIs, and then reusing those same APIs across whole new classes of problem (because the language makes defining APIs is such a hassle that we'd rather not dream up new ones left and right), I think things would improve massively. Forcing the APIs to be public, but allowing the internals to be as obscure and proprietary as you like, would allow for reuse, interoperability, and hopefully improvement (by replacing particular implementations of APIs with better ones). Add a sane API mechanism for backwards compatibility, so that when you realise the API is fundamentally bad, you can or are required to implement the old API in terms of the new, and you don't just abandon people to DLL version hell. A language could provide support all of these things.
None of this would stop you from writing shitty code. But at least, to do so, you'd have to knowingly subvert the compiler in a bogus way, ignoring screeds of the compiler telling you that you and your code suck goats' balls.
Is there a patent on administering electric shocks every time there's a build error?
Well yes, theoretically I would agree. But, then that damn reality pokes its ugly head in and things are more complicated than we want them to be. Enterprise software, especially web based applications often cannot be packaged as a single file. Companies often want the database to run on their existing Oracle (or whatever) install, which means scripts to build out the tables in their database. There are often existing APIs that need to be called that are custom to the client. That means that after the install you will need to add code to make API calls that the standard install does not necessarily make. Many companies have existing web server farms that they want to run the application on so it will have to be deployed to each of the existing servers or they want to separate the static content from the dynamic. There are a million and one reasons that your simplistic view of the world cannot be achieved in the real world.
No sigs in BETA. Beta SUCKS.
Our installer is a guy that shows up at you office, lol.
That combined with your username is the real LOL.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
I agree. By thinking about installation when creating complex enterprise software, you end up making better quality software. When you're forced to handle the inter-dependencies of complex systems in an installation process, you end up having a better handle on how everything interacts. This has been my experience at least.
It's hard for me to think of any software companies that are worse at creating software that actually WORKS.
SAP and Oracle are notorious for pushing out incredibly expensive, complex products that are impossible to install and generally don't work like ANYTHING else.
SAP, especially, seems to be incapable of releasing a product without a half-dozen show-stopping bugs that require obscure workarounds that you'll only find out about by calling support. I won't even talk about the unholy mess that is SAP's support site.
There's a rule about software that people often forget, and it's this:
"Software quality is inversely proportional to cost". In other words, the more expensive a given piece of software is, the crappier it is. Oracle and SAP are the NUMBER ONE offenders in this regard.
I already have enough experience to say with some confidence: One of the major problems of current systems (and especially the installers, as the author of the topic described) is the lack of attention to detail.
If software X works in the environment Y, the author assumes that X is ready to be distributed. But what happens when the environment is Y + 0.45? Failure. Because X software never considered the possibility of Y not being exactly Y.
But NOOOO, is so "uncool" to spend time covering details, right? After all, "Works on my rig"(tm)
Religion: The greatest weapon of mass destruction of all time
Well, you can make a good installer and not every software is simple and/or small enough to use a "all-in-one" executable. The problem is finding qualified people for the job.
Religion: The greatest weapon of mass destruction of all time
The rant is so gentle, that it didn't even make it into the summary: What's the problem with installers, and why should I care enough to RTFA?
Because RPM/DEB makes assumptions. And some of those assumptions are simply invalid for some use cases.
Ever want to install more than one copy of Apache? Maybe you want your database installed somewhere other than default because that's where your GPFS shared disks are mounted? Ok, the latter is possible with RPM, though sometimes a bit more difficult. The former was also possible, but far more painful.
Complex post-requirements? Sure, RPM handles pre-reqs okay, though not circular ones. Post-reqs? When we were switching away from RPM in 2001/2002, no.
Cross platform? No. Want to get your apps installing on Linux, AIX (ok, AIX has RPM now, but it's severely outdated), Sun, HP, and anything else that comes up? Sure, they have their own installers. With their own unique quirks and issues.
In the end, we used tarballs with a Java/C++ front-end. Far simpler. And, for enterprise software, one of the better installers. Though maybe I'm a bit biased there :-)
Define "necessary parts".
We have a lot of storage space these days, but I don't think every piece of software basically having their own /usr/lib or /windows directory is feasible yet.
which is totally what she said
I'm a developer who winds up having to do a lot of backend support and installs, I've been installing various enterprise packages for the last 6 years. The authors experience is VERY familiar to me. It's quite hit or miss, with some of the most expensive ($40,000+) pieces of software giving the most miserable experiences. You spend days trying to fix this or that, and it winds up being some obscure setting somewhere that only a super-expert could ever understand.
What sucks is that we have to put up with this crap. End users wouldn't stand for it.... but yet sometimes I swear IT staff think it's somehow OK, and they either blame themselves, or think they've "learned" something by going through these dumb install problems and jumping through the hoops. I'm tired of it, and it wastes a lot of valuable time. There's some things that can't be avoided, but the majority of the problems I've come across could have provided MUCH better indications of what went wrong, or avoided the problem altogether.
AccountKiller
To those who haven't read the article, the author posits that testing two same-purpose pieces of software to see if they generate the same result is a simple proposition. Then we find out that the systems are SAP and Oracle. This is not like installing two mp3 players, these are the poorly-defined field of 'enterprise apps'.
I don't disagree that the installation for anything claiming to be an enterprise app is usually hard. Setting either SAP or Oracle ~properly~ requires expert knowledge, and running either ~properly~ requires expert knowledge. This is expected, because it's an extremely complex product which is meant to be deeply customized to your own business solutions. This is similar to the gulf between installing the next version of windows and installing, say, a slackware distribution. One is more about clicking next, while the other requests explicit knowledge of the system in order to tailor it to your specific needs, and even after install requires effort to make it usable. One requires you know nothing, and allows almost no customization, the other expects you know everything, and allows an almost infinite level of customization.
That's why the install of MySQLwas so easy for him. Nothing against MySQL, but I'm not going to put it in the same category as Oracle or SAP. It's not trying to be either of those - it has it's own niche. It just doesn't have the same level of customizations or capabilities.
The other thing that always irritates me: Why the hell would you have a software developer installing 'enterprise' software anyway, unless they're some sort of expert in that software type anyway? Don't get me wrong, I've installed many a developer version of Oracle locally, but I'd be the first to point out that I'm not the Oracle-certified expert that I expect will be running the show in production. Don't people understand that these are separate skillsets? The author states that he came from a j2ee shop running large products, my guess is, he didn't have to know how to admin the application servers. Ever try to dive into enterprise app server configurations? Clustering across firewalled domains with reverse proxies, remote caching, load balancing, certificate management, and active directory tie ins? In something 'big', like JBoss or worse, WebSphere? You could be an incredible java developer, but it has nothing to do with setting up and configuring the app server.
So, he was the wrong person for a task that was, quite honestly, supposed to be hard. Of course he had problems.
I remember being kind of annoying in the early 90s when I started using Windows and had to deal with Installers; as a Mac user, I was always used to just copying applications from system to system (although IIRC, some set resource values during install or copied INITs to the System folder).
A couple of software developers told me DLLs were better technically due to resource usage, but to me it just seemed like a clunky form of copy protection.
I kind of felt the same way on Linux/BSD platforms -- why couldn't everything be compiled statically? How much more disk space would it REALLY take to have an entire system statically linked?
I still think this would be a good idea on Windows, even though DLL conflicts seem to not occur that often.
Why would you want to install more than one copy of Apache? I could understand wanting to run multiple instances if you can't configure the virtual servers correctly, but I don't understand multiple copies.
If you wanted to test different versions, you'd be better off using multiple virtual machines - that way you don't have trouble with one version of Apache requiring different libraries than another one.
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
That sounds like a backwards move to me. Usually, you want config files to be in a separate place than your binaries. What about shared libraries? Do you recommend statically linking everything?
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
Mine too, but it never works that way.
The last thing that gets thought about is dependencies - this is also one of the reasons Android software acquires permissions but rarely relinquishes them. We only know how to grow software, once it starts working the "Job is done, go home".
Virtual machines have a performance hit, require permissions, and don't reflect native hardware. Fine for Apache, but what about something like a file manager, or anything which requires OpenGL currently?
Admittedly there's progress on this front - LXC in the Linux kernel goes some of the way to fixing this problem, though what we really need is a distribution that's LXC aware so it's easy to use.
Because they're better. With package manager it is usually "use this old version" or "compile from source". On occasion you get the rare third option of "add this repository of compiled binaries to your package manager" which is no different to downloading a random installer.
A software package should be one file that is download and run. The file should not be unpacked, it should simple be one executable with all necessary parts inside.
Total and utter crap.
Just a few of many reasons why:
Many more complex packages (which is what we are talking about) need background services (often smallish executables with different elevated privileges required). They also have a huge gui front end which can run at normal user privilege level. From the security and efficiency point of view, only a total moron would combine these into one executable.
Many packages have to modify system configuration items (systemwide config files, registry, whatever, depending on OS). The modifications *cannot* be packaged as part of a single executable (does not even make sense).
Nearly all packages have their own private configuration items (default config files or whatever). Having data files like these incorporated into an executable is totally barking from the security point of view - executables should (almost) never be self-modifying; they should sit in protected non-modifiable storage.
Many complex packages have multiple components of which a typical install only requires a subset. Installing the unnecessary components because they are all packed in a single executable is idiotic, it introduces extra potential security holes.
I could go on like this all day but it should be clear by now that packaging *complex* products as a single executable is one of the stupidest ideas ever suggested on slashdot.
Companies often want the database to run on their existing Oracle (or whatever) install, which means scripts to build out the tables in their database.
Is there a reason the installer can't have a button to execute these CREATE TABLE IF NOT EXISTS scripts in a given database? The installers for phpBB, MediaWiki, WordPress, and the like have this.
There are often existing APIs that need to be called that are custom to the client. That means that after the install you will need to add code to make API calls that the standard install does not necessarily make.
Now you're getting somewhere by mentioning the requirement of bespoke development of a plug-in for each client.
That works for some scenarios, but what happens when the user leaves the business, his/her account is locked and suddenly, critical software no longer runs?
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
I assume he meant virtual *hosts*, which is fair enough, though vhosts arent necessarily the answer to everything.
If you had two physical interfaces to a machine then its not a stretch to suggest you might want to glom an instance of httpd onto each.
Invaders must die
Installing huge enterprisey things SAP and Oracle software is harder than using a package manager to install Apache.
The file should not be unpacked, it should simple be one executable with all necessary parts inside.
So what happens when a security vulnerability is discovered in one of these "necessary parts" statically linked into the executable? If the part lives in its own package on which your package depends, a fix for this vulnerability is applied for all applications using the part once the part's maintainer releases the fix. Otherwise, you have to wait for the maintainer to update the application with the fix, and $DEITY help you if the maintainer has pronounced the application's end of life.
On occasion you get the rare third option of "add this repository of compiled binaries to your package manager" which is no different to downloading a random installer.
With one big difference: adding a repository allows the existing package manager to check for and apply updates instead of adding Yet Another Daemon to do this.
I still don't see why you'd need multiple copies of the same software installed, even if they do use OpenGL. If you need them for testing variances between versions, then you're better off taking the performance hit of virtualising the machines.
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
Laziness has no minimum capitalization requirement.
I actually meant virtual machines. Virtual hosts won't allow you to use different versions of Apache (as far as I know), but will get round the need for multiple instances of Apache. You don't even need multiple instances of Apache for dealing with multiple network cards, let alone multiple installs of Apache.
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
I agree. By thinking about installation when creating complex enterprise software, you end up making better quality software. When you're forced to handle the inter-dependencies of complex systems in an installation process, you end up having a better handle on how everything interacts. This has been my experience at least.
Absolutely true. I didn't even bother going there in my response, because I figured it was pointless when someone was actually claiming "enterprizey software is simply too complex for installers". Sigh. As usual, the creators of the problems are blind to the problems...
What installer can set up databases on other machines?
I would watch with interest when that single-file Database you're using messes up for good, completely, because that single-file was deleted by mistake. Tee hee. Or when it got corrupted by power loss, etc.
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
I suspect the complexity is not in being able to parse and alter XML files, but what level of human knowledge is necessary for determining what values to put in them.
Flash and Java and such run a small program at start to check for updates. They do this because if they don't even fewer people will upgrade their software this century BUT you can be CERTAIN that those who update never, SCREAM the hardest when they are affected by a bug fixed ten years ago.
You can rant gently or hard about software developers, but about [ulûk/users] *thunderclap*, you can only curse in black speech.
I am a developer myself and have had quite literally had to debug configurations where it turned out people never configured anything. Yeah, I did X and it doesn't work and they didn't do X. This is like complaining your car doesn't start when you haven't got a car. Your are correct but still an idiot.
Yes, developers are morons but users are malicious morons who predate on fools who utter the lines as "quick fix", "work around" or worst of all "quick win". But only when the shit has not just hit the fan but they are actively drowning in it. Every other time ANY thing that sounds like "permanent solution", "investment in the future" and "decision" is avoided like a... well like a user avoids making a decision or doing anything NOW to avoid trouble in the future.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
There should not be any installers. A software package should be one file that is download and run. The file should not be unpacked, it should simple be one executable with all necessary parts inside.
Any software that is not simple a single file is complex and brittle.
Do we have to include the whole operating environment in the file, even eliminating BIOS? Because all modern software builds on external functions and libraries, even on a game console. Heck, even the cartridges for the original Nintendo relied on firmware inside the console to some extent....
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
What installer can set up databases on other machines?
They can all run scripts. Just because there's not a checkbox labeled "set up our database on the other machine" doesn't mean it can't be done--at least if you're not a lazy bastard.
Or, the easier approach, an installer for each part on each machine. There's really not an excuse for not considering that.
Not all software is that simple. There are more then just 'apps' out there.
Installing software in users' directories is all well and good for testing stuff out, but moving to production it can become problematic. What happens when that particular user leaves? Do you lock his account and thus stop the software running?
Also, how do you keep control of security patching? One machine with 15 different versions of tomcat installed in various directories is going to be difficult to manage, but 15 virtual machines, each with a different version of tomcat installed in the standard directories is much easier to manage. You also get the advantage of being able to upgrade the system without taking down 15 instances all at the same time.
Yes, virtual machines do add complexity, but they also bring new tools to the table which can mean less complexity overall.
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
If we build it, it is because the user, may his children be cursed for a thousand generations, told us to do so. In fact, that is pretty much the reason ANY crap building has been up to cheaply in a dangerous area. ONLY because THE LAW and BIG GOVERNMENT stops users from demanding high rises build out of mud on top of mud in a flood plane on a fault line, has this stopped... and then only when THE LAW and BIG GOVERNMENT do their job really really well. Just google engineering disasters for examples when THE LAW and BIG GOVERNMENT were stopped from doing their job.
Remember that Engineers have strict laws governing their actions. Software Engineers (HAHA) don't. You want to have the same quality from Software Engineers as real engineers? PAY FOR IT! And WAIT FOR IT.
There are good reasons for building codes and there MIGHT be a cause for coding codes BUT it won't happen when "cheapest" wins out every time. I have seen it far to often when a project was reduced in quality by the customer insisting it be done cheaper and faster. Well guess what, then you get buildings oops code that fall down when someone sneezes.
Want an installer that works in more then one near perfect situation? Sure that will be X on the total bill. User: oops no and I want to save Y amount as well, so cut some more corners please.
Is there a patent on administering electric shocks every time a user demands a shortcut but expects quality?
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
why couldn't everything be compiled statically?
Please read my reply to oever.
Congratulations! You win 10 internets!
The correct answer is b). Install software as a system service whenever possible and also have that service run as a system user with only the required permissions to do its job.
Production software should never be reliant on an individual's account/credentials.
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
I would assume that the database itself probably does have its own installer. I think the issue is that it needs to be configured, probably based off the clients need and their existing systems.
I think what the person was trying to get at is that installers make sense for individual tools and applications, but once you start getting into entire systems or stacks the idea of having an 'installer' increasingly becomes nonsensical since there is less and less generalizable behavior.
On an enterprise software level... bring what you need in a local, self contained directory structure. There is absolutely no reason your reliance on foobar v1.20a-final means that Software X cannot have 1.21c-upgraded.
Link to your own directory first in your search path.
Where's my check?
Heck, even the cartridges for the original Nintendo relied on firmware inside the console to some extent....
The Famicom had no firmware at all. The NES added only a CIC (Checking Integrated Circuit), a microcontroller on a completely separate bus that communicated with a matching microcontroller on the cartridge to make sure that the game was "licensed by Nintendo".
Bingo! "My organization uses a bunch of home-grown ad hoc'd garbage that isn't versioned or managed by anyone sane or competent" isn't a problem with installers, it's a problem with having a deeply dysfunctional organization. There is no software that's gonna fix that problem, and it's not because packaging/distribution software is lacking in some functionality.
If you have to install it by hand, why? What are the steps? Why can't those steps be automated? Why can't those dependencies also be automated? What, you can't edit XML files, .ini files, or registry settings on the fly? Why not?
Check out my world simulator thingy.
A real OS doesn't let apps install files in random places all over the disk, so it's not a problem.
"the disk" -- there's your assumption right there, that a system has only one disk. People want to install to the other disk once one disk runs low on free space.
they may give you a performance hit but they also give you portability so say your windows server has a major hardware failure you can move it to another with completely different hardware without windows killing itself because it thinks you have pirated it. it also makes backups and if necessary regression to easier state easier because you can just take a snapshot of the vm. oh and if one copy crashes its os it won't take the other one down with it. lots of advantages to vm's really.
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
I usually start the process by crawling into a corner in the fetal position and sobbing uncontrollably for 30 minutes, cuz I know the next week of my life will be complete hell. Then I throw away the docs, since I know they're a work of fiction. 5-7 days of random typing and button pressing later, I may finally have a functional Informatica system.
007: "Who are you?"
Pussy: "My name is Pussy Galore."
007: "I must be dreaming..."
Sure the installer can CREATE TABLE IF NOT EXISTS. And it often does. I've been involved with several such installs. My point was more that at an enterprise level your application has to be deployed into and existing infrastructure and you cannot take all the possible corporate configurations. They might use akamai so custom tags have to go on each page. Or they might deploy to an application server that you have not seen before (OC4J anyone). Maybe they have a password management scheme that means you have to hit LDAP when your server starts up to pull the application password. They might restrict your ability to create tables and only allow their own DBAs to create tables. I have seen all of this and more at the enterprise level. No medium to large company really allows the possibility of just running an install script for anything of any complexity.
No sigs in BETA. Beta SUCKS.
Okay.. but an installer that says, select the components to install... (oh crap, the RDBMS runs on Linux)... Oh noes, the Front end runs in Windows... Now you need to interface with AD... Creating installers for all these pieces for a system that only gets installed for a hundred or fewer instances or upgraded less than that a year is a waste of energy vs. using a fraction of that time to simple document well. The more pieces that are running on different servers/systems the more complex the install... Also, if you're using 3rd party software, be it Oracle, MS-SQL, or Postgres, automating the settings needed for said install are problematic.
.Net ... you're suggesting I should go back and create installers for this system that is only running in one production environment, and a handful of stage/dev environments? Really? Even if it were installed a few dozen times a year, it wouldn't justify the cost of automating that process, vs. a checklist.
The solution I am working on right now involves connecting to MS-SQL, RabbitMQ, and MongoDB. It's utilizing IIS, Node.js, as well as
Michael J. Ryan - tracker1.info
One thing nobody's mentioned yet is that big commercial applications can have hundreds of separately ordered bits and pieces. That often affects the installation process, and can add a lot of complexity. The more paranoid vendors won't just have you install the whole thing and then disable what you haven't paid for, for fear you might crack the rest. Sometimes it's not even technically feasible either, given the app's internal dependencies.
We've all dealt with vendors and their licensing departments. Even if the technical side of it works perfectly, if there are enough different things to be licensed, sooner or later someone's bound to give you the wrong magic number.
Yeah you don't *need* multiple apache installs, neither do you need VM's... or even web server at all, or bacon.
Invaders must die
Yup. As long as the GUI remains resolutely fixed size bitmaps (with a few hacks to allow smudgy zooms) all our HD monitors do for us is make everything to small to read. I always browse at 120-125%, and some sites come out completely borked -- resizing artefacts on images (including many titles, banners etc), text that gets cut off due to hacky fixed-size boxouts etc. It's all crap.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Sorry, I was writing that in base 8 - it's one less than 9.
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
I would assume that the database itself probably does have its own installer. I think the issue is that it needs to be configured, probably based off the clients need and their existing systems.
Sure, and installer builders allow you to insert an existing installer into the installer you're building.
I think what the person was trying to get at is that installers make sense for individual tools and applications, but once you start getting into entire systems or stacks the idea of having an 'installer' increasingly becomes nonsensical since there is less and less generalizable behavior.
He seemed to be justifying having large sections without an installer at all. Having more than one installer is not outrageous, though likely unnecessary. Having to fill in some info during install is not outrageous, though easy to overdo. But the whole language ("not packaged at all", "cannot be distributed", "XML files edited") of that original post seems to scream: LAZY BASTARD JUST DOES NOT WANT TO BE BOTHERED!
Well current versions of Windows will allow multiple versions of a given DLL to be installed, and use the correct one on a per-app basis. Linux allows setting a binary root for a given application build, that can include dependencies, but even then it's usually less of an issue, as more business applications are built in higher level languages using services that have defined network/local APIs.
Michael J. Ryan - tracker1.info
Okay, but when would you *want* multiple apache installs? Surely you can accomplish almost everything by using either vhosts or by running the same apache binary multiple times with different settings?
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
Creating an installer for a complex system... a couple man-years of labor from your highest paid employees for a system that only gets installed a dozen times a year.. vs. a checklist... Yeah, you'll be making millions with your strategy.
Michael J. Ryan - tracker1.info
Come on,... every reasonable operating system has got a package manager
Most users don't use reasonable operating systems on their PCs. They use Windows, which provides a package manager only for Windows components and for applications coded to the abortion formerly known as Metro.
Your binary of unknown quality will NOT get privilege enough to do CREATE TABLE and friends on my production database.
Wordpress is installed how many times a year, vs. a typical enterprise software package? Sometimes writing an installer vs. a checklist is an easy call to side with the checklist.
Michael J. Ryan - tracker1.info
Are there any IEEE standards for software installers for different platforms right now, and if there were, can anyone reference them so as to help the hopelessly clueless start to understand the problems? Thanks.
What would Richard Feynman do, if he were here right now? He'd do some math and he'd follow through!
Users are not people. Users are users. Not to mention, it is easy to change ownership of directories and give them to a new user. That's the beauty of UNIX.
Now, that being said, when is user apache22 going to leave the company?
Okay.. but an installer that says, select the components to install... (oh crap, the RDBMS runs on Linux)... Oh noes, the Front end runs in Windows... Now you need to interface with AD... Creating installers for all these pieces for a system that only gets installed for a hundred or fewer instances or upgraded less than that a year is a waste of energy vs. using a fraction of that time to simple document well. The more pieces that are running on different servers/systems the more complex the install... Also, if you're using 3rd party software, be it Oracle, MS-SQL, or Postgres, automating the settings needed for said install are problematic.
The solution I am working on right now involves connecting to MS-SQL, RabbitMQ, and MongoDB. It's utilizing IIS, Node.js, as well as .Net ... you're suggesting I should go back and create installers for this system that is only running in one production environment, and a handful of stage/dev environments? Really? Even if it were installed a few dozen times a year, it wouldn't justify the cost of automating that process, vs. a checklist.
1) How good is your checklist? If it actually works, you're already not on my shit list ;-) The article referenced involved multiple steps that were documented that did not work.
2) You're not denying that an installer could be built. You're saying that you understand what it would take, and that it would likely be more effort than just going through the manual process. (And you don't even mention estimation risk--you really know how long it takes to do the manual install, but you can only estimate the project of building the installer.) The post to which I responded claimed it couldn't be done.
3) You seem to be talking about an in-house system, since you talk about running in one environment. The post to which I responded seemed to be talking about a commercial product ("...I manage a product line..."), which is an altogether different story. Not only do developers of expensive products owe decent installers to their paying customers, but in your case the people responsible for the manual installation were involved in the development of the solution and so start with a much greater understanding of the pieces than the poor customers of that poster's company.
Public APIs mean you have to sell/use a competitor's products before you can sell your product, and companies are just too greedy. Plus this would mean a way around the patent problem, which means less money for the greedy as well.
Twinstiq, game news
That is not how I read the comment, esp since the person said they had installers for individual applications/tools. I read the post as the person pointing out that a single installer for the whole system does not make sense and sometimes having an 'installer' is just an unnecessary extra step since all such things do is automate a process... but automation is not always applicable.
The entire point of wide screen monitors was for playing video content, period.
Not to me it wasn't. I've found two purposes for 16:9 monitors completely unrelated to video. One is to allow windows to keep a usable width when you Snap or Tile Vertically into two 960x1080 spaces. The other is to allow laptops to become smaller and lighter while keeping a full-size keyboard.
I don't know, I don't want to! I am sure that doesn't mean everybody else shouldn't want to either though ;)
Next you'll be telling me I can only download apps from one place!
Invaders must die
Generally, system user accounts are not referred to as "users" - that's usually reserved for people. Software should be installed to be run as a system user with the minimum necessary permissions and the software binary should be installed as root so that no-one else can change the binary (obviously the config files may be writable by other accounts).
When people talk of installing software into a user directory, they're usually referring to installing all the binaries, configs and working files into their own home directory. Yes, you can relocate it when you find out what's happened, but you shouldn't be running production software that way.
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
Okay, can anyone who *ISN'T* sgbett answer why someone would want to install multiple versions of Apache on the same machine apart from testing?
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
Any script will do it if the remote machine allows remote database access. Commonly they don't to close an obvious attack vector, but it's perfectly possible.
Please consider this account deleted, I just can't be bothered with the spam anymore.
It's a difference of nomenclature, and I don't really need a lesson on managing systems, as that's been my field for quite some time. System level accounts are just that, built in. You can, however, have application accounts, and they are still users.
Running production software out of /home/bob is bad. Running it out of /opt/software/versionX/bin/foo with a link back to /opt/software/bin is good. You can make /opt/software a home directory.
Plus one for root creating the files/configs so the user has the ability to execute, but not modify beyond perhaps some sudo rights. Unfortunately, politics often screws that up, and an exception is filed, accepted, and never read.
Seriously. Like it or not, when most programmers get something to work, we go home. We don't think about dependencies or low probability interactions. We're happy enough to get an install to work at all. Which brings me back to my original point. Single .exe installs aren't an ideal engineering solution, but they solve the human factors problem of engineers with limited bandwidth (and no matter how good you *think* you are, you have limits).
Please do not read this sig. Thank you.
Not blind, necessarily. Enterprise software is almost certainly designed to be "consultant ware."
Oh, having trouble getting it installed? Yep, our software is very powerful therefore very complex. We can help you with that, let's talk about a retainer.
A function isn't working? It must be your sprawling IT infrastructure. We can help track it down for you with an engineer dispatched to your data center, what's your closest hotel?
More Twoson than Cupertino
Bullshit. If you charge a few millions for such a product, you can afford making a custom installer. Yes, I agree that from a strict profit-making point of view it's better to go with manual steps because that brings you more money. But please, for fuck's sake, don't tell me it can't be done.
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
Bottom line: Building quality installers is not a job generally well suited to the developer of that application. Many (most?) large firms have software distribution teams that utilize some ESD type of tool (SMS, Marimba, Tivoli, etc) and every one that I know anything about has had their own packaging team. This is a team of individuals whose entire job is to build quality installers that are robust enough to handle oddball client configurations. Further, a good installer should be capable of installing with no user interaction whatsoever; aside from perhaps allowing the user to determine if they want that interaction or not. Not that a developer could not do it, but like most specialized things there IS a benefit to having an expert in this specific area do the work. The team who designed or built my car is not the one who prepared it for delivery to me.
Sure, smaller firms (independent especially) won't be able to afford a professional packager and will have to make due. This is, however a problem that has been solved by many companies - not some mystery waiting to be solved.
A good installer should be robust enough to make intelligent decisions based on information gleaned (not from user input) at install time. The more common approach these days seems to be making very specific installer packages and forcing the user to pick the right one before installation.
Furthermore, SAP is a poor example - as best I can tell the software is deliberately made to be confusing in order to necessitate the ecosystem behind it. SAP professionals are very highly paid and specialized and if the company fixed this it would damage that ecosystem.
To be fair, hardly any company releases software with what I would call a quality installer these days. Some are better than others, but none are anything I would have been proud to put my name on back when I ran a packaging team.
Proxmox + OpenVZ?
Dilbert RSS feed
Include that in the install interface, then.
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
Yet another incipient genius who probably hasn't had the slightest experience on the ISV side of this equation with the convenient one-size-fits-all answer to end all answers. Thanks, that was amazingly edifying!
Frankly, you have NO FUCKING CLUE what you're talking about. I would presume you really have no familiarity with actual commercial line-of-business enterprise class software. Any enterprise which is not run by morons and is large enough to qualify as an 'enterprise' has an extensive IT infrastructure which is highly integrated and designed around an enterprise information systems architecture, involves capacity, availability, security, and usability analysis and planning etc. When you 'deploy' software into these environments, and I'm talking about large banks, Fortune 500's, large international corps mainly there's no such thing as "drop the installer on a hard drive and run it". You're dealing with integrated management systems, enterprise-wide credentials and role management, complex licensing situations, other corporate IT policy issues, etc etc etc. The idea that MY software, which handles transactions from generally 1000's of clients and integrates with easily on average 4-5 other complex software stacks is 'lacking an installer' because you don't install it clicky--click is hilarious.
You can think what you want, but at least in my world 'enterprise software' means something very different from what some people seem to be using it for. This is not like in your typical small business environment where you slap up a copy of Apache and install Trac on it and call it a day (and even there I'll note there's no single installer that can handle setting that up for you).
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
This. Although a single script would be great, just have a script for each machine, with a thought out name for each. Include a readme with the install package that runs through which script to run on each machine step by step. Problem solved. Manually setting up databases and configs on every machine/server is a huge PITA. This is a development failure more than anything though. I would not expect the help desk guy to be able to automate all of this. Automated install and versioning is a developer's responsibility for any production software, MAYBE with the exception of prototypes and custom one offs.
Exactly. There are just such a HUGE number of different possible things that can go into an individual setup. There are in our main 2 pieces of product each a rather extensive and tricky XML file that you're almost certain to have to do some significant surgery on. It is POSSIBLE you can set up a 'vanilla' setup for demo purposes basically, but you're sure to have to edit this beast real soon anyway.
There are other aspects too. While I say our system is a 'piece of software' it is really a number of services which can be distributed in different ways between however many machines someone needs for their purposes, and there are several ways you could do that. Depending on exactly how you actually set things up there could be various quirky setup and configuration issues. In most cases the specific setup is one that hasn't been entirely tested before or even entirely anticipated. Often you're dealing with the person that designed some part of things to know exactly how (or even if) something can be done. This is mainly because this sort of software is EARs deploying onto J2EE servers, databases (there are 4 separate schemas that we use for various things, they might well not even be on the same servers). It is just complex and ugly.
I think people get the misimpression from what I said that we aren't concerned with making things easy and smooth. That wouldn't be true. Ease of use is always a concern for any decent ISV. It is just that some issues aren't reducible to a few choices in an install wizard, and there are just factors that aren't sensible to deal with at that level. In fact there are a lot of automation scripts of various types that we use. All database updates for instance are done via a structured set of script modules that we wrote years ago. That can reduce a really complex process to a couple shell commands. Other bits of software DO have installers.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
I just used Apache as an example, feel free to use Enterprise-class software (I think the article referred to Oracle, too, but I worked on one of their competitors).
Testing is a big one. Ensuring that your existing apps are going to continue working under the new version. In enterprise-class software, this is sufficient reason right here. There is no need to keep looking for other excuses, it's so critical that everything continues to work with an upgrade that we can spend three months just planning to apply a quarterly update.
Embeddability. I want to run Apache. I also want to run Frobnitz, which embeds Apache (so they can run precisely the version that they've certified against). I also want to run a test version of Apache before I update it. Likewise with Frobnitz. Obviously this is going to throw my port usage all over the place, but that's a whole different can of beans. Maybe Frobnitz is a bad example of an enterprise-class software, but my management still wants to use it (they had the Shiniest Trinkets at the trade show they went to), it embeds Apache, and if Frobnitz is installing a downlevel Apache using RPM with the standard name, I'm screwed.
I'm sure there are other reasons, but I've not been there. I've just been on the other side, where enterprise-class customers have made requirements on us, including multiple copy support, that made continued use of RPM impractical.
Why does an HP printer driver software need an installer that runs for over 45 minutes on a fast (3+GHz) multi-core system? Almost as bad just to UNINSTALL it.
.001 seconds?
I can't imagine anything so complicated for a printer driver to take that long to install (heck I can copy an entire CDROM to disk in just a few seconds).
What the heck are installers doing while you watch the progress dialog box for 2 minutes that says "Determining Disk Space", when you can get the disk freespace from the dir command in
Oh come on. Wouldn't you rather meet the 'giant electronic bra' than the usual humorless, overworked and hung over system rep? If (he / she / it) could only get past security (or the TSA for that matter) it might well liven up your day.
Expand your horizons!
Faster! Faster! Faster would be better!
The solution I am working on right now involves connecting to MS-SQL, RabbitMQ, and MongoDB. It's utilizing IIS, Node.js, as well as .Net ... you're suggesting I should go back and create installers for this system that is only running in one production environment, and a handful of stage/dev environments?
Yes, if the "stock" install of a product that your is a dependency for your "system" isn't good enough, then at the very least you need to supply a script that will change the config of that product to your liking. If at all possible, that script should be run as part of your installer, asking for passwords and connection information if necessary.
For example, if your system depends on a DBMS, obviously you need to provide a script that creates the actual database you need. If the DBMS needs changes to its config (for example, more memory use than a stock install), then you need to script that as well. It may not be possible to have these scripts run directly as part of your install, but you can pause your install, present the script, tell the user to copy/paste the script and run it on the appropriate machine. If the user clicks "Next" but hasn't actually run the script, then your overall install might fail, but that's not your fault.
So, no, we don't expect you to create a custom installer for some third party product, but we do expect you to automate any changes needed to those third party products.
Yes, there is. The packages from that repository will be able to specify dependencies on standard packages (instead of bringing outdated copies of every library they use), their updates can be centraly managed and scheduled, installations are much easier to automate, etc.
Dilbert RSS feed
does it have to be a good reason? I can think of one, but it is convoluted and stupid, and would only give a manager a bad idea if I were to put it in print.
like an OVA or an OVF. those can contain only the copies of whatever your software needs. I have a feeling that this isnt the best way to distribute everything.
You won't be making millions from the people who go to your competitors because your demo doesn't work.
A republic cannot succeed till it contains a certain body of men imbued with the principles of justice and honour.
No medium to large company really allows the possibility of just running an install script for anything of any complexity.
So what you are saying is that because some companies lock down their systems so that they must manually configure everything, no one should ever create any installers?
The point is not that an installer fails to do something because of an obscure config. Instead it is that the installer completely assumes a very specific config that isn't the default and then doesn't either automate or give you good instructions on how to make sure the dependencies are fulfilled.
They might use akamai so custom tags have to go on each page.
Assuming you are talking about a product that front-ends a web server (like a CMS, storefront, or forums), this really isn't part of an "install", but instead should be provided by settings in the software once it is running. Adding custom tags to a web page is no different from changing a font in Word document, and shouldn't be part of an install.
It's harder for some admin to pirate his software and upload it to pirate bay if there isn't a installer....
Other than proprietary software which you might not have the right to distribute and might, itself, not have an automatable install process, I don't see anything on your list that cannot be automated with Chef. Each service can be mapped to a chef role and individual machines easily provisioned with knife.
But then you'd lose the perception of complexity that you get from having a complex install process. A simple install process would give customers the illusion that the product itself is not complex and then they might balk at the 100K up-front costs you're charging and even, possibly, the 1000's per month.
"Don't blame me, I voted for Kodos!"
I think what you'd find is that each install is unique enough that the effort needed to set up an install script which would have to be gone over with a fine toothed comb and tested several times just to do one or two customers wouldn't be cost effective. We've looked into these things in the past, trust me.
In fact you're probably wrong about perceptions. Everyone enjoys convenience and simplicity. Automatic installer scripts would generally convey a polished appearance, BUT our customers are our customers because of the significant savings and ability to integrate into their own business process and flexibility that our product gives them vs what they have from other vendors. Of course they'd love to pay less, but they know the deal they're getting from us is great for them and that we don't charge stupid amounts of money for nothing. All I can say is we are doing something right because business grows every year.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Now hear's the tricky part: You have to make it resilient to the typical malware associated with Windows installations (particularly malware directed at this application to corrupt the list of repositories). I don't know if this is possible.
Might that be why Microsoft applied so much pressure to introduce Secure Boot when it introduced the Windows Store in Windows 8, to keep MITMs from screwing with the payment method for Windows Store?
I agree that testing is a valid reason to do multiple installs and deb/aptitude package management will let you install multiple versions providing they've got different names (e.g. libcap1 and libcap2).
I know that Oracle installs a specific version of java in an Oracle installation as quite a few tools use java and they don't want to be wasting support services on debugging java version problems. However, this specific version of java won't be used by other programs (unless you force them to) and you can install other versions of Oracle without them conflicting if you use different different ORACLE_HOMEs for them.
When moving stuff to production, you're much better off having Frobnitz running on it's own (virtual) machine. That way, Frobnitz can have exactly the version you want and you can put apache onto a different machine and there'll be no trouble with them conflicting. It then also becomes much easier to test as you can replace the Frobnitz or apache functions separately from each other (and you'll also have the luxury of rolling back to snapshots if/when a virtual machine gets broken).
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
I'm curious how, "Check at start" became "Check at start and don't do anything with the info for hours." Typically, programs that check at start offer to download and launch the installer via modal dialog as soon as the check is complete.
I was trying to allude to Apple's guidelines to not interrupt the user's work flow with a modal dialog when the user first opens the application. (No, I don't remember what Google search terms I used to find those guidelines months or years ago.)
The linux software repositories have different requirements.
Such as the program being distributed under a free software license that conforms with the DFSG. This is traditionally not acceptable for several categories of application.
There should be a fee, though.
How should hobbyist developers of applications distributed for no fee afford this fee, especially when it usually ends up being a separate fee for each platform?
Which is why the OP spelled out security fixes as an exception to the general rule of not pushing updates every day.
Where I'm going is that the only time I've seen updates more than three times a week is for security problems in Ubuntu, especially right before or right after a new six-month release.
Ever want to install more than one copy of Apache?
This is up to the installer writer. I don't have experience with DEB, but with RPM, there is, for instance, no reason why you can't have two versions of the same package installed as long as they don't try to own the same file locations (or at least, as long as those shared files are the same). The Linux kernel does this by default on many Linux distributions, allowing you to have several different versions of the kernel installed that you can switch between. The version of the program is baked into the base install directory, something I note that many non-rpm enterprise software installers do anyway.
Why would you ever want to run testing on production equipment? Mirror production, and test in test.
If you want to test on production anyways you'll find that a silly mistake can result in disaster.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
What check? That's at most half of the solution. It covers most cases on Unix systems, but the situation on Windows (which was referred to explicitly) is a far greater mess. The way linking happens depends on about 10 to 20 different things, and not all of them are under your control.
http://www.moonlight3d.eu/
Amen to that, brother. You have reduced the argument to its most fundamental terms.
Yes, we can do it. But no, we won't pay for it.
-kgj
Easy enough. Don't use that hot mess.
Exactly. Being both a developer and an admin having "installers" is often worse than not having them. I much prefer the "copy the software files somewhere, set environment variables A, B and C, and fill out configuration files X, Y and Z"
An administrator in an enterprise environment should know better how to to those things in HIS environment than a person that has to write an installer that has to fit ALL environments. I can't count the times I had to snapshot a system, run an installer, and then compare the systems to find out what the installer was doing so that I can figure out what needs to be done in my "real" environment, because the installer didn't work in my real environment. A good list about what needs to be done is often more helpful than an automated installer.
Because you make more money on maintenance. Thats on the of the biggest problems.
http://michaelsmith.id.au
It might be difficult because if there is a bug (or a malicious hack) in the installer, then the installer could delete all other databases on that server once it has obtained the sa password of that server.
The question basically boils down to "How much do I trust an installer I have no clue about what it actually does to mess with my systems."
Link to your own directory first in your search path.
Where's my check?
You'll get it when you fix the other part of the question:
...without breaking the other applications that depend on them
That's the key point your technique misses.
Next...
Your lack of ability shines here. This technique carries it all. If the application brings all it needs, then it doesn't matter if the user of the application has their directory first in the search path. If you want to make sure you use your own version of shared or linked objects, that's how you segregate them. It won't break anything, as the path is user specific.
Now again... where's my check.
What's difficult is prying the sa password out of your DBA's cold, dead, hands :P
To be frank, I suspect that your single biggest problem is what Linus Torvalds acutely summed up as "idiotic object model crap", or more politely:
inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.
for i in `facebook friends "=bday" 2>/dev/null | cut -d " " -f 3-`; do facebook wallpost $i "Happy birthday!"; done
Maybe, yeah, if you're working on commodity hardware, running your test server on a mirrored system makes sense.
When the hardware costs $1m+, having a spare might be economically less feasible.
Oh, and I've seen cases where "mirroring" was incomplete, leading to either errors in test, or, worse, errors when you get to the production system. Not always the best idea, either.
...or, at least, it isn't enough that you'll even notice.
I've been working on a free game for a while. Everything it requires is inside the executable. The download is still just over 1 MB. It's small enough that, when trying to get people to try out the game for me, I have issues with people assuming it must be some sort of trojan simply because of its incredibly small size.
Originally I was distributing it like most software, with an executable accompanied by many other files, but this just created issues of people copying the executable but not the graphics files, or copying things but putting them in the wrong directory (which is quite amazing considering that all anyone had to do was extract the ZIP file and run the executable from where it was extracted to). So I included the files in the executable, which brought it up to 10 MB. Later I made it so that most of the graphics come from the server and are cached locally, so that different servers can have different textures, and so now it's only 1 MB.
Also, until a week ago, it was using a dynamically linked version of GLFW for the Linux version. However, I began hearing reports of people not having GLFW available, so I included the necessary apt-get command on the web page so that people would know how to install it. ...but even then, I heard from several people (which probably means everyone who used the Linux version, given that the game isn't all that popular) that they still couldn't use it because when they used that command on their 64-bit system, it would install the 64-bit version of the library, but my executable is 32-bit.
I suppose I could have installed a 64-bit system somewhere, but honestly, every time I install Linux I have to go through hell figuring out how to make it stop asking for my password every three minutes, as well as changing numerous other idiotic default settings. ...and also about 50% of the time the system ends up being unusable anyway and I have to install something else. Thus I've learned not to install new versions of Linux, even if I'm already aware of two bugs in the two and a half year old kernel that the current version of Linux Mint I'm using refuses to upgrade to anything newer. (vm86 mode is broken, and there's a thread locking issue that stalls all threads in an application until you open another terminal and type "for i in 1 2 3 4; do cat /dev/zero > /dev/null & done; sleep 0.1; killall cat")
So instead I just statically linked GLFW as well. I'm sure it added something to the size of the executable, but at present, 25% of the executable is a single PNG image used for the player avatar. While 1 MB may seems small for executables these days, there was a time when our whole computers ran in a single MB. Code simply doesn't require that much memory. When people complain of some software's memory usage, it isn't using all that memory due to a bloated code base, it's using it to store data (or memory leaks). To put it into perspective, the RGB data of a 1920x1080 display requires 6 MB of memory to store -- the entire executable for my game will fit into that multiple times. Thus, the memory saved by dynamically linking is inconsequential.
There are still things that aren't statically linked, like X11 libraries and OpenGL, but I suspect that statically linking those would cause more problems than would be solved. After all, if someone doesn't have X11 or OpenGL libraries, they probably don't have X11 or OpenGL. (I'd also have to find their various licenses to see if I'm even allowed to statically link -- LGPL won't allow you to statically link closed-source applications, despite its reputation of being nearly public domain, and so it is useless for closed-source software.)
As for the topic of this article, I also realize my game desperately needs an instal
Well, I'd say your test system isn't going to have the load of the production system. You could very well get away with cheap hardware on that side. After all, if your test system breaks it doesn't really hurt anything.
As you say, if you go this route you have to make sure it's done right. You have to verify the mirroring is actually working.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
There are two stinky common problems with my game, both of which annoy the hell out of me, but neither of which I can really do anything about.
The first is issues with graphics rendering. It seems that, even though OpenGL has a way to report errors like "out of memory," a lot of graphics drivers simply don't bother to do so. Instead they just render shit incorrectly and generally fuck shit up. The result is that it looks like the game sucks, but the truth is the game isn't being told anything about what's wrong. It presently doesn't pay attention other than to report the errors on stderr, but then to my knowledge, nothing useful has ever come out of OpenGL's error reporting functions, so it isn't like I'm missing out on a chance to give useful information to the user. Indeed, the graphics stacks which don't have these problems seem to deal with low memory not by reporting an error, but by swapping things to system memory where, if memory usage goes up further, the OS begins swapping out to disk. Thus the good drivers just get slower when they run low on memory, but otherwise present no errors. The bad ones just randomly drop textures and display lists, and again present no errors.
The second is issues with malloc(). Sure, malloc() will tell you when it cannot allocate memory. The problem is that there's generally nothing you can do in that case other than to terminate the program. You can't even printf() about the error because printf() uses malloc() internally and so if malloc() isn't working, printf() won't work either. Nevermind trying to do something more reasonable like display a message to the user about what went wrong and what they might be able to do about it.
Unfortunately, many of the tools programmers rely upon to make software have been written lazily, and so even if you yourself write your code to detect as many errors as possible, there are still plenty you can't do anything about. My game checks the return value of everything. In most cases it just prints a message to stdout and exits, as many errors are just so unlikely that it isn't worth the trouble of writing code to do anything else. Even so, I still get malloc() errors that don't make sense. I made it track memory usage and found that malloc() fails after allocating 400 MB of data on systems with 4 GB and no other software running. I have no clue why it's happening, and I can't do anything about it after it happens. It'd be nice if malloc() were more informative about why it is failing than to simply return NULL as a generic error. I've thought about simply doing one huge malloc() for everything I need and then write my own memory allocator to allocate out of that chunk so that I can be guaranteed to get what I need, but even that doesn't solve problems like a later printf() or some other library call failing when it calls the real malloc(), and I'd also lose out on features like realloc() being able to move memory around by asking the OS to remap pages rather than copying them.
Indeed, it would probably make a lot of sense if malloc(), like the good OpenGL stacks, simply started swapping to temporary files when it could no longer allocate more memory. Even better if it told the application about this so that it can drop things that aren't really necessary (like cached data), and so that the application can rely on the swapping to keep running as it informs the user about the problem and offers a choice to continue on at a snail's pace or to give up and terminate. ...but that's not what we have. We just have something that returns NULL with no warning whatsoever and leaves it up to the programmer to figure out some way to do something sensible in an environment in which it's no longer safe to make any library calls (since they may use malloc() internally).
The state of error handling is really rotten all the way to the core. It isn't just individual pieces of software that suck at it. Even people who want to do it right are kind of screwed.
Which is bullshit! If that's the entire point of Enterprise software is primarily to get the foot in the door and milk the client for all their worth and then expend them like a used husk, why bother?
If you're going to be honest about it, price the software along with a dedicated software developer for $120k a year (not included). At least they have an idea of what they're getting into.
Life is not for the lazy.
So use a directory mount point. Yes, Windows does that.
Does assigning a mount point folder path to a drive support semantics equivalent to unionfs, where files on one physical drive overlay files on another, or does a drive have to be a single directory by itself? For example, if programs were unable to install anywhere other than %ProgramFiles%\Title of Program (which resolves to something like C:\Program Files (x86)\Title of Program), how could I tell Windows which drive should contain a particular directory? This guide from Microsoft sort of implies that the mount point has to be an empty folder, which %ProgramFiles% isn't. Besides, how hard is it for the end user to discover that "yes, Windows does that"?
Or grow the volume by adding a new disk. Yes, Windows does that, too.
I found a description of the process using Google windows grow volume. But how hard is it for people to discover that Windows does that? And the volume appears to be extended at the block level, not the file system level, so it's not so good for use with external drives that may not always be mounted at the same time as the boot volume.
you're suggesting I should go back and create installers for this system that is only running in one production environment, and a handful of stage/dev environments? Really? Even if it were installed a few dozen times a year, it wouldn't justify the cost of automating that process, vs. a checklist.
That depends. Checklists are more error-prone than scripts, and doing things via scripts pretty much forces you to keep the scripts up-to-date, so there is a higher degree of knowledge capture. When I do things via checklists the checklist is often a few iterations behind the reality, because I know what the current deviations are. When I do things via scripts they are always up-to-date, and if I get hit by a bus my employer won't lose anything.
There is certainly a place for checklists, but for any software that is going to be deployed to customers--even one or two--scripts are almost always the right way to go, in part because they encourage in-house testing before release, and remove from the customer's hands a very error-prone and stressful step.
Blasphemy is a human right. Blasphemophobia kills.
The question is where the profits come from. Faced with short-sighted would be buyers, many enterprise software companies take a small loss on the original software sold and make their actual profit on the services getting it up and running, and maintenance charges of the same. It is an anti-virtuous circle, because a new company selling a product that is not plainly outright superior cannot charge a fair price for their software when the customer mindset works against the customer's own long termbest interest.
What I want are the full instructions on how to get software X to function on a known good configuration.
I'm talking ALL the instructions, as in I have a box with the minimum Fedora v 26 install, what are all the keystrokes that I will need to install this software. No assuming that I will have X set up some way on my machine, or that I've installed the right version of Mesa3D, or that vim is installed.
I don't want to find out that I'm hunting down some bug because yum install kerberos installed MIT kerberos instead of Hemidall kerberos.
I want this because almost everyone skip steps they consider obvious. The puzzle is so much easier to figure out when you can look at the picture on the lid.
...each install is unique enough that the effort needed to set up an install script...
The fact that you're still thinking of it as an install script is indicative that you might not have explored solving the problem with some of the more modern tools. You should really take a look at Chef...when you automate with Chef, you're not building an install script but a set of re-usable and configurable installation components that the engine intelligently applies based on the profile for the target machine. Those XML files that you're editing can become Ruby ERBs with logic to build the XML based on per-profile data, reference data and data obtained through searches of the network topology. For instance, let's say your XML file needs a comma separated list of ip/port combinations for all servers of a certain type in the deployment. Something like this would be very difficult to put into a deployment script, but is almost trivial to do in Chef (search based on role with a little ruby code to join the results together.) And as the deployment changes and new machines are added/removed, the tool handles re-generating those configuration files based on the updated deployment topology.
I work in enterprise software too (albeit SaaS) and we have everything automated with Chef. Our application has many different components (dbs, queues, schedulers, caches, REST services, etc) and Chef is able to coordinate everything fairly easily. The fact that we can use the same Chef recipes to deploy to production, QA and developer environments (through vagrant-managed VMs on developer machines) attests to how flexible the tool is.
"Don't blame me, I voted for Kodos!"
Why start with an insult?
You're half right - if the file is found in the start directory, no need to go to the search path. As for the rest of it, I think this comment and your response says it all. Remember that you can't control how other applications may edit the path, nor what versions of dependencies they may place on the system. The comment about the path being user specific is just irrelevant.
If you're concerned about isolation at this level, you can always use dedicated servers at the application layer or the data layer or where ever you're likely to run into problems. Presumably anyone who's spending hundreds of thousands of dollars on software won't balk at this.
Pre-configured OpenVZ images on linux+ NSIS on win?
I know tobacco is bad for you, so I smoke weed with crack.
In some installs, the database is Oracle, in others MS-SQL or DB2... Some installs will be MS-SQL and the application services, and front end will be on a single system, in others they may be split up. Some systems interface outside services and other systems. You really think that creating an installer flexible enough to ask for all the options, and baby stepping through is more effective than a checklist... dbms installed (check), application installed (check), application's config pointed at correct database (check)... I mean you really want my installer to know enough about the SQL installer, as well as the MQ and other systems to install them too?
Michael J. Ryan - tracker1.info
Huh, didn't know you could necrobump on /.
Nevertheless: Yes. Yes, an installer can have multiple options for satisfying its dependencies. Yes, it can check on runtime which of these are present on the system. Have you never seen the output of a "./configure" (often used before "make && make install" on Linux)? As I said previously: if you are a good programmer, it will take you roughly 10x the time you use for installing your software once to create a working installer. Then of course it depends on how often you install your software whether it makes sense for you to create an installer.
for i in `facebook friends "=bday" 2>/dev/null | cut -d " " -f 3-`; do facebook wallpost $i "Happy birthday!"; done