hobofan

I think there is still a point to be made that alternative more granular settings may help in less people turning it on.

e.g. I have "reduced motion" turned on because the workspace switching animation (and some of the other animations) on macOS is unbearably slow, and that flag is the only way to get rid of it.

Also, enterprises don't give a rip if models are open.

They care about control. I see many of my enterprise (or just-below-enterprise) clients very annoyed at OpenAI and Google after 2-3 years of model toil, where they had to constantly re-calibrate onto new models, on tight externally mandated deadlines, with little certainity. Now they are reaching for open weight models instead, that they currently host with the same inference providers, but have the option to in-house if push comes to shove.

Hmm... I'm a big fan of a lot of the things that the tokio project has built and a happy user of axum.

I'm not sure that projects like Topcoat and something like their ORM is a great direction for the project, and worry that they will possibly gain outsized adoption in the community based on name recognition rather than merit.

Almost everything further than a few years in the future and a few predicted pangea events appear to be data errors.

open source requires humans to volunteer their time

Your idealistic of open source may require that, but in practice a huge part of open source is commercial and a large chunk of that is low on collaboration (across vendor boundaries).

Yeah, I'm sure they've spent a significant time of their whole engineering department in the 13 years since the blog post on this!

I think the point is that while it does act as negative acceleration there isn't a causal relationship with the actual speed of the car, which is mainly related to how far the gas pedal is pressed.

Postgres 19, which is about to be released is adding support for SQL/PGQ.

I can tell you from quotes that I've seen, that compared to the 2018 prices listed on the page, end-of-2022 pricing was slightly up per core.

We were already well on our way of dumping Neo4J due to performance/operational/architectural reasons at the point, but seeing the quote solidified it.

Most graph databases only offer an advantage in query language, as it allows for more ergonomic graph traversal compared to e.g. recursive CTEs in SQL. However with SQL/PGQ, the same query ergonomics are coming to traditional databases.

If you look under the hood there is usually nothing special about graph databases that will make them more performant. If you lay out a query plan side-by side between e.g. Postgres and Neo4J, they will look identical, just that the leaf-nodes in Postgres will be a table-scan, while in Neo4J they will be either a vertex-scan or a edge-scan (which can both be seen as special cases of a table-scan).

As someone that has worked a lot with graph databases in the past, I'd largely recommend not using them. The price you pay in terms of worse ecosystem and less battle-tested maintenance tooling is not worth it to just have better syntax.

In a situation like this, induced demand could "easily" (on a technical, not a political sustainable level) be combated by shifting subsidies from car -> public transport. Induced demand won't be taken up as readily if there is a significant monetary penalty for it.

that make the software useful, usable, and updated

There is a lot of OSS software out there (e.g. in scientific communities) that I would say would barely qualify for each of those three attributes. The main reason it's valuable for the respective communities, is because it's the only thing that's available.

I use pi btw

Not sure if intentionally meant as a reference, but it gives "I use Arch btw" vibes.

It's interesting how OpenAI at the same time pioneered chat as primary interface for LLMs (+ have one of their strongest brands and defensibility for the common user there) and also seemingly wanting to steer away from it in so many ways.

This is honestly such a great direction (or at least hedge) for Mistral. They are already a great fit for EU companies, and are establishing a good relationship with them.

If they can stand up a robotics software platform without US or China cloud ties, pair it with robotics hardware that is already in the process of commoditization, they'll be running in open doors in the EU manufacturing/logistics sector.

It very much depends on what kind of system you are building, as each of them have different input/output modalities, each combination of them allowing for different attacks. If you are building a generic agent that can theoretically connect to anything and should build things end-to-end without interventions, then yes, it's very intractable to defend against prompt injection.

In more narrow cases, like Chat UIs it becomes a lot easier, though if it should appeal to a generic audience, still easy for individual users to misconfigure.

And if you want to use it in the most high-security environments where nothing can leak in/out, you will have to air-gap the system anyways (like any traditional software).

You're perhaps making it harder to craft a prompt injection, but not impossible. This is a false sense of security.

It's not a false sense security, it's part of a layered security strategy. Yes, it will never be impossible, but so are many individual steps in cybersecurity attacks. There are other systems (like email) that are essentially impossible to fully lock down with purely mechanical security measures if you want to allow for meaningful work (e.g. having email attachments). A second-judge LLM when paired with keyword/pattern blocklists, and active alterting/lockout after repeated attack attempts can form a very robust line of defense that in practice can be near-impossible to break.

For many attacks, to have actual exploitability, you also need to have compromised a peripheral system (or user account) to have repeated attempts at circumventing prompt injection measures.

And, are you absolutely sure you'll never forget to lock each and every thing down, including things you weren't aware of?

That's part of every normal (non-LLM) security audit. If you don't know what data can potentially go where, then you are open in attacks in any system. The AI space does add a bit of complexity here, if using MCPs hosted with third parties, though.

Prompt injections are a whole class of vulnerabilities, and I would say there is generally a pretty good idea of how to mitigate them to be impactful. However in many cases those mitigations are not implemented (in the strictness that they require), as they are usually either too costly (second LLM as judge) or lead to worse UX (tool call confirmation with appropriate review of all input parameters on every tool call; disconnecting web access).

If you configure GitHub to allow public code or LLM instructions to run in contexts that have access to sensitive things, they will leak; that’s not GitHub’s fault, it’s yours.

Is there a way to segment access per agentic workflow, so that you can have both habe an agentic workflow that has access to sensitive data and one that has only access to public data? Is the default to set the scope to only the current repository? Does Github appropriately inform about the risk of combining an agentic workflow with access to private repository data?

If the answer to any of those questions is "no", then that's a problem.

(Classic GH Workflows are also riddled with priveledge escalation via PR-triggered workflows, but that's another topic.)

I mean Elm has removed features breaking compat

To be fair, Elm hasn't made it to 1.0 (yet). That's where languages should make breaking changes before being stuck with the flaws forever.

I've head the displeasure of working with more than one Elm zealot in the past, and also allowed a service to make it into production (which was a huge disaster). Due to that, I know a lot more about Elm than I'd like to.

I think the "Elm is stable not dead" seen from the few people that stuck around with Elm is largely cope for being stuck with an unmaintained language. Languages, like all other pieces of software need maintenance or they degrade in the world moving around it (e.g. there is/was no official aarch64 build of Elm in the period of non-maintenance).

I also would say that Elm is still largely unfit for most realistic production scenarios, unless you have the manpower to build everything from scratch, as interoperability with the outside web world (JS/TS) is an afterthough, and by some parts of the community not desired.

The project was dead. The previous release was 7 years ago, where it stopped because the creator (same as author of this announcement) stopped maintaining it and since the community hasn't progress beyond a BDFL-model that's where it died.

So it was dead, it just now has been resurrected (and AFAIK with a whithered community in the meantime).

HEPA-filter air purifier and a robot vacuum that is scheduled to run while your are not in the apartment (to reduce baseline dust) are probably the most simple/cost-effective measures.

Seeking approval. It's apparent from everything he posts on X + the memeing + the whole "I am a elite Path of Exile"-saga.

That is not a homebrew sytax that Postgres came up with themselves.

It's SQL/PGQ, which was derived from the Cypher language for Neo4J and now is part of the SQL standard.

I think it makes more sense if it's not viewed under the aspect of trying to be maximally productive in its output. If you look at it over they years, they've also tried to do a share of public outreach / education (though I'm not sure how successful), and I think they also sustain themselves in terms of labor with burnt out tech people that are looking for a change of scenery.

So similar to a good zoo, that does both active conservation work, and at the same time public education (e.g. in the form of guided tours for school trips).

I guess that's why it seems to languish in obscurity.

I think even in a well-executed form, it would likely still be quite obscure, as there is next to no need for it in western societies (apart from emergency preperation).

I don't have the historic numbers at hand, but I would assume that for each of those categories this is a similar proportional increase, so it's similarly notable to mention the increase in spending on humanoid robots.

That's just your typical list that makes up the Linux foundation.

It might not be the idealistic flavour of open source you prefer, but it's the flavour of open source that's actively in use in most tech companies, and that also forms the makeup of most corporate open source participation (e.g. also the top corporate Linux contributors).

2. Isn't there a slight risk of upstream attacks being amplified by this?

I think the argument would be that consuming Minimus' containers would have a less severe amplification (or even reduction), as all upstream attacks that rely on a combination of third-party vulnerabilities would be rendered infeasible (since they reduce the amount of third-party dependencies in an image).

3. This ties into 2, if someone downloads and uses an image that is later found to be compromised they mostly have no way of being notified that happened.

For this you need a consumption-aware scanner anyways (e.g. that lists images running in your Kubernetes). Anything else will be too spammy, as you can't notify for everything for you have at some point in time have used as a base image.

Asking the very obvious question (as it's not apparent from the website): Why would I use this over DHI (Docker Hardened Images) or Chainguard Images, both of which also have a set of free hardened images?

There are ~25k total different MTG cards. Who cares if even 1k of them are for collabs (as long as they don't contain broken cards that end up in tournament play)?