Have you seen the rate of Germany's GDP decrease in the recent years? I think it's hard to claim the USA and UK are falling back when pitted against Germany for that reason.
b) Apparently you don't know the difference between a script and a compiled program.
Apparently you ignore the fact the interpreter is a program and using a current interpreter included with the distribution to manipulate an old piece of software still counts.
c) In other words, you are using the same version of the X Window System. No big surprise it continues to work.
I really can't be assed to go through the effort, really.
But to simplify it for you, the PE headers would need to be modified for it to even run on windows 3.11 due to the explicit deprecation Microsoft made for older windows applications, then you may have a problem with DEP on XP and definately a problem running 16bit applications on Windows Vista and higher, which means you'll just end up running windows 1.1 inside a virtual machine.
On the Linux side, it's a matter of satisfying dependencies from libc to a gnome 1.0 environment where you'll end up probably running it inside a gnome 1.0 instance in a Xephyr, which is only slightly better than having to run it inside a virtual machine.
Case in point: Neither will run out of the box, same thing.
Is it that you don't know the difference between scripts and complied applications or that you know the difference and are making a false equivalency or that you are deliberately extending the discussion to something not being discussed (scripts) to "score points" (red herring) or that you are extending the example beyond the original endpoint of the discussion (moving the goal posts)?
I gave adequate examples of using them with older software too on a modern system, such as when I mentioned syncterm (a mostly statically linked binary) with scripts that ran on a modern version of the interpreter that manipulated it through x11 messages.
How about using something from X10, assuming you can find it?
Back then Unix sockets were used for IPC, kind of like how Microsoft was using DDE for IPC instead of COM back then.
But, you could still communicate with a statically built application from decades ago using unix sockets just fine. On Windows, not so much because 16bit application are no longer supported (however DDE as an API still exists in Windows today).
I wouldn't be surprised if clock.exe from windows 3 did actually work in win7
It wouldn't.
If his point is that some Windows IPC feature was key to its success, then pointing out that Windows wasn't as nifty before that feature was added is just making his point.
His point was about versioning, however software that old did not have Windows' RegFree com technology and his Linux examples were based on developers that didn't use best practices with dbus and reusing the same name spaces for major version changes, which would be no different from a windows developer ignoring best practices and sticking with the old com registration system using identical name spaces or using a bad assembly manifest (which is more common than you'd think thanks to Visual Studio being a bit 'too' smart).
However, his clock example was relatively non-sense because the first reason it would not work is due to binary problems which the clock application from older versions of Windows will also exhibit and then clarifying that it had to be the binary, not recompiled from sources. Do you see where I'd feel this is utter non-sense?
TL;DR: It's a confusing experience on Ubuntu for solely political reasons, ruining the user experience.
Clicking 'yes' to installing support for other stuff is so confusing... Sorry, I don't buy it. I'd buy the fact the user doesn't want to know and so ignores and doesn't read what was written, but confused? Nope.
what do you imagine would happen if you took some component - say... a gnome "clock" widget that plugs into the taskbar - and by that i mean you took the *binary* not the source code - from Gnome 1.0 (whenever it was written - when was it - 15 years ago, now?) and tried to use it in Gnome 3.0?
The same thing that would happen if I took clock.exe from windows 1.1 and tried to run it in windows 7.
now, what miguel's pointing out is that even if you took code from *six months ago*, you have the same problem! and that the consequences of this, over the 15+ years in which linux desktop software has been developing - have burdened both the developers, the users and the gnu/linux distros - with constant problems that they're just getting fed up with.
Except I have scripts that automatically switch power states, networking configurations and screen locks from a year and half ago that I haven't rewritten working today on the latest verison of Kubuntu. The fact a single application can't do it doesn't mean the entire system is broken, it just means that application wasn't designed properly and there are similar issues with older com applications when you have conflicts. Older com providers in the past typically had the same registered name despite being major version differences and if you installed an application that installed an older version of a com component, all your new applications would suddenly stop working, even if it was installed in a entirely different location because it made a new registration on the com system. The fact Gnome (which admittedly, I'm not really familiar with, so I'm just going to trust your word on this) didn't choose their namespaces properly or figure out a better plan for supporting backwards compatibility has nothing to with dbus sucking, the same issues exist in com.
contrast this with the fact - the FACT - that if you grabbed a random 20-year-old Microsoft OLE (COM) / Active-X (COM) DLL from anywhere off the internet (assuming you can find it), and you tried dropping that Active-X component into I.E. 10 or into the absolute latest-and-greatest version of microsoft office, guess what will happen?
I still have an old version of syncterm on my system that has x11 messaging support for being controlled via other application. It still works today on a modern x.org server from a perl script.
i can't.... i can't begin to get across to you, if you don't understand this by now, quite how powerful a concept this is, and it's one that, clearly, the linux community *doesn't* understand or appreciate... to everyone's detriment.
I just think you're just being selective in your comparisons. The solutions already exist on the OS.
According to the website, Geenz Spad and Mimika Oh made some fixes in the OS X build.
This has nothing to do with "after installing X-Code (a 10 minute fully automated process), I can run and compile all major programming/script languages from the command-line. "
If it truly worked, there wouldn't need to be a huge need to dick around with it to get it to compile on OS X unlike on other platforms.
But since you are comparing it with installing using the package manager on Ubuntu, why wouldn't you just use one of the binaries they provide on their website?
Because, I actually compile the builds that go on the website and OS X is not just touch and go like this person implied he could with his wizardry.
I'm fairly certain that was not what GP meant. But you already knew that.
His examples seemed pretty clear to me.
The problems solved by having a OS defined common object model are very real, and versioning/backwards compatibility is just one such problem.
I'm failing to understand the issue, there isn't actually that many standards. File sockets was the unix way of doing it, x11 is pretty much just the old way of doing IPC in a graphical environment, dbus is the new way that was intended to combine both graphical and non-graphical communications as well as provided methods to offer extended services for 'future technologies' created without requiring rewriting the standard.
As for versioning, x11's versioning was extremely graceful and so is dbus's, so I genuinely don't see the issue. None of these implementations suffered the faults the COM/DCOM system did with regards to reference counting, name space collisions with DLL hell (for registering a specific provider for certain functionality) - In actual fact the versioning Linux libraries use prevent this to begin with and message pumping that would cause system wide lock ups.
Would you mind contributing your wizard skills to make setup "just work" immediately for compiling Exodus viewer on OS X, please?
It's fairly painless on Ubuntu, installing everything through the package manager and can compile on the go, with the exception of manually installing autobuild (but that's the same on every OS).
I'm one of those people who tried OS X some years ago when people on Slashdot were promoting it to be the opensource bees knees. I fairly quickly caught on how bad the operating system system was, being able to cause kernel panics through mode setting, broken forks because of the lack of proper posix compliance, where libraries are not async safe etc.
Slashdot Mirror
I thought it was obvious... Windows 8 appeals to squares... Litterally.
Have you seen the rate of Germany's GDP decrease in the recent years? I think it's hard to claim the USA and UK are falling back when pitted against Germany for that reason.
Cry some more.
Apparently you ignore the fact the interpreter is a program and using a current interpreter included with the distribution to manipulate an old piece of software still counts.
Selective reading.
I really can't be assed to go through the effort, really.
But to simplify it for you, the PE headers would need to be modified for it to even run on windows 3.11 due to the explicit deprecation Microsoft made for older windows applications, then you may have a problem with DEP on XP and definately a problem running 16bit applications on Windows Vista and higher, which means you'll just end up running windows 1.1 inside a virtual machine.
On the Linux side, it's a matter of satisfying dependencies from libc to a gnome 1.0 environment where you'll end up probably running it inside a gnome 1.0 instance in a Xephyr, which is only slightly better than having to run it inside a virtual machine.
Case in point: Neither will run out of the box, same thing.
I gave adequate examples of using them with older software too on a modern system, such as when I mentioned syncterm (a mostly statically linked binary) with scripts that ran on a modern version of the interpreter that manipulated it through x11 messages.
Back then Unix sockets were used for IPC, kind of like how Microsoft was using DDE for IPC instead of COM back then.
But, you could still communicate with a statically built application from decades ago using unix sockets just fine. On Windows, not so much because 16bit application are no longer supported (however DDE as an API still exists in Windows today).
It wouldn't.
His point was about versioning, however software that old did not have Windows' RegFree com technology and his Linux examples were based on developers that didn't use best practices with dbus and reusing the same name spaces for major version changes, which would be no different from a windows developer ignoring best practices and sticking with the old com registration system using identical name spaces or using a bad assembly manifest (which is more common than you'd think thanks to Visual Studio being a bit 'too' smart).
However, his clock example was relatively non-sense because the first reason it would not work is due to binary problems which the clock application from older versions of Windows will also exhibit and then clarifying that it had to be the binary, not recompiled from sources. Do you see where I'd feel this is utter non-sense?
Aren't you a special snowflake?
They didn't. They are very much still in business. Now back to the original question:
Could you explain to me what was wrong with Novell's offerings to resolve the problems stated?
Clicking 'yes' to installing support for other stuff is so confusing... Sorry, I don't buy it. I'd buy the fact the user doesn't want to know and so ignores and doesn't read what was written, but confused? Nope.
Out of curiosity, did you buy your Linux system from a Linux OEM like System76 ?
u mad?
You realize this is a non-issue because of how you're supposed to use namespaces is identical to how you handle library namespaces on Linux?
The same thing that would happen if I took clock.exe from windows 1.1 and tried to run it in windows 7.
Except I have scripts that automatically switch power states, networking configurations and screen locks from a year and half ago that I haven't rewritten working today on the latest verison of Kubuntu. The fact a single application can't do it doesn't mean the entire system is broken, it just means that application wasn't designed properly and there are similar issues with older com applications when you have conflicts. Older com providers in the past typically had the same registered name despite being major version differences and if you installed an application that installed an older version of a com component, all your new applications would suddenly stop working, even if it was installed in a entirely different location because it made a new registration on the com system. The fact Gnome (which admittedly, I'm not really familiar with, so I'm just going to trust your word on this) didn't choose their namespaces properly or figure out a better plan for supporting backwards compatibility has nothing to with dbus sucking, the same issues exist in com.
I still have an old version of syncterm on my system that has x11 messaging support for being controlled via other application. It still works today on a modern x.org server from a perl script.
I just think you're just being selective in your comparisons. The solutions already exist on the OS.
This has nothing to do with "after installing X-Code (a 10 minute fully automated process), I can run and compile all major programming/script languages from the command-line. "
If it truly worked, there wouldn't need to be a huge need to dick around with it to get it to compile on OS X unlike on other platforms.
Because, I actually compile the builds that go on the website and OS X is not just touch and go like this person implied he could with his wizardry.
His examples seemed pretty clear to me.
I'm failing to understand the issue, there isn't actually that many standards. File sockets was the unix way of doing it, x11 is pretty much just the old way of doing IPC in a graphical environment, dbus is the new way that was intended to combine both graphical and non-graphical communications as well as provided methods to offer extended services for 'future technologies' created without requiring rewriting the standard.
As for versioning, x11's versioning was extremely graceful and so is dbus's, so I genuinely don't see the issue. None of these implementations suffered the faults the COM/DCOM system did with regards to reference counting, name space collisions with DLL hell (for registering a specific provider for certain functionality) - In actual fact the versioning Linux libraries use prevent this to begin with and message pumping that would cause system wide lock ups.
If by "works exceptionally well" you mean "segfaults often", then yes, you are correct.
Your post holds no relevance to today's Linux mainstream distros.
Why doesn't ubuntu-restricted's packages not offer the codecs for you again?
Would you mind contributing your wizard skills to make setup "just work" immediately for compiling Exodus viewer on OS X, please?
It's fairly painless on Ubuntu, installing everything through the package manager and can compile on the go, with the exception of manually installing autobuild (but that's the same on every OS).
Could you explain to me what was wrong with Novell's offerings to resolve the problems you stated?
Arguing? So far the dominant sound system is ALSA and has been for over a decade. Compare this to Microsoft's sound APIs in the past decade...
To counter your annecdotal evidence.
I'm one of those people who tried OS X some years ago when people on Slashdot were promoting it to be the opensource bees knees. I fairly quickly caught on how bad the operating system system was, being able to cause kernel panics through mode setting, broken forks because of the lack of proper posix compliance, where libraries are not async safe etc.
So your complaint is that you don't know x11 messaging and dbus?
When did it happen under the PLN currency?
I agree completely, let's shutdown bitcoin, WoW and EVE!
Personally, I don't get the point of using Bitcoins when there is Solidcoin that has apparently a not so vulnerable backend.