Solaris Specific Problems with OSS Linking and Compilation
See also GCC on Solaris. A very good article
by Rich Teer
Build-Install OpenSolaris at OpenSolaris.org might be
helpful too:
This is the first of two articles in which we describe
how to acquire and build the source code for OpenSolaris.
The first article provides all the necessary background
information (terminology, where to get the tools, and so on)
and describes a basic compilation and installation, and the
second article will describe a more complicated compilation
and installation.
These articles describe how to build and install
OpenSolaris; they are not intended to be an "OpenSolaris
developers' guide", so information beyond that which is
required for building and installing OpenSolaris is not
included. This should not be seen as a problem, however,
because (as with most other large-scale open source
projects) the number of active OpenSolaris developers who
will need this knowledge is likely to be small compared to
the number of people who will want to build it for their own
edification.
These articles assume at least a passing familiarity with
building major software projects and some C programming. It
is unlikely that someone who is struggling to compile "Hello
World" would be trying to compile OpenSolaris! However, we
will otherwise assume no knowledge of building Solaris, and
describe all the necessary steps.
What could possibly be so difficult
about porting the Flash Player to Linux?I'm glad you asked.
The executive summary of what follows
would probably be: ensuring that a
single plugin binary functions on the
widest diversity of Linux/x86
distributions within reason. Read on for
the details.
First, we take the existing Flash
Player 7 Linux code along with the
current revision of the main Player
codebase, modify the Linux-specific
stuff as needed, and get the plugin to
compile in the first place. Then we
upgrade the Linux-specific parts to take
advantage of all the latest v8 and v9
features. Which APIs to use? That has
already been covered in copious detail
throughout previous posts.
While we have the plugin limping
along on our development machines, there
comes a point where we need to hand off
builds to our QA team for testing. This
is when we notice that the plugin works
great on our dev boxes, but hardly or
not at all on any other distributions.
Generally, the problem is libraries,
libraries, libraries. For example, the
player dynamically opens libasound.so to
dig out the ALSA audio functions. I
recently learned that the 'libasound.so'
symlink is only available on systems
with the right devel packages installed.
The proper file to open is
'libasound.so.2'. Hopefully. Repeat for
the rest of the dynamic library loads.
Things get more painful when the
plugin refuses to load. The first line
of debugging is the 'ldd' utility to see
if the plugin is finding all of the
libraries it wants on its new host
system. A major problem has been that
the plugin wants to find libstdc++.so.6.
Certain older Linux systems that we are
trying to support only have libstdc++.so.5.
This is not something we can plausibly
dynamically load at runtime as in the
case of libasound.so.2. This is why
I wanted to know how to statically link
libstdc++.so.6 with the main
binary-- larger distro range.
Many thanks to participants on the
Automake mailing list as well as my
contacts at Red Hat, we actually figured
out how to do this (it has to do with
the way to toolchain is built vs.
specific project built options).
Next problem: The plugin does not
load on stock Fedora Core 5 or 6
systems. All the libraries are present
and resolving this time. So what's going
on? These systems come "hardened" from
the start and they don't like binaries
that contain something called text
relocations ("textrels"). These textrels
are caused by 2 things in this case:
- statically linking
libstdc++.so.6
- manual assembly language
optimizations
For number 1, we embarked on a new
adventure to build a super-special
custom toolchain that builds
libstdc++.so.6 just right so that it can
be static linked with the plugin without
those nagging textrels. The ASM
optimization bits are giving us some
problems but
Tinic thinks he has a way to make
those functions play ball in order to
create a fast binary. So now the plugin
works on hardened Linux or SELinux or
whatever the right buzzword is; it works
with a Linux distro that uses the
security feature of randomizing a
program's base address.
I hope I've answered your question.
sunfreeware.com Comments
on gcc To use the gcc package from sunfreeware.com you
MUST install all of the SUNW deveoper packages that come on Sun's
Solaris CDs.
The software used to create gcc 3.4.2 (the steps are very similar for earlier
versions of gcc) was all from packages on sunfreeware.com. These include the
gcc-3.3.2, bison-1.875d, flex-2.5.31, texinfo-4.2, autoconf-2.59, make-3.80, and
automake-1.9 packages. It may also be important to install the libiconv-1.8
package to use some of the languages in gcc 3.4.2. See also a comment below
about the libgcc package.
- I downloaded the gcc-3.4.2.tar.gz source from the GNU site.
- I put the source in a directory with plenty of disk space.
- I then ran
gunzip gcc-3.4.2.tar.gz
tar xvf gcc-3.4.2.tar
(this creates a directory gcc-3.4.2)
cd gcc-3.4.2
mkdir objdir
cd objdir
../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld
--disable-nls
(except in the case of Solaris 2.5 on SPARC where I used
../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj --enable-languages=c,c++,objc
and left out the other language options - like the gnat ada.)
(I choose to use the as and ld that come with Solaris and are usually
in the /usr/ccs/bin directory. These files are only there if the
SUNW developer packages from the Solaris have been installed. I
have noticed problems with the NLS support and so I disable that. The
default installation directory is /usr/local.)
make bootstrap
make install
(this puts a lot of files in /usr/local subdirectories) and the gcc
and other executables in /usr/local/bin.
- I put /usr/local/bin and /usr/ccs/bin in my PATH environment.
There are differences between this version of gcc and previous 2.95.x versions
on Solaris systems. For details, go to
http://gcc.gnu.org/gcc-3.4/
In particular, gcc-3.4.2 offers support for the creation of 64-bit
executables when the source code permits it. Programs like top, lsof, ipfilter,
and others support, and may need, such compiles to work properly when running
the 64-bit versions of Solaris 7, 8, and 9 on SPARC platforms. In some cases,
simply using the -m64 flag for gcc during compiles (which may require either
editing the Makefiles to add -m64 to CFLAGS or just doing gcc -m64 on command
lines) works.
When you compile something with any of these compilers, the executable may
end up depending on one or more of the libraries in /usr/local/lib such as
libgcc_s.so. An end user may need these libraries, but not want the entire gcc
file set. I have provided a package called libgcc (right now this is for
gcc-3.3.x but a version for 3.4.x is being created) for each level of Solaris.
This contains all the files from /usr/local/lib generated by a gcc package
installation. An end user can install this or a subset. You can determine if one
of these libraries is needed by running ldd on an executable to see the library
dependencies.
I am happy to hear about better ways to create gcc or problems that may be
specific to my packages. Detailed problems with gcc can be asked in the
gnu.gcc.help newsgroup or related places.
Sun Studio 11 Sun Studio 11 software removes the price barrier and is available for Free!
Sun Studio 11 software is the latest
release of record-setting, optimizing compilers and tools for the C, C++
and Fortran developer. This release delivers the highest optimizations
and the best performance in the development of scalable 32-bit and
64-bit applications on Sun's newest hardware platforms including the
latest multi-core UltraSPARC, x64 and x86 platforms. And Sun Studio 11
software now removes the price barrier and is available for Free!
Sun Studio 11 software compilers allow developers to leverage the
latest in parallel programming and maximize throughput on multi-core
systems. In addition, even single-threaded applications gain as the
compilers can identify opportunities to parallelize execution and
automatically, without source-code changes, produce back-end code to
take advantage of this.
Build-Install OpenSolaris at OpenSolaris.org
by Rich Teer
This is the first of two articles in which we describe
how to acquire and build the source code for OpenSolaris.
The first article provides all the necessary background
information (terminology, where to get the tools, and so on)
and describes a basic compilation and installation, and the
second article will describe a more complicated compilation
and installation.
These articles describe how to build and install
OpenSolaris; they are not intended to be an "OpenSolaris
developers' guide", so information beyond that which is
required for building and installing OpenSolaris is not
included. This should not be seen as a problem, however,
because (as with most other large-scale open source
projects) the number of active OpenSolaris developers who
will need this knowledge is likely to be small compared to
the number of people who will want to build it for their own
edification.
These articles assume at least a passing familiarity with
building major software projects and some C programming. It
is unlikely that someone who is struggling to compile "Hello
World" would be trying to compile OpenSolaris! However, we
will otherwise assume no knowledge of building Solaris, and
describe all the necessary steps.
[Nov 1, 1999]
Porting
Open Source Software to SCO Dr. Ronald Joe Record Open Source Program
Architect
Much of the most useful and popular software
today is published and distributed in source form. The Apache web
server, KDE, the Mtools DOS utilities and the GNU C compiler are a few
examples of what is commonly referred to as Open Source software. This
article attempts to provide some insight, tips, techniques and
methodology for building Open Source software on and for
SCO OpenServer 5,
UnixWare 7 and in general.
The targets in CGC are configured by default with reasonable
guesses about the compile and link options that are required to compile the
code. However, the actual options required depend on your system configuration.
For instance, your default cc
compiler may not have been configured
to automatically find the X11 include files. You might, therefore, get an error
message the Xlib.h
cannot be found. You should find out where on
your system Xlib.h
is installed, use the `T edit-target' command to
add a compile option of the form -L
path_name where
path_name is the full path of the directory containing the file. `T
edit-Target' is on the shift-middle-button menu.
Recall that X started in about 1984 to be the platform independent
interface thingy. It is supposed to work everywhere - yes even on your
PC/AT, and even on your Mac (<- on the Mac X even works with DECnet transport
protocol [though tcp/ip is much more common]!). In raw source code form it is
available for free.
Here are some interesting excerpts from X Window System C Library and
Protocol Reference by Robert W. Scheifler, James Gettys, Ron Newman, Al
Mento, and Al Wojtas (© 1988 MIT and DEC ISBN 1-55558-012-2):
The X Window System(tm), or X, is a network-transparent window system...that
was designed at MIT.
...
It runs under ... several operating sytems.
...
Xlib is a C subroutine library that applications programs (clients) use to
interface with the window system by means of a stream connection.
Please note that while much X documentation refers to "X toolkits" (e.g.
Xt, Xm, Xmu, etc.) such toolkits are typically front
ends to C subroutine libraries. Hence those "toolkits" are typically
called from some other compiled language (which is usually C or C++). Perl/Tk
(and Tcl/Tk for that matter) is (are) a bit more than mere "toolkits"
in that they allow access to a good deal of Xlib functionality via the other
languages (Perl and Tcl respectively). [BTW there also is a Lisp version of Xlib
that you need not concern yourself with in an attempt to port Perl/Tk.]
Take a look at "Getting
X" from the folks who write and maintain it.
They (the X consortium) also have a page on Writing
Portable X Code which is a must read document. You should probably
check out the Xlib man
pages too.
Perl/Tk can be built on Unix platforms under X11
R5, R6,
R6.1, and R6.3.
I do not know if it has been built with prior releases. The X Consortium plans
on calls the latest release of X "Broadway"
or X11R6.3. See also an X newsgroup for more
information.
The critical Xlib files include: the sharable image libX11.a
(or libX11.so, or LIBX11.EXE, or whatever
name.extension your system uses for this type of file), and the header file Xlib.h
(as in #include <Xlib.h>).
Softpanorama Recommended
Compiling Sendmail
[PDF]
Building and Deploying
OpenSSH for the Solaris™ Operating Environment
Everything Solaris -
Useful Open Source Tools
Sun's Linker and Libraries Guide
Binary Formats
Society
Groupthink :
Two Party System
as Polyarchy :
Corruption of Regulators :
Bureaucracies :
Understanding Micromanagers
and Control Freaks : Toxic Managers :
Harvard Mafia :
Diplomatic Communication
: Surviving a Bad Performance
Review : Insufficient Retirement Funds as
Immanent Problem of Neoliberal Regime : PseudoScience :
Who Rules America :
Neoliberalism
: The Iron
Law of Oligarchy :
Libertarian Philosophy
Quotes
War and Peace
: Skeptical
Finance : John
Kenneth Galbraith :Talleyrand :
Oscar Wilde :
Otto Von Bismarck :
Keynes :
George Carlin :
Skeptics :
Propaganda : SE
quotes : Language Design and Programming Quotes :
Random IT-related quotes :
Somerset Maugham :
Marcus Aurelius :
Kurt Vonnegut :
Eric Hoffer :
Winston Churchill :
Napoleon Bonaparte :
Ambrose Bierce :
Bernard Shaw :
Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient
markets hypothesis :
Political Skeptic Bulletin, 2013 :
Unemployment Bulletin, 2010 :
Vol 23, No.10
(October, 2011) An observation about corporate security departments :
Slightly Skeptical Euromaydan Chronicles, June 2014 :
Greenspan legacy bulletin, 2008 :
Vol 25, No.10 (October, 2013) Cryptolocker Trojan
(Win32/Crilock.A) :
Vol 25, No.08 (August, 2013) Cloud providers
as intelligence collection hubs :
Financial Humor Bulletin, 2010 :
Inequality Bulletin, 2009 :
Financial Humor Bulletin, 2008 :
Copyleft Problems
Bulletin, 2004 :
Financial Humor Bulletin, 2011 :
Energy Bulletin, 2010 :
Malware Protection Bulletin, 2010 : Vol 26,
No.1 (January, 2013) Object-Oriented Cult :
Political Skeptic Bulletin, 2011 :
Vol 23, No.11 (November, 2011) Softpanorama classification
of sysadmin horror stories : Vol 25, No.05
(May, 2013) Corporate bullshit as a communication method :
Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000):
the triumph of the US computer engineering :
Donald Knuth : TAoCP
and its Influence of Computer Science : Richard Stallman
: Linus Torvalds :
Larry Wall :
John K. Ousterhout :
CTSS : Multix OS Unix
History : Unix shell history :
VI editor :
History of pipes concept :
Solaris : MS DOS
: Programming Languages History :
PL/1 : Simula 67 :
C :
History of GCC development :
Scripting Languages :
Perl history :
OS History : Mail :
DNS : SSH
: CPU Instruction Sets :
SPARC systems 1987-2006 :
Norton Commander :
Norton Utilities :
Norton Ghost :
Frontpage history :
Malware Defense History :
GNU Screen :
OSS early history
Classic books:
The Peter
Principle : Parkinson
Law : 1984 :
The Mythical Man-Month :
How to Solve It by George Polya :
The Art of Computer Programming :
The Elements of Programming Style :
The Unix Hater’s Handbook :
The Jargon file :
The True Believer :
Programming Pearls :
The Good Soldier Svejk :
The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society :
Ten Commandments
of the IT Slackers Society : Computer Humor Collection
: BSD Logo Story :
The Cuckoo's Egg :
IT Slang : C++ Humor
: ARE YOU A BBS ADDICT? :
The Perl Purity Test :
Object oriented programmers of all nations
: Financial Humor :
Financial Humor Bulletin,
2008 : Financial
Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related
Humor : Programming Language Humor :
Goldman Sachs related humor :
Greenspan humor : C Humor :
Scripting Humor :
Real Programmers Humor :
Web Humor : GPL-related Humor
: OFM Humor :
Politically Incorrect Humor :
IDS Humor :
"Linux Sucks" Humor : Russian
Musical Humor : Best Russian Programmer
Humor : Microsoft plans to buy Catholic Church
: Richard Stallman Related Humor :
Admin Humor : Perl-related
Humor : Linus Torvalds Related
humor : PseudoScience Related Humor :
Networking Humor :
Shell Humor :
Financial Humor Bulletin,
2011 : Financial
Humor Bulletin, 2012 :
Financial Humor Bulletin,
2013 : Java Humor : Software
Engineering Humor : Sun Solaris Related Humor :
Education Humor : IBM
Humor : Assembler-related Humor :
VIM Humor : Computer
Viruses Humor : Bright tomorrow is rescheduled
to a day after tomorrow : Classic Computer
Humor
The Last but not Least Technology is dominated by
two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt.
Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org
was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP)
without any remuneration. This document is an industrial compilation designed and created exclusively
for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong
to respective owners. Quotes are made for educational purposes only
in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or
referenced source) and are
not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness
of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be
tracked by Google please disable Javascript for this site. This site is perfectly usable without
Javascript.
Last modified:
March 12, 2019
...
I enjoy reading this blog so I can follow the progress. Thanks for that, and speedy progress!
Posted by: ArmEagle | September 25, 2006 03:28 PM How about the short answer:
Because we *choose* to make it difficult...
Chris
Posted by: Chris M | September 25, 2006 03:43 PM Why there is a need for "ensuring that a single plugin binary functions on the widest diversity of Linux/x86 distributions"? Why can't you make several packages, like Opera does for example?
Posted by: digital | September 25, 2006 04:46 PM why not release, find bugs, patch... release, find security flaws, patch... repeat ad nauseum. Seems to work for Microsoft.
Posted by: Todd | September 25, 2006 05:30 PM If you have to builtin static libstdc++.so.6 into flash player, please provide alternative 'lightweight' version without this blob.
It would be nice to see 'lightweight' alternative flash player version without any hardcoded libraries.
This is very important due to security reasons. I can install patch or updated library as soon as it is released. Sometimes in less than 24 hours to keep system protected.
If binary flash will have all libraries builtin, it is wise to not install it, or just remove it when any security/stability bug will appear in one of libraries sticking inside huge flash plugin. Static libraries make programs very big.
I understand that some older systems do not have required libraries and Adobe is trying to reach compability with as much distros as possible.
Flash plugin for windows is not required to be compatible with MS-DOS 1.0 or Windows 3.11 so very old Linuxes should be avoided too.
Linux is not Windows so security is really very important.
For example take a look at skype for Linux. They provide dynamic and static packages.
Posted by: Zbigniew L. | September 25, 2006 05:32 PM I'm glad that there is some work going into the development of the flash plugin for linux. I find it quite unfortunate that it is so far behind the Windows and Mac versions.
Perhaps the bigger problem lies with the content providers. Why do they require only the newest flash player? Google Video and YouTube work fine with the 7 player. Why can't others follow along? Frustrating...
Posted by: Victor | September 25, 2006 05:33 PM Adobe makes it hard for themselves because they stil don't know what linux actually is.
Posted by: matt w | September 25, 2006 07:22 PM Obviously, what would speed this up quite a bit would be open sourcing the effort, instead of relying on one guy. What jerks you are, though: you pervade the market with this hidden-source plugin, then fall out of sync with the Linux community, and still expect to have friendly relationships with the FOSS world? Why should anyone care about your stupid problems or your lack of ideas about how to do something that hundreds of other projects do (build packages that can install on various Linux distros)? Flash is a cancer on the web -- on the world, for that matter. It is antithetical to everything Linux is about. All Linux users should avoid Flash like the plague, and support FOSS alternatives. Screw you and your lame, late, talentless effort.
By the way, this isn't an "off topic" "request" for you to open source the effort. This is an angry rant about the entire existence of your project. You are a jerk for participating, and for expecting any goodwill from the Linux community. I hope you get fired.
Posted by: obviously | September 25, 2006 08:09 PM Cool. Thanks for keeping us updated on your progress.
Posted by: Huey Van Iadore | September 26, 2006 12:45 AM Mike, I think digital is right (and Ralf Wildenhues also pointed this out on the automake list) - why do you want a 'catch-all' binary? Just provide one for libstdc++.so.5 and one for libstdc++.so.6. And one statically linked, but that may cause problems - Ralf pointed them out.
I've had similar problems on HP-UX, linking libraries compiled with standard C++ mode (-AA) with others compiled with classic C++ (-AP); short answer is: it doesn't work, and you don't want to deal with the unpredictable problems this kind of setup can cause.
Also, as far as I remember, Adobe offers a custom version of the player for every Windows version you choose, so this wouldn't be much of a pain.
Posted by: Stefan | September 26, 2006 12:47 AM Thank you for write progress here. I think this is the right way better thant make several packages for each distro.
Posted by: nauj27 | September 26, 2006 12:56 AM Just hurry up! Nothing takes this long. The bottom line is that Flash has no intentions of releasing a linux version.
Posted by: Rich | September 26, 2006 03:20 AM Chris M: no. Because Linux people make every effort possible to ensure absolute incompatibility between different distros, even between single distribution+version of the distribution, but different level of freshness.
Posted by: Yarick | September 26, 2006 03:28 AM This is starting to look more and more like vapourware. This is starting to look a little like another "Duke Nukem Forever"? If you have not heard about it then see here under "Development timeline" (http://en.wikipedia.org/wiki/Duke_nukem_forever). Just when they think they are ready to release they find out another list of reasons not to release. There is no perfect software developed by Adobe or anyone else in the commercial software industry. People can only strive continually to make perfect software. If you do not release anything in the meantime you have vapourware.
I heard no one make any claims to even try to synchronise releases of the future versions of flash. Who is to say that by the time flash 9 for Linux comes out (if ever) it will not be made obsolete by flash v25? This seems to be somehow wrong that flash has a built-in windows endorsement all of a sudden.
I only hope a free (as in freedom) alternative or a complete replacement to the flash paradigm catches on soon. It may happen sooner than a current version of the adobe flash for Linux. Until then I will use: "Wine" + "Firefox windows" + "flash 9 for windows". I know it is a pain but you can actually share saved information such as bookmarks using soft links between the windows and Linux versions of Firefox. It is better than chasing the flash 9 for Linux mirage.
I am tired of seeing people beg for a almost current version of flash for Linux instead of understanding what is happening. Please do not beg, find other legal ways to make an effective protest.
Posted by: arrgh.. | September 26, 2006 05:36 AM The thing you notice by reading this blog is that you are always bussy with very simpel problems.
A libstdc++6 dependency is perfectly acceptable for such a modern plugin. The more conservative users will stick with Flash 6 for a long time anyway.
PS
Show some respect towards hardening.
Posted by: Pascal S. de Kloe | September 26, 2006 05:47 AM Opera is not a one-click install from withing the browser. Plus, it's a lot of work ;)
Posted by: Vincent | September 26, 2006 05:53 AM as the above person says, just do it like opera!
Posted by: SYNERGiST | September 26, 2006 06:32 AM digital, let them cope with one as a beginning ;)
Posted by: hmm | September 26, 2006 07:14 AM I agree with some of what "obviously" said.
Open sourcing or simply releasing betas would speed up your effort significantly. The past 6 months I have worked with a few open source projects and the majority of bugs filled in these projects are from the community, not from the developers.
There are a ton of people interested in Flash on Linux. Some of them are hostile and probably won't do anything to help you but a great many more *will*. If betas are released people will file bugs. If the source is released people will write patches.
Also, I suggest reading Eric Raymond's "The Cathedral and the Bazaar" (not the book, the essay). It will reinforce what I've just said.
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/cathedral-bazaar.ps
Posted by: Ben | September 26, 2006 07:40 AM Have you recently taken a look at the license terms for libstdc++? Last time I looked, it was GPL. If you statically compile it in, you just forced the source release for the Flash Player, too. If you only dynamically link it in, since it's considered part of the system platform, you only need to provide enough glue to enable "recompile" (or more accurately, relinking) against the latest, installed libstdc++ copy.
Ie, what you REALLY want to do is to distribute in a form which can be linked to platform libraries at installation time. GPL zealots will thank you though if you continue with the static linking, but your employer might not...
Posted by: Osma Ahvenlampi | September 26, 2006 07:48 AM Opera provides separate packages for different distros (and different versions of those) and a generic rpm/deb and it all works. I can't really understand why you're going over such big hoops other than trying to prove it's almost possible ;)
Posted by: baczek | September 26, 2006 08:14 AM Obviously:
Some people actually need to feed their families. Don't judge someone for working for a company that does not open their software.
As for flash being a cancer on the web: It just proves how good of a product flash is. You can have your opinion and never go to any sites that use flash. No one is stopping you from banning those sites for yourself.
Posted by: Ryan | September 26, 2006 09:08 AM Just release one for libstdc++ 5 and one for 6 instead of statically linking - statically linking is a practice GREATLY frowned upon in the unix world and WILL cause problems, especially with critical security updates to the package you're statically linking - becuase your module is vulnerable to the security exploit that would have otherwise already been fixed with dynamic linking when the person updated their system.
You provide different binaries for each different version of windows, I'm sure you can have atleast two versions of linux.
Or better yet, open source the player - there is no reason for the player to not be open source. Allowing people to write the player for their own systems gives your format wider reach with lower effort on your part, and then you can concentrate your effort on your authoring suite, thus allowing you to raise the quality of your authoring suite without additional costs.
Posted by: Derek Meek | September 26, 2006 09:20 AM Some of these pro-FOSS comments are mind-numbingly dumb. It seems like a fusion between Slashdot+Digg trollers.
Posted by: TiCL | September 26, 2006 09:50 AM If it gets too difficult supporting all major linux distros with a single binary, you could always release multiple binaries.
Posted by: David Finch | September 26, 2006 11:28 AM I'm so sick of the flash vaporware for Linux.
Plenty of other companies release software for Linux, it shouldn't take three years. Yes there are challenges, solve them and get moving or open source.
Hopefully developers will avoid flash like the plague. Especially considering their Linux support history and Linux's growing market share.
I am glad that it is being worked on, but the half hearted effort is disappointing. Sadly you are going to continue to get a lot of crap for your companies poor decisions.
Posted by: Chris | September 26, 2006 11:34 AM An Open Source Flash player is a BAD IDEA. Flash's main strength is that it works IDENTICALLY no matter where you run it. I don't want to have to start developing Flash for multiple versions of the Flash player. It's bad enough with HTML/CSS, and that's child's play compared to Flash.
Posted by: Matt Rix | September 26, 2006 11:38 AM Statically linking the libc++ is not a good idea.
If you statically link to libc++, you need to honor the LGPL requirements : that is, you must offer to provide the binary of flash player for Linux as a set of object (.o) files so that people can recompile them (See the LGPL at http://www.gnu.org/licenses/lgpl.html). The idea behind is that while the LGPL can be used in a proprietary software, end-users must have the ability to change this part of the program to suit their needs.
Posted by: johnelgato | September 26, 2006 11:51 AM 1. how long have you been working on this project?
2. how many developers are working on flash for linux vs how many worked on flash for windows?
3. Flash for linux is last app needed by my grandmother, to free herself from the microsoftopoly. How much is money is your employer getting from microsoft for dragging its feet with flash for linux?
4. Do you really feel youve been given the resources you need to make this project succeed?
5. If you do succeed, do you think flash v10 will make youre work a waste of time and effort?
6. What happened to the original promise of simultanious releases on windows/linux/mac?
7. Have you developed on linux before?
8. Do you understand the GPL?
9. Do you have a resume? Can we look it over to decide if this project is just lip service from adobe?
10. Does all this harsh critisism get to you??? Or do you just ignore community feedback?
Posted by: WrongWay | September 26, 2006 12:07 PM Thanks for the information, it's very interesting to see how you are thinking, even though I also would like to see a dynamically linked version of the player in the absense of an open source one. And even more would like to lay my hands on a beta version so I could stop having to restart my browser after every flash film... please.
Too bad about all the trolls you get - just know that it's most likely very young kids thinking it's the cool way to behave. In general, not even the hardcore die-hard free software proponents are like that, they just stay away from the program instead. Every "cause" has its (often juvenile) loudmouthed idiots.
Posted by: Stoffe | September 26, 2006 12:13 PM Anyone who can't bother to upgrade their libc is not a customer.
Posted by: Anonymous | September 26, 2006 12:24 PM libstdc++6 is licensed under GPL v2 with the special linking exception. Binaries may link or otherwise use libstdc++6 without that act causing the resulting executable to be covered by the GPL. Meaning, proprietary software (or any software under any license) is allowed to link against libstdc++6 without restriction (i.e., read the license included with libstdc++6 and you'll see). This sort of special exception is used by quite a few libraries to make the library itself fall under GPL but not taint non-GPL code linking to it.
Posted by: webaugur | September 26, 2006 12:30 PM I don't get the reason for libstdc++.so.5 because I don't know which distro you try to support with it. Don't forget, that Flash is a desktop tool and I've never seen a desktop older than the latest debian version. So please think about it again and don't start with statical linked libs, because it's a real high security risk.
Posted by: netzkeks | September 26, 2006 12:42 PM For all the trolls who talk about the GPL and even ask if they "understand" how it works; I'll just say that the STDLIB++ *is* LGPL-like *OBVIOUSLY* (more specifically, GPL+ no-linking restriction; just like, heh, all programming GNU stdlibs? what-a-surprise) so they *CAN* link with it without any license requirements. They can't derivate from it without having the derivate code as GPL+no-linking-restriction (ie, keeping the same license), but hey, they don't want to afaik.
Cf (in any and all source files of the stdlib++ package):
// As a special exception, you may use this file as part of a free software
// library without restriction. Specifically, if other files instantiate
// templates or use macros or inline functions from this file, or you compile
// this file and link it with other files to produce an executable, this
// file does not by itself cause the resulting executable to be covered by
// the GNU General Public License. This exception does not however
// invalidate any other reasons why the executable file might be covered by
// the GNU General Public License.
Linking "statically" or "dynamically" doesn't change anything. So it's perfectly legal (it would be better if Flash was F/OSS, but we know it's not going to happen anytime soon).
Please get a clue before posting. Thanks.
Now, for people asking why it takes so long: surprise, getting software out sometimes takes time; stop complaining, and if you don't care for flash, don't whine :).
They said early 2007, it may be before, just wait and hope YouTube doesn't switch to Flash 8/9 before ;).
Simon
Posted by: Simon C. | September 26, 2006 12:44 PM Ah, I hadn't seen that webaugur said it; heh I should read all comments but I couldn't restrain myself with that much FUD ;)
Oh, and please, yep, provide versions for different libraries with no stdlib++ within the package. I want Flash to have the smallest memory footprint possible. Please, pretty please? :)
(You can still make the "all-in-one" package more visible on the website, just provide the lightest package possible for users and distributions who know what they're doing. Thanks).
Posted by: Simon C. | September 26, 2006 12:49 PM @obvious, wrongway, Chris M. et al:
Please do not flame Mike or Tinic - while I think all these angry posts have their legitimation, you are "beating" the wrong persons.
Better address that towards Emmy Huang, the Flash product manager. http://weblogs.macromedia.com/emmy/
I am also beginning to wonder what prevents Adobe from releasing a Beta. The whole thing gets more and more smelly. As if the Acrobat Reader ever was perfect when released to the public....
However, since obviously the counsels and not the sales persons dominate Adobe (just think about these ridiculous and (in German law) void restrictions for the Flash specs), I doubt that even Emmy would have the power to change things (if he wanted to do so, what I seriously doubt).
Maybe we should start developing a Gnash like open player in a legislation where the legal restrictions for the Flash specs are void? I mean such as mplayer, libdvdcss etc.?
Posted by: amd-linux | September 26, 2006 12:54 PM In response to some previous comments I just have to point out the following:
According to the documentation for libstdc++, it is GPL with a special runtime exception clause allowing for binaries to use it without having to be released as GPL themselves. This means its perfectly ok for it to be statically linked with a program that isn't GPL.
Posted by: anonymous | September 26, 2006 12:55 PM Well amoungst all that has been mentioned such as static linking a GPL library & releasing two versions so .5 & .6 can dynamically link are quite valid.
I think it's time to drop libstdc++5 anyway as it is very legacy nowadays.
I remember the stink when some distro kernels went to 4k stacks and everyones nvidia driver broke as a result.
Sometimes you need to force progress.
Thos who have to have libstdc++5 can stick with an older version of flash.
I think the underlying matter is that these flash developers are under-resourced and they dont want to admit it. Adobe probably doesn't see the value in giving themthe resources to make this product happen in a reasonable time frame.
Posted by: Gavindi | September 26, 2006 12:56 PM Another thing about libstdc++5/6 support. If there is something in v6 that you require for the plugin then you could always work more closely with the open source community. It may be possible to get libstdc++6 packages built for Linux distros going quite a ways back if needed. We're not talking about hundreds of library files that would have to be installed here.
Then you could release your plugin with a libstdc++6 dependancy and say go to this-or-that URL if the player complains that libstdc++6 is not found on your system.
Posted by: k12linux | September 26, 2006 01:23 PM As a Flash Developer and a long time Linux user. I really don't like the way people are bashing Adobe. In fact just like most Linux users I don't mind using the close source NVIDIA drivers. Why? Because I just want my system to work and I don't plan on working on the Display Drivers anytime soon. So the same thing goes for the Adobe Flash Player. In fact if there was a better Flash plug-in out there I would have been using that one.
I'm looking forward to the Flash 9 Player for Linux. Flash has a large user base making it easy to reach the users we want at the current company I'm working for. On top of that Flash is not just locked to one platform so everything I develop will work under Windows, MacOS X, and sooner or later Linux.
Posted by: Erick Feiling | September 26, 2006 01:24 PM
That might solve some of your versioning worries now, but
they're just going to lurk in a dark corner like the child locked in a cupboard,and come back to bite you really hard down the line.
And that's assuming that the plugin only exports the symbols it needs to, so
you don't end up with the program binding against the private version of
libstdc++. That'll cause many problems, as you end up calling functions in the plugin version of libstdc++ with data formatted for the system version, which may well be imcompatiable, and hence the computer will end up talking the language of Chaucer to a modern englishman. Kinda.
Do you mean have ld.so link it in, or load it with dlopen? If the latter, then
how are you going to handle loading a different major version of the library to the one you linked against? If you're going to punt, then why not just use ld.so and weak references?
If you're going to do this, then the version of libstdc++ you link the plugin against should be compiled with -fPIC (to generate position independant code).
Posted by: Ceri Storey | September 26, 2006 02:02 PM If you statically link anything in the GNU+Linux system into Flash, myself and hundreds of others will sue the shit out of you a thousand times over.
Posted by: Jon | September 26, 2006 02:04 PM I'm sure Adobe does _not_ own all the rights to every bit of code in flash, namely certain video codecs, meaning opening the source is a definate NO. so why do people keep bringing this up?
also, they have to ensure that as many people as possible can install and use the plugin, because if it only works on 1 or 2 distros, then it would be a huge waste of time.
Opera DOES NOT offer different binaries per distro, it's the same binary... just packaged differently... deb's for debian and ubuntu, rpm's for redhat and suse, and so on...
please cut the developers some slack, he posted a blog so people won't be completely in the dark about the status of Flash9 for linux... appearently he cares
Posted by: freddfx | September 26, 2006 02:16 PM I think plenty of Linux users have given up caring whether or not Adobe releases Flash 9.
The whole episode has been a marketing nightmare if you ask me. You've alienated a good portion of the Linux crowd by saying our platform is too difficult to deal with and you folks don't really know when the hell you plan on releasing it to begin with.
I for one will not beg a company to let us beta test their software - not one that has treated us in such a shitty manner.
So how's this, take your time in releasing Flash for Linux. Perhaps we'll give a shit awhile after the release. Maybe just maybe I'll consider using it again. As of right now I'm disabling Flash on my home desktop, my ibook and my office computer.
Posted by: macewan | September 26, 2006 02:32 PM TiCL: that's why we've excluded you from the community. Troll elsewhere freak.
AMD-linux: it's hard to do that if you don't know the internals of the program. It's only a matter of time though before the Gnash hackers surpass Flash in functionality/speed. And thanks for mentioning that manager, it appears someone is going to have a full inbox.
Posted by: 1c3d0g | September 26, 2006 02:37 PM Ditto the questions about whether it is legal to do anything with libstdc++.
Erick: Let's suppose that you access the penguin.swf webpage using IE. For completely arbitrary reasons, the page is translated into Chinese. You get a message that says, "Use Linux to access this page." Adobe has declared war on Linux by choosing to make the internet inaccessible. For some reason they like to support Microsoft's monopoly and when you limit people's choices, that gets them upset.
Posted by: lmf | September 26, 2006 02:48 PM isn't the libasound.so -> libasound.so.2 symlink created by ldconfig? while it might technically be a problem of the distro if it is missing, would it be possible to include a run of ldconfig in the installer? (although this wouldn't work for a user install, if you provide that option).
i'm surprised you don't just release a beta (call it an alpha, if that makes you feel better) for a nice modern stable distro like ubuntu and learn from the hackers that try and get it working on other distros. they will perhaps have to make strange ugly maneuvers, but you can do more graceful equivalents from the other side of the compiler.
stand on the shoulders of giants, or at the least, some backroom hackers.
by setting yourselves the goal of supporting a wide range of distros with your closed project, you are taking on the task of maintainer for all of those distros. most developers don't even take care of this themselves, they leave it to a downstream maintainer.
Posted by: pix | September 26, 2006 03:42 PM Wow there are a lot of mind numbingly retarded, ungrateful, narrow minded biggots replying on here. Sheesh guys, if someone is doing a quality job for you and you're not paying for it you have no right to complain.
Thanks Adobe for considering such an insignificant market share. Thanks Mike Melanson for ignoring all of the ungrateful jerks out there.
Posted by: Jonathan | September 26, 2006 04:18 PM Hi, I hate to sound negative, but it basically sounds to me like you haven't got the foggiest idea how to build software for Linux.
There have been lots of companies in the past that have tried to take their crusty in-house build systems and make portable Linux binaries. Invariably they find that their build systems are inferior to the standard automake system. And in the end, they will normally conclude that the best way to distribute the software is as a separate package for each major distribution or as a shell script that rebuilds/relinks the software on the user's machine.
Posted by: jwb | September 26, 2006 04:26 PM @lmf : I guess the equation is quite simple. What is the marketshare of linux in home computers ? What is the standard profile of a linux user ? Is it the main target for adobe/macromedia ? Simple ROI equation.
Besides it has nothing to do with MS monopoly, Flash Player has always worked well on Mac OS for obvious reasons, and is not available on linux for obvious reasons as well.
Posted by: proteus | September 26, 2006 04:35 PM @jon
Well, aren't you a total asshole. It has repeatedly been said on this thread that statically linking libstdc++ is perfectly legal but you choose to ignore that just to spread more FUD.
Where's the heavier comment moderation we called for a while ago?
Posted by: Bloody | September 26, 2006 05:07 PM Jon, you aren't a lawyer, so you won't be suing Adobe for anything.
Go back to Slashdot already with the rest of the anti-Flash trolls.
Adobe may be slow with the Linux Flash player, but so was Macromedia with Flash 7. Looking forward to the public beta...
Posted by: Rob H. | September 26, 2006 05:09 PM You could release not the source, but the compiled .o object files, with a script to link them to the correct libraries for the user's system, and leave system-specific code. Many proprietary kernel modules do this, and have uncompiled 'wrapper' code so it can be compiled for the specific kernel, which is linked to the meat, already compiled, proprietary .o file.
Posted by: Apage43 | September 26, 2006 05:25 PM Adobe declared war on Linux??? How does one even come so such a conclusion?
Posted by: freddfx | September 26, 2006 05:46 PM lets face it adobe are corp. assholes that prefer other corp. assholes like apple and microsoft
Posted by: ahron | September 26, 2006 06:08 PM I think microsoft is behind all this ...
Posted by: El Loco | September 26, 2006 06:41 PM Well, I've found it quite nice that I don't have to deal with Flash 9 Ads... On the other hand, I would like to play some Flash games against my friends...
*hopefully* this will come out soon, cuz I wanna play Dofus without sound lag. (speaking of Dofus, you guys need to fix the bugs that make Flash 9 incompatible with it before you release Flash 9 for linux XD (so much for perfect compatibility :P))
Until then, I hope that you are able to release it soon. (and for the love of pearl, please hurry on this, I'd love to see some of the e-cards my friends send me)
Posted by: rummik | September 26, 2006 07:35 PM It would be sad if the developers got discouraged because of some of the stuff people said and just decided to drop the linux flash player. Please be kind, and no more FUD.
I'm just glad that the developers are trying so hard b/c i know from a practical standpoint adobe has nothing to lose if it dropped it's linux flash player right now. (not to say that in the future they won't need one... when linux rules the world...)
Posted by: Abbas Khan | September 26, 2006 08:28 PM I would not bash the developers attempting get flash working under Linux. I am sure they are doing their best. There may well be others who can do more and better in the community, but these guys (both of them?) working on flash for Linux are all we have for the moment on our side. I doubt very much that they have a say in when to release flash for Linux, how much resources to dedicate towards the completion of flash for Linux any sooner or even for that matter, making flash open source. What they say on this blog may well be restricted to what they are allowed to say. Have you considered that some of them might even hold the same opinion as the angry Linux users here?
If you want to be juvenile and vent at someone then find the pencil pushers in the upper management who have a say in these matters and fill up their inboxes. I only hope the management read these comments and take them to heart. Although, I am sure the pencil pushers there in adobe get paid big bucks whether there is a Linux version of flash 9 or not and they do not give a flying rats ass about the Linux or its users.
Posted by: Arrgh.. | September 26, 2006 09:51 PM And Linux users wonder why the world hates them. -_-
Posted by: Phy | September 26, 2006 10:46 PM Hi Mike, just one idea that you might already have had:
Instead of making the plugin work with many different distros in many different config, couldn't you just build one good enough build that compiles in your Gentoo stable arch machines, and then tell the distros how they should work with the plugin?
It's easier to give everyone the prerequisites to make your program work with then than you try to please greeks and trojans at the same time.
Posted by: Bruno | September 26, 2006 11:29 PM "Just release one for libstdc++ 5 and one for 6..."
You ought to do that. It makes sense, it's easy and it covers everyone. Yes, idiots may not understand which one to download, but you could just link the right version to the right distro; like 'fedora core 5 download here' would link to the right libstdc++
Surely that makes sense!
Posted by: John | September 27, 2006 02:03 AM Mmm.. All the "open source Flash, let community file bugs" crowds - please, do us a favor, join Gnash devteam. Can't do this ? No skills, no time, no money ? Then shut the fsck up, you just don't know what are you talking about.
Mike and everyone @ adobe linux team - just do it right, don't listen to crybabies - their cries are nothing more than kid's disappointment his flashy (sic :-) new toy isn't right here right now. Community of grownups patiently waits .
Posted by: Yarick | September 27, 2006 02:42 AM As this fiasco goes on and on, and the excuses get lamer and lamer, I realize that Adobe has hired a complete linux programming newbie to port one of their most popular and pieces of software.
Sounds to me like they want to see this fail miserably. Where did they get this guy? Can't even load a linked library? Doesn't use automake? These are simple problems to pretty much any seasoned linux programmer.
Posted by: Anonymous | September 27, 2006 04:35 AM @proteus I guess the equation is quite simple. What is the marketshare of linux in home computers ? What is the standard profile of a linux user ? Is it the main target for adobe/macromedia ? Simple ROI equation.
Besides it has nothing to do with MS monopoly, Flash Player has always worked well on Mac OS for obvious reasons, and is not available on linux for obvious reasons as well.
Do you know how this whole flash thing works? They give away the player and make money by having websites that use flash. And how many mac users are out there? Most studies show Linux with a bigger market share than Mac. They want to reach an audience that uses multimedia heavily. Are you really telling me that elementary school teachers are the heaviest multimedia users? There is no "ROI" calculation that would suggest mac is better than linux. When you make the web inaccessible to linux users, yes, you have declared war on them, even if that is a result of complete indifference to linux. Monopolies make everyone worse off, not just existing linux users.
Posted by: Anonymous | September 27, 2006 06:11 AM If disliking opensource and not wanting to share API specs with projects like gnash.. Why not porting the player lib to Java? In our days Java is fast enough to do the rendering and audioprocessing stuff, it works on every platform pretty much the same and C(++) source is not too hard to port to it in most cases. Furthermore Java runs on mobile systems - so flash media could be played *everywhere* with it. Of course it would be hard and expensive to get the grip with it at first - but later developing becomes pretty easy.
Posted by: Fenix | September 27, 2006 09:02 AM Regarding the market share of Linux: Adobe actually has more to lose than you realize. Flash is used in embedded devices like the Sonos music player, which runs Linux on a SuperH CPU. So they need to keep developing Flash for Linux regardless of the indetectable market share.
Of course, I bet those licensees get access to the source code in order to build their own specialized versions of the Flash Player :)
Posted by: jwb | September 27, 2006 10:50 AM If adobe is bothering to port flash, why not shockwave as well??
Posted by: NoTiG | September 27, 2006 11:17 AM Fellow Linux users... It looks like it's time to cut our losses and move on. Maybe this is for the best. Maybe better open alternatives will come out of this huge gaping hole that Adobe has left and is making very little effort to patch up.
I actually had some hopes that Adobe was going to to succeed in releasing Flash 9 in a reasonable time period a few month back. Sadly though, that doesn't appear to be the case at this point. Seriously, some of these "issues" that are holding up the release are just instances of Adobe making things much harder than they actually are. Listening to their endless excuses, one would think that they were porting all their applications to Linux, rather than just a browser plugin. Mean while, whole distributions will be born and developed in in the time it has taken Adobe to release a measly browser plugin. What a disgrace.
Mike, I have nothing against you personally, but I think Adobe has set you up to fail terribly by not providing you the necessary resources to complete this task and not really taking your project seriously enought to back it effectively. Ultimately, I think if and when Flash 9 for Linux is actually released, version 10 for Windows and Mac will have already been released or imminent, rendering your current work osolete and starting us on the same drawn out path all over again.
Posted by: jbus | September 27, 2006 11:28 AM Linux communities are known for many things, but wanting a single binary is usually not one of em :)
just getting mighty tired of the "you don't have the right flash, get it here"
Nowadays I get these about hourly ..
booo at Adobe
Posted by: q | September 27, 2006 12:55 PM Most distro maintainers will surely repackage what you provide, ebem if they do it in a subtle/sly way like debian/ubuntu and have the package installer do the download.
With this in mind, the libc 6.0/5.0 problem need not be your worry.
Let the packagers put a 6.0 dependancy in their package and leave it at that.
At least do a dynamically linked version for package maintainers to use.
Posted by: Samn Liddicott | September 27, 2006 01:17 PM LMF, I can understand where you are coming from. At the same time I feel that Adobe is not blocking the Internet from Linux users the Web Developers are. The Web Developers could choose to compile their Flash content in Flash 7 or just use HTML and JavaScript. Flash 8 is faster, has a lot of cool filters and better support for video. I hate knowing that when I have to develop content under Flash 7.
NoTiG as for your comment you have to stop looking at the Adobe Flash 9 Player port like the WINE or Mono projects under Linux. As for right now Adobe Flex is really the only tool that compiles stuff out in Flash 9. Even if a Flash 10 Player comes out you think it would be hard for them to use the Flash Player 9 code base and update from there?
I for one do not stand beside Linux/GPL zealots when it comes to trying to open source this plug-in. In most cases a lot of Open Source developers are being paid by some of these big companies like IBM,Novell and even Red Hat to work on an Open Source project. It's not like I don't understand the joys of Open Source software. However not like most people on this form I do understand that these developers need to make a living.
Now could Adobe Open Source the Flash 9 Player and pay these developers to work on it still? That's something I really don't know and the people on this form should ask Adobe that. The only thing I would really want to ask is for a 64-bit and maybe even a PPC Flash plug-in. Now, I don't own an old Mac but it's still about reaching more people. I don't see why people are not even pushing for that.
Posted by: Erick Feiling | September 27, 2006 01:30 PM EXECUTIVE SUMMARY
-----------------
Releasing Adobe Flash Player for GNU/Linux distros is difficult because is not free software.
Period.
Posted by: ricar | September 27, 2006 02:46 PM Thanks for your hard work and your patience with our comments.
I really don't want to contribute to a flame war about the GPL and libstdc++, but I do really hope you make sure it's legal to distribute your propietary code statically linked to that GPL+exception code. Because for what I understand, it's legal to dynamically link to it, but not to distribute it statically linked with propietary code. That goes against the very core of the GPL.
Here's what they say about the exception:
http://www.gnu.org/licenses/gpl-faq.html#LibGCCException
My advice: drop libstdc++.so.5 and link dynamically to the latest one. I can't imagine any desktop user using the old one and still wanting flash player 9.
Posted by: GNEMAN | September 27, 2006 08:01 PM There's not really a need for supporting very old desktop distributions, when they are mostly free to upgrade.
The trolls should get a life, too. Flash Player 9 for Linux is not vapourware, and it cannot be open-sourced. Operationally, it is a success; now the installation issues must be addressed.
If Flash Player 9 was "another Duke Nukem Forever", then it wouldn't have been demonstrated to a large crowd. Adobe has made a committment, and upped the ante.
And let's face it, if we're nice, Adobe might consider getting a larger team to port Flash (the authorer program) to Linux too.
Posted by: Chris Lees | September 27, 2006 10:07 PM I'm embarassed I was ever part of the linux community when I read these comments. You come across as a bunch of elitist pricks.
Mike, you're doing a great job. Keep up the good work.
Critics: Not having binary compatibility across distro's is a bug, not a feature. Automake is a workaround, not a better design. And if you think flash is so evil, provide me with an alternative, because I've looked at them all (gnash, svg, ...) and none of them do even half of what I need for my projects.
Posted by: Joeri Sebrechts | September 28, 2006 02:42 AM I can understand why Adobe wants a static player in the sense they want to make it as easy as possible to install and across the various distros. It does feel odd that Adobe is willing to increase (massivly) overall player download size though, given the fact Linux users are used to software having dependancies and like other posters have pointed out, the distro maintainers themselves will most likley want to package the app up themselves into there own package format. It also seems odd that Adobe are happy to delay release based on finding a way to staticaly link the whole thing based on the above points.
Now I'm not knocking the Adobe Flash Linux team, but it does appear they all have little Linux development experience. Given this fact and the fact they are forced to work closed-source, I think they are doing exactly the right thing by seeking help from the Linux community. I really hope they listen hard to what everyone has to say as we then might actually see a decent FP9 come to Linux, within a sensible timeframe and something that is fairly easy for Adobe to update and maintain.
Posted by: Jethro | September 28, 2006 02:55 AM By the time you learn the basic details about software development on POSIX/GNU, we won't need anything from you anymore.
Everyone who reads this, please help promoting and completing Gnash, the free (as in freedom) replacement for Adobe Flash.
http://www.gnu.org/software/gnash/
Posted by: Robert Millan | September 28, 2006 03:27 AM Just make sure it works against the Linux Standards Base (LSB) and everyone else be damned!
Posted by: Keith | September 28, 2006 04:24 AM Flash is already a blight ont he web, replacing standardised, accessible HTML with a proprietary hindrance to content. If you care at all about equality, you would get the latest version of flash working on ALL modern desktops before releasing on any, and make more of an effort to discourage it's use on websites, except for embedded media. That way, everyone has access to the same content at the same time. Even then, you should be moving flash (the editor's) output format to SVG+Ecmascript, if you care about the future of the web, and not just about building a monopoly and lining your own pockets. The situation with shockwave is even worse. Personally, I can't wait to see flash replaced with standards.
Posted by: Sync'd Release across platforms | September 28, 2006 04:38 AM To all the "Flash is a cancer on the web" people:
You're absolutely right, I couldn't agree with you more. I would like to personally thank you for having the courage to flood the poor Linux developer's blog with these wise and insightful comments. This is, of course, the best place to put them -- no one could be more responsible for the horror that is Flash than this man. I appreciate you not harassing the pencil pushers telling him what to do, or the webmasters who implement Flash; they have nothing to do with the problem. The sole cause of all our problems is the only guy seemingly working on the Linux version, and I totally agree that harassing him with accusations of incompetence will definitely make Flash happen faster, and make everyone appreciate the principle and people in the Linux community. Again, thank you so very much for standing up for what being an asshole implies you should believe in. I assure you that you do not go unapperciated. Amen, my brothers, amen.
Posted by: Arren Lex | September 28, 2006 10:57 AM Thanks for the update and working on getting flash on linux. Robert Millan has the right idea - anyone who complains should just join gnash and do something or shut up.
Posted by: Jonathan | September 28, 2006 11:04 AM One suggestion for Obviously: Flash Block
No one is forcing you to use flash. Some respect man!
As for Mike and friends, I get the impression that you are making this harder that it really is.
First, distros could find ways to install the player, second you are FREE to exclude folks wo/ some-freaking-library.
AND, it's not that you're asking install std++ v4 Alpha XXX Build to run the player.
Focus on performance stuff, asm stuff, etc... NOT library versions and distro incompatibilities.
AND please erase any silly/disrespectful comments from your minds .
Keep up the good work.We need Flash 9 to get by.
Posted by: Ogla Sungutay | September 28, 2006 11:10 AM Interpretation of these comments may vary..
The way I see it, a lot of webcontent is in flash, and it's frustrating, certainly to people that want to use Linux without being pro's. And we all want to be able to see the latest trendy clip when we hear about it.
Most of the heated reactions just indicate the desire there is for this software.
Who's to blaim? Surely the content providers are to some extend. However flash does presents itself as being cross platform. Many content developers count on the fact that other OS's follow withing a reasonable amount of time.
What is reasonable? Surely this is where most debate is about.
Some flame 'hey it is free' so you should shut up. This is a rediculous radical view, it would be the same as only supplying food to people of a certain religion in a refugee camp.I believe most people would aggree it's normal that linux is supported within a reasonable amount of time.
personnally I deem it reasonable if it is there within say 6 months or so.
I sure as hell don't blaim you two, who are developing/porting the flash player.
A critic might addapt the view that adobe is putting just enough money in porting to stay ahead of FLOSS solutions which would not carry their brand.
This blog is a friendly interface, but it isn't the end of the world.
Either you support it cross platform, and then you can't deny that Linux is a player.Or you don't, I don't like this hibrid situation.
Posted by: curto | September 28, 2006 01:03 PM Static linking is bad in the form of mass distribution on diff environments, as has been said in earlier comments you'll end up causing yourself and your team more problems in the long run. Including legal ones, please see http://people.redhat.com/drepper/no_static_linking.html
The general recommendation is to release and just state dependencies as others have stated
Posted by: Christopher Warner | September 28, 2006 01:44 PM Here's something lots of people seem to be forgetting:
A single binary is necessary because of Firefox's new plugin-handling architecture. If you start with a fresh install of the newest version of firefox, you can (and should be able to -- it makes the user experience consistent across operating systems) just point-and-click install the current version of Flashplayer 7 for Linux, no distro installer, no scripts, no hassle. In fact, this is the *only* way it can easily be installed on a multiuser system on which the user doesn't have root access -- a distro-specific binary would, by definition, require the user to be able to tinker with the OS package manager, something which we can't all do at work.
I do agree, though, that Adobe should be *very* careful with the licensing terms of the c++ library. It would be bad for future Adobe Linux projects to have Eben Moglen on their ass. And it really might just be easier to link agains the version 6 library -- those who said that systems that use version 5 are obsolete are right, in that the only ones that still use that are very conservative, usually server/cluster machines. Any desktop will be fairly up to date. (This is the upshot of not paying the $500 Microsoft Tax for an upgrade to the operating system!) Any desktop system that's not up to date ought to be, by all rights.
Please try not to let the zealots get to you. Quite a few of us use Linux because of the control we can have over the system, not because of any philosophical motivation. We just want it to work.
And I should probably note that we're likely to be a lot less in-your-face than the other crowd. Just because they're vocal doesn't mean that they speak for us all.
Posted by: bdrell | September 28, 2006 02:58 PM In fact just like most Linux users I don't mind using the close source NVIDIA drivers.
= = = = = = = = = = = = = =
I say we use closed source drivers, closed source software and closed formats and standards since its obviously a waste of time explaining the adage asking an inch and taking a mile.
Its a slippery slope like the guy who says hes just gonna try heroin once. It wont hurt you once...but after that its another story.
Your atittude will never force Adobe to get off their effing ass.
Adobe's atittude reminds me why closed formats are bad.
Whether theyre vital or just eyecandy.
And to they guy from CRN who has nothing else to write about but trolls on a blog: "Whaaaaaaa, he's being me to me.....Whaaaaa, I want my mommy!"
If any software is hindered by what some douchebag like myself says about Adobe on a little blog, then maybe you should unplug your computer and chuck it in the river.