Hacker Newsnew | past | comments | ask | show | jobs | submit | raro11's commentslogin

I assume he labels the bag and never has the need to remove it (you just take a new bag). Edit: Nope I was wrong. Bad bad bad

> $16.49/month server [...] hetzner CCX13

That server is now $51.09 for those wondering See https://news.ycombinator.com/item?id=48540844


Thank you


They'll be forced to embed alternative stores in the PlayStation.

I won't wait for it though. After 28 years of always having a Sony at home, it ends here for me at the age of 35.


> They'll be forced to embed alternative stores in the PlayStation.

Steam Summer sales on a PlayStation? I want that today.

If this decision somehow ends up with Steam and Proton for PlayStation, it will be well worth it. Gaben, please get some lawyers to write to the EU posthaste, and start porting Proton to iOS & PlayStation


Technically already possible (and works surprisingly well!) if you have a PS5 with old enough firmware.

https://www.youtube.com/watch?v=UhnLdFYR2-s


What a horrible page to navigate


On mobile, It’s hijacking my scroll in such a way that I literally cannot move further down the page. And “reader mode” is only showing me the first paragraph or so.

I’ll have to try again later on desktop. The content looks interesting but it’s literally impossible to read. I cannot get past the section that introduces Ernst and Young.


On desktop it keeps adding forced pauses to scrolling, of varying sizes, and you need to scroll down a between 1 and 10 pages worth to begin scrolling again.

It might "work" just fine on mobile (or not) but you may have stopped trying before reaching the point of re-scrolling, because it's insane.


I eventually managed to get far enough into the article that I thought I saw the main stat - the stat that 26% of the citations were hallucinated. Then the scroll threw me back to the top again and I gave up entirely on reading from my phone.

Coming back later on desktop, I see that the percentage keeps climbing the further you manage to make it down the page. The real stat is 60% of the citations were hallucinated.


I recommend just clicking and dragging the actual scrollbar on desktop for this one. Wild


Feels like my scroll is hallucinating


This is a whole 'nother level of user hostility, never before have I seen anything like it.


My iPhone automatically enabled reader mode - I disabled it to see what you are referring to and I agree…


Non-linear feedback with literal stalls, yikes.

Some people should not be allowed to make a website.


I'm usually annoyed by people complaining about scroll hijacking on HN but this site was a new level of bad.


I've stopped reading because of it. I can't scroll. Was this thing vibe-coded? Funny they are picking on EY for not reading their reports but it looks like they didn't test their website.


They put a lot of effort in to make it that bad!


Very difficult to use on mobile.


Tried it. Docker wasn't preinstalled so asked Claude to do it and make sure it's running (supervisord or the likes isn't preinstalled).

It neatly did so and "registered" it as a sprite service. Then I exited my session, waiting for the sprite to go idle, but I don't think it ever does.. Still have it active. Don't know how to idle it.

Can't tell for sure if this means I'm losing credits as there is no billing usage shown anywhere.

Also waiting for the moment where I can launch a sprite from another's checkpoint.


We had a bug where some sprites would fail to properly suspend while entering their suspended state. You're not eating into credits so no worries there. We've been rolling out a fix across the fleet today so you should be seeing proper status soon.


This is great news! If we upgraded our sprite already how long should it take to suspend? I noticed the upgrade earlier and installed it but my sprite is still running.


ahh finally success—a fresh sprite goes to sleep as it should. unfortunately the original one i created doesn't, so I guess I'm going to have to kill that one off.


Ok so, "running" sprite status has had some cache consistency issues. You're not being charged for idle sprites, but they may show as "running" even when you're not using them. The UX has improved, and it reliably shows what you expect. Some of the existing sprites need an environment upgrade, but you'll see those improve over the next few days.


There's no way to stop sprites from the CLI.

Supposedly they auto-stop when inactive.

But I've tried multiple times and they don't stop, and it's not just Docker that prevents them from stopping.

I created a new sprite and installed ffmpeg. Then exited. Next day I run `sprite ls` and it's been running continuously for 23 hours.

No way to tell if I'm being billed for it or not.

And the per-hour pricing is extremely expensive.

So for now it's `sprite destroy -s spritename`.

Maybe I'll check it out again in a few months after the fly team has iterated on this a few times.


Sprites are active when:

* They're servicing an incoming HTTP request.

* You're interacting with a console.

They're hair-trigger inactive otherwise. They don't bill CPU unless they're active. The idea is that there isn't really any uncertainty about when it's running; when you stop interacting with it it stops metering.

This is a new shape for a cloud computing thingy and there'll be snags this week with it, but we don't make our money by billing people for stuff they don't want. We've always gone out of our way not to nickel-and-dime casual users and we're trying hard to find new ways to lean into that here.

(Destroying a Sprite you're done with is a perfectly reasonable move; they're disposable.)


No console activity, no HTTP requests, but it doesn't stop.

Can't find any place in CLI or web UI to see how many minutes are charged for CPU, memory, storage.

    $ sprite ls
    Sprites in organization <redacted>:

    ┌────┬───────┬────────┐
    │NAME│STATUS │CREATED │
    ├────┼───────┼────────┤
    │duh │running│ 23h ago│
    └────┴───────┴────────┘

    Total: 1 sprite(s)


My read of his response is that, even though the sprite is in a running state, that doesn’t mean it’s in a billable state given you aren’t connected; that’s not said explicitly, and I’m making an inference, and so it would be helpful if you let us know if you are billed for these hours.


> Sprites are active when: * They're servicing an incoming HTTP request. * You're interacting with a console.

They are advocated as Linux machines. How about daemons then, or cron jobs? What semantics can we expect from them?


I think the idling feature still needs some work. I created one over the weekend that hasn't idled once, and I've run several tests with sprites that have nothing in them—just `sprite create` and log out, just to see what happens (which unfortunately is nothing, left alone it keeps on running as well.)

I love the idea and most of the execution, I've really enjoyed getting my first sprite configured just the way I want it. It just needs the idling feature to work as advertised before I think I can use it as cost-effectively as it promises.


What does "when you stop interacting with it" mean? Closing all TCP connections? When CPU usage drops to below some threshold?


There needs to be a way to see how much it is being used then and not simply the life of the Sprite.


You can. There’s a usage dashboard


Where is it?


For what it's worth, CPU pricing is based on CPU util. A sprite sitting idle CPU costs almost nothing, even when "active".


So is it similar to railway in this context?


Yeah. My sprites never idled inspite of having nothing running in them and had to be destroyed. Ideally there should be two settings

1. A timeout after the last console session is exited 2. Force idle using the CLI


Just tried it again. Creation took a very long time, then errored.

    $ sprite version
    sprite version v0.0.1-rc30

    $ sprite create quk

     Error creating sprite: failed to create sprite: Post "https://api.sprites.dev/v1/sprites": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

But despite the error, the sprite was apparently created, and it runs continuously.

    $ sprite ls
    Sprites in organization <redacted>:

    ┌────┬───────┬────────┐
    │NAME│STATUS │CREATED │
    ├────┼───────┼────────┤
    │quk │running│14m ago │
    └────┴───────┴────────┘

    Total: 1 sprite(s)


Get a console in your sprite. Run “screen”. Run a loop in there : while date; do sleep 1; done. Detach screen and exit the session. Wait a few minutes and go back into the sprite. Reattach screen. You’ll see a gap in the timestamps.

They do suspend even when they say they are “running”.


Just use container-os as your runtime image: https://hub.docker.com/r/miget/container-os

and you should be good


Could you explain more about how this helps and how one might use a different runtime image on Sprites?


I don't think you can choose the runtime image on Sprites, not sure what they are referring to here.


Gitlab

SourceGraph


Cockroach


prisma


Damn that's cool! Nice work


I was about to explore sqlite/litestream but didn't because we have two services (cron and admin-web) that write to the database. Regular www-web services are read-only.

We only have one instance of cron and admin-web. We could make sure they are always on the same host. So reading this made me happy.

Do you have a blog/gist where I can find/steal some of your work?


I do not - however, I keep meaning to write up a generic version of our CDK code for sharing/reuse. I'll make a post here when I do.


Thank you



Sounds like @dang should merge, those are exact duplicates


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: