Btw, they had 3D pelican-on-the-bicycle easter egg in one of the promo videos: https://youtu.be/bOC3DisEOfg?t=117 so I'm pretty sure that they spent some small amount of resources to train the model to produce good svg version as well. :D
That’s my point. I think if they are trying to benchmax creating a pelican riding on a bicycle SVG. In that process, they’re probably making SVG creation better and easier as a whole, even though they might just be training for that one specific SVG.
The 3D version is interesting, because it's more detailed which means more things to get wrong. The mudguards are symmetrical for some reason which you would never see in real life, and there are three brake cables but no brakes!
I also think there's an extra level that I would hope an AI would nail which maybe an amateur artist would also fail at, such as thinking about what position a pelican would actually ride a bike in (maybe angling the beak down for aerodynamics etc.), but we are far away from this.
When you see how good the output of the Luna model without reasoning is compared to SotA just a year and a half ago, it's pretty clear that it's been trained on explicitly.
I don't see how this is proof, and not just that the model got the better. You're comparing models a year and a half apart; this is a lifetime in LLM development.
It's a lifetime on things that are explicitly being trained on! But small models like Luna didn't magically become more powerful than SotA models on stuff that they weren't explicitly trained on with a dedicated RL-pipeline.
That'd be too restrictive, but to get improvement in a particular domain you definitely need to train specifically for it. Just cramming more random internet text in a bigger model has stopped being a effective way of scaling since at least mid 2023.
No, you don't. There have been technological advances beyond just "more random Internet text", and they lead to more powerful models with more refined emergent behaviours.
I'm considering myself as quite enthusiastic about integrating "AI" into SWE processes. HOWEVER I'm really tired of reading AI-generated or heavily post-processed blogs.
So I would really appreciate if you can share with me some blogs (mostly about engineering but other topics are fine I guess) where authors declare that they prefer not to use "AI" for writing.
I guess it's fine to use some tools to fix grammar lightly or cherry-pick some suggested improvements.
But I __really__ want to "hear" voices and ideas of real people, not from Internet-averaged generative algorithms.
Been playing around Bluefin recently [1]. Which is based on Fedora Silverblue [2]. These are atomic OSes which seems very nice and innovative indeed.
I'm Debian user for 15+ years. But stable version is too old and testing for some reasons breaking quite often (last year I wasted more time on fixing Debian Testing after updates than my friend which uses Arch -_-). Now I'm looking for good alternatives and I think I will stick with containers rabbit hole. :)
Thanks @jcastro [3] and contributers for fantastic work! <3
Would be nice to see alternative documents for similar topics (e.g. something like OWASP Cheatsheet but from more practical point of view).
With all the respect, I'm a bit skeptical about this document for such reasons:
- Name is quite pompous. It's a very good marketing trick: calling some document like if it was written by group of researchers from a Copenhagen university. :)
Yes, Lucia is a relatively popular library but it doesn't mean that it is promoting best practices and that its author should be considered an authority in such important field unless opposite is proven.
- I don't like some aspects of Lucia library design: when user token is almost expired - instead of generating new security token Lucia suggesting just to extend life of existing one. I see it as a very insecure behavior: token lives forever and can be abused forever. This violates one of the security best practices of limited token lifetime.
But both Lucia and "Copenhagen Book" encourages this practice [1]:
> when user token is almost expired - instead of generating new security token Lucia suggesting just to extend life of existing one
The link you posted shows code to extend the session, which is common practice (it's called rolling session), not to "extend" the token's life (which should be impossible, a token needs to be immutable in the first place, which is why refreshing a token gives you a new token instead of mutating the original).
If you destroyed a token and send a reply to the client with a new token, but the client already sent you a new request with old token, that request will be denied.
I don't think there's any difference between extending the existing session and creating a new one in Lucia's context.
In the first scenario, the attacker steals the token and uses it forever. In the second, the attacker steals the token and they'll get a fresh one near its expiry. They can still impersonate the user forever. The user might notice something when they get kicked out (because the attacker renewed the token, rendering the old one invalid) but it's unlikely. For good UX, you need a grace period anyway, otherwise legitimate users can have problems with parallel requests (request one causes a token refresh, request two gets rejected because it was initiated before the first one was completed).
You can use a second token (a refresh token) but it only pushes the risk to the second token. Now we need to worry about the second token being stolen and abused forever.
Refresh tokens are useful for not having to hit the database on every request though: Typically, the short lived session token can be validated without hitting the db (e.g. it's a signed JWT). But it means that you can't invalidate it when stolen, it will be valid until expiry time so the expiry time has to be short to limit the damage. For the refresh token, on the other hand, you do hit the db. Using a second token doesn't add any security, hitting the db does, because the refresh token can be invalidated (by deleting it from the db).
Lucia always hits the db (at least in their examples), so you can invalidate tokens anytime. To mitigate risks, you can allow the user to see and terminate their active sessions (preferably with time, location, and device info: "Logged in 12 AM yesterday from an iPhone in Copenhagen"). You could also notify the user when someone logs in from a new location or device.
That's about all you can do. There's simply no fully secure way of implementing long-lived sessions.
I think you’re reading into the name a little, haha. I’m interested in your alternative method for session token replacement, though! I think you make a good point, but I’m not an expert by any means.
Usually on low-risk projects where I don't want to bother myself with handling token pairs (or where it's impossible) I have similar simplified approach but regenerating token:
- Session token has two timepoints: validUntil and renewableUntil.
- If now > validUntil && now < renewableUntil - I'm regenerating session token.
This way user is not logged out periodically but session token is not staying the same for 5 years.
I agree with this. I think all tokens should expire. If you accidentally zip up an auth token in an application's config directory it is nice if it becomes inert after a while. If you extend the token it could live forever.
For my application the token is valid for a few months, but we will automatically issue you a new one when you make requests. So the old token will expire eventually. But the client will update the token automatically making your "session" indefinite.
So when you throw away a drive that you had sitting in the junk drawer for a year that token is inert. Even if you are using a cloned machine that is still extending the same "session".
Thanks! Very promising. Another thing that surprised me is low latency and usability: I signed up, clicked "New Project" and it showed me editor. Like INSTANTLY.
I hope it'll be more or less on the same level later. It feels like magic especially after extremely slow and laggy Figma (seriously, modern 3D games with tons of polygons are working much smoother than web-based tool for drawing colorful rectangles).
reply