Pup Biru

the other insidious part about it is that pretty much everyone agrees: experience is critical to ensuring AI isn’t just producing slop… 30% of the time you get something that’s not just working, but well architected

now when you get AI to do things, even if you go with the assertion that it’s quicker (which a lot of the time i doubt: task choice is also critical for effectively using AI to generate useful outputs), you’re grinding down on your experience… not only are you learning less, but you’re also letting your reasoning skills degrade because you’re not using them (this is a pretty well-documented effect in standard neuroscience afaik)

imo, only use AI in situations where you’d put a library in, because the level of abstraction from the problem solving is similar

i took the phrase

You don’t need to understand why they struggle, just accept that they do.

to mean that you shouldn’t assume someone is lying. they just might have different circumstance or needs. that doesn’t invalidate their experience, just that you’re solving different problems (which may not have been well communicated, and also may not even be technical problems).

if you’re trying to solve their problems, then sure that’s a discussing… but 99% of tech conversations on the internet like this are people berating others for “not understanding” the “simple” way it’s done because it works fine for them

slight disagree: proud version is actually when you become so disillusioned with your old code that you throw it all out and start again

what’s not how a model works? i didn’t say anything about how a specific thing works… i simply said that emergent behaviours are real things, and separately that consciousness doesn’t look like a human brain to be consciousness

given we can’t even reliably define it, let alone test for it, if true AGI ever comes along i’m sure there will be plenty of debate about if it “counts”

who knows: consciousness could just be bootstrapping a particular set of self-sustaining loops, which could happen in something that looks like the underlying technology that LLMs are built on

but as i said, i tend to think LLMs are not the path towards that (IMO mostly because language is a very leaky abstraction)

emergent behaviour does exist and just because something is not structured exactly like our own brains doesn’t mean it’s not conscious/etc, but yes i would tend to agree

well see when you’re too lazy to design a schema and just want to throw broken data into a black hole where you may or may not be able to retrieve it and deal with the repercussions in production - or better yet let the ops team handle it at 3am - then that’s when you’d choose mongodb

saying Microsoft requires that you go out and obtain a signed certificate that proves your identity as a developer

clearly that’s not the case if this was exploitable… again, N++ has an auto update mechanism that they current use. if they used a microsoft signing key to sign a builds hash, this hijack would not be possible

thus they have an update mechanism that works around microsoft signing… how is irrelevant. that is the current state of the software

The update mechanism was successful hijacked because integrity checks and authentication checks were not properly in place

that part we definitely agree on

Notepad++ even said that they moved hosting providers after this happened to them

side note: doesn’t remotely solve the problem… software updates should be immune to this to start with. it’s a problem that the hosting provider was compromised, but honestly we’re talking about a state sponsored hack targeting other states: almost no hosting provider would include this in their risk assessment, let alone shared hosting providers

Can you point out an existing open source application that runs on Windows that only uses GPG signatures?

again, that’s irrelevant… the concept that we’re talking about isn’t even specific to GPG. signing a hash using a private key is basic crypto, and GPG is a specific out of the box implementation

if we remove microsoft signing as an option for whatever reason (which we have) then it’s still very possible, and very easy to implement signed updates into your own custom update mechanism

yes but as you yourself said

I think they want to, but Microsoft has made it expensive for open source developers who do this as a hobby and not as a job to sign their software. I know not too long ago, this particular dev was asking its users to install a root certificate on their PC so that they wouldn’t have to deal with Microsofts method of signing software, but that kind of backfired on them.

the part that we’re arguing against isn’t that a microsoft signing key would have fixed the problem, it’s

No, because you wouldn’t be able to execute the updated exe without a valid signature. You would essentially brick the install with that method, and probably upset Microsoft’s security software in the process.

this update mechanism already exists: it’s the reason the hijack was possible. whatever the technical process behind the scenes is irrelevant… that is how it currently works; it’s not a “what if”

adding signing into that existing process without any 3rd party involvement is both free, and very very easy

which is why this is a solved (for free) problem on linux

Windows and MacOS do not use that method to verify the authenticity of developer’s certificates.

completely irrelevant… software authenticity doesn’t have to be provided by your OS… this is an update mechanism that’s built into the software itself. a GPG signature like this would have prevented the hack

The update mechanism works fine, but you will not be able to execute the binary on a Windows or MacOS system

that’s what we’re saying: this update mechanism already exists, and seems to install unsigned software. that’s the entire point of this hack… the technical how it works is irrelevant

there are more ways to do signing than paying microsoft boat loads of money… just check a gpg sig file ffs (probably using detached signatures: again, it’s already built into existing tools and it’s a well-known, easily solved problem)

what’s irrelevant is the argument about how the auto update mechanism would work because it already exists

that’s all completely irrelevant…, there is already an update mechanism built into NPP: that’s the entire point of the attack… it’s this update mechanism that got hijacked

i’ve already linked the docs that state that native windows containers exist. whether or not specific images exist is not relevant

WSL, Hyper-V and Windows Containers are all options

they have to be built specifically for windows (of course the kernels are different, so the binaries are going to be different) but you can run Windows native applications on Windows kernel with a different implementation of containers using the standard Docker CLI and interfaces

Cgroups are just 1 (by far the most common) implementation of the container backend

i believe they’re saying that the deflector shield requires constant power, so that’s part of why the engine is required while moving rather than just while accelerating

the vuln afaik is for remote code execution via basically a mechanism that’s kinda like a transparent RPC to the server (think like you just write frontend code with like a “getUsers” and it just automatically retrieves and deserializes the results so you can render the UI without worrying about how that data exists in the browser)

i’m not a front end engineer, and haven’t used react server components, but i am a principal software engineer, i do react for personal projects, and have written react professionally

i can’t think of a way it’d be exploitable via purely client-side means

i THINK what they mean is that you can use some of the RSC stuff without the RPC-style interfaces, and in that case they say the server component is still vulnerable, but you still need react things running on your server

a huge majority of react code is client-side only, with server-side code written in other languages/frameworks and interfaces with something like REST or GraphQL (or even RPC of course)

it looks like this only applies react server components, and it doesn’t look like element uses react server components

but i only had a quick skim; could be wrong, but personally i wouldn’t shut it down - not that im running a server myself

most things scale if you throw enough resources at them. we generally say that things don’t scale if the majority case doesn’t scale… it costs far fewer resources to scale with multiple repos that it does to scale a monorepo, thus monorepo doesn’t scale: i’d argue even the google case proves that… they’ve already sunk so much into dev tooling to make it work… it might be beneficial to the culture (in that they like engineers to work across the entire google codebase), but it’s not a decision made because it scales: scale is an impediment

that’s a good and bad thing though…

it’s easy to reference code, so it leads to tight coupling

it’s easy to reference code, so let’s pull this out into a separately testable, well-documented, reusable library

my main reason for ever using a monorepo is to separate out a bunch of shared libraries into real libraries, and still be able to have eg HMR

google does a lot of things that just aren’t realistic for the large majority of cases

before kubernetes, you couldn’t just reference borg and say “well google does it” and call it a day

i’d say it’s less that it’s inadequate, and more that it’s complex

for a small team, build a monolith and don’t worry

for a medium team, you’ll want to split your code into discreet parts (libraries shared across different parts of your codebase, services with discreet test boundaries, etc)… but you still need coordination of changes across all those things, and team members will probably be touching every part of the codebase at some point

for large teams, you want to take those discreet parts and make them fairly independent, and able to be managed separately: different languages, different deployment patterns, different test frameworks, heck even different infrastructure

a monorepo is a shit version of real, robust tooling in many categories… it’s quick to setup, and allows you a path to easily change to better tooling when it’s needed