Slashdot Mirror
Lightspark 0.4.2 Open Source Flash Player Released
suraj.sun writes "The Lightspark project has released version 0.4.2 of its free, open source Flash player. According to Lightspark developer Alessandro Pignotti, the alternative Flash Player implementation is 'designed from the ground up to be efficient on current and (hopefully) future hardware.'
The latest release of Lightspark features better compatibility with YouTube videos, sound synchronization support and the ability to use fontconfig for font selection. Other changes include plug-in support for Google's Chrome/Chromium web browser and support for Firefox's out of process plug-in (OOPP) mode, which was added in version 3.6.4 of the browser."
At least link to the project page rather than a rehashed "news" story: http://sourceforge.net/apps/trac/lightspark
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
...would be blacklisting for sites that serve ads and popups. I'd settle for restricting flash to site domain only.
Now that open source has embraces the flash standard, no doubt Adobe will add proprietary additions so sow incompatibility.
The protentially nice thing about this howerve is that if
1) it's efficient
2) not buggy
3) supports DRM
then it answers apple's complaints about flash and Youtube's complaints about H264. The problme for apple was that it would be insane to make your player beholden to a closed 3rd party app, espeically one from a company that hsitorically dragged it's heels in incorproating your platforms new features. Apple thrives on offering distinguishing features and adobe smothers them if they don't incorporate them.
But if the source is open apple is free to make sure it keeps up. So long as it is not as buggy as flash was.
Likewise youtube complained they could not monetize Video under H264 as well as under flash. the ability to have linking and overlays and such was required for the cash register.
Again this is now possible if this supports DRM.
One nice thing is that since apple already has a sandboxing system in both OSX and iOS, having it open source may allow them to get a tighter sandbox. No need to count on Adobe's sandbox working.
Some drink at the fountain of knowledge. Others just gargle.
I seem to remember that the real problem Flash clones is that documentation is not completely free and if you read it you have to be under strong NDA for the rest of your life. This should also be why Gnash always lags behind. How did he overcome this issue? Or are we waiting for a lawsuit to strike as soon as the plugin becomes usable?
How does this compare to the FSF sponsered Gnash then?
By my count there are atleast 4 opensource flash project. Most of them seem to exist just for the developer's own benefit. Is there any analysis or review and comparison of the several open source flash clones?
...is it secure?
Chico and Harpo on the problems with Flash substitutes
http://www.youtube.com/watch?v=F5Ovh18nYwc
"Alright never mind c'mon we work without it.."
.
Prisencolinensinainciusol. Ol Rait!
Has anyone done any benchmarking? Is it hardware accelerated (video, vector etc) on Linux?
ayottesoftware.com
Will it work with www.hulu.com?
...the guy kind of has a point.
When this can be a drop in replacement for the vendor's version that doesn't support video acceleration on most platforms, then it will be something.
For now, it is something that just looks very promising for now.
A Pirate and a Puritan look the same on a balance sheet.
The good news: it's an open-source Flash player
The bad news: for better compatibility with web browsers, it's written in Flash
Mafia Wars, etc?
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
The irony is that if open source people didn't have a target to emulate, there's tons of things that would have never been written since a baseline and mindshare in the overall tech market wouldn't have existed:
lex = flex
yacc = bison
sh = bash
UNIX = LINUX
vi = vim
To name just a few.
So your complaint about "proprietary" falls on deaf ears. If nothing else, what you call proprietary seeds things.
I'm trying to build it now and in case anybody wants to bitch about audio systems, it appears to use PulseAudio.
Of course I have ALSA.
Shit is going to ensue.
I seem to remember that the real problem Flash clones is that documentation is not completely free and if you read it you have to be under strong NDA for the rest of your life. This should also be why Gnash always lags behind. How did he overcome this issue? Or are we waiting for a lawsuit to strike as soon as the plugin becomes usable?
The creator of the project trained a chimpansee to understand code, a literal code-monkey if you will or rather a code-ape to be more accurate. This code-ape then reads the Flash documentation and explains it with sign language to the project creator. Since the code-ape cannot be properly held to an NDA the project continues unencumbered by draconian laws or demonic contracts.
Big apple, new Yorik, undig it, something's unrotting in Edenmark.
What makes you think those developers are interested in getting people to use Linux?
Mada mada dane.
i386 protected mode OS
ext2/3
emacs
Perl, Python and others
decss
bayesian spam filtering
eclipse
To name a few more. Proprietary is not necessarily first, just the first to try and make profit from the project.
"Please describe the scientific nature of the 'whammy'" - Agent Scully
Some projects are worthwhile, this smells of things like "ReactOS", i.e. something I would never use.
But fortunately, the Open Source community comprises a lot more people than just you.
I would suggest to the people on this project to go contribute to open source projects that would get people to even have an inclination of using a LINUX desktop.
And I would suggest *you* to go contribute to those projects if you want to see them succeed.
No problem is insoluble in all conceivable circumstances.
After it's compiled, you'll end up with a standalone client and a Firefox add-on. It shouldn't be hard to provide an add-on download. As far as I can see, it's Linux only, however.
Some projects are worthwhile, this smells of things like "ReactOS", i.e. something I would never use.
Ah, I see, so unless *you* would use it, it's a "waste of time".
Uhuh.
I would gladly run this instead of adobe flash if it ran on windows. Flash is the kind of thing I use lightly enough that I wouldn't mind reporting bugs and trying to help out that way.
Don't forget rpm/deb and the entire package management and distribution infrastructure.
It still surprises me that this came from the open source community AND that to this day no commercial OS has anything close.
Even cygwin doesn't use it in it's distribution, though I understand they have their reasons. But then what reason does projects like macports have to not use real package management?
You appear to have made a pretty much random list of technologies/programs - why?
My understanding is that Flash has an open specification, just like PDF. So it's not the format that's proprietary, only most of the software that uses the format. This was a problem with PDF too for a long time, but now there's tons of both Free and non-Free tools for both creating and viewing PDF files.
As long as the spec is open, there's no problem; anyone can create compatible software. The problem is usually that it takes a lot longer for other people (especially F/OSS writers) to do it than the company that created the spec and has a vested interest in making it popular.
Don't forget rpm/deb and the entire package management and distribution infrastructure.
It still surprises me that this came from the open source community AND that to this day no commercial OS has anything close.
It's simple: proprietary software places want to have control over everything. They don't want to be just another program on your desktop, they want to take it over with buttons everywhere on your desktop and start menu, their corporation name on your start menu (instead of just putting their program in a submenu called "Graphics programs"), etc. This is why proprietary software companies like Windows so much; it doesn't have any problems with them taking over a user's computer with their bloatware.
Package management systems take away control from software makers, and give it to users. Software makers don't like that.
One of the big problems in Linux is Flash support. For better or worse, Flash is needed to view a lot of websites, most notably Youtube. An open-source flash player promotes Linux on the desktop, by making it so that users can do all the same things in Linux that they currently do in Windows.
You're not going to get people to switch to Linux by making it impossible to do all the things they do in Windows. However, if you can make it even easier to do things in Linux that they currently do in Windows, or allow them to do the same things but also add capabilities that are locked out in Windows, they might just switch. For instance, a browser/flash player that lets them right-click and save a copy of a video (even though the website doesn't want to allow that), is something that many users would like. Or a browser that lets them block certain flash content (ads) while allowing others (videos); this is something you usually don't find from proprietary vendors like MS, because they're more interested in other corporations' interests than in users' interests.
It still surprises me that this came from the open source community AND that to this day no commercial OS has anything close.
That's because packaging systems exist primarily to address problems that - by and large - don't exist on "commercial OSes": cascading webs of slightly incompatible software versions (ie: "dependency hell") and ease of installation.
Ah, I see, so unless *you* would use it, it's a "waste of time".
ReactOS is a "waste of time" because it will never, ever be a genuinely viable alternative to running Windows.
You appear to have made a pretty much random list of technologies/programs - why?
Switch back to Slashdot's D1 system.
For now, it is something that just looks very promising for now.
You work in the Department of Redundancy Department, no?
It is dangerous to be right when the government is wrong.
Lightspark is using a Jit(just in time) compiler framework that as it stands right now is x86 only, there will go a long time before this project can help those that adobe doesnt support with their flash player. Those using Powerpc, arm are still without any working flash implementation, can only hope it will support those at a later stage, but I am rather pesemistic.
While all of these things are valuable (except Perl and Emacs), they are hardly new inventions. Bit of intellectual honesty please!
The best thing about Flash, from a programming perspective, is that you don't have to write in a bunch of special cases for different platforms like you do when writing HTML/CSS/JS for IE/Mozilla/WebKit.
If this project catches on, it better be perfect or I'll be one of many writing a sniffer to block my apps from running on it.
Also, the 'Flash is buggy' stuff needs to stop. It makes you sound ignorant. Flash is a runtime. People can write wonderfully stable, efficient code in ActionScript or they can take down the whole process, just like they can in Java, C++, Objective C, or whatever. If flash wan't around, advertisers would hire the same half-wits to write banner ads in Java or JavaScript and your CPU fan would spin just as fast. (This is why you need adblock.)
Flash is needed to view a lot of websites, most notably Youtube.
To heck with YouTube... My wife needs Flash to watch /Brothers and Sisters/ and my kids "need" it to play the games thy like.
"I don't know, therefore Aliens" Wafflebox1
Flash Player is a bloated slow pig of a program. Windows users need a Flash Player alternative just as much as Linux users do.
So when I hear about a release, I look for the Standalone EXE player, which unfortunately doesn't exist.
I also wonder how this compares to Gnash. I've tested out Gnash, and it crashed on several SWF files I played through the program on Windows. Gnash also obviously wasn't designed at all to run on Windows, since it is missing the essential feature of Drag-Drop files onto the standalone player window.
Well Windows apps did for a while have the DLL hell issue. Not sure if they still do.
But more important I think is the unified package distribution system. packagekit for gnome for example... I only need to get one notice from it that I have software updates. Whereas go to any presentation running a Windows laptop and you'll inevitably see at least one software update, though sometimes several from different apps during the presentation.
What I'm questioning is not the application providers, but the OS vendors lack of inclusion of a common platform for these issues.
Even Apple has this problem when you have lots of 3rd party apps.
Package management in the rpm sense also means to me easier control for the sysadmin to be able to install/uninstall software. The greatest feature is batch non-interactive installs/upgrades. You simply do not have this with commercial software.
>> For now, it is something that just looks very promising for now.
>
> You work in the Department of Redundancy Department, no?
IT occupational hazard.
A Pirate and a Puritan look the same on a balance sheet.
emacs: hardly the first text editor
Not even the first programmers editor, but as a derivative of TECO, it could be argued to be the oldest still-widely-used text editor (with vi as a possible alternative, depending on how you measure the "release date"). Oh, and it couldn't "steal Vi's crown" at anything, because both were in development at about the same time. As for making text editing "more difficult", the state of the art at that time was TECO, and both vi and emacs were big improvements over that.
But your real flaw is looking at emacs purely as a text editor. That's like looking at the Xerox Star and saying it wasn't innovative because computer graphics already existed. The big innovation of Emacs was to embed a full high-level-language interpreter. TECO was programmable, but the programs (much like vi programs) were unreadable line-noise. This enhanced ease-of-use for the macro writer led to an explosion of emacs add-ons and plug-ins that ended up making emacs more-or-less the prototype of the modern IDE.
All that said, I mostly agree with you about the rest of the list, but that doesn't mean the original poster is wrong--merely that his list was poorly chosen. In the early days, most software was what we now call "open source", so pretty much all of modern computing is built on a basis of open source. Better examples might include Curses, Sendmail, Netnews, and, arguably, even compilers and interpreters and such fundamental CS concepts as lists and trees.
How can open source DRM work? DRM relies on the source being closed to slow attempts to reverse-engineer it. Open-source DRM could be cracked in minutes.
"When information is power, privacy is freedom" - Jah-Wren Ryel
Heck, their biggest competitor in their fastest-growing market is basing their entire web experience on Apple's browser engine, so it doesn't seem like Apple is too worried about competition there.
Let's not forget webkit's roots - KHTML - which they took and improved upon. Let's not be too cheeky in calling it Apple's browser engine. The opensource licence requires them to use, improve and release the source so others can do the same. many unsung heroes/companies have been doing that for ages. The fact that Apple did it to the original KHTML source doesn't doesn't make the derived product their own. Someone correct me if I'm wrong.
Well Windows apps did for a while have the DLL hell issue. Not sure if they still do.
Er, yeah. That ceased being a real issue back around the 1997-98 timeframe.
But more important I think is the unified package distribution system. packagekit for gnome for example... I only need to get one notice from it that I have software updates. Whereas go to any presentation running a Windows laptop and you'll inevitably see at least one software update, though sometimes several from different apps during the presentation.
The practical difference here is small. Certainly (and clearly) not enough for software developers to funnel all their software distribution through Microsoft (assuming the legal system would even allow them to).
What I'm questioning is not the application providers, but the OS vendors lack of inclusion of a common platform for these issues.
The "platform" exists, it's called Windows Update.
Package management in the rpm sense also means to me easier control for the sysadmin to be able to install/uninstall software. The greatest feature is batch non-interactive installs/upgrades. You simply do not have this with commercial software.
You can absolutely do batch and non-interactive installs with MSI (and other third-party Windows installation systems). Active Directory and Group Policy can do software distribution for anything that's an MSI, and there are third-party solutions for apps without MSI installers.
Er, yeah. That ceased being a real issue back around the 1997-98 timeframe.
Really?
The "platform" exists, it's called Windows Update.
I see, you work at Microsoft.
You can absolutely do batch and non-interactive installs with MSI (and other third-party Windows installation systems). Active Directory and Group Policy can do software distribution for anything that's an MSI, and there are third-party solutions for apps without MSI installers.
Packaging system has nothing to do with non-interactive installation. The fact that interactive installers exist, just shows how idiotic the whole Windows software distribution model is.
Contrary to the popular belief, there indeed is no God.
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.
The practical difference here is small. Certainly (and clearly) not enough for software developers to funnel all their software distribution through Microsoft (assuming the legal system would even allow them to).
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.
Take Adobe's acrobat reader for example. All I had to do was install their .repo file and now I can get acrobat reader updates along with everything else in the system. Simpler for Adobe, cause they don't have to write an updater tool. And less hassle for the user cause I don't get a separate update notification for every single app I have installed.
There's nothing stopping Apple or Microsoft from implementing those. It's not /that/ difficult to do. A 3rd party could implement it of course but what's their motivation? It's not something that users would pay for and it's not something developers would necessarily pay for. It is something however that directly affects the "user experience" of the operating system. So it makes most sense for Apple and Microsoft to develop.
(re: DLL-hell)
Really?
As a common problem ? Absolutely.
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? As a user I don't particularly care as long as everything works. Macs do this and I actually find it a very comfortable solution to the problem. Don't want an app anymore, delete it. No "cruft" lying around (less than Windows anyway). And when I do install an app I don't have to think about what the heck it depends on.
But from a technology standpoint, I like the sharing that RPM makes possible. Though I do agree it's a bit of work to keep things in sync in the back-end. However, I must say I think the public Linux repos/distros have gotten things a lot cleaner in recent years.
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.
It may be unnecessary to have a packaging system with a non-interactive installation. But the important thing I think it does provide is a unified way of installing/upgrading/tracking across all software on the system (also non-interactively).
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.
It's been a while since I've used Debian, but the last time I did, I found it to be one of the most horribly interactive installation systems ever. To be fair, it's quite possible I chose the wrong installation option.
Redhat/Fedora-based systems however have never been interactive or required interactivity at the RPM level.
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.
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
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 /?'.
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.
I already addressed the motivation... several times.
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.
Agreed. OSS does need better care in that area. Though to be fair, I think there's far more dependency in OSS apps than commercial apps.
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).
I don't think you understand what people mean by "required interactivity". If you have the time, I suggest read the "Unix Philosophy". The author describes the issue in point as "Captive User Interfaces". These are interfaces that _require_ the user to sit there and baby sit an application. Yes, certainly typing "yum install..." requires an action by the user. However, a simple "yum -y install ..." will not _require_ further input from the user (unless of course there's some sort of failure). 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.
If an operation is going to take a while I want to make my choices up front, walk away and be able to come back and have it be done. That's the difference between interactivity and non-interactivity. Don't confuse this with action vs non-action.
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".
RPMs are inherently scriptable and I have this ability.
And, similarly, you can do batch and unattended installations on Windows.
Again... theoretically possible is one thing. Practical possibility is another. Can I take most of the software I'd want to install on Windows and do this? I know I certainly can for Linux.
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 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 /?'.
Again, you've ignored my statement. Of course some developer could do something wrong. That always happens. But that's not what I'm talking about. I'm talking about the usual case of (theoretically) competent developers following the documentation and design of the tools available to them. With RPMs it actually is entirely wrong to have an interactive RPM. While someone may be able to figure it out, there's certainly nothing in the documentation that tells you how to do that. And unless I am mistaken, it is _NOT_ wrong to create an MSI that requires interactivity. I seem to recall seeing in Microsoft's documentation them describing just how you can do it. And making it entirely a developer choice.
I'm not making a value judgement on Microsoft's case for MSIs. But I am pointing out the inherent difference in the system and what that means to me when I have to manage Microsoft systems.
As a common problem ? Absolutely.
Then Windows users have strange definition of a "problem". Every time one has to combine products that use incompatible versions of libraries, havoc ensues unless each products drags absolutely everything with itself. 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.
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.
"Automated" means that it handles dependencies, configuration and resolves conflicting settings.
Hate to break it to you, but 'apt-get install blah' or 'yum install blah' are interactive.
You obviously never used those tools. 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.
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.
Contrary to the popular belief, there indeed is no God.
It's not that it doesn't exist, it's more that they took the brute force approach to solving it. A lot of it is distributed on CD/DVD, just put everything on the disc. Even digital downloads now rather bloat their installers than deal with it, for example because you might not be online anymore when you try to install it or you're running it from a different PC. They just assume you have the bandwidth, if not get the boxed/burned version.
Live today, because you never know what tomorrow brings
Package management systems take away control from software makers, and give it to users.
In what way?
I just tried it, and the plugin is just grey for Mafia Wars and Farmville.
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.
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.
Something that happens quite rarely these days, which is my point.
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.
Can you give some examples of "trivial programs being distributed as 1G packages"
Each and every piece of software released after 2000.
, and/or common, contemporary software that has or causes DLL conflicts ?
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?
And.... Your point is ?
My point is, Windows does not have it. If it did, people would not have 8-core boxes running 10 VMWare instances, each running a single "server" product.
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
Then you are incompetent at your job.
, but I have some personal VMs with Ubuntu installed.
Oh wow.
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.
What the Hell are you arguing about? If you run a single, customized desktop installation, you would want update started manually and running interactively. If you run large number of boxes with predictable or identical configuration, you launch can have everything running with a cron job.
However if you are a competent sysadmin maintaining a large system, you run the update on a staging box, check if it is safe to run with default settings on production hosts, then run cssh to update everything at once (possibly after some other updates that you find necessary -- you may, for example, revert some customization, produce pre-merged configuration, etc). Anything less is unsafe -- you either delay security-related fixes or apply upgrades that may be incompatible with your setup. Anything more wastes time that can be used for something more productive.
Windows is so far behind this, "sysadmins" like you can't even imagine what responsible maintenance procedure looks like. "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.
And you seem completely incapable of actually understanding and contributing anything to the discussion except rhetoric and comical exaggeration.
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.
Contrary to the popular belief, there indeed is no God.
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.
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.
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.
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.
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.
The lessons in the book are still important to understand even in GUIs. The reason the author talks about "captive user interfaces" is because a GUI does not specifically "have" to be captive. And it's perfectly possible to write captive command line programs.
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.
If you move a whole bunch of files from one directory to another. As soon as there's any sort of issue (eg. a file is marked read-only or the file will overwrite an existing one), then the copy operation stops as it prompts the user. The concept of the "captive user interface" is still there. Well if I'm moving a large enough data set, that operation could take hours. I want to be able to leave it and come back and expect it to either (1) be done or (2)do as much as it can and have a checklist of things i should manually acknowledge. The typical "Yes, Yes All, No, No All" options are really dumb and not sufficient. (Ideally the UI should also allow me to treat this as an atomic operation, but that's another story).
As with Linux, it depends on the developer to package it properly.
You're ignoring my comments again. On Windows, a "setup.exe" is perfectly "proper". It's the defacto standard. On Fedora, sure it's "possible" but it's really not proper. It's not how most apps are installed.
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).
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.
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 will I be able to do it? It's completely not the same level of work or effort.
Cl
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,
Typical Microsoft -- solution to progress creating problem is to stop progress.
and standardised locations for third parties to install their own.
There are no "third parties" (unsupported second class citizens) in a properly designed system.
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.
Exaggeration apparently is completely lost on you. 20M for an application that has 100K of original code is not acceptable in any sanely developed system -- considering that all this code will end up separately loaded into memory.
Can you point to some examples of applications that do this ?
All of them. 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.
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.
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.
Struggling to see the relevance between automating software installation and this.
This means, you are stupid.
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).
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.
That using yum (or whatever) on Linux to install something is an interactive task.
Stop bringing up this stupid strawman, this is completely irrelevant to anything I am talking about. init can be run interactively -- does it matter, too?
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".
Windows does not have such thing, unless you are talking about compatibility between Microsoft products with other Microsoft products of the same generation.
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.
On Windows, if Microsoft-sanctioned update breaks anything, you have only two choices -- not to update, or break and replace everything. 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. With package manager sysadmin most of the time relies on updates and only occasionally has to perform configuration that he didn't initiate himself.
I can understand if you're caught up in the Linux mindset of "updating
Contrary to the popular belief, there indeed is no God.
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
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
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).
That's because Linux implemented a proper solution first, you dumbass. Everyone else is far behind.
Your definition of "third party" is broken.
No, it is not. For the user there should be no distinction between components provides by OS vendor and by everyone else.
Well that's the problem with foaming zealots. You can never be sure when they're serious.
Microsoft fanboys call everyone else zealots.
Name some.
HP printer drivers. A whole CD of dependencies. Surprisingly, HP maintains software with the same functionality for Linux -- in packaged form it has no built-in dependencies, and properly interacts with CUPS, SANE, KDE, GNOME and every frontend in existence.
Perhaps you missed the point of %PROGRAMFILES\Common Files, or just %SYSTEMROOT%\System[32] for poorly written applications.
I don't think, you recognize anything you are supposedly arguing with. To be honest, I can't even determine which part of things you actually know anything about because you bring up random facts about Windows installation mechanism, that have absolutely nothing to do with its deficiencies I am talking about. Are you just trying to get the last word by sprinkling some idiotic statements with insults? It doesn't work that way.
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.
This is exactly the problem -- same DLLs of slightly different versions end up in multiple locations. Then, when applications run, DLLs are simultaneously mapped into multiple location in memory. As context switches between processes, there is no performance gain from reusing library image in RAM that would happen otherwise, and that was the reason for creating dynamic libraries in the first place (CPU cache lines can persist across context switches, less page-out/page-in of read-only pages when memory is full, etc).
Or did you think, it's all harmless as long as you have enough memory?
That's because you're so desparate to go Windows-bashing you ignored the actual topic of discussion.
Let me refresh your memory:
Someone (not me) said:
Package management in the rpm sense also means to me easier control for the sysadmin to be able to install/uninstall software. The greatest feature is batch non-interactive installs/upgrades. You simply do not have this with commercial software.
You replied:
You can absolutely do batch and non-interactive installs with MSI (and other third-party Windows installation systems). Active Directory and Group Policy can do software distribution for anything that's an MSI, and there are third-party solutions for apps without MSI installers.
I replied:
Packaging system has nothing to do with non-interactive installation. The fact that interactive installers exist, just shows how idiotic the whole Windows software distribution model is.
So first and foremost , you are arguing with the wrong person.
Second, you have claimed:
Hate to break it to you, but 'apt-get install blah' or 'yum install blah' are interactive.
and then went on a long chain of rebuttals "explaining" that you can still call package managers "interactive" because they can run interactively by the user.
I guess, this was intended to somehow counter my position that existence of interactive installers is broken. This means, you are either too stupid or pretend to be too stupid to realize the obviou
Contrary to the popular belief, there indeed is no God.
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.
Again... the problem with multiple updates is that you get nagged simultaneously or one right after the other.
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.
No, that's the cornerstone of Unix command line tools. And is specifically NOT the core of any of my arguments. It's the cornerstone of the argument you think I'm arguing even though I've repeatedly said otherwise. I do highly suggest you read "The UNIX Philosophy" by Mike Gancarz.
But in real terms the difference between "double clicking"/"running rpm -ivh" and "clicking next a few more times" is not large.
For single program one-off situations, that may be the case. But again I don't think that was ever the argument.
Anyway, I've enjoyed debating with you, but I think this thread has lost it's focus.