ye-olde-sysrq

prior to this, bandcamp was owned by Epic and lord only knows why they bought them or what their bigger plan was. i also have no idea how much they staffed up under epic rule since they went from a small business to being owned by the fortnite money man. Entirely possible it's something like:

1. bandcamp is a sustainable normal small-to-medium business growing healthily

2. Epic has tons of fortnitebux and is feuding with apple so they buy bandcamp as some kind of tangential play should they end up as a big alternative store on iOS. so they could have a music store offering (to compare to itunes? not that apple gives a crap about itunes anymore??) in addition to an app store?

3. the money music stops and everyone races for a seat. bandcamp is left hanging.

4. epic sells bandcamp to whoever just to get it off the books so they can focus on fortnite lootboxes

5. songtradr or whatever their name is tells the union to pound sand and cuts bandcamp down to a core team because they're planning to just gut the product and transition all these indie artists over to whatever platform they were running before. This is a music IP company. I don't think they want to handle B2C purchases or provide streaming music. They just wanted to buy a big pot of artists and IP to add to their collection.

Let's be real, fiat currencies are essentially backed by Uranium 235 and defense industry engineering capabilities. (both as it relates to turning the U235 into large amounts of energy in a small amount of time and producing other things like aircraft carriers)

funnily enough you CAN actually redeem the banknotes for these things but most people don't typically enjoy the experience

I know you're not posting in good faith but I do want to underline two things, in case anyone else is reading this who is similarly dismissive as OP:

- they did kill her

- she was clearly not a witch, given that they do not exist

And given the dearth of warlock or wizard trials, it is safe to say that this was clearly motivated by sexism - viewing women as far more likely to be agents of Satan, just as Eve handed Adam the apple.

I've posted something to this effect before but I'll post it again. I'm terrified someone is going to enshittify bandcamp.

I used to be a huge what fan, primarily for discovery. Never would've known I liked atmospheric black metal if not for them.

When they closed, I didn't really have enough "in" in the scene to know where other refugees went, so I just shopped around for anywhere else that would let me get "real" (in the what sense of real - decent encodes from raw source material that have the full spectrum and aren't just FLAC encodes of "high quality" mp3's). I don't pretend to be able to hear the difference, but I like it for archival purposes. I have plexamp transcode the audio anyway when I'm on mobile.

Turns out most people don't give a shit so most places don't offer flacs. Except bandcamp. Plus they pay artists fairly, which ended up being as important to me as the flacs as I came to support indie bands for whom selling on bandcamp was a huge lift. I like seeing CDs literally come from residential addresses in Sweden. I like supporting the random 1 dude making awesome metal out of his basement.

VC can be a great way to break into markets that just have inherently large moats or barriers to entry. Stripe is an example: you can code all you like but you literally can't move money without going through a ton of very annoying (to devs, anyway) footwork to get cozy with the existing financial institutions. The connections your VCs give you can matter as much as the money.

They can also literally kill your company. VCs have a very specific strategy: they give some money to 1000 companies knowing that 990 of them will return 0% in the hopes that of the remaining ten, 9 of them return %X000 and one returns %X0000. Given this, they are going to have very little interest in finding a company that will return even "good" results. They're going to push you to shoot for huge growth or die trying. And given the choice between "grow modestly and safely" and "grow faster but risk exploding" they will push you to pick the latter, because in their business model they can't even count low enough to measure returns that are just 10x.

KSP1 was made by a bunch of scrappy lovable indie devs making their first game (iirc Squad's team was a marketing company prior to this?) in a LCOL area funded by dreams and whatever $10 early access sales they made on steam, with no-one to tell them what to do.

KSP2 is made by TTWO, who is a publicly traded AAA studio of notable fame and decades of legacy and domain expertise.

If Squad sold KSP1's IP to TTWO and then went and made "KSP2" under a new name with their squad-sale money, that would be a different story. But even with that goodwill, I would still not be believing in the current KSP2 ever being a success story.

OpenOffice is a zombie living on the old name alone. LibreOffice is the "new" (it's like over a decade old i think) current one and e.g. ships preinstalled on big ubuntu images, for instance.

OSRS also moved to oldschool.runescape.wiki and AIUI jagex pays for their hosting and provides some kind of content access to make updating/syncing easier.

Plus they have RuneLite cooperating with crowdsourcing things like droptables and drop rates. (And of course mods often will outright tell them what certain droprates are or how they function).

KSP2 isn't an enshittification play, imo. It's literally just bad project management.

I'll list their sins from my armchair:

- remaking a beloved, established game that has a prodigious base of features and extremely extensive modding support. you have a HUGE hill to climb just to get to your "MVP" - you have to supplant the existing game plus its modding community, and this is already a niche audience of ["people who find orbital mechanics as a primary gameplay loop to be fun"]. They were always going to need to really fucking knock it out of the park on their first at-bat to make this work.

- doing so on a short time-frame

- trying to be all artsy about it too. not that that's a bad thing, but it does position you to take your time rather than going fast. and like I said, they already had a steep hill to climb.

- standard-issue development hell. it happens.

- special-issue development hell where TTWO did some fucky-wucky stuff where they hired away a ton of the staff from the studio they were contracting with, cancelled the contract, and brought it all in-house with the poached team. Hardly an encouraging sign.

- with all the delays adding up, I suspect they were given the ultimatum to either ship their current state into EA and start recouping money, or get scuttled. People have allegedly looked into the code and found extensive additional systems that were basically hastily commented or hacked out so they could ship some vaguely-functional core.

I was really, really looking forward to KSP2. KSP1 but with good graphics, a non-unity engine (it was always a miracle that squad had gotten such good large-scale physics out of unity), and promises of official support for non-kerbin bases and interstellar travel? Yes please, sign me up!

But honestly, my mental model for how this would be successful was "they'll reimplement the existing base game in a new engine. big task but doable for TTWO's money, it's not indie anymore, and they obviously already understand the product. Then, with the base game ported, people will be willing to buy in EA because they see the promise of 'KSP but more!!!'". And that last bit was going to be critical, they'd need people bought-in if they wanted TTWO to keep funding them / them keep funding themselves.

So when they launched this scrap heap into EA, I knew it was doomed. And look at the, what 8ish months between then and now? They've released a few quaint patches that ignored all the huge issues and done basically nothing else.

I fully expect them to now slowly wind the EA down with a skeleton crew and people will just forget it to an ignoble death. I mean, TTWO can hardly be keen on continuing to pour development funding into this EA, right?

Look at the reviews for KSP2. This is not even one of the larger problems with the game. They released into EA with terrible, nearly unplayable performance... on an RTX 4090! a $1600-2000 GPU that at the time was difficult to obtain even if you had the cash.

On the days you don't commute, you could plug your foreman grill into a wall socket and sit in a chair staring at the wall for the same length of time to simulate the same effect.

>I didn't say it schedules platform threads, but JVM has many other performance issues with its GC/object identity/lock monitoring model, which makes it harder choice for ultra-high performance apps, so virtual thread scheduling may improve your app perf by 5%, where other 95% stuck in other bottlenecks

Switching from async to virtual threads is typically not an improvement to performance in well-factored async code. The primary benefit is a clearer programming model that's significantly easier to get right and less code to implement while still the same performance.

>Also, you can avoid all switching with 20 years old ExecutorService, where you have exactly the same m:n mapping between tasks and machine threads.

You misunderstand the point of virtual threads. There is no need to pool them, as (most) executor service implementations do. And the whole point is that you no longer need to avoid blocking them, which pretty much every currently-existing solution will be doing. There's 0 benefit to switching without also updating your code to take advantage of the new paradigm.

>because virtual threads are not supported in ecosystem well, and it will take another 10 years for it to catch up, before that most API/libs will use old concepts and you take large risks of fragmentation by introducing virtual threads to your app.

What risks? The whole point of virtual threads vs async/await is that they don't color functions in the same way that async does.

Also, pretty much every notable framework already has support for virtual threads (Spring, jetty, helidon, and many others). The API has been the same for a couple years at this point.

>Also, my belief is that JVM itself adds lots of overhead.

The JVM has ~nothing to do with the scheduling of platform threads

>and there any benchmarks saying it is couple hundred threads, and not 100k threads?..

It depends greatly on your hardware

>couple hundred is about thread per core on modern CPUs..

It depends on the hardware, of course

Overall, yes, you could probably run a lot of concurrent processes on a c7i.48xlarge in 2023. But why would you want to do that when, if you used virtual threads (or async), you could do the same work on an c7i.large? That's the whole point of this. There's no reason to waste CPU and memory on kernel context switching overhead.

I think the best argument you could make to say steam is a monopoly is to say that their plan is roughly:

1. Make a platform gamers love to use so much that they will still use it even if other stores are literally giving the games away for free

2. Build a brand that your target audience recognizes worldwide and trusts with their entire game collection.

3. "Exploit" the fact that your audience loves your product and brand so fanatically that you can charge the same amount on an open platform (PC/windows/linux) that other app stores need walled gardens (apple/android - literal lockin and literal near-monopolies/duopoly) to be able to charge.

I really struggle to find a way to frame Valve as the bad guy here. It's PC. There's literally nothing stopping you from just installing as many app stores / launcher platforms as you want. And it's not all-or-nothing - people DO use multiple launchers/stores. What gamer doesn't begrudgingly have Origin and at least one of EGS or the Blizzard/battlenet launcher installed alongside steam? And yet people still use steam, and spend the most money there by far.

Excellent! With virtual threads, all the blocking code I wrote is efficient now :)

Less-joking: I'm so excited for this to start getting adoption. For a pre-release/preview feature, Loom already has SO much traction, with most major frameworks already having support for running app/user code on virtual threads and one notable project (Helidon Nima) replacing netty with their own solution based on blocking IO and virtual threads. Now I want to see the community run with it.

I've always thought async IO was just plain gross.

Python's implementation is so yucky that after using it for one project I decided that I'd rather DIY it with multiprocessing than use async again. (I don't have any more constructive feedback than that, my apologies, it was a while ago so I don't remember the specifics but what has lasted is the sour taste of the sum of all the problems we had with it - perhaps notably that only about 2 people on my dev team of 5 actually understood the async paradigm).

netty did it fine. I've built multiple projects on top of netty and it's fine. I like event-based-async more than async-await-based-async. But it's still a headache and notably I really rather missed the kinds of guarantees you can get (in blocking code) by wrapping the block in try-catch-finally (to e.g. guarantee resources get freed or that two counters, say a requests-in and a requests-out, are guaranteed to match up).

But dang am I excited to not do that anymore. I have one specific project that I'm planning to port from async to blocking+virtualthreads that I expect to greatly simplify the code. It has a lot of requests it makes back and forth (it has to manually resolve DNS queries among other things) so there's good chunks of 50-200 ms where I have to either yield (and has gross async code that yields and resumes all the heck over the place) or block the thread for human-noticeable chunks of time (also very gross of course!).