The egregoric lifecycle of a company. People that want to make money take over a successful business and run it into the ground not realizing their budget cuts are what killed the company (because, like locus, they've already moved on to the next feast).
Well, CL is very mature, with sbcl, abcl, ecl, clasp, clisp, lispworks, allegro etc all with different pros and cons, editors and libraries, besides the elegance of scheme, I would have little clue why one would use anything else.
Eh, I've worked on a lot of really shitty C code bases. Yeah memory safety is a class of bug but that doesn't exist in other languages but every ecosystem has its share of footguns.
The real time sinks are caused by the same thing regardless of language; poor design.
It is the issue, when the industry nonetheless keeps on insisting on using languages that have neither garbage collection nor ownership semantics. Is your kernel, OS, userland memory-safe yet?
They don't break out salaries specifically, but personnel costs are in this paragraph:
> To sustain our ongoing development efforts, about half of Signal’s overall operating budget goes towards recruiting, compensating, and retaining the people who build and care for Signal. When benefits, HR services, taxes, recruiting, and salaries are included, this translates to around $19 million dollars per year.
Regarding the first point. If I understand correctly you say that there is an inevitable performance hit when not running in kernel mode. But is that really so?
I don't like that you were downvoted for curiosity.
Yes, there is a performance hit but how large it is depends a lot on what you're doing.
"Switching" is one of the most costly operations and in Kernel mode you do not need to do it unless interacting with something in user space.. which you would only do because something in Userspace requested it somehow.
For other things, such as virtual memory, Microsoft found that the protections needed for virtual memory could be anywhere between 10 and 20%; but since there's no concept of virtual memory in kernel space: it's hard to say concretely that your program would be "20% faster". It would be too much of a different program.
The whole point of dpdk is that it bypasses the kernel to obtain speed. It almost certainly requires a lot of privileges, but the kernel itself isn't the source of the hit.
The cost is in the switch between driver->kernel->network-consumer as running TCP and routing packets to the correct process are done by the kernel.
If you run dpdk you get raw ethernet frames and run TCP yourself. This means that a program can receive any data sent to the machine. More sophisticate cards can do routing in hardware and present multiple "virtual" cards, but this is not yet commonly available in consumer hardware.
dpdk is not general purpose networking. It's passing a device to a process and forgetting about it; the process itself needs to decode what is sent on the wire and make sense of it.
It's basically the kernel giving up on trying to do anything with the hardware, thus it's not available to any other process except the one that takes the hardware.
To have general purpose networking in user space you will end up with some other IPC which does not rely on sockets (because sockets are kernel) or shared memory which is dangerous as hell.
I had never heard of this concept before seeing this article. Great to hear it's in Germany also! Would you know if there is a list of co-ops in Germany somewhere, to see if there is one closer to me than Karlsruhe?
There are two things named Cooperatives: One is a coop that is owned by those it serves, e.g. a housing coop is owned by those who live in the flats, a food coop is owned by those who buy the food. The other is the coop as a legal form of corporations where you have essentially no difference between a regular corporation, a LLC or a cooperative, and the cooperatives will usually own other entities with different legal forms for actually run the business.
ReWe is the latter, and has nothing in common but the name of the legal form with what is discussed here.
