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.
Why not package enterprise-grade software into InstallShield or RPM/DEB packages like every other piece of end-user software?
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!
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.
DNA is the ultimate spaghetti code.
...when there are package managers?
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?
Yawn
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.
The applications themselves are just WAR and JAR files drop them into the configured server and BAM
What?! The server explodes? I'm surprised you continue your nefarious business practices, don't you have any shame?
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.
Come on,... every reasonable operating system has got a package manager and an easy-to-use frontend for it.
You don't know "package managers"? It's the same as an "app store", only more portable.
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?
I run binaries straight out of a user directory and avoid system wide installations of programs when it is at all possible.
I know that this is not ideal on a multi user system. BUT it could be. Why not because like all systems that try to make the core too flexible, there will be user permission issues, core call conflicts created, library compatibility issues that need to be addressed and complicated installation requirements as a consequence.
I run the Firefox binary in my user space, Google Earth, music notation programs and the list goes on. With storage being cheap why not allow and teach users to do this instead of having to become root or administrator to accomplish the use of a friggin' binary! :(){ :|:& };:
DUMP system wide installers completely and just use README quit doing the click this bs gui garbage to do things that are not really necessary! AND above all quit dummying down computer users and thinking that programmers are by nature just that much more intelligent than us poor stupid (L) users.
Unfortunately the OP tried the two most clueless software companies on the planet. They're easy targets for this sort of rant.
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
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?
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.
Sure simple apps to redistribute are easy, but the complexity occurs when you have to configure the OS and other third party applications. Most programmers don't realize that it's difficult if there is someone taking care of this. It doesn't matter if you're using a packager or a custom executable to do the job, it just has to be done as any other programming job needs to be done. The only thing is that you're working outside of the bubble that programming languages give you and I don't think that's taught very often in schools (from what I see anyways, maybe some do).
Just keep this in mind, if there is a 1 in 1000 chance that something can go wrong, take care of it. If a human needs to touch it, consider it broken.
If you have a problem with installs, hire someone that knows something more about computers than just how to program them.
In the end, if you have this job, and it's for something other than a simple app, you'll end up writing in 2 or 3 languages (whether they be scripting or not) and at one point during the prototyping you'll make the decision whether to use a commercial packager or not (either way doesn't matter, they may or may not include what you need).
So in the end it's like programming anything, but I find that you need to know more about your environment than just programming some software in one language, not more complex, just a larger bubble.
One mistake that some companies make is to hire people that don't know programming, or only know programming for this job. You need both.
Crappy code is my bread & butter. Adapt a "can do"attitude and you have job security. And frankly, stop the whining already, its 2013 and you geniuses programmers have yet deliver in a couple of areas. Where is my hard AI. Make up your mind about NP.
Crappy code had its function and if i am paid to work on that code i will do so. I will even maintain your spaghetti structure if you really want me to, but i will charge extra. For me, its just a job.
I do have my own preferred code layout for readability but even on that subject there is no industry standard. camelCase? Newline before { , what? Honestly, the worries of the next programmer is not my priority. Getting payed is. And that's highly dependent on the opinion "du jour" of the boss "du jour".
Its a job, shut up and do your job.
The third one ended up crashing my entire computer (not just Virtual Box). After an hour or so of digging, I discovered that I had to turn off Data Execution Prevention at the BIOS level. That’s fair; I won’t hold that one against Oracle.
Since when is it ever OK for a virtual machine to take down the physical host? Oracle provided image, Oracle provide VM host, Oracle provided crash, and after all of the ranting, "won't hold that one against Oracle". Really?
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.
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.
His assertion that open source solutions are easy to install reeks of drinking deeply from the Kool Aid. I've had plenty of installation nightmares in Linux.
This one really takes the cake, though: "Ever installed Eclipse? Easy."
What the actual fuck? Eclipse has never been anything but a headache for me. To this day I can't upgrade anything in it because it installs with conflicting dependencies.
Laziness has no minimum capitalization requirement.
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.
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.
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.
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.
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.
It is mostly just fine if you fubar a CMS or Wiki database, nobody is going to complain. Screwing up a multiple terabyte production database... different story.
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.
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'
And scripts need passwords to do stuff on the installation, which may not even be possible to script.
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!
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
I worked for a development company as a systems administrator. Not only are enterprise applications difficult when you take them across every flavor of operating system known to man it's ratcheted up even more! Try installing those apps on AIX or HP-UX Some times there is NO DOCUMENTATION at all! Honestly a Java (i do not work for any java affiliated company) interface can be made to work across all platforms but for some reason it don't make sense for application developers to use. It's maddening,
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.
Hey man, WAR is hell.
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.
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.
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
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
*pulls the shiny icon to the Applications folder*
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.
I wonder if reading your code is anything like reading the 123 word sentence in your summary.
You lost all cred as a developer as soon as you admitted to using an iPhone.
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'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.
From my experience the difficulties with software development, as well as hardware development, logistics, and everything else that goes into producing an efficient, upgradable, long lived system almost always arise from a lack of (what we in the defense industry refer to as) "systems engineering". You start with very high, overarching functional requirements defining what the entire system must do as a whole. You decompose those requirements into sub-functions while maintaining strict definition and control of the function-to-function interfaces, and so on until you have a functional architecture. Then you allocate functionality to software and hardware configuration items - again under strict control (i.e., configuration management). Each configuration item is tested separately to the requirements allocated to it, then configuration items are combined together and integration testing is performed to higher and higher levels until the entire system is tested as a whole to the original highest level requirements. This is all very difficult to do, granted, but with strict discipline it can be done. The biggest problem is always the same - poorly defined requirements. Always. In many to most cases, the customer thinks they know what they want - but they do not - and insist on proceeding on to the design phase before even the highest level functional requirements care iron clad. When this happens on very large projects failure is inevitable. The system engineer's job is to get the requirements right despite the best efforts of the customer to "just get something built so it looks like progress". Seen it many times.
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
BS. SecureBoot is about MAFIAA DRM.
Because you make more money on maintenance. Thats on the of the biggest problems.
http://michaelsmith.id.au
...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
After all, who would seriously run a Windows server on actual hardware with the exploits Windows has. Worse still, why would anybody want to take the time to secure it since it isn't secure enough by default when UNIX (and its various children) is already secure and just needs proper administration?
Love submitter's problems with Windows Explorer. Perfect example of why Shell Extensions are shit - some third party thing is trying to thumbnail files or extract metadata to display in a panel and has fallen over. But oh, it must be Microsoft's fault! (It is, really, because they created the capability of Shell Extensions in the first place.)
And holding up Eclipse as a perfect example of how to do things? Because obviously Java updates *never* break Eclipse in any way, shape or form. And because Eclipse updates *never* break ADK in any way, shape or form. Get real.
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.
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.
There's a software company that puts out shit, runs like shit, has a shit development process, but has a GREAT sales team that sells shit to PHBs. The PHBs then take this shit and hand it to their techs to implement. Then their business gets ran into the ground because they don't listen to how shitty the software is, and LabTech Software (during the sales process) goes on about how to change your business so it runs with LabTech.
They have so many ridiculous UI bugs and even misspellings. Their support is useless. Of course, they sell consulting services. You report an obvious bug, and their response is that it's a feature or that it is a feature request. Try tabbing through their UI and laugh at the tab order their shit-for-brains Floridian programmers are too lazy to maintain/fix.
ConnectWise is total shit, too. Took them years to link a blob of text to the fucking database entries that comprise the blob of text. The solution when changing a bunch of those entries was to either manually cleanup the resolution field (blob of text) or clear it and open/save each time entry so that the text in your time entries matched what was in your resolution field.
They still can't put a fucking "\n" at the end of their time stamp string when you click the fucking clock button. STILL! That actually worked for years, but they fucked it up for no reason. A fucking "\n"!!!
One time they cleared a bunch of password fields to "null" if the length was over some number of characters (like 40 something characters - caused a problem when maintaining a history of passwords in that field). Worked fine for years, then an update, then fucking bam! Lost your passwords. Idiots.
These two fucks ups of companies used to work together in the same building. Fuck them both. I sincerely hope someone or multiple people from both companies are reading this shit and can reflect for a bit. You know who I am. I've drank with you fucktards at Bonnet Creek.
They're registering your computer in the HP botnet, of course.
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.
Hey, this is only the tip of the iceberg.
For instance, how many systems have a Country table, then force the customers to populate that table? Every. Single. Customer. Ditto for States/Provinces/Cantons.
Even if a system cannot ever be fully pre-populated, many basic setup options can be ready to go for 80% of the customers. Yet how many packages try?
The polish and sophistication of a lot of shipping software is seriously lacking.
What an open source shill.