Live data from Hacker News

Second Life on GitHub

community.secondlife.com

41–50 of 126 posts

Re: Second Life on GitHub

#41
post #37

Second Life has always really interested me, seems like it's got a quite the meaningful heritage behind it. If they are looking to move into the full VR/AR/Metaverse space, I can see that wisdom/prior art coming in very handy.

https://www.engadget.com/2020-03-27-why-second-life-linden-l...

Re: Second Life on GitHub

#43

Earlier quoted context omitted.

The source is published to GitHub though, no? https://github.com/torvalds/linux It's an easy mistake to make, the code is there and there's nothing to suggest it's a mirror.

That said, every PR receives a bot comment indicating that the GH repo is a mirror and the user needs to submit a patch to LKML. And yet there are currently 312 open PRs on the repo. I've always wondered how people manage to know enough about the kernel to be able to contribute a PR to it, yet don't know the GH repo is a mirror and seemingly ignore the bot response and leave their PR opened.

I'm surprised with the massive number of auto-close-bots on GH (combined with the kernel's development culture) that they don't just auto-close them

I've also never understood why GH allows turning off issues, but not turning off PRs

Re: Second Life on GitHub

#44

That’s the project where Facebook‘s Metaverse forked from, right?

No, but when I saw where Meta's effort had got them it struck me they might have been better putting that development work towards modernizing an implementation of SL.

Re: Second Life on GitHub

#45
post #13

Earlier quoted context omitted.

No, open source means a specific thing. You're perhaps thinking of "source available", which means "you can read the source but have to comply to a bunch of stuff"

Not really. A lot of folks, including myself, don't subscribe to the OSI's definition of open-source because it just doesn't match the common usage. Open-source takes many forms, and source available is just one example.

Considering the term originated with them, it's fair to say they get to dictate what it means.

Re: Second Life on GitHub

#47
post #7

Earlier quoted context omitted.

The historical reason is https://github.com/torvalds/linux/pull/17#issuecomment-56546... Perhaps some of these issues have been fixed by now, but the Linux project has been going on just fine without GitHub (git was even invented for the Linux kernel project itself even before GitHub existed) so there doesn't seem to be any reason to switch even if all the mentioned problems were to be fixed

Some good old Torvalds roasting going on in that thread.

Ironically his rant about why authors should do the line-breaking

instead of your text renderer is really frustrating to

read because of all the seemingly random line breaks

throughout his comment.

Re: Second Life on GitHub

#49

I wonder why Meta didn't fork Second Life to use for their 3D world rather than re-invent the wheel and in the end build a bad product.

I don't know about the clients, but I've worked with a few ex-LL people and heard nobody really likes what the protocol became, and also lots of core parts of the LSL execution model they regret. Presumably Cory thought he could do better the second time around. (And maybe he did! I'm not sure Facebook's metaverse problems are technical ones...)

Re: Second Life on GitHub

#50
post #20

I don't know if things have changed but the last time I tried SL the client was so rough and awkward it seemed like an alpha. Even moving was laggy and annoying.

The biggest contributor of lag is not having things cached or being in a laggy region. On first connect, it used to be practice to go to a busy scene (a mall) and then go do something in real life for an hour or so while the viewer grabbed everything and cached it. Regions can be very low lag or amazingly laggy, depending on a bunch of things (particulary misbehaving scripts).

The causes of lag in Second Life are complicated, and are, at last, getting a lot of attention right now.

I've been working on that with a multi-threaded viewer in Rust.[1] After I started posting videos like that, there was a lot less "can't do" attitude from the Linden Lab devs. Now there's a "performance viewer" project out of Linden Lab, using many of the same techniques. Key concept: the backlog of assets to be loaded needs to be on a priority queue which gets reordered as the viewpoint moves. Otherwise you bottleneck loading stuff that you were previously near, not stuff near where you are now. There's a nice B-tree solution to this. Once you have that, everything in close-up is present and at high resolution.

Hardware helps. 100mb/s networking and putting the viewer cache on an SSD will help a lot.

There's still a big problem server side with the transient load when a new user enters a region. A mall or event with a lot of traffic can slow way down. The server devs are trying for more concurrency, but it's hard in an old single-thread 32-bit C++ program.

It's striking that, despite all the "metaverse" hype, there are very few people, even among game devs, talking about the nuts and bolts of making this stuff work. The metaverse conferences are mostly about branding, NFTs, and moderation/censorship.

[1] https://video.hardlimit.com/w/sFPkECUxRUSxbKXRkCmjJK

Post reply on HN