fefe23

To borrow an old adage: The determined programmer can write C code in any language. :-)

This is an astonishingly bad idea. Don't do this.

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...

So, let me get this straight. You published your software under a free license that stipulates they can't remove the license and are otherwise free to do as they please.

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.

I find it very funny that the post is basically complaining about fearmongering by the maker of Sentry to scare people into not hosting themselves.

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.

Sure I'll just upload my company secrets to some random dude from the Internet. Lemmi just add you to the Signal group!

The title is confusing. He is not reimplementing the STL. He is writing some C++ classes providing functionality that is also already implemented in STL.

Hahaha holy moly they are linking to https://adblock.turtlecute.org/index.html to prove how great their adblocking is.

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.

In civilized areas of the planet this is called torture.

I like his other two talks better than this one.

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.

Oh no! Herb Sutter is leaving Microsoft?!

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.

Why didn't they block his access to the mailing list instead?

It's not his code that people felt hurt by, was it?

LFS has been a tremendous resource over the years for me. I'm happy it exists and that people put in the time to keep it going.

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.

I'm sick and tired of the "the evil attacker attacked this harmless company" rhetoric.

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.

Have you considered that you may have a different kind of humor than Justine?

Why would you even post this here? Who do you think this is helping?

Ladies and Gentlemen, let the race (to the bottom) begin!

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.

If you use shared memory with a captive process, that process can probably hack you if it gets taken over by an attacker.

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.

This smells like they are using shared memory, which is almost certainly a security nightmare. The way they are selling it makes me fear they aren't aware of what a time bomb they are sitting on.

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.

This is pretty much shameless advertising for a competing product.

Holy shit these claims are wild! It's not just a percent more performance here and there, the graphs look more like 50% more throughput on the same hardware (depending on the cpu architecture).

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.

After two sets of disastrous quarterly earnings the company’s market value has shrivelled to $84bn, less than the value of its plants and equipment, from over $210bn in January.

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.

These sound like reason you retconned so it sounds like you didn't choose Illumos because your founder used to work at Sun and Joyent before. :-)

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.

io_uring actually changes this story because you can communicate events without crossing the syscall barrier, but only if you get enough incoming events to saturate your processing capabilities.

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.

That is an assumption and generalization you can't make. In fact it is usually wrong. I invite you to do actual measurements before claiming things as fact in the future.

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.

This argument is basically hand waving, and it's factually wrong.

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.

I couldn't read what he had to say because his site opened an interrupting dialog element asking me to subscribe or join or something.

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.

For the love of all that is good and wholesome, DO NOT USE MEDIUM.

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:

https://i.imgur.com/AIrZmUp.png

This is satire, right?

Please tell me this is satire.

Yes. They call it "secure" and have zero arguments to back up that claim except Rust's memory safety guarantees.

Which, by the way, do not apply, since the SHA256-Code is marked unsafe.

"cryptographically secure bootloader" is a meaningless phrase.

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.

I don't understand the argument for rST. If you need more control than Markdown can deliver, then write your stuff in HTML to begin with.

I have written a ton of documents in plain HTML, including slide decks, documentation for customers, reports for customers, a blog. I have not written a book yet. If I were to write a book, I would use LaTeX because then the typographic fidelity of the output would be my paramount objective.

Plain HTML is actually pretty awesome. It allows you to encode the structure of the document and then style if however you wanted. When I started in this business, you had to use LaTeX for that kind of flexibility. HTML has gotten a bad rep, I think, because it's dark side of including Javascript and a ton of frameworks for whatever perceived goal looks easy and seductive and then forces you into serfdom by obstructing future reuse.

If you stick with the bare minimum HTML you'll be fine. Better than fine actually. Text processors can these days usually import bare metal HTML just fine if need be. They only fail if you give them the "processed food" output of some kind of rendering pipeline.

The only other system for documentation we haven't covered in this thread is troff for man pages :-) Any takers?