maurice2k

There's also RoadRunner, a more PHP like alternative to FrankenPHP:

https://roadrunner.dev/

Just from the headline, this reminds me of Microsoft Windows in the 1990s that came with it's on interpretation of JavaScript (aka "we have implemented some JavaScript like stuff that seems to work like Netscape but in fact doesn't")

In general this sounds pretty cool: GJS is built on the SpiderMonkey JavaScript engine. It utilizes GObject Introspection to provide access to the GNOME APIs using ECMAScript 2021 JavaScript.

Just don't compare it with Node.js; it's something else. No, your code might not run in that environment; APIs are most likely not compatible.

Question is if this extension detects having changed owners itself? Maybe something else, not an extension, would be better suited for that kind of check, although of course more complex I guess.

the problem is that most people do not monitor heavy use of TXT records; it's rather A/AAAA resolves in my experience.

but most production system i've seen allow all outgoing traffic (if poorly managed) or restrict it to port 443 (for some APIs) which is kind of all.

so if you're not in a very very restricted system (and then DNS should be restricted as well!) you'll most likely find an easy way to copy stuff over HTTPS.

Fully agree, but I doubt this is not the reality we live in... ;-)

I guess you're the audience they're targeting with this nerdy content :-)

I can also lightly smile but give this to a 20 or 30 year old person. They won't understand it.

Nothing is wrong with 1995 and I really liked the time when content was king.

But younger people looking at Times New Roman websites is like telling them 'use man pages'.

I think GNU is not doing themselves a favor in being so old school. I'm not saying they should use (nonfree scnr) JavaScript bloated websites but a more modern look is not that complicate and achievable with free HTML and CSS standards.

"*Note: The custom script allows us to interact with the Twitter API while circumventing the nonfree JS that is sent to the Web browser. For viewing replies and retweeting posts, we use Choqok."

So funny and so sad. Nonfree JS? They're in their own cloud of whatever. Yes, there is nonfree stuff. But nonfree stuff also can get things done.

That's exactly what I think about RMS, FSF and GNU.

I'm mostly working with younger people (like 20-30 years old) and well, they don't really know what GNU or the FSF is.

As a Linux user I'm using GNU software all day but for most people it's just "linux command line tools". It's fine and if they do the job, well done! But this doesn't help the FSF or the GNU project.

A lot of these tools have pretty good documentation but when you visit one of the GNU websites you feel like it's 1995 again. It's more like man pages in HTML. Actually same for Apache Software Foundation.

And this is not getting better...

A start would be a modern representation of the tools and the ideas behind free software, maybe with a bit less philosophy. GNU needs to get a bit "cooler".

I think the same is true for Debian Linux.

Small and comes with a lot of packages that are only an "apt install" away. I only install packages that I need an check that nothing else is running and/or has open ports.

Don't see this as a pro BSD argument.

For servers I'm exclusively using Debian for 20 years and there was literally never a problem while upgrading from one release to another. Of course there were hickups with packages but not with the core system. I expect something similar for BSDs...

Honest question: Why choose BSD over Linux?

I've worked/played around with BSD back in the 90s and actually never looked back. Tried it here and there within the last 20 years but never found it as versatile as Linux.

Working on macOS (how much BSD is still in that system?) since 6 month now and finally getting used to it. Still feels a bit crippled compared to the tools I used under Windows/Linux.

Exactly. I'm not a super-expert in Node.js but worked a lot with it and also know a lot of internals.

And I can definitely say: IO speed is pretty good. To be honest, I've never come across a language with bad IO speed and I've seen quite a lot of languages.

I also did some benchmarks (like orf did) and speed is pretty good. Maybe Rust is a little bit better because it's nearer to syscalls than Node.js is but we're not talking about 760kb/s vs. 250mb/s.

200GB of logs and 25 instances means 8GB per instance. Not sure what they're doing, but processing of 8GB taking 3h is like doing it with my 80286 processor ;-) Even with inserting stuff in MongoDB this seems way to slow. And they only replaced the file IO part with Rust...

I guess the records array is getting pretty huge which might result in swapping to disk. But then: don't let it happen, just flush it to the database or whatever. I believe the problem could have been solved with Node.js without issues.

Looks like the situation improved a bit: https://cryptography.rs/

I would still like to have a more comprehensive or high level stdlib for Rust that is maintained by a core Rust team.

I was evaluating Rust for some cryptography use case and there were only "random" community libs available that lacked support here and there. And I actually had no trust in any of those libs.

A stdlib must not contain everything but a solid cryptography lib is probably a good idea.

Go has one of the best stdlib I've come across. It's very well written and documented, the code is extraordinarily clean and easy to understand, even for advanced topics like cryptography (of course you need some fundamental understanding here).

I think it's comparable to Python.

Go's stdlib was one of the reasons I ended up with Go instead of Rust (might have changed; Rust had a lot community content, but not a comprehensive stdlib; last checked 3-4 years ago).

And you can even beat this by using Golang's own net library and a pool (but not messing around with an own event loop):

https://github.com/maurice2k/tcpserver

I'm running ~600k to ~800k chrome sessions a day, each in a new browser process (no tabs/pages) because of cookie interferences.

The magic is hidden in chrome's command line parameters which can significantly speed up the browser start.

I'm not using headless because I need an extension but most command line switches also apply to headless I guess...

A prepared profile/user directory also helps speeding up things.

Last autoupdate check on 2015-09-26 ... IN THE FUTURE? THE LAST ONE?