sauercrowd

I used to think this but once you treat them as another path to get in they become really useful.

Yes, you still have your 2fa and password, but you create a fast path in addition to it when you get in.

It became even more useful once I stopped insisting they have to go into 1password

I'm pretty impressed how openai is both extremly verticalized but also building products across the whole depth of that stack.

Not sure if they're just trying to find what the abstractions are worth focusing, or if it will stay that way, but certainly cool to see how much they're trying out.

Why does it have to be ad revenue though? A forecast of ad revenue alone being below expectations really doesn't say much about a company like openAi

The short term tokens section is weird.

If you do need a short-lived, signed token for something, there is a better spec called PASETO which is designed to be secure

Suggesting to non security people (like myself) something for auth that isn't a mainstream idea seems like a bad idea? Not to mention that it doesn't refer any reasons why it's better

TL;DR: they made a course for citizens

So what's being proposed here? Why bother and just use US clouds?

Had a pixelbook and it was hands down one of the best laptops I ever had. Sure, ChromeOS is fairly boxed in but the Linux VM was reasonably good and the built quality was just something else.

I wish they'd just make ~ pixelbook with ubuntu... it'd be such a powermove, and they if anyone could pull it off

I was excited at first by this, but the "designed for gemini intelligence"... like what does that even mean

Don't disagree, but the "if you're doing it right" is a big asterisk for an open source project with people you have no idea what quality bar they're at.

And in my experience it's quite hard to figure that out by quickly looking at it.

Not to mention that contributions on github (almost?) never include the prompt chain anyway, so the status quo is even worse

You were responding to a comment about the price point being not that expensive, claiming that "200 usd for a college text book is very US centric", so I assumed you were arguing against that it's "worth the money".

So what are you arguing for? I genuinely cannot tell.

I mean even having linters and everything still creates a whole bunch of noise in their PR section, not to mention that a lot of the changes I make to stuff that's written by codex is not stuff that's caught by linters.

It's just bad/wrong/context lacking decisions and mental models it introduces, that if not carefull will just create a massive mess of a codebase. (I know, because I've tried, and had to deal with it)

And if someone vibecodes a PR and it works, why dont they just share the prompt so a repo owner could vibecode it themselves?

The price of that book could pay for months (and in some cases years) of tuition in EU countries.

To your later comment, the devices are provided. You dont need to buy them.

Also that's not actual price. the tuition fees are that, doesn't mean that's the price. It's just heavily subsizied by the government. Hard to find sources, but the actual price/student in Germany seems to be ~10k Euro/student/year.

Hard to find

No disagreement here. Just very short sighted.

I'm somewhat surprised with Github's strategy in the AI times.

I understand how appealing it is to build an AI coding agent and all that, but shouldn't they - above everything else - make sure they remain THE platform for code distribution, collaboration and alike? And it doesnt need to be humans, that can be agents as well.

They should serve the AI agent world first and foremost. Cause if they dont pull that off, and dont pull off building one of the best coding agents - whcih so far they didnt - there isn't much left.

There's so many new features needed in this new world. Really unclear why we hear so little about it, while maintainers smack the alarm bell that they're drowning in slop.

Here's what I'd suggest

1. There needs to be reframing of the engineer role in the team, by the leadership. It's not just to build things, but to help the customer. The job of the engineer is to build a good product for the customer, not just to "build", fix Jiras, ...

2. At the same time, get some engineers on customer calls. It doesnt need to be everyone, but you need to shorten the feedback cycle that engineers directly get signal from their users. A lot of information gets lost through Jira's, intermediates, ...

They dont have need talk, just listen. Will they pay attention? That comes back to the reframing of their job being to create a good product for users. If everyone understands that's the goal, they will.

If you have engineers building custom extensions for your database, because your CRM product needs some low level performance optimizations - it'll still be good but less interesting.

The goal is to get some engineers talking to customers, cause they'll talk to other engineers. And engineers know how to talk to engineers. It'll shorten the feedback cycle, and that's good for both speed + signal.

Now I don't know how much of that you already do, and they might even do all these things already, and what you see is the output of the worst issues already taken care of. If the latter is the case, there's some more cross team comms needed

This describes quite well the huge advantage small companies have vs big companies.

(Motivated) people at small companies "care", and what I mean with that is they are responsible and can see a large enough portion of the customer experience that - if something is broken - they'll see the pain and try to address it.

At a big company no one cares. They of course care about their job, but their job is such a small fraction of the overall customer experience, that seeing their work having an impact on their customer is exceptionally difficult.

That's why large companies need to encode customer feedback into a system to imitate feedback cycles. Mostly in metrics. That's a very lossy way to capture signal, and leaves a lot to be desired, but so far it doesnt seem like anyone has come up with a better system.

Highly recommend trying pi.dev

It's fully open, fairly minimal, very extensible and (while getting very frequent updates) never has broken on me so far.

Been using it more and more in the last two months, switching more and more from codex to it now.

half baked? disagree, doing EU is hard - it's a bunch of fully sovereign countries trying/having to agree, and we're still figuring out how that could work.

We'll need a bunch of steps like that, to get closer to the efficiencies we're hoping for.

true

Go actually does https://pkg.go.dev/embed

I do think it's more painful to distribute files when you're a distributed as a single binary vs scripts, since the latter has to figure out bundling of files anyway.

But still - it does exist

In the same way s3 is different to a dropbox, and a car being different to a bike.

Can't tell if you're ragebaiting here, but I'm very confused by this question because they support an entirely different set of features, and if you use both it's painfully obvious how they're different.

Docker is built for running services, distribution is part of that, but it's core is that you can pull an image and run random service on your machine packaged with all the right libraries, network them into your machine in the way you like so it can access the right things, constrain it's resources, and create our own image based on it.

Snap/Flatpak is built to distribute applications, sandboxing being a core part of it, with applications wanting to integrate into distribution mechanics such as audio, URL handling, taking screenshots, ...

docker and flatpak/snap are _extremely_ different tools with very different purposes.

there's no daemon with gci, it's just docker swarm doing everything.

GCI itself is just a command line tool, just layering opinions and convenience on top to make the experience more smooth

The tide seems to be shifting on codex, but also lets not forget openai has a brand that none of the others have - it's _the_ AI.

Sure Google can go against that, but it's openai is definitely in a much better spot. It's pretty important for a consumer market.

I wish it would be, but it's not. Gemini feels more sluggish, it's relatively overloaded with animations compared to chatgpt. Like most Google products.

Really surprised by all the comments here, they didnt hire him because of the amazing security openclawd had, but because he's one of the first one's who made a truly personal assistant that's actually valueable to people.

It's about what he created, not what he didnt create.

They're not acquiring the product he built, they're acquiring the product vision.

... most of which can be fixed by a rewrite in Rust

huh? That is clearly not the case. memory bugs - sure. Not having a public test suite, not accepting public contributions, weakly typed columns and lack of concurrency has nothing to do with the language. They're governance decisions, that's it.

I see this situation trhough the prism of the innovator's dilemma: the incumbent is not willing to sacrifice a part of its market to evolve, so we need a new player to come and innovate.

I don't think the innovators dilemma quite applies in the open source world. Projects are tools, that's it. Preserving a project for the sake of preserving it isn't a good idea.

If people need to run a sqlite db in these exotic places, shedding it means someone else has to build their own tool now that can do it. Sqlite has decided that they care about that, so they support it, so they can't use rust. Seems sound.

Projects coming and going is a good thing in open source, not a bug.

This seems quite useful to me, especially for a larger org. If your dev's are working on LLM features, they'll need access to the OpenAI APIs. So are you just gonna give all of them a key? the same key?

No idea how this is solved at the moment, so seems like a smart step

You seem to read a lot into what I wrote, so let me phrase it differently.

These are ways I'd suggest to approach working with LLMs if you enjoy building software, and are trying to find out how it can fit into your workflow.

If this isnt you, these suggestions probably wont work.

I don't get any enjoyment from "building something without understanding".

That's not what I said. It's about your primary goal. Are you trying to learn technology xyz, and found a project so you can apply it vs you want a solution to your problem, and nothing exists, so you're building it.

What's really important is that wether you understand in the end what the LLM has written or not is 100% your decision.

You can be fully hands off, or you can be involved in every step.

and hate how much extra bullshit I didn't ask for they always add to the output.

I can recommend for that problem to make the "jumps" smaller, e.g. "Add a react component for the profile section, just put a placeholder for now" instead of "add a user profile".

With coding LLMs there's a bit of a hidden "zoom" functionality by doing that, which can help calibrating the speed/involvment/thinking you and the LLM does.

Three things I can suggest to try, having struggled with something similiar:

1. Look at it as a completely different discipline, dont consider it leverage for coding - it's it's own thing.

2. Try using it on something you just want to exist, not something you want to build or are interested in understanding.

3. Make the "jumps" smaller. Don't oneshot the project. Do the thinking yourself, and treat it as a junior programmer: "Let's now add react components for the profile section and mount them. Dont wire them up yet" instead of "Build the profile section". This also helps finding the right speed so that you can keep up with what's happening in the codebase