smashed

Just imagine how hard it would be to push a new programming language. No AI models would be able to generate code in that new language, or they would be extremely limited. This would make adoption much more difficult in a world where all developers use AI tooling extensively.

I believe this trend could create new opportunities also: as everyone uses AI tools to generate statistically average quality code, only those not using AI tools will be able to create true innovation.

Aren't you going to track the keys in a database, where you can keep the tenant id and creation time, scope of the key and any other significant metadata anyway?

A static prefix + checksum, maybe a version number so you can future-proof the system sounds like best practice. For example `ASKEY1-(128bit random base32 encoded)-(chksum)`.

When asked for full source code they seem transparent about it:

https://forum.gl-inet.com/t/source-code-for-gl-firmware-and-...

You can't reproduce their images and they don't share the improvements.

Of course not GPL compliant but not a concern in China I believe.

I really can't agree with Google in this particular case.

The terms eventually evolved to mean the same thing, as pretty much all brews became hopped.

The interpretation will vary a lot depending on the culture and the century you are digging into.

Some references: https://zythophile.co.uk/2009/12/14/the-long-battle-between-...

What would you use to build and self-host an ecommerce site quickly and that is not a SaaS?

You might consider adding a big warning on your official documentation about unsupported distribution packages.

Add links to relevant issue tracker/bug reports or mailing list discussions saying until So and so issue are resolved, the official statement is that distribution package is unsupported, not recommended and deemed dangerous to use.

This is as much leverage as you can have with the distribution community. Then wait for them to upstream patches and attempt to fix the issues. Accept fixes as you consider appropriate or not.

It's also important to at least respect the distribution's opinions in regards to having only one version of a library's major release . Just respect and understanding, you don't have to agree.

Also, all the problematic libs cited by the packager are 0.x.x numbered which sounds like a very young and immature ecosystem of dependencies. Of course, this is bound to cause pain to packagers. I think this speaks volumes about the high level of interest for bcachefs, that they actually tried to make it work instead of not bothering.

Lots of talk about tunneling and wrapping/disguising ssh but a vendor does not need any of that to control its machine.

For example you could have the on-prem host poll a "licensing" or "software update" server that also happens to reply with ad-hoc commands to execute on demand. Could be straight up shell commands and the result can be sent back. No need for ssh, long lived connections, reverse tunnels or anything.

The only way to mitigate this is to fully trust the vendor, have a strong legal framework to protect against wrongdoings or fully block all internet access to endpoints you don't fully control.

Maybe clarify what you can do better or different or just how exactly you're doing it and let the audience decide.

That's a bummer. But the core Risc-V support should be contributed straight to the Linux kernel/u-boot/gcc/glibc anyway I guess. Then board makers, not chip makers, should contribute/provide yocto support, based on that foundational work.

Not sure which key organization they are referring too though.

Since clients will attempt to resolve ntp.org in order to actually sync their clock, there is a good probability that some clients will be way off.

Enabling dnssec on that zone was probably not without important drawbacks? I wonder if the operators thought about that potential pitfall. Seems like they might be doing a disservice to their core mission of allowing devices to sync their clock.

Residential ISPs usually monitor the blacklisting of their IP addresses and will contact/suspend the customer once the IPs get listed on public black lists.

https://github.com/systemd/systemd/pull/31550

This might be why they started rushing their backdoored release, even though it was not perfect yet.

A utf character from a language that has zero chance of being mapped to your programmer's keyboard in the middle of a code line, that would be obvious intentional tampering or at the very least raise some eyebrows.

What's at stake here is systematic and transparent recording of all video and audio conversation.

Does it exist? Does ms teams for example has an enterprise feature available to record and archive everything without the meeting organizer activating the recording explicitly?

Python's import model is not without its flaws either, but at least you have a working application state, no need to fully initialize your app for every single request.

For simple apps that are contained within a few files, PHP is hard to beat for simplicity and speed.

Nftables and the netfilter project is the firewall implementation in Linux.

The legacy and beloved iptables format is fully replaced nowadays by nftables. You don't have to learn anything new because the iptables command line is just a compatibility layer on top of nftables with full compatibility. When you insert iptables rules, they get translated to nftables seamlessly. This has been the default on all major distros for years.

Converting to nftables has a few neat advantages such as much improved set/map and verdict tables support, unified IPv4, IPv6 and bridge rules, etc. But you don't have to. Everything old still works.

Flow tables is an optional feature of netfilter, I think originally meant to interface with hardware NAT accelerators in cheap routers, but it also has a pure software default implementation that can speed things up in some cases. That's what is being discussed in this article.

You use nftables to define and hook into flow tables. They work together, not against each other.

The problem I have is that it's usually junk fluff pieces with way too much text for SEO optimization.

I feel anything computer generated should be short bullet points or comparison tables, not long form text as it's just not good at that.

For example think of a blog post where the author walks you through its thought process, trial and error and ultimate solution. That is very humane and relatable, something an LLM can approximate/copy but it will never be genuine. I'd prefer in that case just the raw solution, not a fake and deceptive walkthrough.

And buy direct, don't use Amazon because of the counterfeit risks.