fefe23
Use HTTP server-sent events instead. Those can keep the connection open so you don't have to poll to get real-time updates and they will also let you resume from the last entry you saw previously.
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
They took you by your word and did exactly that.
What did you think a license is for? For artistic expression? It's a contract. If you want to get paid, put that in your license.
I recommend AGPL 3. Then nobody will rip you off. And if they do, you can drag them to court over it.
And then he does the exact same thing, on behalf of Sentry.
I hope he got paid for this. Otherwise it would just be sad.
That site then says:
I found that the uBlock Origin extension breaks the final result. To fix it, add adblock.turtlecute.org as an exception in uBlock rules.
Exactly the kind of belly laugh I needed right now. That side also falsely "measures" that my ad blocker lets all kinds of sites through when in fact my setup lets absolute zero third party sites through. Hilarious!
I wonder how many people fall for sites like that.
I find "this worked for me once at Etsy when we were a 20 person team" not a very convincing argument. That does not mean I think he's wrong. Just that the conclusion needs better arguments.
One argument that comes to mind is: If you treat people like children, they will start behaving like children. Treat people as adults if you want them to shoulder responsibility.
The main message of this talk is that when a designer tried to deploy a fix into production and it blew up production, they realized he had the wrong kind of permissions and their solution was to give him full deployment permissions.
Well, great if that worked for you. It might or might not work for others.
I would recommend not letting anybody deploy to production. You can deploy to staging, then tests are run, and only after those all pass can anyone deploy to production.
Also, the current process is not just the result of ego. It is also the result of evolution. We usually take steps to prevent things from happening because they have blown up in the past and we would like to not have that happen again.
That does not bode well for Microsoft. At least from the outside perspective it looks like he was the adult in the room, the driving force behind standards adoption and even trying to steer C++-the-language towards a better vision of the future.
If he is gone, MSVC will again be the unloved bastard child it has long been before Herb's efforts started to pay off. This is very disheartening news.
I'm happy he held out for this long even though he was being stonewalled every step of the way, like when Microsoft proposed std::span and it was adopted but minus the range checking (which was the whole point of std::span).
Now he has been pushing for a C++ preprocessor. Consider how desperate you have to be to even consider that as a potential solution for naysayers blocking your every move.
It's not his code that people felt hurt by, was it?
I often wonder why the existence of long "you also need to do this completely unintuitive thing first" documentation on the open internet isn't shaming more projects into reducing barriers to build their software.
Take some responsibility for your actions!
I loathe that you can apparently get away by telling reporters that it must have been a nation state actor. Oh it was just one kid in a hotel room? Well then he must have autism! Hey have you seen Rain Man? Yeah, must have been that kind of super power autism!
It's revolting. Get your act together and stop blaming kids. If a kid can unlock your door by entering the Konami code on your door bell, that's on you.
Why would you even post this here? Who do you think this is helping?
While the vultures will shit out AI generated garbage in volume to make ever diminishing returns while externalizing hosting cost to Youtube and co, actual creators will starve because nobody will see their content among the AI generated shit tsunami.
Finally the AI bros are finishing the enshittification job their surveillance advertising comrades couldn't. Destroy ALL the internet! Burn all human culture! Force feed blipverts to children for all I care, as long as I make bank!
I guess it's easiest to destroy culture if you didn't have any to begin with.
I agree with your parallelism counter-argument in principle. However even there it would probably make sense to not trust each other, to limit the blast radius of successful attacks.
In your next point the "careful" illustrates exactly my point. Using shared memory for IPC is like using C or C++ and saying "well I'll be careful then". It can work but it will be very dangerous and most likely there will be security issues. You are much better off not doing it.
Postgres is a beautiful argument in that respect. Yes you can write a database in C or C++ and have it use shared memory. It's just not recommended because you need professionals of the caliber of the Postgres people to pull it off. I understand many organizations think they have those. I don't think they actually do though.
Shared memory works as a transport if you either assume that all parties are trusted (in which case why do IPC in the first place? Just put them in a monolith), or you do hardcore capturing (make a copy of each message in the framework before handing it off). Their web page mentions zero copy, so it's probably not the second one.
Also, benchmarks are misleading.
It's easy to get good latency if your throughput is so high that you can do polling or spin locks, like for example in benchmarks. But that's probably not a good assumption for general usage because it will be very inefficient and waste power and require more cooling as well.
My immediate fear was that they optimized away the security features like absence of timing side channels, but they say they still have those.
They also claim to have formal proof of correctness, which is even more amazing, because they are not doing it on a symbolic level but on a machine instruction level. Apparently they tought their reasoning system the semantics of all the CPU instructions used in the assembler implementation.
I'll still wait what djb has to say about this, but it looks freaking amazing to me.
Holy smokes. I just looked at the INTC 5 year chart and it is, in fact, a bath of blood. I don't think it happens very often that the market cap of a company is less than the worth of its physical assets.
Frankly I don't understand why they blogged that at all. It reeks of desperation, like they feel they need to defend their choice. They don't.
It also should not matter to their customers. They get exposed APIs and don't have to care about the implementation details.
epoll batching only works in respect to the event notifications from kernel to user space. The only other thing that could be considered batched is that you can switch from "I want to read" to "I want to write" without telling the kernel first that you don't want to read anymore. But that's hardly worth mentioning.
I, for example, implement an async web server and your case basically never happens. You get a connection, you call read, there is not going to be data yet. In fact calling read immediately is basically wasted effort, so I'm not doing it. I save one syscall over your proposal right away. Optimizations like TCP fast open might change this over time, but definitely won't when you do SSL. You need to wait for a request and then for replies. SSL involves several additional back and fros over plain TCP.
Writing is worse unless you tell the OS to provide ungodly buffer space per connection, which you shouldn't, because then your server won't scale.
Yes, switching from user to kernel mode and back is expensive. But let's count the syscalls.
Model 1: Threads. 1 blocking read(), 1 blocking write(). Plus cost for the OS scheduler.
Model 2: 1 "I want to read", 1 "can I read now?", 1 actual read, 1 "I want to write now", 1 "can I write now?", 1 actual write. Multiply as necessary if the read or write are only partial. Add IPC cost as necessary if you have more than one thread handling async events.
Measuring by the syscall overhead, blocking I/O is much more efficient.
There are other costs to it, though, so it usually consumes more resources per handled socket and turns out to be more expensive than async I/O. But it's not the syscall cost causing it.
If I see that, I immediately stop reading and close the window.
There is no better way to show me you are not actually talking to me than interrupting yourself and me with distracting bullshit UI elements.
Here is what Medium looks like to someone who was considering spending their time to read your content:
https://imgur.com/a/do-not-use-medium-WhK3omB
EDIT: Apparently imgur is thoroughly enshittified as well. I didn't notice, I'm using Firefox with adblocker. Try this url instead:
Please tell me this is satire.
Which, by the way, do not apply, since the SHA256-Code is marked unsafe.
They mean a boot loader that validates cryptographic public key signatures of the loaded component. That would be a secure cryptographic bootloader. AFTER they have proven that it is, in fact, secure.
You can't just write some code and then say it must be secure because Rust was involved.