I would say it's opposite. No one contributes to open source and the developers have to make money on the side to work on the project (i.e., do consulting/tech support/etc). Or more often companies with money come to fork an open source project from the developer, and continue pretending it's their own now.
> I would say it's opposite. No one contributes to open source and the developers have to make money on the side to work on the project
You missed the important part of his sentence:
> All those open source copycat projects, using open source to get exposure then switching
The original open source here was Cassandra. Scylla exists to pick off that market share. They launch with a free license, pull customers, then swap license. The actual adoption of Scylla would have been a fraction had it been released under this license to start, which everyone understands.
> Or more often companies with money come to fork an open source project from the developer, and continue pretending it's their own now
It had already been AGPL, so it's not like they're protecting against competition. They already had a license that avoided the forking problem. This isn't protection against AWS (keyspaces likely has more OSS cassandra code in the protocol tier than it has Scylla code, if it has either). It's protection against free consumption.
Copycat is a bit of a stretch here imho, considering it's in different language, and even the general architecture. But I agree they are very compatible on the protocol level, which they used as an advantage as people don't need to rewrite their code when they migrate.
> Copycat is a bit of a stretch here imho, considering it's in different language, and even the general architecture. But I agree they are very compatible on the protocol level, which they used as an advantage as people don't need to rewrite their code when they migrate
It's not a stretch. They literally copied the java code and re-implemented it class-by-class with Seastar/c++.
Yes, I understand they looked at the source and re-implemented a bunch of it when they started 10 years ago. But in the result it's a very different code. I mean, it's 45K commits so I believe they implemented things by themselves in majority of those commits. I guess we just have different understanding of the copycat term.
Youre not far off, just use your original sentence and acknowledge that Scylla isn’t the OSS here, its the company that came in, forked a volunteer driven project, and tried to pretend its theirs:
> Or more often companies with money come to fork an open source project from the developer, and continue pretending it's their own now.
I like Scylla and we use it, so I wish them well. But what I don't understand with this announcement is how it supposed to work if they don't publish the pricing model. Just "contact us to get a quote". How people are supposed to make advance plans without clear pricing?
I don't think that Java serialization is designed for such a small object with just two fields. It's designed for large and complex objects. Obviously it would be slower and much larger in size that a columnar implementation designed and heavily optimized for this scenarios. It's not a fair comparison and too far from a real use case.
Try with nested objects and at least a dozen of fields across this hierarchy. And different structure for each row. It's still not a use case for Java serialization, but at least closer to what a real code would do.
Same for Protobuf, I guess. Also the JSON serialization plays the same role more or less.
Maybe something like Avro Data Files is better for a comparison with columnar formats.
I've got an education in Russia and I don't recall such practice. Maybe some of professor do that, but that's more like an exception.
Most others test your way of thinking. They even allow you to use text books when preparing the answer, though usually they allows only books they bring to the exam.
You definitely could. But I guess it should be secure by default. Even if you didn't implement any check on the server.
Because people are lazy or they may forget to implement the security checks, or simply be unaware about them.
Ex., when you hacked up a super simple script to display a number of today's users of your startup to display on the big screen in your office. You would probably want something as simple as possible. This page is just 3-5 lines of code. Maybe one-liner even. No authorization or other security, as it's for the office intranet.
Without CORS any website that is visited by people from your office could fetch that number on screen.
Even with CORS, DNS rebinding may be a concern here. I think HTTPS may prevent that as the cert wouldn't contain the original site but in this setup where you want "no other security" it would probably work.
As I see from the public stats, it's about the rate people get for a car loan in US. And a car could easily be above $70K. From personal experience, when I had no credit history (i.e., the similar situation) I was charged twice of that rate. So it doesn't seem to be a lot.
You need an explicit marker for compat with legacy code. The issue defines unspecified as "a null may occur, but we don't know whether its presence is deliberate".
Explicit nullability fixes the missing information in older code. There could be other ways to mark opting into strict nullability through metadata at the class, module, package or VM level; but fine grained markers are the less disruptive for gradual migration. In particular this keeps the information local instead of relying on an ambient context.
Agreed that the type system treated `T` as nullable, but code may also have comments, annotations and invariants placing stronger constraints. This means that "a null may occur" also lived with "this won't ever be null but the type system does not let me express it" and in the absence of marker it's hard to distinguish both cases.
We've been using it for a while, and I'm absolutely happy with the project.
Before that, we had a Kubespray based setup. It's a bunch of Ansible script and it allows to make any custom setup, like absolutely anything as you in control of the machines. But the other side of this is that it's extremely easy to break everything. Which we did a couple of times. And so any upgrade is a risk of loosing the whole cluster, so we decided it must be run in VM with full backup before each upgrade. Another problem that it takes about an hour to apply a change, because Ansible has to apply all the scripts each time.
Then we migrated to Talos, and it's a day and night. The initial setup took like an hour, including reading the docs and a tutorial. Easy to setup, easy to maintain, easy to upgrade (and it takes minutes). Note that we run the nodes as VMs in Proxmox, so the disk and network setup are outside of Talos scope, as well as backups, and it's actually simplifies everything. So it "just works" and we can focus on your app not the cluster setup.
I'd suggest to run it on top a virtualization environment, like Proxmox. That solves a lot of problems, and not just related to Talos. Basically, you split k8s and the resource management, networking, disks, etc, as well as getting backup, migration, etc.
While the author probably wants to own the main code, I'm sure there are other things he may want to get help from external contributors.
For example unit tests. At least to show that it works, and how to use it. Also a build config, like gradle/maven, so others would be able to use this lib.
