And they are happy with 32bit Flash too [LWN.net]

Because this is prefessional software, of course :-)

Posted Oct 19, 2008 12:44 UTC (Sun) by macc (subscriber, #510) [Link]

He, he.

64bit platforms are not an obscure niche market.
Not today and certainly not tomorrow.

So Adobe seems to be mired in being incapable to jump.
( probably should shove the "white" boys out the backdoor.)

Reading that referenced blog ( even if the main
article is outdated the follow ups from this
guy read rather similar ) gcc is completely unusable
( at least for the hacks historically used by adobe/flash )
X is a pit full of poisonous snakes, linux as a platform
an unfixable mess.

How come so may OSS projects are completely cross platform
/ architecure / byteorder and compile effortlessly with gcc
to well behaved and performing binaries ?

I am regularly astonished how former windows programmers
can break a perfectly good unix system in completely
unexpected ways.
( Just tried to fix teamspeak2 on my sons box. No go )

MACC

64bit platforms? Huge market, yes. Pure 64bit platforms without 32bit support? Don't make me laugh...

Posted Oct 19, 2008 13:55 UTC (Sun) by khim (subscriber, #9252) [Link]

64bit platforms are not an obscure niche market.

Certainly not! They are widespread and Adobe Flash works just fine there! Oh, you mean "pure 64bit platforms without 32bit support"... That's not "obscure niche market", true. That's uber-obscure super-niche market.

How come so may OSS projects are completely cross platform / architecure / byteorder and compile effortlessly with gcc to well behaved and performing binaries ?

Effortlessly? Easily? Have you tried to compile VirtualDub with gcc? Or GNOME with MSVC? Few OSS projects go from Windows world to Linux world - because it's hard. It's much easier to go the other way (with help of the CygWin and MingW). OSS projects either live in Windows and don't even try to port to Linux because it's API is horrible mess or they live in Linux and then they are forced to deal with all these idiosyncrasies. Even so they often choose to care only about few platforms (TraceMonkey support is limited to x86, x86-64 and ARM right now, for example). Plus there are yet-another-problem: most "portability solutions" are designed with source availability in mind (have you tried to use rpm from RHEL on Debian or something like that? It's quite a challenge)

I am regularly astonished how former windows programmers can break a perfectly good unix system in completely unexpected ways.

Actually that's just different mindset: Linux programmers work in community and expect that other will fix their own bugs while they can be asked to change the program if there are some change in other place. Windows programmers goal is to make program compatible with given set of libraries/programs/etc but they are not ready to accept the fact that program which worked yesterday can require fix today.

64bit platforms? Huge market, yes. Pure 64bit platforms without 32bit support? Don't make me laugh...

Posted Oct 20, 2008 7:25 UTC (Mon) by quotemstr (subscriber, #45331) [Link]

What about Linux is horrible mess? You'd do well to support your accusations. I'd argue that Win32 is a horrible mess, actually, filled with compatibility kludges, automagical common control versioning, silently redirected writes to parts of the filesystem namespace, and so on. Not the worst I've ever seen, but I'd rather work on a nice POSIX system any day.

I can't speak for VirtualDub, but GTK+ programs actually run fine under Windows. Take Pidgin as a great example. If a program is hard to port, it's because that program's design is tied to the platform, not because platform X or platform Y's APIs are inherently bad.

Where is the mess? Everywhere: sound, video, embedding, etc.

Posted Oct 20, 2008 8:36 UTC (Mon) by khim (subscriber, #9252) [Link]

I'd argue that Win32 is a horrible mess, actually, filled with compatibility kludges, automagical common control versioning, silently redirected writes to parts of the filesystem namespace, and so on.

You are looking on the system from the POV of system developer. From POV of application developer lack of said automagical versioning is a mess.

Why? Some examples.

Sound. How well OSS emulation is working today? Oh, right, OSS API was a mess and so it can not be adequately supported. Now everyone must rewrite everything for ALSA... or may be GStreamer... or may be PulseAudio...

Video. There are just two interfaces: V4L and V4L2. So if I don't need the features I can safely use V4L, right? Oh, no backward compatibility... Ok, I'll use V4L2... What? No support for some devices? So I must support both? What a mess... (Note: AFAIK this particular mess was cleaned up and now most devices support V4L2 - but for years the situation was as described).

Widgets. Can I embed Qt widget in a GTK program? No? Why No? Ok. At least GTK widgets are usable in Qt (not so long ago this was impossible too).

Remember the ire Windows users directed on Microsoft for discontinuing VB6? It was supported for ten years before Visual Fred replaced it! In Linux such tectonic shifts (when you can not use old APIs anymore) happen once per year or two. And rarely developers offer support for "obsolete" technologies. The only one lib which actually supports old APIs is GLibC - yes, there are occasional glitches, but you can still take old program from the era where files were limited to 2GiB and it'll work. Oh and linux kernel itself is pretty good at keeping things backward compatible... unless you'll count aforementioned "big switches" like OSS->ALSA transition or V4L->V4L2 transitions.

Transitions in Windows are handles in the sane way (from the POV of everyone who's not system developer):
1. APIv1 is introduced.
2. APIv2 is introduces some years later. APIv1 is still usable and for a few years you can safely ignore APIv2.
3. APIv1 is declared deprecated and developers are encouraged to switch to APIv2.
4. Few years later APIv1 is... removed? no! frozen: you can still use APIv1, but some features are not available.
5. Finally, 10-15 years down the road APIv1 is removed.

If there are APIv3 or APIv4 introduced along the way - it means at some point you'll have concurrect support for three or four versions of API...

In linux it's done "in clean way":
1. APIv1 is introduced.
2. APIv2 is introduced some years later. Now you must support both APIv1 and APIv2. Because they don't play well on the same system and you never know when particular distributions will switch from APIv1 to APIv2.
3. APIv1 is removed.

This is the best way to scare away ISVs and "normal" users. Who just want to use the system and not think about versions of kernel, GLibC and GTK. Who want to select API to support all currect systems (say: 2-3years old) and future systems (again: 2-3years in the future). Why this limits? It's easy: PCs average lifespan is 2-3 years. And you want your application be available for everyone who's currently using PC. So Any API must be supported for at least five years (ten is better) and for at least three years after replacement is introduced (five is better).

Situation is slowly changing - but it's still far from being equal to Windows. Actually friedliness to ISV is almost directly proportional to market share: Linux is 1% (because of the aforementioned problems), Mac OS is 5-10% (it's better then Windows, but it still likes to do things like drop support for Carbon when 100% incompatible replacement was only available for eight years), and the rest is Windows (which is horrible in many ways but has excellent backward compatibility).

Remember: Joe Average does not care as much for "cleannes of the architecture" - but he does care about his ability ro use old software. And ISVs like to produce software which till PC lasts. This is not an option in current Linux ecosystem - unless you'll ignore it and go with separate abstraction layer (JDK, for example).

Where is the mess? Everywhere: sound, video, embedding, etc.

Posted Oct 27, 2008 0:22 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

No, Linux (the kernel) still supports the very first filesystem it had, and runs its very first binaries.

OTOH, I once bought a MSFT game, and it did not run on the next version of Windows. Just the splash screen showed, then complete hang.

This "Linux is a mess" is complete FUD. Yes, I do want my programs to run on the next (and then some) Fedora. Usually that means that they got recompiled (by my distribution or somebody else, even myself) on the way. I very rarely have any use for year-old binaries (except for some self-written programs that I just copied over and am still running as 32 bits on this 64 bits, mostly out of lazyness). And where I do need to run old binaries, I use a "enterprise" distribution; there I have a very much longer guarantee than on any Windows I've seen.

Hmm... Check your facts first, them talk

Posted Oct 27, 2008 7:57 UTC (Mon) by khim (subscriber, #9252) [Link]

No, Linux (the kernel) still supports the very first filesystem it had, and runs its very first binaries.

The very firstsystem? Did you mean very first filesystemS? There were two: ext1 and xiafs. Both are unsupported today. As for binaries... yes, "Hello world" runs, but real binaries fail routinely. Programs which iteract with hardware (floppy, CD, sound) are expecially fragile.

OTOH, I once bought a MSFT game, and it did not run on the next version of Windows. Just the splash screen showed, then complete hang.

What was the name of the game and what did you do to make it work? I've found that most games can be persuaded to work in the next version of Windows if you'll just remove what copy protection software they are using. That's not a Windows problem: copy protection creators go far beyond spec.

Look, I'm not saying Windows compatibility is 100% sure thing. But Microsoft thinks about compatibility! Compare with Linux: yes, there exist the way to properly support sound in old program. But it's still unmerged - six years after ALSA introduction! You can be 100% sure Microsoft will never tolerate such a huge breach of continuity. You can be 100% sure such transtion layer will be developed and introduced alongside the new interface, not some years after the fact when poor sound support will start to really hurt Linux reputation.

Yes, I do want my programs to run on the next (and then some) Fedora. Usually that means that they got recompiled (by my distribution or somebody else, even myself) on the way. I very rarely have any use for year-old binaries (except for some self-written programs that I just copied over and am still running as 32 bits on this 64 bits, mostly out of lazyness).

Yes, that typical Linux user attitude. But Windows user are accustomed to much longer support times. And for binaries, not for source. Some companies are still using 10-15 years old programs written in Visual Basic 2 for Windows 3.1 (that's one reason as to why Windows for x86-64 is not such a big hit: you can not use Windows 3.x programs there).

And where I do need to run old binaries, I use a "enterprise" distribution; there I have a very much longer guarantee than on any Windows I've seen.

Have you actually used Enterprise Windows? Let's compare, shell we:
Windows2000: introduced in 2000 (duh), EOL July 13, 2010
RHEL2.1: introduced in 2002, EOL May 31, 2009
Windows2003: introduced in 2003 (duh), EOL July 14, 2015
RHEL4: introduced in 2005, EOL February 29, 2012
RHEL5: introduced in 2007, EOL March 31, 2014
Windows2008: introduced in 2008 (duh), EOL October 07, 2018
Sorry, but if you'll compare enterprise Linux distributions with what Microsoft is offering... you'll find Linux sorely lacking. RHEL and Ubuntu LTS fall far short of what the Microsoft is offering where SLES is barely matching it (but if I wanted an Microsoft-controlled OS I'd used Windows). Don't try to rebuff FUD with FUD of your own - it backfires.

P.S. Note: I'm not saying Linux is hopeless. On the contrary: Linux is slowly moving in right direction. But to fix the problem you first must admit yet. Sadly Linux developers tend to ignore it and blow up every time points it out. That's not the way to win ISVs and users.

Where is the mess? Everywhere: sound, video, embedding, etc.

Posted Jan 26, 2012 1:25 UTC (Thu) by HelloWorld (guest, #56129) [Link]

> Sound. How well OSS emulation is working today? Oh, right, OSS API was a mess and so it can not be adequately supported. Now everyone must rewrite everything for ALSA... or may be GStreamer... or may be PulseAudio...
This is downright bullshit. There's OSS emulation in ALSA and it works most of the time. PulseAudio has padsp for OSS-only applications and an ALSA plugin for ALSA-only applications.

> Video. There are just two interfaces: V4L and V4L2. So if I don't need the features I can safely use V4L, right? Oh, no backward compatibility...
Again, this is just bullshit. V4L2 drivers do include a compatibility mode for V4L applications.

> Widgets. Can I embed Qt widget in a GTK program? No? Why No? Ok. At least GTK widgets are usable in Qt (not so long ago this was impossible too).
I agree that having two GUI toolkits is unfortunate, but it has _nothing_at_all_ to do with backward compatibility.

> 1. APIv1 is introduced.
> 2. APIv2 is introduced some years later. Now you must support both APIv1 and APIv2. Because they don't play well on the same system and you never know when particular distributions will switch from APIv1 to APIv2.
Right, except that you failed to provide even *one* example. I have gtk2 and gtk3 applications running side-by-side right now. I've run a Qt3 application (Xilinx ISE) just a few months ago.

So please, just stop making up random bullshit here.