Debating A Software Center For Fedora

[Hamish Wilson]

Perhaps a better option, rather than messing with linux distros individual ways of doing things would be to make Linux distros have out of the box android app support and was able to download any android app from any source online and run it and for linux software keep things as they are.

I assume you are aware that Linux and Android applications are not completable with each other? So unless you have a killer compatibly layer, I do not see this happening. I mean, just the differences between the ARM and Intel architectures would cause some headaches I would imagine. Not trying to kill your idea, just wondering if you thought about that.

[DanL]

Did C and C++ suddenly become fast? No, they are as slow (compared to ASM) as they ever were.

You're ignoring advances made in compiler optimization and you seem to be suffering from the common (and antiquated) "assembly = holy grail of programming performance" delusion.

[plonoma]

About the slowness of languages.

When testing out a language with an environment. It's also the environment and implementation of the language that plays a role.
Over time newer languages get faster because compilers, environments (VM's) and other involved software gets more optimizations.
The speed of things is NOT static. C++ compilers didn't make the same slow code when C++ was just beginning to being implemented.
Same with the newer languages.



For an application speed and running fluid are two not related concepts.
The perception of it being fluid or not depends on the UI. Which can be completely decoupled from the heavy lifting through threads and other constructs.

As a software developer, Linux is shaping up nicely but for making software I really want the following sorted out.
- Don't care about the user faced including GUI aspects of a package manager when talking about cross-distribution ways of doing stuff.
This does not matter and is not in need to be standardized across distributions. Don't waste effort in trying to do that.
- A software developer needs a standardized package format and installation api for packages.
- As a programmer I need a few functions to do basic things, the absolute minimum are libraries to fire up my application and check for frameworks, libraries other things I can then start.
The LSB provides api's for doing this and much more, it gets better in each version.
- A software developer needs a decent way to store application.
Meaning the Directory structure that is very crappy these days.
Go the GoboLinux way, seriously!
Throwing all bins and other things from different programs in one directory and doing that with other directories is a mess.

[curaga]

Which is wrong, of course.

OK, I'd love to hear your opinion on why Google after several years and several increasingly powerful generations of hw has still not managed to do a fluid UI. Call me cynical, but that really sounds to me like a more fundamental issue.

Python has been acceptable and widely used for more than a decade. It's one of the most popular languages right now. Claiming that CΡUs are not fast enough for Python is not only disingenuous, it is dead wrong.

I don't define "fast enough" as barely able to run, but as being able to run completely fluidly even under (moderate) load.

Normal people refer to market penetration charts for CPUs and see what is actually in use today, check trends for the near future and design software to run on what people actually use. If you did that (and it's quite obvious you haven't) you'd see that Python, even Ruby, are quite acceptable for modern software - if they weren't, you can bet they wouldn't be quite as popular as they are.

No chart is perfect, since business users with 5-10 year upgrade cycles rarely are taken into account, just as an example. But as another example, look at the Fedora stats (smolt). 33% of their users have sub-2Ghz cpus, and 25% of users have less than 1gb of ram.

Those are substantial portions to me. And the real outlook is likely worse than that, for reasons such as the business group.

[BlackStar]

No, the hw penetration became good enough that they became acceptable. Python and friends are not at that point yet, and probably will not be in years.

Python has been acceptable and widely used for more than a decade. It's one of the most popular languages right now. Claiming that CΡUs are not fast enough for Python is not only disingenuous, it is dead wrong.

The fact that Intel releases a new gen yearly has nothing to do with hw penetration. Using 1% or less of user base as an argument to be slow just doesn't cut it.

No? Oh, I forgot, you are the one with the 486. Don't mind me, carry on then.

Normal people refer to market penetration charts for CPUs and see what is actually in use today, check trends for the near future and design software to run on what people actually use. If you did that (and it's quite obvious you haven't) you'd see that Python, even Ruby, are quite acceptable for modern software - if they weren't, you can bet they wouldn't be quite as popular as they are.

[BlackStar]

Also, for your mobile Java mention, it's widely regarded as the reason Android UI is still laggy even on quad core phones.

Which is wrong, of course.

[BlackStar]

Perhaps a better option, rather than messing with linux distros individual ways of doing things would be to make Linux distros have out of the box android app support and was able to download any android app from any source online and run it and for linux software keep things as they are.

I'm all for that! The synergy would be huge and Linux popularity would skyrocket if people could create and distribute applications as easily as in the Android market!

But no Linux entity will even consider that option. Canonical wants to create its own smartphone and TVs (that noone sane will buy), Novell is dead, Red Hat has given app on the desktop and Google is not a Linux shop (it's got its own incompatible OS). Debian and Gentoo are their own little microcosms and don't really care for popularity (nor have the raw firepower to support such a project).

Still, too bad... It's a huge opportunity that will apparently remain untapped.

[curaga]

Also, for your mobile Java mention, it's widely regarded as the reason Android UI is still laggy even on quad core phones.

[curaga]

Did C and C++ suddenly become fast?

No, the hw penetration became good enough that they became acceptable. Python and friends are not at that point yet, and probably will not be in years.

The fact that Intel releases a new gen yearly has nothing to do with hw penetration. Using 1% or less of user base as an argument to be slow just doesn't cut it.

[BlackStar]

Quite. So you're saying that to run a package manager applet, you need to have an i7 monster with more ram than hd?

Indeed, I don't really believe your 486 can cut it anymore. Time for an upgrade.

Also how you jumped from interpreted to C++ [you're right of course there, I'm mostly embedded]. But the jump from C++ to say python is more than from C to C++.

You are aware that this very argument I made was common 10-15 years ago, right? C++ was the slow evil beast that no sane programmer would use, because HOLY BLOATED MOFO. And C was the slow beast 20 years ago in the ASM vs C holy wars.

Did C and C++ suddenly become fast? No, they are as slow (compared to ASM) as they ever was. So what changed? Software complexity. Software has become so complex that the time you need to hand-optimize any moderately large project has become longer than the mean time between new-gen CPU releases. The trade-off is simply not worth it.

Java, once considered slow and bloated, now powers half the world's smartphones. Ruby, PHP and Python, all slower than Java, power most of the web. A large part of scientific analysis is performed in Matlab - another slow, bloated language. Even embedded systems now run C# and, given, the choice, most sane people would prefer that over C provided it fits the power and performance profile (you'd be surprised how often it does).

C++ is the COBOL of today. It will always exist, but at some point most people will consider as a painful memory of the dark ages.

(Edit: Ubuntu Software Center should be optimized to startup faster. That's not done by rewriting in C but by improving the current code. Note that the update-manager is C and is almost as slow, which might point to a systemic problem.)