Kdbus Will Likely Be Merged Into The Kernel This Year

[TheBlackCat]

I was speaking in general, not about kdbus/systemd/whatever. The same bloat is just as visible in editors, office suites, web browsers, email clients. You cannot claim that all these very different areas of software have legacy baggage as the reason for their bloat.

But we aren't talking about "editors, office suites, web browsers, email clients". We are talking about kdbus and systemd. How is your philosophy relevant to the issue at hand?

[curaga]

The only way to cope with this challenge is to improve machine speed. We are currently 3-4 orders of magnitude ahead of problem complexity improvements which you can easily see. Computers are everywhere. In the future complexity will grow. It means development time slows down even further. The only way to fight this is add more CPU/GPU power and improve IDEs and use larger abstractions from libraries. You might need to start working with 100 MB black box components MIN. Anything smaller is premature optimization, the root of all evil. The hard drives surely can handle this and besides apps move to cloud where there is infinite space and deduplication so it doesn't matter.

Yes, that is the problem. Because new problem X demands such abstractions, new developers only become familiar with those 100mb libs, and then proceed to use them even in areas that have no need for those. Thus bloating up things that otherwise should have become N times faster as hw became N times faster. They should expand their horizons and use the right tool for the job; yet wishing for that is hopeless, I too recognize that.

Luckily some of the industry analysts agree with me. Single core speeds stopped scaling years ago, SMP will not scale well to over 16 cores. Once that point is reached, developers will be forced to create more efficient software, as the hardware improvements will become slower and slower.

But we aren't talking about "editors, office suites, web browsers, email clients". We are talking about kdbus and systemd. How is your philosophy relevant to the issue at hand?

We are? Did you not read the last few pages?

The thread has not been on topic for a while now, that's completely ok for phoronix. kdbus is actually going in the right direction when compared with the user-space dbus. The relevance of this discussion to kdbus - well it went there organically, it doesn't have to be relevant

[caligula]

Luckily some of the industry analysts agree with me. Single core speeds stopped scaling years ago, SMP will not scale well to over 16 cores. Once that point is reached, developers will be forced to create more efficient software, as the hardware improvements will become slower and slower.

That's why people move to GPU programming and cloud. GPU scales nicely. Back in 1999 Nvidia had 4 core Geforce 256, now thousands of cores. Cloud also scales in different ways. Desktop is losing momentum because it can't scale in several ways.

[erendorn]

Yes, that is the problem. Because new problem X demands such abstractions, new developers only become familiar with those 100mb libs, and then proceed to use them even in areas that have no need for those. Thus bloating up things that otherwise should have become N times faster as hw became N times faster. They should expand their horizons and use the right tool for the job; yet wishing for that is hopeless, I too recognize that.

Luckily some of the industry analysts agree with me. Single core speeds stopped scaling years ago, SMP will not scale well to over 16 cores. Once that point is reached, developers will be forced to create more efficient software, as the hardware improvements will become slower and slower.

I think software has not become N time faster because a text editor does not benefit from gaining 6 orders of magnitude in speed of editing text.
Improving software does not always equal to making it run faster.
So as hardware gets better, you can introduce features that would otherwise slow down your software, without impacting the user => we are working at constant responsiveness.
If hardware stops getting faster, I bet that software will stop getting more "bloated", and we will use the next easier method to bring in new features.

[curaga]

That's why people move to GPU programming and cloud. GPU scales nicely. Back in 1999 Nvidia had 4 core Geforce 256, now thousands of cores. Cloud also scales in different ways. Desktop is losing momentum because it can't scale in several ways.

I can't believe you're actually defending software bloat by saying "just put it in the cloud".

BTW GPU scaling has also stopped a couple years ago, it hit the wattage wall in both number of cores and frequency.

[caligula]

I can't believe you're actually defending software bloat by saying "just put it in the cloud".

BTW GPU scaling has also stopped a couple years ago, it hit the wattage wall in both number of cores and frequency.

Bloat is bad when it's bad. In editors there are certain boundaries and demands we must meet. For example human perception might say the lag of GUI operations needs to be less than 100 ms. Computers are terribly fast. In fact they're "too fast" for running traditional editors. We are actually wasting computational power when the operations take say 1 ms and not 100 ms. If you ask your users , you get the majority of satisfied customers when you reach the 100 ms goal. After that there are only few whining oldskool unix beards who want 0.001 ms response time. Nobody needs that. It's better to cram in productivity enhancing features until lag is say 50 ms. Still way below 100 ms.

[Skrapion]

The same bloat is just as visible in editors, office suites, web browsers, email clients. You cannot claim that all these very different areas of software have legacy baggage as the reason for their bloat.

I don't know about you, but I'm far more productive in today's editors, office suites, web browsers, and email clients.

Editors are now able to jump to code definitions, fold code, and point out errors before I compile.

Office suites now enable me to make fully-formatted brochures, cross-referenced TOCs and indices, or import shipping labels via SQL. Even the real-time preview in the font drop-down box is a nice time saver. Hell, if we go back far enough, there was a time when office suites didn't spell check as you type.

Speaking of spell checking, it's awful nice to see those red squiggles in my web browser nowadays. And if we're going back to the 90s, then we don't even have tabbed browsing. No thank you!

My email client can now do an instant search, it can show my replies in conversation format, and it can manage my RSS feeds.

If you really think software has gotten worse, then put your money where your mouth is. I'm sure you can get 90's-era software to run on a modern machine. Run that for a while, and then tell us how you've found the promise land.

[curaga]

Bloat is bad when it's bad. In editors there are certain boundaries and demands we must meet. For example human perception might say the lag of GUI operations needs to be less than 100 ms. Computers are terribly fast. In fact they're "too fast" for running traditional editors. We are actually wasting computational power when the operations take say 1 ms and not 100 ms. If you ask your users , you get the majority of satisfied customers when you reach the 100 ms goal. After that there are only few whining oldskool unix beards who want 0.001 ms response time. Nobody needs that. It's better to cram in productivity enhancing features until lag is say 50 ms. Still way below 100 ms.

Right, you're on to it. The old-school usability threshold is indeed 100ms. But you're wrong in that it's enough. People are capable of distinguishing 70 fps - ~14 ms lag - with small training. Once you get used to such, you will feel the bad usability in 100ms apps. There is no need to throw ad hominems on that, there exists fast software on all platforms, not just unix.

You also claim that it would be wasting power to go even faster. This is not so, "race to idle" has been consistently proven to save power in most workloads. Finishing that code highlighting in 1ms instead of 100ms might let your battery run 7 h instead of 6 h, or drop your computer's average power consumption by 5 W.

If you really think software has gotten worse, then put your money where your mouth is. I'm sure you can get 90's-era software to run on a modern machine. Run that for a while, and then tell us how you've found the promise land.

I do put my money where my mouth is. Why do you get the impression I don't?

I run as efficient software as possible given the demands. There are places such as web browsers where one must move forward to be able to access some sites, but in other areas (editor, email) I'm happily running non-flashy, fast, efficient software.

It is also visible in the sw I develop. I try to make it as efficient as possible given my skills, and the required functionality.

[ssokolow]

You can find fast stuff that's still modern where it matters if you look. For example, I don't mind a little fiddling with .Xresources to get things set up (as ugly as it may be), so I use rxvt-unicode with screen or tmux for tabs and I get something that's very snappy and has a higher-quality terminal emulation the the VTE widget or Konsole KPart you find at the heart of 99% of the other terminal emulators.

(Though, given that Terminology claims to give urxvt a run for its money, I'm keeping an eye on it to see if it gains a tmux-like detach/reattach function. It's not as if it's difficult to replicate urxvt's kuake plugin at the WM level.)

Same with my desktop. LXDE does what I need, leaving more resources free to pour into the things that actually can benefit from it like running every browser I use (including a bunch of modern.ie VMs) in parallel for more efficient testing of the websites I write.

[erendorn]

Right, you're on to it. The old-school usability threshold is indeed 100ms. But you're wrong in that it's enough. People are capable of distinguishing 70 fps - ~14 ms lag - with small training. Once you get used to such, you will feel the bad usability in 100ms apps. There is no need to throw ad hominems on that, there exists fast software on all platforms, not just unix.

You also claim that it would be wasting power to go even faster. This is not so, "race to idle" has been consistently proven to save power in most workloads. Finishing that code highlighting in 1ms instead of 100ms might let your battery run 7 h instead of 6 h, or drop your computer's average power consumption by 5 W.

I think you missed "majority of users" and "demand" in his post.
Life tip: when there is demand for more battery life, developers put more emphasis on lightweight solutions (as seen in the tablet and smartphone software market, which is widely different from the desktop market in terms of features offered and size of solutions).