The first thing that comes to my mind is that most desktop Linux users will find all the software they need in the repositories, with the exception of the Flash plugin (but Adobe maintains Ubuntu and Fedora repositories for that plugin anyway, so the point is a bit moot) -- so setting noexec on/home is reasonable and will probably go unnoticed by the users who are most vulnerable to trojans (at least in my experience).
That's no different to the way most Windows users find their software in shops, or on cnet. Setting noexec on/home also doesn't stop people just installing something system-wide using rpm (or whatever).
Even if the noexec strategy was not in use, a virus writer would still have issues to deal with. Different distros are not necessarily compatible, and even within a single distro, there is no guarantee of compatibility. A trojan that tries to pass itself off as a routine program in GNOME would stick out like a sore thumb for a KDE user. A virus that tries to add itself to.bashrc would not be very effective for a csh user (nor would it be very effective for a user who does not use the shell, which is not as rare as you might think). The sort of monoculture that exists with Windows -- where a particular set of programs is very likely to be installed and used -- is not so prevalent with common Linux distros.
Linux is more than enough of a monoculture where it counts, so that point is moot. Any user capable of identifying the difference between a GNOME app and a KDE is app is already well above the level of knowledge where they're unlikely to be infected by something so obvious. No competent (and even most incompetent) attackers would focus only on a single shell's dotfiles, they'll simply hit all of them, along with the various methods for automatically starting software in the most common GUI shells.
Sure, it is possible to write Linux viruses, but the effect is not as severe (Warhol worms do not seem very likely); even if "Linux" grew to the popularity of Windows, it would require a single distro to be king, with a single configuration -- a monoculture that is not very likely to happen.
It wouldn't require anything of the sort. If Linux really was that fragmented, and distros really were that different, then they wouldn't have such vast software repositories to leverage - anything that makes it simple to run a "good" program on multiple distros, makes it equally easy to run a "bad" program on those same distros. There simply isn't much variation between the most common Linux distros, and it's disingenuous at best to say the practical result is any different to the variations between the multiple versions of Windows on the market.
The simple fact is that you can't protect a machine when ignorant end users can install arbitrary software.
The problem with the "core" of Windows is that it's not based on open standards [...]
Like what ?
It would be much, much better for them as a business, long term, to basically break the whole "Windows" concept up into a bunch of widgets that people can pick, ala carte, to add to whatever OS they choose to run. For example, MSFT did a great job getting game developers on board with Direct X, and as such, gaming is a compelling reason for many people to have Windows on a machine. But it's becoming less and less compelling as other alternatives become more refined and polished - and in 5 or 10 years I can easily imagine that alternatives for gaming (things like Cedega or other projects) will become much, much, MUCH more polished and viable, to the point where it won't be worth maintaining a seperate OS or machine just for gaming for many people.
Huh ? Why would "many people" be maintaining a _separate_ Windows machines just for games ? Why wouldn't they just be doing everything with that Windows machine ?
Like I said, it's an exit strategy for when the competition eventually and inevitably catches up to them.
Catches up with them in regards to what ? Projects like WINE are never going to be able to deliver equivalent application compatibility to Windows in a useful timeframe.
That'd be only about $24,000, actually. Well within our operating budget for upgrades this year.
That's not really the question. The question is how is that ~$25k of Investment going to deliver some Return ? You haven't really described an environment where SSDs in end-user PCs are going to deliver productivity increases.
Further, on a modern consumer computer, the hard drive is responsible for a significant fraction of the total power usage;
How do you figure that ? An average LCD will draw somewhere in the region of 30-50W, depending on size. The CPU probably around 20-30W. An average hard disk, even while seeking, will only pull 7-8W.
I'd be surprised if the hard disk was responsible for even 10% of the power draw of the typical PC.
We are transitioning all of our desktop and laptop systems here to SSD. Over 120 systems. $100 a pop, and we're spending another $100 on Win7. (already site-licenced Office 2k10).
What (and how) is the expected timeframe on recovering that tens-of-thousands-of-dollars expense ?
It would be interesting if they went the OS X route and went with the *nix (whatever) underpinnings and their stuff atop that. They'd get over a lot of core issues with the OS that people complain about, improve compatibility (which they may hate now, but they'll want it in the future as people become more OS agnostic).
There's nothing wrong with the "core" of Windows. Making Yet Another UNIX Clone (though that doesn't really describe OSX, at least not the way it's commonly used) would be *at best* a step sideways, and more likely a step backwards.
That's not true. With a single tool implementation like PackageKit, I get a single notification that there are many updates. In a "typical" windows setup, I'll get popups and notifications from all sorts of apps where I just have to keep clicking through them. Think of all the users out there that don't immediately update software when a notification comes in. Just recently, I got continuous notifications from Adobe Acrobat Reader on Windows nagging me about a new update. Then when I finally did install it, it kept reminding me I had to reboot. I really didn't want to at the time, I was busy with actual work and don't like rebooting often. The software, despite what they're saying still works. So I don't want the nag. And if you magnify that issue to all apps installed, it'd be just a horrible pop-up fest of "update me now" dialogs.
The practical difference between a single "unified updater" nagging about an update every other day, and a different "per-app" nagging about an update every other day, is not really significant. Either way, you end up getting nagged, it's just the nagging has a different skin each time.
Yes, there's some fundamental differences about what Unix command-line assumes about the user and what most people deem appropriate for "the desktop". But, you'll notice most of the tenets of the Unix Philosophy say nothing of the example you mention. The only one that comes close is the one about making every program a filter and that's down at #9.
I was actually thinking about ESR's "Rule of Silence: When a program has nothing surprising to say, it should say nothing". However, there's also Lesser Tenet #5: "silence is golden". Basically, the "no news is good news" principle is a cornerstone of UNIX tool implementation and, more importantly in the context of this discussion, describes the fundamental core of your argument. Again, I will make the point that UI behaviour acceptable to highly-experienced UNIX users, is of questionable relevance to the typical desktop PC user.
I'll give you a great example that's still a problem on Windows and I believe Linux. I think however, that Macs do this correctly.
Macs do not behave in the way you describe. When they hit some sort of roadblock copying, they stop (and they have some *very* unintuitive and destructive behaviour when doing things like copying two directories with the same name to one place). In some situations (generally involving network operations), not only do they stop, but they don't allow the possibility of resuming.
In fact, I can't think of _any_ UI off the top of my head which behaves the way you want, unless explicitly told to (cp -f, for example). If you want one justification as to why, I shall point you to ESR's ""Rule of Repair: When you must fail, fail noisily and as soon as possible".
You're ignoring my comments again. On Windows, a "setup.exe" is perfectly "proper". It's the defacto standard.
A properly built setup.exe will also allow unattended installs.
And that's exactly my point. It's something that's difficult to to do in Windows. And not difficult to do in Linux. I'm not talking about teaching someone who barely knows how to center text in MSOffice how to do system administration. I'm talking about how much effort it is for someone with reasonable administrative experience being able to figure out and implement.
I would argue that someone with reasonable _Windows_ sysadmin admin experience shouldn't have too much trouble, assuming their tools (the MSIs and setup.exe's, etc) are properly built. Obviously if they have to fight against the developer, then it's going to be more difficult - but so is installing (and especially maintaining) packages outside the control of the package manager.
With rpms, you learn a few options like "-e, -U" etc and you can get through. On Windows, what do I have to do? Install an Exchange server or something? And only if I'm lucky if the app I wanted had an appropriate MSI wil
Typical Microsoft -- solution to progress creating problem is to stop progress.
It's hardly a "Microsoft" solution, it's the solution on essentially every platform except Linux (or those using software primarily derived from Linux sources).
Linux is the _only_ mainstream platform that treats standardised, stable, binary-compatibility as a bad thing. Everyone else considers it an architectural requirement.
There are no "third parties" (unsupported second class citizens) in a properly designed system.
Your definition of "third party" is broken.
Exaggeration apparently is completely lost on you.
Well that's the problem with foaming zealots. You can never be sure when they're serious.
All of them.
Name some.
Try to find any dynamically linked library that is not shipped by Microsoft in any package that is known to use that library, and you will either find none (so it is statically linked) or a separate copy. And this happens with each and every application/library combination. This duplication causes performance degradation because CPU can't re-use library code in its cache across context switches.
Perhaps you missed the point of %PROGRAMFILES\Common Files, or just %SYSTEMROOT%\System[32] for poorly written applications.
For a counter-example, Apple (shockingly enough, given their history of Windows software) put a set of DLLs used by their applications in %PROGRAMFILES%\Common Files\Apple\Apple Application Support.
And those automated installs will still create massive amounts of duplicated copies of everything, or cause failures, or both. The fact they are running without you clicking on icons is absolutely irrelevant, I am talking about installers actually doing something useful.
You seem to be working from a false premise.
This only happens when those "Linux VMs" are administered by Windows admins such as yourself. Using VM as a replacement for package manager is a typical Windows technique, that exists because Windows has no usable package manager. Obviously Windows admins do it on Linux for the same purpose.
False. Note the presence of multiple solutions (Zones, Jails, Xen, UML, chroot) that are used in a similar fashion, most of which are _only_ capable of running Linux or some other UNIX.
Stop bringing up this stupid strawman, this is completely irrelevant to anything I am talking about.
That's because you're so desparate to go Windows-bashing you ignored the actual topic of discussion.
Windows does not have such thing, unless you are talking about compatibility between Microsoft products with other Microsoft products of the same generation.
False. Trivially demonstrable as such too, simply by firing up any one of a zillion old Windows applications on a newer release than the one they were written to.
On Windows, if Microsoft-sanctioned update breaks anything, you have only two choices -- not to update, or break and replace everything.
Just like RHEL, Ubuntu, Solaris, OSX, or basically any other platform, you mean ?
Without a package manager on any system you have to manually produce a consistent configuration on every such update, what takes entirety of sysadmin's time.
This is so far from the truth I can only assume you're back into "every Windows application is a minimum 1GB package" territory again.
Replacement of packages and required upgrades are not something some guy writes for each and every situation, and it's not something a human has to worry about -- it's all generated automatically, and automatically applied to a running system. The only alternative to this is to abandon all development not done by OS vendor, something that Microsoft, obviously tries to promote.
And this one is just so far from _reality_ that I'm beginning to think you're just on some nasty trip.
I have 24 years of experience in software development a
Fixing product defects is what happens when you ship defective products.
So you think every software vendor ships defective products ?
In the auto or any other industry it's a "recall". You ship a defective product, you have to fix it. You sound like they're doing it out of the goodness of their hearts. Do you work for MS, own stock, or what?
I never even suggested they're doing it for any reason other than good business. The same reason every other vendor fixes their bugs.
It's because to Microsoft, and undiscovered bug is a nonexistant bug. Their "security" model has always been "security through obscurity". Their philosophy is "why fix a bug if you don't have to?"
Yet they proactively fix bugs and distribute those fixes at no cost. Strange.
I'll give this guy the Uber geek crown if he adds a 200 foot vertical climb to his trip to the "datacenter". Because kids, that alone is a major PITA... nothing like screwing around with a laptop 200 feet up, in wind and having the damn thing sway about 2 feet back and forth while you work. Oh... dont drop anything... during setup when the RF guys screwed up and cut my comms wire to the base of the tower I dropped a laptop from 200 feet... Even Panasonic toughbooks dont survive that fall.
Why isn't the system at the bottom of the tower with 200 feet of cable above it ?
Only because libraries are now are either Microsoft products, or everything is tied to the executables -- they can just as well be statically linked now.
Er, yeah, that's kind of the point. The solution to dependency hell is a properly controlled set of stable, binary compatible (forwards and backwards) base libraries, and standardised locations for third parties to install their own.
Each and every piece of software released after 2000.
Uh huh. Even our whole install point for Office 2007 is less than a gig, and I can see at least a dozen "trivial applications" in our software distribution share whose installers are less than 20MB.
It'd be a lot easier if people like you just said you were trolling from the get-go.
Only because they all come with their own copy of everything, and it stays that way in memory, causing performance problems. How many copies of, say, JPEG library do you have in your RAM right now?
Can you point to some examples of applications that do this ?
My point is, Windows does not have it.
Absolutely it does. You can automate and batch unattended installs. Individual application developers might write their application in such a way that you can't do that, but that's not the fault of Windows.
If it did, people would not have 8-core boxes running 10 VMWare instances, each running a single "server" product.
Struggling to see the relevance between automating software installation and this. Not to mention your scenario is also quite common with Linux VMs, in no small part because of dependency hell (though being able to run the ideal scenario of one service per server is also nice).
What the Hell are you arguing about?
That using yum (or whatever) on Linux to install something is an interactive task.
Windows is so far behind this, "sysadmins" like you can't even imagine what responsible maintenance procedure looks like.
Yet strangely you've described an implementation of the standard practice I've been using for around a decade, across Windows, FreeBSD, Solaris and Linux servers.
"Interactivity" and "scripting" are of about the same relevance as the color of the box installation media came in -- what matters is the amount of work package manager does to keep things consistent, so human doesn't have to.
What's even better is when you have a platform that doesn't need to do all that work in the first place, because it actually has some understanding of "standard functionality" and "binary compatibility".
I can understand if you're caught up in the Linux mindset of "updating X must also cascade into updates for Y, A, J and a replacement of Q with N" then you might have trouble grasping the concept of just updating X, but don't worry, it'll come with time.
My understanding is that you are an experienced Windows sysadmin (a.k.a. VMWare jockey), who does not realize that it's possible to have efficient and straightforward package manager and reliable installation and update procedure, so he makes idiotic claims about irrelevant details.
Considering I haven't adminned Windows machines in anger for going on 5 years now, and I've been adminning various UNIX platforms for 10-15 years, I'd say your understanding is - unsurprisingly - awful. I do look after a few VMware clusters, however, so I guess you're not completely wrong.
I already addressed the motivation... several times.
Not really. The updater apps are already written, and getting notifications every other day for different apps is really no different whether it comes from an individual application or a central tool.
I don't think you understand what people mean by "required interactivity". If you have the time, I suggest read the "Unix Philosophy".
"The UNIX Philosophy" is almost entirely about writing commandline tools for highly competent end users to automate tasks with. It's relevance to interactive GUI interfaces for mostly ignorant users is rather suspect.
To pick one rather obvious point, when the typical end user runs some program and gets no response or feedback, they assume it hasn't done anything and/or failed. The UNIX Philosophy is pretty much the complete opposite.
Contrarily, _every_ graphical installer I've ever used (Windows, Linux, Apple, etc.) always requires the user to sit through various choices and mixing in long operations with babysitting "click next to continue" type operations.
Really ? Because most installers I can recall (though I will readily admit to installing things rarely) ask a few questions to start with about location, EULA, install for all users, etc, then go off and do their thing until the last "I'm done" screen where you just have to click finish.
The inherent problem with a graphical installer is that even if you reduce it to a single "OK" click in the beginning of the app, it doesn't solve the problem. The reason is when I have to do a batch operation, eg because I'm installing multiple apps, I want to just "set it up and go".
You're _way_ outside the normal use case for just about everyone except a UNIX nerd here.
Tools that I typically want on a Windows system would be Firefox, putty, 7-zip, Acrobat Reader. Perhaps the Gimp and OpenOffice. In a business setting MS Office of course. Can I get all those programs to install non-interactively on Windows? I've seen technotes for how to do this with MSOffice. But honestly it's way more work than it was worth to me. To me it wasn't both practical AND possible.
As with Linux, it depends on the developer to package it properly. Again, a batched/scripted/unattended install is so far outside the common use case for a Windows (or OS X, or indeed pretty much anything) end user that it not being the default is both understandable and expected. If you want to batch/script unattended installs, it's expected you'll be doing it in a managed environment, and thus have the requisite knowledge (or be prepared to learn).
Clearly we have different definitions of "interactive". Mine is one where end user interaction is required. Yours is one where end user interaction above a certain level is required.
Then Windows users have strange definition of a "problem".
I can't even remember the last time I saw a DLL related problem.
Every time one has to combine products that use incompatible versions of libraries, [...]
Something that happens quite rarely these days, which is my point.
It became easier for software vendors to distribute trivial programs as 1G packages, however users still have to deal with incompatibilities and duplication of everything at runtime.
Can you give some examples of "trivial programs being distributed as 1G packages", and/or common, contemporary software that has or causes DLL conflicts ?
"Automated" means that it handles dependencies, configuration and resolves conflicting settings.
And.... Your point is ?
You obviously never used those tools.
I'm responsible for a couple of hundred Linux machines, I probably run yum at least once a day, on average. Admittedly I don't use apt much since we're pretty much completely a CentOS/RHEL shop, but I have some personal VMs with Ubuntu installed.
They have interactive mode used to give the user choice of settings and merge user-modified configuration with modifications in a package, however both can (and should) be turned off when performed unattended or when user intends to always rely on updates in the package.
Which is relevant how, exactly ? My point was that and end user using those tools to install or update software *is an interactive task*. The fact that they can also be scripted to do stuff as well is utterly irrelevant.
Interactivity is not the issue in the first place -- you seem to unable to realize that functionality is not the same as presence or absence of user interface doodads.
And you seem completely incapable of actually understanding and contributing anything to the discussion except rhetoric and comical exaggeration.
You're just being silly there. Of course that approach would never work. People wouldn't go for it and Microsoft wouldn't want to deal with the hassle. The approach is just what the OSS people did with yum for example. Provide a software updater that others can hook into.
The practical difference between them installing some sort of.repo equivalent, and special updater apps, is not significant. The end result (timely updates) is the same.
There's nothing stopping Apple or Microsoft from implementing those. It's not/that/ difficult to do.
Sure, but where's the motivation ? The practical results will be little different from today, and chances are fair to good third party vendors won't use it anyway.
But as I understand it Windows apps solved this problem by simply including dlls in their own app directories. Or did they find a different solution?
The solution is a _stable_ base of shared libraries providing large amounts of functionality provided in the base system and the ability of apps to package local copies of DLLs if they need them. The "stable" part is what's missing from OSS systems, as updating one part nearly always leads to a cascade of dependency updates as well, because ABI stability in the OSS world is, at best, an afterthought.
The solution on OS X, by the way, is identical - a large set of stable libraries in the base distribution and facilities for per-app libraries where required.
Sure yum/can/ be interactive. But it's easy enough to tell it to just install what it needs to. Basically what I mean is that I can easily install/upgrade software in batch across a number of systems relatively easily on Redhat-based systems. This is entirely different from a graphical installer that absolutely and always requires me to sit in front of it and click "OK" to move the dialog forward.
And, similarly, you can do batch and unattended installations on Windows. That doesn't change the fact that an individual installing a specific application they want using yum (or some graphical wrapper for it) is an interactive task.
I've read things that imply non-interactive installs is possible in Windows. But the from what I've gathered it takes quite a bit of effort to setup an environment that allows for that.On top of that MSIs/may/ allow for non-interactivity but they also may not. It's really up to whoever wrote the MSI.
Yes. Just like RPMs.
I was quite excited when I first heard about MSIs on Windows, but then got rather disappointed when most MSI apps I installed still ran interactively.
MSIs almost always have switches for non-interactive installs. They don't do that by default, of course, since 99% of the time they're being installed in a situation where the user wants an interactive task.
You/could/ argue that someone can get an RPM to require interactivity as well. But that's not quite the same thing. RPMs don't have specific features that allow it.. ie. it really is designed for batch operations. And you really break it's operation with things like yum if you try to do something like that.
The "interactive" part is typing 'yum install blah', or 'rpm -ivh blah'. That's the equivalent of running an MSI and hitting next a few times. Both are interactive tasks (ie: not automated, not transparent, not managed by a third party).
If you know how I can install any and all MSI's I come across non-interactively, I'd greatly appreciate a pointer to a tutorial or something.
As with Linux apps, it's utterly dependent on the developer (or someone else) to package it properly. With that said, most MSIs should come with an "unattended install" option. Try running 'someinstaller.msi/?'.
Packaging system has nothing to do with non-interactive installation.
I think you need to complain to the poster I was replying to. He was the one using automated installation as an example of why a packaging system is good.
The fact that interactive installers exist, just shows how idiotic the whole Windows software distribution model is.
Hate to break it to you, but 'apt-get install blah' or 'yum install blah' are interactive.
Copyright's primary purpose is to make sure people make money from their work so that we have an economy, which is a benefit to society.
Copyright's primary purpose is to make sure a given piece of work can be sold more than once (effectively infinitely in its modern incarnation).
If nobody pays anyone for their work, you won't have the amount and quality of art as before, and culture would suffer. It's common sense.
So you're saying there wasn't any art and culture to speak of before a couple of centuries ago ?
There's plenty of ways people producing "art" and "culture" can be paid for their work without copyright.
I never understood the complaint when Slugboat Willy was about to fall into public domain. We have a right to Mickey Mouse? Who cares about it? If Disney is still making money off of it, why shouldn't they still own it?
The real question is what have they done to justify such extraordinary legal privileges as copyright provides, that no other form of productive labour is given ?
We live in a different era than when copyright was first created, an era in which media is far more pervasive and long-term than before, so it makes sense to extend copyrights to reflect today's media reality.
This is completely backwards. We live in an era where creating is much easier, where distribution and advertising costs can be practically zero and where distribution time is effectively instant. Or, to put it another way, where most of the expenses and risks around content production (that copyright is supposed to help) have been significantly reduced, if not practically eliminated.
Copyright terms should be getting *shorter*, not longer, especially if you believe its purpose is to "encourage the progress of the arts". Where's the motivation to produce new content if you (and your family, down to your grandchildren's grandchildren) can be selling the same piece of content you made when you were a teenager ?
Slashdot Mirror
Was I required to?
Well, I did specifically ask what the expected ROI of upgrading a bunch of PCs was (both both how and when). You didn't really answer that question.
OS X tends to have lower latency than Windows out of the box (you can disable services in Windows to help things).
Do you have any benchmarks for this ? OS X is much more sluggish than Windows in general use, so it's kind of hard to believe.
The first thing that comes to my mind is that most desktop Linux users will find all the software they need in the repositories, with the exception of the Flash plugin (but Adobe maintains Ubuntu and Fedora repositories for that plugin anyway, so the point is a bit moot) -- so setting noexec on /home is reasonable and will probably go unnoticed by the users who are most vulnerable to trojans (at least in my experience).
That's no different to the way most Windows users find their software in shops, or on cnet. Setting noexec on /home also doesn't stop people just installing something system-wide using rpm (or whatever).
Even if the noexec strategy was not in use, a virus writer would still have issues to deal with. Different distros are not necessarily compatible, and even within a single distro, there is no guarantee of compatibility. A trojan that tries to pass itself off as a routine program in GNOME would stick out like a sore thumb for a KDE user. A virus that tries to add itself to .bashrc would not be very effective for a csh user (nor would it be very effective for a user who does not use the shell, which is not as rare as you might think). The sort of monoculture that exists with Windows -- where a particular set of programs is very likely to be installed and used -- is not so prevalent with common Linux distros.
Linux is more than enough of a monoculture where it counts, so that point is moot. Any user capable of identifying the difference between a GNOME app and a KDE is app is already well above the level of knowledge where they're unlikely to be infected by something so obvious. No competent (and even most incompetent) attackers would focus only on a single shell's dotfiles, they'll simply hit all of them, along with the various methods for automatically starting software in the most common GUI shells.
Sure, it is possible to write Linux viruses, but the effect is not as severe (Warhol worms do not seem very likely); even if "Linux" grew to the popularity of Windows, it would require a single distro to be king, with a single configuration -- a monoculture that is not very likely to happen.
It wouldn't require anything of the sort. If Linux really was that fragmented, and distros really were that different, then they wouldn't have such vast software repositories to leverage - anything that makes it simple to run a "good" program on multiple distros, makes it equally easy to run a "bad" program on those same distros. There simply isn't much variation between the most common Linux distros, and it's disingenuous at best to say the practical result is any different to the variations between the multiple versions of Windows on the market.
The simple fact is that you can't protect a machine when ignorant end users can install arbitrary software.
The problem with the "core" of Windows is that it's not based on open standards [...]
Like what ?
It would be much, much better for them as a business, long term, to basically break the whole "Windows" concept up into a bunch of widgets that people can pick, ala carte, to add to whatever OS they choose to run. For example, MSFT did a great job getting game developers on board with Direct X, and as such, gaming is a compelling reason for many people to have Windows on a machine. But it's becoming less and less compelling as other alternatives become more refined and polished - and in 5 or 10 years I can easily imagine that alternatives for gaming (things like Cedega or other projects) will become much, much, MUCH more polished and viable, to the point where it won't be worth maintaining a seperate OS or machine just for gaming for many people.
Huh ? Why would "many people" be maintaining a _separate_ Windows machines just for games ? Why wouldn't they just be doing everything with that Windows machine ?
Like I said, it's an exit strategy for when the competition eventually and inevitably catches up to them.
Catches up with them in regards to what ? Projects like WINE are never going to be able to deliver equivalent application compatibility to Windows in a useful timeframe.
That'd be only about $24,000, actually. Well within our operating budget for upgrades this year.
That's not really the question. The question is how is that ~$25k of Investment going to deliver some Return ? You haven't really described an environment where SSDs in end-user PCs are going to deliver productivity increases.
So to get 300Mbps would be $1200/month, [...]
You generate ~40GB of new data every day ?
I could buy a new tape library and new tapes 2-3 times a year for that.
Are you accounting for your tape pickup/delivery and storage costs ? The human time in swapping tapes ?
Further, on a modern consumer computer, the hard drive is responsible for a significant fraction of the total power usage;
How do you figure that ? An average LCD will draw somewhere in the region of 30-50W, depending on size. The CPU probably around 20-30W. An average hard disk, even while seeking, will only pull 7-8W.
I'd be surprised if the hard disk was responsible for even 10% of the power draw of the typical PC.
We are transitioning all of our desktop and laptop systems here to SSD. Over 120 systems. $100 a pop, and we're spending another $100 on Win7. (already site-licenced Office 2k10).
What (and how) is the expected timeframe on recovering that tens-of-thousands-of-dollars expense ?
But Microsoft aren't doing those things. They've had a catastrophic release for each of their main products, [...]
That's a mighty strange definition of "catastrophic" you have there.
It would be interesting if they went the OS X route and went with the *nix (whatever) underpinnings and their stuff atop that. They'd get over a lot of core issues with the OS that people complain about, improve compatibility (which they may hate now, but they'll want it in the future as people become more OS agnostic).
There's nothing wrong with the "core" of Windows. Making Yet Another UNIX Clone (though that doesn't really describe OSX, at least not the way it's commonly used) would be *at best* a step sideways, and more likely a step backwards.
And oddly enough - not very much money at all.You should probably recalculate allowing for a) inflation and b) taxes.
That's not true. With a single tool implementation like PackageKit, I get a single notification that there are many updates. In a "typical" windows setup, I'll get popups and notifications from all sorts of apps where I just have to keep clicking through them. Think of all the users out there that don't immediately update software when a notification comes in. Just recently, I got continuous notifications from Adobe Acrobat Reader on Windows nagging me about a new update. Then when I finally did install it, it kept reminding me I had to reboot. I really didn't want to at the time, I was busy with actual work and don't like rebooting often. The software, despite what they're saying still works. So I don't want the nag. And if you magnify that issue to all apps installed, it'd be just a horrible pop-up fest of "update me now" dialogs.
The practical difference between a single "unified updater" nagging about an update every other day, and a different "per-app" nagging about an update every other day, is not really significant. Either way, you end up getting nagged, it's just the nagging has a different skin each time.
Yes, there's some fundamental differences about what Unix command-line assumes about the user and what most people deem appropriate for "the desktop". But, you'll notice most of the tenets of the Unix Philosophy say nothing of the example you mention. The only one that comes close is the one about making every program a filter and that's down at #9.
I was actually thinking about ESR's "Rule of Silence: When a program has nothing surprising to say, it should say nothing". However, there's also Lesser Tenet #5: "silence is golden". Basically, the "no news is good news" principle is a cornerstone of UNIX tool implementation and, more importantly in the context of this discussion, describes the fundamental core of your argument. Again, I will make the point that UI behaviour acceptable to highly-experienced UNIX users, is of questionable relevance to the typical desktop PC user.
I'll give you a great example that's still a problem on Windows and I believe Linux. I think however, that Macs do this correctly.
Macs do not behave in the way you describe. When they hit some sort of roadblock copying, they stop (and they have some *very* unintuitive and destructive behaviour when doing things like copying two directories with the same name to one place). In some situations (generally involving network operations), not only do they stop, but they don't allow the possibility of resuming.
In fact, I can't think of _any_ UI off the top of my head which behaves the way you want, unless explicitly told to (cp -f, for example). If you want one justification as to why, I shall point you to ESR's ""Rule of Repair: When you must fail, fail noisily and as soon as possible".
You're ignoring my comments again. On Windows, a "setup.exe" is perfectly "proper". It's the defacto standard.
A properly built setup.exe will also allow unattended installs.
And that's exactly my point. It's something that's difficult to to do in Windows. And not difficult to do in Linux. I'm not talking about teaching someone who barely knows how to center text in MSOffice how to do system administration. I'm talking about how much effort it is for someone with reasonable administrative experience being able to figure out and implement.
I would argue that someone with reasonable _Windows_ sysadmin admin experience shouldn't have too much trouble, assuming their tools (the MSIs and setup.exe's, etc) are properly built. Obviously if they have to fight against the developer, then it's going to be more difficult - but so is installing (and especially maintaining) packages outside the control of the package manager.
With rpms, you learn a few options like "-e, -U" etc and you can get through. On Windows, what do I have to do? Install an Exchange server or something? And only if I'm lucky if the app I wanted had an appropriate MSI wil
Typical Microsoft -- solution to progress creating problem is to stop progress.
It's hardly a "Microsoft" solution, it's the solution on essentially every platform except Linux (or those using software primarily derived from Linux sources).
Linux is the _only_ mainstream platform that treats standardised, stable, binary-compatibility as a bad thing. Everyone else considers it an architectural requirement.
There are no "third parties" (unsupported second class citizens) in a properly designed system.
Your definition of "third party" is broken.
Exaggeration apparently is completely lost on you.
Well that's the problem with foaming zealots. You can never be sure when they're serious.
All of them.
Name some.
Try to find any dynamically linked library that is not shipped by Microsoft in any package that is known to use that library, and you will either find none (so it is statically linked) or a separate copy. And this happens with each and every application/library combination. This duplication causes performance degradation because CPU can't re-use library code in its cache across context switches.
Perhaps you missed the point of %PROGRAMFILES\Common Files, or just %SYSTEMROOT%\System[32] for poorly written applications.
For a counter-example, Apple (shockingly enough, given their history of Windows software) put a set of DLLs used by their applications in %PROGRAMFILES%\Common Files\Apple\Apple Application Support.
And those automated installs will still create massive amounts of duplicated copies of everything, or cause failures, or both. The fact they are running without you clicking on icons is absolutely irrelevant, I am talking about installers actually doing something useful.
You seem to be working from a false premise.
This only happens when those "Linux VMs" are administered by Windows admins such as yourself. Using VM as a replacement for package manager is a typical Windows technique, that exists because Windows has no usable package manager. Obviously Windows admins do it on Linux for the same purpose.
False. Note the presence of multiple solutions (Zones, Jails, Xen, UML, chroot) that are used in a similar fashion, most of which are _only_ capable of running Linux or some other UNIX.
Stop bringing up this stupid strawman, this is completely irrelevant to anything I am talking about.
That's because you're so desparate to go Windows-bashing you ignored the actual topic of discussion.
Windows does not have such thing, unless you are talking about compatibility between Microsoft products with other Microsoft products of the same generation.
False. Trivially demonstrable as such too, simply by firing up any one of a zillion old Windows applications on a newer release than the one they were written to.
On Windows, if Microsoft-sanctioned update breaks anything, you have only two choices -- not to update, or break and replace everything.
Just like RHEL, Ubuntu, Solaris, OSX, or basically any other platform, you mean ?
Without a package manager on any system you have to manually produce a consistent configuration on every such update, what takes entirety of sysadmin's time.
This is so far from the truth I can only assume you're back into "every Windows application is a minimum 1GB package" territory again.
Replacement of packages and required upgrades are not something some guy writes for each and every situation, and it's not something a human has to worry about -- it's all generated automatically, and automatically applied to a running system. The only alternative to this is to abandon all development not done by OS vendor, something that Microsoft, obviously tries to promote.
And this one is just so far from _reality_ that I'm beginning to think you're just on some nasty trip.
I have 24 years of experience in software development a
Fixing product defects is what happens when you ship defective products.
So you think every software vendor ships defective products ?
In the auto or any other industry it's a "recall". You ship a defective product, you have to fix it. You sound like they're doing it out of the goodness of their hearts. Do you work for MS, own stock, or what?
I never even suggested they're doing it for any reason other than good business. The same reason every other vendor fixes their bugs.
It's because to Microsoft, and undiscovered bug is a nonexistant bug. Their "security" model has always been "security through obscurity". Their philosophy is "why fix a bug if you don't have to?"
Yet they proactively fix bugs and distribute those fixes at no cost. Strange.
I'll give this guy the Uber geek crown if he adds a 200 foot vertical climb to his trip to the "datacenter". Because kids, that alone is a major PITA... nothing like screwing around with a laptop 200 feet up, in wind and having the damn thing sway about 2 feet back and forth while you work. Oh... dont drop anything... during setup when the RF guys screwed up and cut my comms wire to the base of the tower I dropped a laptop from 200 feet... Even Panasonic toughbooks dont survive that fall.
Why isn't the system at the bottom of the tower with 200 feet of cable above it ?
Only because libraries are now are either Microsoft products, or everything is tied to the executables -- they can just as well be statically linked now.
Er, yeah, that's kind of the point. The solution to dependency hell is a properly controlled set of stable, binary compatible (forwards and backwards) base libraries, and standardised locations for third parties to install their own.
Each and every piece of software released after 2000.
Uh huh. Even our whole install point for Office 2007 is less than a gig, and I can see at least a dozen "trivial applications" in our software distribution share whose installers are less than 20MB.
It'd be a lot easier if people like you just said you were trolling from the get-go.
Only because they all come with their own copy of everything, and it stays that way in memory, causing performance problems. How many copies of, say, JPEG library do you have in your RAM right now?
Can you point to some examples of applications that do this ?
My point is, Windows does not have it.
Absolutely it does. You can automate and batch unattended installs. Individual application developers might write their application in such a way that you can't do that, but that's not the fault of Windows.
If it did, people would not have 8-core boxes running 10 VMWare instances, each running a single "server" product.
Struggling to see the relevance between automating software installation and this. Not to mention your scenario is also quite common with Linux VMs, in no small part because of dependency hell (though being able to run the ideal scenario of one service per server is also nice).
What the Hell are you arguing about?
That using yum (or whatever) on Linux to install something is an interactive task.
Windows is so far behind this, "sysadmins" like you can't even imagine what responsible maintenance procedure looks like.
Yet strangely you've described an implementation of the standard practice I've been using for around a decade, across Windows, FreeBSD, Solaris and Linux servers.
"Interactivity" and "scripting" are of about the same relevance as the color of the box installation media came in -- what matters is the amount of work package manager does to keep things consistent, so human doesn't have to.
What's even better is when you have a platform that doesn't need to do all that work in the first place, because it actually has some understanding of "standard functionality" and "binary compatibility".
I can understand if you're caught up in the Linux mindset of "updating X must also cascade into updates for Y, A, J and a replacement of Q with N" then you might have trouble grasping the concept of just updating X, but don't worry, it'll come with time.
My understanding is that you are an experienced Windows sysadmin (a.k.a. VMWare jockey), who does not realize that it's possible to have efficient and straightforward package manager and reliable installation and update procedure, so he makes idiotic claims about irrelevant details.
Considering I haven't adminned Windows machines in anger for going on 5 years now, and I've been adminning various UNIX platforms for 10-15 years, I'd say your understanding is - unsurprisingly - awful. I do look after a few VMware clusters, however, so I guess you're not completely wrong.
An independent source-code audit could have saved three lives in that case.
What evidence do you have that an independent code audit would have had any more chance of catching the error than an internal code audit ?
I already addressed the motivation... several times.
Not really. The updater apps are already written, and getting notifications every other day for different apps is really no different whether it comes from an individual application or a central tool.
I don't think you understand what people mean by "required interactivity". If you have the time, I suggest read the "Unix Philosophy".
"The UNIX Philosophy" is almost entirely about writing commandline tools for highly competent end users to automate tasks with. It's relevance to interactive GUI interfaces for mostly ignorant users is rather suspect.
To pick one rather obvious point, when the typical end user runs some program and gets no response or feedback, they assume it hasn't done anything and/or failed. The UNIX Philosophy is pretty much the complete opposite.
Contrarily, _every_ graphical installer I've ever used (Windows, Linux, Apple, etc.) always requires the user to sit through various choices and mixing in long operations with babysitting "click next to continue" type operations.
Really ? Because most installers I can recall (though I will readily admit to installing things rarely) ask a few questions to start with about location, EULA, install for all users, etc, then go off and do their thing until the last "I'm done" screen where you just have to click finish.
The inherent problem with a graphical installer is that even if you reduce it to a single "OK" click in the beginning of the app, it doesn't solve the problem. The reason is when I have to do a batch operation, eg because I'm installing multiple apps, I want to just "set it up and go".
You're _way_ outside the normal use case for just about everyone except a UNIX nerd here.
Tools that I typically want on a Windows system would be Firefox, putty, 7-zip, Acrobat Reader. Perhaps the Gimp and OpenOffice. In a business setting MS Office of course. Can I get all those programs to install non-interactively on Windows? I've seen technotes for how to do this with MSOffice. But honestly it's way more work than it was worth to me. To me it wasn't both practical AND possible.
As with Linux, it depends on the developer to package it properly. Again, a batched/scripted/unattended install is so far outside the common use case for a Windows (or OS X, or indeed pretty much anything) end user that it not being the default is both understandable and expected. If you want to batch/script unattended installs, it's expected you'll be doing it in a managed environment, and thus have the requisite knowledge (or be prepared to learn).
Clearly we have different definitions of "interactive". Mine is one where end user interaction is required. Yours is one where end user interaction above a certain level is required.
Then Windows users have strange definition of a "problem".
I can't even remember the last time I saw a DLL related problem.
Every time one has to combine products that use incompatible versions of libraries, [...]
Something that happens quite rarely these days, which is my point.
It became easier for software vendors to distribute trivial programs as 1G packages, however users still have to deal with incompatibilities and duplication of everything at runtime.
Can you give some examples of "trivial programs being distributed as 1G packages", and/or common, contemporary software that has or causes DLL conflicts ?
"Automated" means that it handles dependencies, configuration and resolves conflicting settings.
And.... Your point is ?
You obviously never used those tools.
I'm responsible for a couple of hundred Linux machines, I probably run yum at least once a day, on average. Admittedly I don't use apt much since we're pretty much completely a CentOS/RHEL shop, but I have some personal VMs with Ubuntu installed.
They have interactive mode used to give the user choice of settings and merge user-modified configuration with modifications in a package, however both can (and should) be turned off when performed unattended or when user intends to always rely on updates in the package.
Which is relevant how, exactly ? My point was that and end user using those tools to install or update software *is an interactive task*. The fact that they can also be scripted to do stuff as well is utterly irrelevant.
Interactivity is not the issue in the first place -- you seem to unable to realize that functionality is not the same as presence or absence of user interface doodads.
And you seem completely incapable of actually understanding and contributing anything to the discussion except rhetoric and comical exaggeration.
You're just being silly there. Of course that approach would never work. People wouldn't go for it and Microsoft wouldn't want to deal with the hassle. The approach is just what the OSS people did with yum for example. Provide a software updater that others can hook into.
The practical difference between them installing some sort of .repo equivalent, and special updater apps, is not significant. The end result (timely updates) is the same.
There's nothing stopping Apple or Microsoft from implementing those. It's not /that/ difficult to do.
Sure, but where's the motivation ? The practical results will be little different from today, and chances are fair to good third party vendors won't use it anyway.
But as I understand it Windows apps solved this problem by simply including dlls in their own app directories. Or did they find a different solution?
The solution is a _stable_ base of shared libraries providing large amounts of functionality provided in the base system and the ability of apps to package local copies of DLLs if they need them. The "stable" part is what's missing from OSS systems, as updating one part nearly always leads to a cascade of dependency updates as well, because ABI stability in the OSS world is, at best, an afterthought.
The solution on OS X, by the way, is identical - a large set of stable libraries in the base distribution and facilities for per-app libraries where required.
Sure yum /can/ be interactive. But it's easy enough to tell it to just install what it needs to. Basically what I mean is that I can easily install/upgrade software in batch across a number of systems relatively easily on Redhat-based systems. This is entirely different from a graphical installer that absolutely and always requires me to sit in front of it and click "OK" to move the dialog forward.
And, similarly, you can do batch and unattended installations on Windows. That doesn't change the fact that an individual installing a specific application they want using yum (or some graphical wrapper for it) is an interactive task.
I've read things that imply non-interactive installs is possible in Windows. But the from what I've gathered it takes quite a bit of effort to setup an environment that allows for that.On top of that MSIs /may/ allow for non-interactivity but they also may not. It's really up to whoever wrote the MSI.
Yes. Just like RPMs.
I was quite excited when I first heard about MSIs on Windows, but then got rather disappointed when most MSI apps I installed still ran interactively.
MSIs almost always have switches for non-interactive installs. They don't do that by default, of course, since 99% of the time they're being installed in a situation where the user wants an interactive task.
You /could/ argue that someone can get an RPM to require interactivity as well. But that's not quite the same thing. RPMs don't have specific features that allow it.. ie. it really is designed for batch operations. And you really break it's operation with things like yum if you try to do something like that.
The "interactive" part is typing 'yum install blah', or 'rpm -ivh blah'. That's the equivalent of running an MSI and hitting next a few times. Both are interactive tasks (ie: not automated, not transparent, not managed by a third party).
If you know how I can install any and all MSI's I come across non-interactively, I'd greatly appreciate a pointer to a tutorial or something.
As with Linux apps, it's utterly dependent on the developer (or someone else) to package it properly. With that said, most MSIs should come with an "unattended install" option. Try running 'someinstaller.msi /?'.
A lot of people agree to click through EULA's, but that isn't the greatest example.
EULA's aren't contracts.
Really?
As a common problem ? Absolutely.
Packaging system has nothing to do with non-interactive installation.
I think you need to complain to the poster I was replying to. He was the one using automated installation as an example of why a packaging system is good.
The fact that interactive installers exist, just shows how idiotic the whole Windows software distribution model is.
Hate to break it to you, but 'apt-get install blah' or 'yum install blah' are interactive.
Well, I'll just copy that code, [...]
From where ?
Copyright's primary purpose is to make sure people make money from their work so that we have an economy, which is a benefit to society.
Copyright's primary purpose is to make sure a given piece of work can be sold more than once (effectively infinitely in its modern incarnation).
If nobody pays anyone for their work, you won't have the amount and quality of art as before, and culture would suffer. It's common sense.
So you're saying there wasn't any art and culture to speak of before a couple of centuries ago ?
There's plenty of ways people producing "art" and "culture" can be paid for their work without copyright.
I never understood the complaint when Slugboat Willy was about to fall into public domain. We have a right to Mickey Mouse? Who cares about it? If Disney is still making money off of it, why shouldn't they still own it?
The real question is what have they done to justify such extraordinary legal privileges as copyright provides, that no other form of productive labour is given ?
We live in a different era than when copyright was first created, an era in which media is far more pervasive and long-term than before, so it makes sense to extend copyrights to reflect today's media reality.
This is completely backwards. We live in an era where creating is much easier, where distribution and advertising costs can be practically zero and where distribution time is effectively instant. Or, to put it another way, where most of the expenses and risks around content production (that copyright is supposed to help) have been significantly reduced, if not practically eliminated.
Copyright terms should be getting *shorter*, not longer, especially if you believe its purpose is to "encourage the progress of the arts". Where's the motivation to produce new content if you (and your family, down to your grandchildren's grandchildren) can be selling the same piece of content you made when you were a teenager ?