I am delighted to inform CrowdStrike that they have just done additional, extensive, damage to their brand, and will no doubt have just emboldened those who were tempted to sue them.
Your unethical behavior and abuse of the DMCA will be used to punish you.
If you succeed in getting ClownStrike taken down, you will be hated even more.
Have fun annihilating your brand, reputation, and customer/industry trust and goodwill.
Sometimes companies completely change their name after reputation damage. Maybe they are attacking clownstrike because they had intentions of escaping reputational damage by changing their name to clownstrike ?
They will not fix this. Indeed, regulation is required, but meaningful change requires a functioning, coherent government with institutions that are not fully enclosed in regulatory capture.
The United States is falling apart, and it is no longer capable of solving its own problems. Now, inertia keeps legacy systems functioning, until fascism and/or balkanization a-la USSR takes over.
Write your own. Wrote one fairly recently in good-ole-sepples that uses UNIX domain sockets and pushes around half a gigabyte a second on weak ARM hardware. Domain sockets are great. Shared memory is even better. If you need a portable solution between processes, not threads, I recommend domain sockets and a simple binary protocol for high throughput.
The article mentions that the perf of unix domain sockets was not significantly better:
> I was surprised at how similarly most things performed. I did a cursory investigation into Linux-specific approaches like dbus and Unix Domain Sockets, but they seemed to be in the same ballpark as the non-shared memory approaches.
I wholeheartedly agree. To add a bit more carrot for people on the fence, unlike TCP/UDP sockets, you don't have to be concerned about endianness because the bits never leave the machine. For a lot of use-cases, this is a big win that doesn't get as much appreciation as I think it should.
> unlike TCP/UDP sockets, you don't have to be concerned about endianness because the bits never leave the machine
Why would you be concerned about endianness even if you're using TCP or UDP, if you control the protocol?
Little endian won; in 99.9% of cases there's no reason to use big endian unless you're implementing an existing protocol which explicitly mandates big endian. Doing something over the network doesn't magically make it better to use big endian, and the whole "network endian = big endian" is just silly.
This is reasonable, but a bit unfortunate specifically for TCP/UDP. The extremely strong convention is that all network protocols are "network byte format" which is Big-Endian.
Obviously no issue for local IPC, but when things become published network protocols, little-endian makes me sad.
> This is reasonable, but a bit unfortunate specifically for TCP/UDP. The extremely strong convention is that all network protocols are "network byte format" which is Big-Endian.
This is really only relevant for packet headers, tho. What goes into payload is entirely up to the developer. There is no specific reason to keep endianness the same between TCP/UDP and its payload. As long as it's clear which one to use.
RFC1700 is marked as obsolete. IIRC, network order is big-endian is because it allowed faster packet switching? But we're at the point where I can do dual-border routing with DPI orders of magnitude faster than switches from that era can do basic switching.
Some people choose little-endian for payload because they are:
a) unaware of endianness and will discover a funny thing when they suddenly start talking between BE and LE nodes. Rust forces you to choose when you write or read numbers.
b) Think since their CPU is LE then payload should be LE as well for performance. This is false because even on ancient hardware this would not take more than 3 cycles (in a context of network communication shaving off 3 cycles is a hilarious endeavor)
c) Aware of all of this and choose LE because they felt like it.
> Think since their CPU is LE then payload should be LE as well for performance. This is false because even on ancient hardware this would not take more than 3 cycles (in a context of network communication shaving off 3 cycles is a hilarious endeavor)
Having to do BE/LE conversions means that you can't just reinterpret cast your network buffers into whatever is the native application message type. Yes, there are ways around that (by wrapping every integer field with an endian converting accessor), but it is a significant amount of yak shaving.
Well, the native application type depends on what platform that application is running. That means LE in 99.9% of cases. Don't need to sell LE for payload to me, I'm already sold. It's people that think network byte order has anything to do with payload that are confused.
Rust apparently wants to reverse its warning logic and instead of banning unsafe{} inside unsafe fn(), they want to require it and make it a hard error.
Sometimes, I think about what I really want. What I want most in the universe, for myself.
There's plenty I want for everyone else. I seldom let myself think about what would be good for me lately.
Sometimes, like tonight, I do know what I want for myself.
It's impossible, but it's my greatest desire for my life.
I want to be "uplifted". I want my brain capacity to be expanded by orders of magnitude. I want to understand, I want to comprehend, I want to see it all and fully understand the shape and implications of all things in my sight. I want to be more than a human mind. I want to be far, far wiser. It's not power I want. It's knowledge. It's understanding.
I get this.
The problem is whenever I gain some new depth of knowledge it expands my mind such that I also realize more of how little I know.
Yet the pursuit of it is still thrilling.
I oscillate between this (having an expanded brain capacity) and the exact opposite (a more limited brain capacity, the ability to take things one at a time, be eternally optimistic, not have your mind race all the time, sleep instantly when you lie down).
True. I'm not an insomniac or anything close and I exercise regularly. I think sleep hygiene and sleep posture (and breathing during sleep) are the last pieces of the puzzle. Still working on it.
Yeah I've been there. But I don't think you can improve your working memory or your "intelligence" (however you choose to measure it) much beyond your baseline (which could be quite high already, compared to the average). And the only way to stay at your baseline is by having a very relaxed life (good quality sleep, good nutrition and water, exercise etc).
Yearning for a bigger brain only made me feel worse.
I recommend you to watch the movie "Transcendence", ignore the reviews. After that let it just be an idea for the movie plot and instead go walk through the woods for a while. I used to be where you are now, but no singularly can fix what is in essence a spiritual problem.
Watch all the funding dry up and the researcher get framed for some random, stupid crime, with just enough prison time to make sure he won't see the inside of a lab again before he's too senile to use it or dead.
Could also be a slip in the tub etc.
There's a lot of money in suffering, and if you think there aren't people sick enough out there to do real horrible shit to protect that income stream, you're kidding yourself.
How do you think this fucked up civilization was twisted into the giant pulsating tumor it currently is?
Finally, a software fad that I actually want to support! About time I get one!
SQLite is more than good enough for an awful lot of things. Most of the time that I do see software using MariaDB etc, I think to myself "they didn't need a server model for this, SQLite would have been fine".
Would love to see someone rewrite SQLite in Rust - it's always the example I go to for full-coverage, fuzzed to hell and back, code. IMO there is nothing a new language could improve. It really is insanely stable and well tested.
