saynsedit

Performant is not a word. Use a word more specific to your meaning, perhaps "efficient" in this context.

The original point is that this doesn't have to be a kernel. None of the current rationale gives any use-cases for the features you're offering, you're just saying "this feature requires kernel support" well what is the use case for that feature? Maybe there is another way that doesn't require kernel support.

Multicast messaging as your main motivation for a message ordering layer when that layer has drastic effects on performance and operational characteristics is a strange proposition. I'm willing to argue that 99% of application protocols will have no use for baked-in multicast as you've implemented it. What exactly is the killer use case for multicast messaging with side-channel aware causal message ordering? What prevents an application that cares about this from ordering incoming messages according to a lamport clock itself?

I see no downside to these features in general, it's just that the justification for putting it in the kernel is weak. Kernel code has an infinitely high maintenance cost and it's not clear bus1 is the end-all messaging layer you want it to be. There are lots of past failed examples, inotify, dnotify, and fanotify come to mind...

No.

* I don't see a time-slice accounting for the bus broker as an issue. If it's a system daemon, you can define away the problem. What's the use case for doing time-slice accounting where ignoring the system daemon's usage matters?

* for priority inheritance, have multiple daemons for each message priority level. Only privileges processes can use the high-priority message router, but can optionally use the low-priority message router when they want to inherit the priority of their sender.

* like I said, context switching is irrelevant since context switching is not the bottleneck in event latency nor in power usage.

* if FD accounting is important, move it out of the broker and make it p2p with broker coordination.

* kernel and LSM hooking feels like a feature looking for a use-case. If anyone really wants to do that, I'm sure the specific use case can be accommodated. Not every user space program need be trackable via LSM.

* for side channel and message ordering, why is this a core feature of the transport layer? I don't think all applications need this and if they do, something simpler and more specific to the application protocol could be developed. Generalized message ordering guarantees as part of the transport layer seems like it violates end-to-end design. A robust application protocol will end up ensuring this on its own anyway.

There you have it. I'm sorry but you don't have a strong case. Linus is even more opposed to this than I am and is probably better about system design than I am as well.

You can create a multicast-capable (n-to-n) IPC system in such a way that is safe, reliable, predictable, scalable, fast and lightweight in user-space. Kernel is not required!

"Software must be provided as a package – not as a service – with each user running their own private copy."

My ideology resonates with this statement.

On a more rational level, I agree that an environment that promotes application diversity encourages competition and innovation and ultimately will keep the tech economy humming.

I can see that removing the infrastructure requirement for distributing and providing web applications opens up web application development to a larger group.

There are shades of similarity of this idea with copyright reform and the free culture ideas of Lawrence Lessig. Once IP hits a certain threshold of common knowledge, preventing others from freely using it inhibits economic growth. Once something becomes cultural, it's hard for innovation to not grow out of it.

An example is Pokemon: independent companies can't make Pokemon products without gatekeeping from Nintendo. Currently, If a third-party pokemon product benefits consumers and drives the economy but is specifically bad for Nintendo then it won't be allowed. The counter argument is to innovate somewhere else but that's ignoring the fact that innovation is born out of experience and if I had no control over experiencing Pokemon regularly in my life because it's a cultural phenomenon, my ability to innovate is essentially handicapped.

What would you say is the main driving rationale for bus1?

I see, so basically assume the two end points are at zero and there is some rotation accounting for the endpoint offset in real space.

It still doesn't seem fully accurate as I can imagine a non-rotated cubic curve with endpoints at an offset, but I assume your simplification works well enough.

Is using a curve whose end points are fixed to zero to model the warping accurate? I can't see a rationale for why the end points should both be 0.

News release from the future:

After 2 years the original Otto product failed to get a footing in the market. Simultaneously, all attempts to integrate Otto technology into the core uber product failed due to internal politics and the fundamental impedance mismatch between self-driving AI for trucks and urban transportation. Additionally all original core Otto staff have left, and some are pursuing a new company that will revolutionize the future of truck driving.

Any examples? Even Debian packages include custom patches.

Sure, you're correct on that. Thanks for staying on topic.

No I very much did not make it my strawman. Look at the original announcement email, they themselves list performance as their main motivation.

Please, I can argue down any allegedly rationale for creating Bus1. Try me. You have yet to put forth any convincing argument.

The real bottom line is Linux already has a coherent IPC system but third parties don't like it and are irrationally fixated with an in-kernel solution that reflects their grand idea of what a coherent IPC system should look like. It's childish, it's bad engineering, and it's a waste of effort.

This is still irrelevant.

You were asserting that the majority of programmers think Linux == UNIX and have never tried to write a portable application.

Thst is clearly false as the majority of programmers probably confuse Mac OS X for UNIX and most modern unix-like software is portable to at least Linux, Mac OS X, and FreeBSD. Portable is more general than "portable across every UNIX that has existed."

Increasing the specificity of your argument mid-way to avoid the incorrectness of your initial general argument isn't very genuine.

But yes, your revised second statement is probably correct: most UNIX programmers have never tried writing portable code across "DG/UX, Solaris, HP-UX, Aix, FreeBSD, Red-Hat, Debian" exactly because there is no practical reason for it.

I don't buy these arguments...

For priority inversion it seems dbus-daemon is at fault here, not user-space message routing in general. It's just as easy to have two message routing processes, one for low priority messages and one for high priority messages.

As far as 4 context switches versus 2 with regards to latency. A context switch takes microseconds... This is vastly smaller than the 250ms UI response time.

Again, this looks like a solution looking for a problem.

Fixing wifi or screen before working on micro-problems in the kernel for the sake of global power efficiency is founded in every kind of logic. It's literally Amdahl's Law: reducing power usage in a component that already has the most minimal power usage is a waste of effort for no noticeable effect. The cost-benefit ratio is indefensible. This is insanity.

My point still stands. I don't think it's very likely that the main power hog in a mobile phone is the IPC mechanism. Unless IPC is happening in a tight loop, on the order of millions if times per second, it's just not common enough to really make a dent.

You have wifi, screen brightness, CPU-hungry background apps, etc. to fix first.

Irrelevant, if the vast majority of modern packages work with the big three, it's highly likely they work with other conforming POSIX systems.

If people started writing about how Kaspersky was not to be trusted because of potential ties to the Russian government that would seriously harm their business!!! Kaspersky is a potential advertiser after all.

Better to reserve the Russian sympathizer narrative for situations when it would vastly increase readership. A Kaspersky take-down benefits nobody's pocket.

Manafort's Russian ties aren't only known to Trump. The entire Republican Party establishment is well-aware of his background. Manafort is a part of that establishment and he's close to HW Bush.

This isn't Trump using private information to his personal advantage. This is complicity within the entire Republican Party establishment.

It's more likely that the Republican party itself has ties to Russia. Manafort was probably a compromise between the Republican establishment and the Trump campaign when he won the nomination, seeing as he let Lewandowski go and Manafort was tasked with moderating Trump's image. It also was Manafort who allegedly pressured Trump into supporting Ryan.

Trump is probably not using the Presidency to get preferential business treatment in Russia. There are much much much much easier ways to get edge, even in Russia. If he is, it's a goal that is way out there on the periphery, likely not something on which he would base his choice of campaign chairman.

The reasons are mostly performance reasons. As I said in my other post, IPC latency is way down in the priority list of things to optimize (relatively to network and disk latency).

Unless the application is a HPC parallel computation that is IPC bound, Bus1 has no performance justification. If the main justification for a modern kernel IPC mechanism is performance, I'd much much much more trust a proposal coming out of the HPC community than the desktop experience community.

There's no case for this usually marginal speed benefit.

Most programs are dealing with vastly slower bottlenecks. Like network or disk latency. IPC latency is so far down the list of priorities in terms of things to optimize.

Not to mention that regular user-kernel-user buffer copying is plenty fast now, especially since the buffers will likely be cache-resident. Zero-copy is mostly hype without performance numbers to back it up. Don't need this complex message sealing mechanism.

Eh? The majority of modern POSIXy software runs on at least Linux, Mac OS X, and FreeBSD.

In fact, Mac OS X is the most widely deployed UNIX-like system ever. What you're a claiming to be true probably more applies to Mac OS X than Linux.

I honestly haven't seen a recent package that was accidentally not portable in the long-term across the various modern UNIX-like systems because of confusion of Linux for POSIX.

What's more likely:

Trump hires Manafort because he has Russian ties?

Or

Trump hires Manafort because he's connected to the Republican establishment?

That's like saying "I use this hammer to tie my shoes and it's good because now I have a hammer."

A simple cron job doesn't require managing uptime. It just needs to run frequently enough and then upload the generated HTML to github. I'm sure he uses his laptop at least once a day. This is crazy!!!

The Lambda method seems like a more complex and unreasonable way to solve the problem. It's like using a hammer to tie your shoes.

This can literally run from his laptop whenever it's online. You don't need a fully fledged server to do this.

Run the Python cron job every five minutes. It checks the condition of all data sources. You don't need a server to do this, you can run this from your house!

Why is this not a single Python script on a cron that uploads to github pages?

Calling this satire insults the skill and wit of competent satirists the world over.

It's not clever or funny. It's lazy. It's exaggerated to the point of questionable emotional stability on the part of the writer.

Actually it is funny, but only in an ironic way.

"-Well, Amazon has ECS, but you gotta write XML or some shit."