Debating A Software Center For Fedora

[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.

[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.

[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.

[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.