It’s not illegal to tell the truth, but it might open them up for lawsuits, so there’s little to no upside for the company and an unknown possible downside, so no one does it.
For example, an open source "community edition" could be treated as a freemium product and an OSS marketing could adapt a PLG playbook to help identify and nurture those who are good candidates for the "enterprise edition". Also, you have a community. They're in Slack or Discord, making pull requests, filing Github issues. You should be able to adapt the CLG playbook to help identify and nurture future customers from within the community.
In practice, I have never once seen this work. Arguably Canonical and Red Hat are the two best examples of CLG/OSS business models, and both of them have uneasy relationships with the greater Open Source community. Canonical is seen and treated as the Microsoft of the Linux world; their promises aren't worth the bits they're delivered on, and they'll sacrifice anything for money. Red Hat is cautiously embraced by the community despite being much more benevolent, usually because their aligned interests don't always consider power users or extensible architecture. They move fast, break things, and forgot to ask your opinion.
Neither Canonical or Red Hat are particularly well-loved by the greater Linux community, for wildly different reasons. At the core of their failure is the illusion of a successful Open Core business (or "freemium" as you put it). The delusional business obsession over ruining the free version of software is exactly why Open Source is so successful where businesses fail. You should research why Linux and BSD won over the alternatives from AT&T and IBM; they didn't have a premium or pro version, they were the pro version. The creation story of GPL, Free Software and Linux as a whole is a warning about how business models collapse when they molest functionality for money.
I see your point, but I have to believe there is a commercial path that can be mindfully pursued. You can build hosted tools, or add commercial value with an "app" model where there is a clear division between the platform, which is free, and the apps, which can be paid or not.
I only used Bird once and have always thought they were not a great way of getting around. That said this is a real bummer to me. If commuting and mobility were much much easier the world would look a lot different for the better (in my opinion).
I hope there are more attempts to make getting around and getting to places you need and want to go easier.
I moved from ruby 2.7 to 3.2 for a rails app and was hopeful that it would lead to large speedups like shopify claims it did for them, but was bummed to find it did basically nothing. Anyone else running a large rails app have a similar or different experience?
From the blog post, it sounded like their benchmark relied heavily on a gem with a C extension (nokogiri). It's hard to imagine a performance improvement on code that YJIT has no control over.
Yes, we ended up replacing Nokogiri by Nokolexbor, our own port of lexbor parser with like almost full compatibility with Nokogiri APIs while being around 5x faster: https://github.com/serpapi/nokolexbor
Very interesting blog post! My best guess as to how shopify is able to achieve such large increases in speed is they have a lot more actual ruby code than most codebases (https://shopify.engineering/ruby-yjit-is-production-ready).
1. How did you evaluate performance? Did you let it run for a while in production? YJIT's improvements will be most visible over time.
2. If your web app's response times are dominated by database queries, then YJIT will do nothing for you. Even re-writing your app in assembly language won't help. All languages are equally fast when sitting around waiting for the database to response. ;-)
That said, if your response times are dominated by db query wait times, maybe the async queries in Rails 7.x can offer you some very nice improvements. However, you will probably need to restructure (not rewrite, exactly, but restructure) your code to take advantage. Not the whole app, just the hot spots.
We saw memory go up when moving from 3.1 to 3.2, but we also removed compiling Ruby with jemalloc and used the defaults. We have seen performance increase by about 10% for our web applications. Our forking background processes run about the same. YJIT appears to perform for repeated requests – ie first run will not expose any benefit, ie your tests won't run faster.
[edit, the memory increase was small just a few percent IRC]
Sorry to hear you had that experience we saw 30% speedup moving from 2.6 to 3.2 and the 95th in many cases was 40%... Did you happen to enable yjit and if so which app server are you running?
I benchmarked a good sized app (ran a black-box QA suite multiple times) while monitoring performance and req/response times with Prometheus/Grafana with Ruby 3.2.
With YJIT enabled memory usage ballooned and performance dipped below non-YJIT Ruby 3.2, IIRC the difference was a good 10% degradation. Granted, it's an API only service so no HTML is being generated, only JSON and that could be the culprit.
Suffice it to say, we didn't enable YJIT for 3.2. Maybe 3.3 is indeed different, but both the faster and less memory claims are really suspicious to me.
Interesting. Do you think html generation is one of the things that makes the numbers look so good for 3.2 YJIT? We run a mostly json api only app. I think json serialization is notoriously slow in ruby so I was hoping yjit would speed it up.
I'm not so sure. Whether this article is good or not is a moot point. Hasbro is publicly traded so there is verifiable information about the company available. As others have pointed out, we can see them rapidly selling off assets and IP and cutting staff. I'm not a professional analyst, but surely one could substantiate an argument for or against this decision.
Edit: Also, this decision isn't a single data point. We can look at the track record and business trajectory to make an informed decision. I am not particularly well informed about Hasbro, but based on historical stock price, industry trends and comments here, it really seems like they are fucking up
MTG and D&D both grew by like 20% last year. If they’re fucking up with managing them it’s not showing in the numbers yet.
Also it would be hard to know from numbers anyway. Maybe if they managed it better it would be up 30% Neither product has significant competition so you couldn’t even really guess by comparing to an overall market.
Broader Hasbro numbers might be a little more comparable (there is an overall toy and games industry) but still tough.
It’s often hard to tell from the numbers that a company is being ruined until it is too late.
Yeah, MTG twitter is really mad about it, but people at WoTC often have fairly narrow skillsets, so I would not be surprised that at some point they want to rebalance the set of skills that they have access to to do something different.
I found out they fired a community manager... and I had no idea who that person was without a bunch of googling, which tells you a bit about how effective that spending was for wotc.
Not to say that I think wotc corporate is at all infallible, they are clearly not very good at doing anything besides designing the cards themselves, and even then, they have largely inherited a very good game rather than really doing anything amazing.
Wotc could really use a shake up that raises the standards of what they produce to the level of eg riot games, but that's unlikely to happen any time soon.
I don’t. Further it’s common for all stockholders to be asked to vote on decisions with 1 vote per share. While it’s true most people have only a trivial number of shares and are therefore largely irrelevant they also don’t have access to non public information.
Most Boards of Directors contain a bunch of representatives of the largest institutional holders and some members hand picked by the CEO.
In Hasbro's case, the Chair of the Board is listed as an employee of the company and was their interim CEO. The rest of board follows what you would expect.
Simple. Did the management meet the various internal targets outlined by the board.. Those could be anything from profitability, to total cost structure, to anything really
Good and bad itself depends on the perspective. Good for Hasbro? Can be argued I guess, depends also on its current economic situation and a lot of things other people may indeed not have the best knowledge about. Good for the players and fans of DnD? Good for those who actually work in the company and got laid off, or the remaining staff there? Almost surely not. This decision is not taken on their behalf and does not serve them in any way. And considering the popularity of DnD there is no surprise that the issue is going to be approached from an employee or player perspective rather than an investor or manager one.
This is really cool. I wonder how long it will be till we have GPT-4 quality models that run locally (if we ever will). Would open up a lot of possibilities.
We aren't quite there yet, but the last year has been an incredibly exciting time for the open source LLM community. If your computer is decently powerful, you might be really surprised by what's already possible. LM Studio on Apple Silicon supports GGUF quants on GPU out the box.
Thanks! We've heard something similar - many Python tools in financial services. I think they build tools on R too. We should probably try to reach out to people in this industry to learn about the kinds of apps they build and whether their home grown tools are missing something we can ship
I am never able to find any good example projects that use it with react and aren't just a toy which is bit of a bummer, because I think that would be a great stack.
Django makes it dead easy to take a URL route and return HTML. Obviously there's some fussing to add a script tag that points at your JavaScript file, but what exactly are you looking for beyond that? I'm not exactly sure what you're looking for beyond that (as someone who ~only writes Django+React); that's kind of it. There's no big magic, it responds to http requests with data.
For a full-on SPA (which I'm assuming is what they mean by "and aren't just a toy"), you'd also need at least frontend routing and an example how to make that play nice with Django URL routes, probably a data store (which at this point I think is just going to be redux), and most of the Django views would return JSON instead of HTML.
None of those concerns have anything to do with Django: just have Django return your HTML for all views that don't return JSON (which is to say, set the 404 to your HTML).
There's no need to use a data store like Redux. Any routing framework will work. Any react framework will work. Django has no impact on how you structure your SPA in any way! If you can build a SPA, making it work with Django is literally just "return HTML with a script tag". There's no "use React with Django" tutorials because that's literally it. If you can return HTML from a Django view, you've got everything you need for whatever React project you intend to build.
