Look at the list of acceptable uses, and then look at the governing jurisdiction. Never have I seen so many people celebrate something as being "open source" without bothering to understand the implications of an agreement.
The open source label is a problem but not unique to DeepSeek. I think the biggest offenders are the big figures in AI who have conducted a marketing campaign repeatedly mislabeling closed source open weight models as open source. Yann LeCun, Andrew Ng, etc speak open washing lies almost everyday if you follow them. LeCun is especially corrupt since he’s just trying to paint Meta’s Llama positively by pretending it is open source.
But yes this sentence in the DeepSeek license is a huge problem:
> The courts located in the domicile of Hangzhou DeepSeek Artificial Intelligence Fundamental Technology Research Co., Ltd. shall have exclusive jurisdiction of any dispute arising out of this agreement.
Good luck when DeepSeek users try to navigate legal issues, like just yesterday when it was revealed that they’ve been leaking everyone’s conversations to the world.
Definitely not the only model doing this, but this one's a little more complicated. The GitHub repo for R1 just has an MIT license, and most people commenting on this across both tech and general news reports are missing this.
Everyone keeps on reporting that it's covered by the MIT license. I will acknowledge this model is more transparent and visible than proprietary alternatives, but the acceptable uses of the model it is derived from just make it unusable for many.
Even the technical people I'm talking to about this one keep on reporting that it is 100% open. None of these are.
If you are really good at what you do, and if you understand how real startups work, it becomes clear that location is the most irrelevant factor to success. I second Jason's views. If someone isn't going to work with you because you refuse to move to South End, Mountain View, or Brooklyn, then they can go fuck themselves. I travel to these places quite a bit though, and I love having a career that brings me to both coasts often.
The Midwest is the perfect place for a startup. Now that being said, Chicago has an entertaining startup scene. Entertaining in that I feel like they are trying too hard to be like San Franscisco.
Some background, this database stores data in a hierarchy data structure using a B+tree. I did some writing about this a while back, and talked to some of the developers. What's interesting about this database is that for specific use cases, it'll blow a plain old RDMBs out of the water in terms of performance because they've written a query optimizer and an execution engine that can take advantage of the proximity of related records.
JPA is fine, if and only if you've got a framework managing the entity manager lifecycle for you in a reasonable way.
In my opinion if I need an entire separate framework (or container) to manage it, I think its broken. I've switched to Ebean for Java ORM and am vastly happier now.
JPA also gets the award for the worst programmatic query building API I've ever seen. As a result it seems like the majority of people just use JPQL strings which is really annoying as its also SQL but not quite SQL.
Definitely write the Spring 3 blog post! I can't get deep into it right now, but I'd be interested in an overview, especially from someone who uses Rails as well.
You are joking right, "Try not to stuff your app with everything you can possibly think of." Like providing a admin interface on Refinery as well as authentication with Devise is "everything and the kitchen sink".
Have you used Refinery? I have and wouldn't base an app on it, or even use it again for a CMS - frankly you could build the same admin features better in Rails in a couple of days, and tailor them properly to your application. Refinery is not a good model of a rails app and is probably the main reason for his problems or perception that Rails is heavy - it was a mistake to try to base an app on it and most of his gripes seem centered on that - there's a lesson there and it's not about Rails.
Rails has become lighter with 3.x and will become lighter still with 4.x - they're dropping a lot of unnecessary stuff and trying to pare it down to the minimum - an admirable direction and quite the opposite to Java, which makes this article all the more baffling. Of course it's not the perfect framework and there are plenty of options, but the complaints of the article are histrionics.
The laundry list of possible technologies in the article is absurd - RefineryCMS, Devise, Omniauth, Carrierwave, Unicorn, Rack Rewrite, Fog, New Relic, Foreman, AMQP, and Honeybadger, Heroku.
You can get started with rails on a cheap VPS and serve your first few hundred thousand users with the following very simple stack: Apache, Ruby, Passenger, Rails. Setup is a few lines in your package manager of choice, writing the app is straightforward and requires none of the software above, maintenance is running aptitude update and bundle update now and then.
Out of the stack above, Devise is quite a nice authentication solution and is the only one I'd recommend, but it's easy to roll your own, as to the rest of his list, if you don't need it, don't bother using it, none of it is required.
"An admirable direction and quite the opposite of Java." What are you talking, specifics please? Is Java a framework with features comparable to Rails?
Why is the laundry list of technologies absurd, these are the technologies that I run a business on. I think what's absurd is the level of reaction in your comment. Rails people now have this defensive reaction, and I've noticed it in person as well.
It reminds me of the reaction of Java zealots in 2007. It really does. "Oh, really, you couldn't be serious, I mean it's absurd to think that Ruby...." It wasn't absurd to challenge, and neither is this challenge.
Firstly, apologies for the harsh tone and references in the 3rd person as I see from your other comments that you are the author of the article.
"An admirable direction and quite the opposite of Java." What are you talking, specifics please? Is Java a framework with features comparable to Rails?
I admit this was sloppy wording, however your article is called 'Rails, You Have Turned into Java.' :) I was comparing Rails 4 (removes lots of features/bloat), with Java Frameworks which do not have a reputation for slimming down... Of course I'm sure there are some minimal Java web frameworks out there too (sorry not familiar with many). Your article is somewhat provocative and not representative of the experience of many with Rails so I wouldn't be surprised if you encounter a defensive reaction to this sort of sentiment. That's to be expected, as was the reaction of those using Java frameworks to DHH's blowhard rhetoric when he started out with Rails.
Why is the laundry list of technologies absurd, these are the technologies that I run a business on.
They're absurd as a criticism of Rails because many of them are completely external to Rails, not required to run a website/app, and some of them are not the right choices IMHO. Rails does not require any of these components to run websites even at scale. Sure some of them might be useful, but none are essential or intrinsic to Rails.
Forgive me but I think the choice of RefineryCMS was a mistake, and if you back out of that mistake, you'd find Rails a lot more forgiving, a lot lighter, and a lot more suited to what you want to do if you're writing a large webapp with lots of components (or several interacting webapps). Problems with engines, subapps, conflicting routes etc are all based on this, and simply don't occur in most Rails apps. I've used it as a CMS for some clients and regret having done so in retrospect - it's not terrible standalone (also not great) but I can see how integrating it with an app would be a nightmare. You don't need to use meta-frameworks built on Rails to build an app, in fact I'd say it's a mistake, use a few discrete gems like devise, and just build what you want.
I am not joking. There is absolutely no reason to put an admin interface in an app.
Here is an example applicaion, let's call it Foo. It's a blogging tool:
* FooCore: This is an API exposing the data Foo that works with, and the ways to change that data. It has a Blog model, a Posting model and an Author model. It has endpoints like "GET /api/blogs", "PUT /api/blogs/:id/postings" and "GET /api/authors/:id" to create blogs and postings. It has no UI.
* FooApp: This is the user-facing frontend application. It serves the main site in HTML, JS, CSS and whatever other. It renders blogs from FooCore by calling is API. It has no logic other than presenting the UI and acting as an MVC controller and view (the M being the API). It calls the API both from its server app, as well from the browser via XMLHttpRequest.
* FooAdmin: This is the user-facing admin frontend app. It serves the "back office" admin UI for managing blogs and posts and users.
We now have a very elegant app where the division between the parts is crystal clear. The admin UI's requirements do not affect the public UI's requirements or vice versa. The underlying data model can't build up weird UI cruft because there is no UI to let sloppy devs screw it up with their laziness.
(Need a new UI -- say, you want to accept blog postings via email? Create a new app, FooEmailApp that handles only this interaction using the same API. Want to accept blog postings by fax? Create a new app, FooFaxApp. Neither frontends will have code that bogs down the other UIs. If you decide fax is dead, just delete the entire app.)
(And you can extend your own ecosystem of services organically. Need role-based permissions? Create an app for it, and wrap every HTTP verb with a check against the permission app.)
Anyway, the above app is not complete; you want login via Twitter, so we add Checkpoint into the mix. This happens:
1. When FooCore wants needs a user, it looks in its session cookie and determines which user it is.
2. If there is no user, we create a redirect to Checkpoint's /login/twitter. Checkpoint does the necessary OAuth interaction behind the scenes, stores the credentials in its store, update its own cookie, and redirects back to FooCore. (Remember, Checkpoint has no UI. It just redirects to Twitter, which displays the usual OAuth login/authorization dialog.)
3. FooCore can now use Checkpoint's cookie to determine who the logged-in user is, and it can ask Checkpoint for data such as the user's name and email. It can also create an internal User object that represents FooCore's own data about the user, such as blogs and postings.
The upshot: The app knows nothing about authentication. It outsources everything. It can focus on the important stuff.
This modular separation of concerns into separate apps sharpens your focus as a developer, and forces you to think about the data and the interactions that are necessary. Because of HTTP/REST's relative poverty, everything becomes a verb, and every verb must be designed separately.
Two other benefits: It forces you to think of reuse, since every feature becomes an opportunity to reuse a modular component. Secondly, it forces you to think of "presentation" and the divison between ugly internal state and public state, because every interface becomes much more exposed to the world; when an app becomes an API, you are subject to more scrutiny than if you were tucking the stuff away in some class somewhere in your app.
No, I'm not kidding. Back in 2006 we tried the old model of putting everything and kitchen sink (login/auth, normal UI, admin UI, promo site, email notifications, role-based permissions, statistics, visualizations, image upload etc.) into our apps. The model does not scale. The benefits of a "many small apps" model have been obvious even for relatively small applications.
I'm not defending anything. If anything I'm attacking? :-)
Every app that I need a user to access requires three requests to IT. Each application must go through a pre-approval process and a separate set of meetings to determine requirements.
That's not to mention that many applications have a view/edit distinction, requiring nearly the same page based on permissions. If you make the choice to split this page into two applications, your UI will have to be written twice rather than an if statement in the view logic. (Oh, and wait until the change request comes in..)
Maybe your system will work in small businesses and direct to customer apps. It's a non-starter in many other places.
> Every app that I need a user to access requires three requests to IT.
Then you have (voluntarily or as a result of placing yourself in such an organization) hobbled yourself and your ability to be an efficient developer.
If your escape route through a beaurocracy — in order to accomplishing your goals — is to compromise in your technical design, then you have my sympathy. That is a situation I could never tolerate personally. (Do you really use Ruby? Sounds like Java would be something an organization of this type would use.)
> That's not to mention that many applications have a view/edit distinction
That requirement is certainly not incompatible with the model.
No, please don't let this article affect your experience with Rails. Rails is awesome. It is. It's a great framework to learn and the problems that the author of this piece was discussing are really just a critique of his own faults. He made some awful decisions about architecture and framework and now he's paying the price.
