HN user

matlock

225 karma

flomotlik@gmail.com

Posts3
Comments81
View on HN
Claude Code 2.0 10 months ago

Over the weekend I had it extract and Analyse Little but Fierce, a simplified and kid friendly DnD 5e and extract markdown files that help me DMing for my kids. Then it Analyse No, thank you evil as I want to base the setting on it but with LBF rules. And then have the markdown turn into nice looking pdfs. Claude code is so much more than coding and it’s amazing.

You don't own the music. You can't share it, use your own software to analyze, shuffle, remix it, etc

I'm a consumer of music, not a creator so I don't care that I don't own it. There are tons of ways creators can analyze, shuffle, remix or do whatever with it, but as a pure consumer Spotify is simply much better for me than CDs. I never cared about owning Music, CDs were always just a transport Medium so I can listen to the music.

But now there's Hulu, Disney+, Amazon Prime, HBO Go, Showtime Anytime, Peacock Premium, etc. Except now instead of one easy to use interface to access it all, it's spread out all over the place and inconsistent as hell. And more expensive!

They aren't though because you can be selective and cancel anytime and resubscribe. And you can watch exactly what you want at any time compared to cable. As a consumer it is way better because there is way more choice and competition at the moment.

While I don't disagree that we shouldn't strive for maintainbility, things like medical software, airplane software or similar highly tested mission critical pieces are specifically built to last for that long. Nobody is going to pay us to build a WebShop to last for 20 years, thats just not a necessity when getting it out quick is so much more important from a business perspective than making it last forever.

That’s often unobtainable with modern software development because we rely so much on things that change too often, but it doesn’t have to be that way

The reason we rely on things that change often is because we want to leverage them to get products out faster. Many different layers of that (as every tech stack is essentially a product by someone) and we have lots of updates to deal with. The flipside of slow moving projects is bugs might not be fixed or new helpful features might not be coming in, meaning you have to build it yourself.

As a community we know and have known how to build mission critical software for decades, but we actively often decide not to do it because it isn't that important compared to other factors.

But to be honest it is in the interest of the other countries who want the EU to stay to make this really really hard on the UK. And the UK has almost no leverage (or has none to be precise).

So while I absolutely hate to see it happen because I've got lots of friends in the UK, this is either going to hurt badly (hard Brexit), or the UK will simply lose any ability to shape the future of the EU while accepting most of its rules. Don't see any middle ground as the middle ground would massively hurt all other EU countries so its not going to happen.

Other people already pointed out the mistakes in your argument as this is necessary to build a common market across dozens of countries and hundreds of millions of people. Please read up on what the EU is trying to do, you really don't seem to have a grasp on it.

But what you're saying is that eventually you'll make money on every transaction which just goes along with the comment made before. The joke is really about goods where you can't lower the cost or increase the price enough to make the economics work.

The fist copy of Microsoft Windows might cost 1 billion dollars to produce, while every next copy is essentially free

You'd have to split R&D costs by the units sold here. If you spend 1B and sell 1000 copies a price of 100$ per copy won't help you.

"What is more probable is tha FB will try a legal trick claiming they are an American company and they follow the laws of California, not EU, even if they gladly accept European advertisers's money via Ireland"

That is specifically not possible under GDPR. It doesn't matter where your company sits, if you store data from europeans (or people living in europe) you have to follow the GDPR with potential for severe punishment. There really is no loophole afaik.

Can second PIA. Used it for years now and its solid. And I'm not affiliated in any way with it, just a happy customer

Opera is Reborn 9 years ago

Obviously in the US there's more checks and balances, to make a company's statement more believable. Or that's what we believe anyway...

Without significant prove that this is not the case this handwaving way of comparing the US democratic state to China is just wrong. From Consumer protection to free and fair elections the US system is almost nothing alike the chinese system. Of course the US has massive issues (as do other Western democratic nations) but this handwavy "well they just don't tell you' stuff without actual good data behind is just destroys any credibility and is a huge problem for our democracies. Please stop doing it unless you provide exhaustive evidence.

Its not about how tricky the implementation is, but what the value of setting this up is. With Lambda for example you just get this magic that invokes your functions when something happens. You don't have to deal with, manage or think about this at all. And its built into many different parts of the stack from S3 to APIG to Dynamo or SNS.

You can of course do something like that yourself in your own infrastructure, but then every piece of software needs to support it somehow, you need to manage that event bus infrastructure and you most likely have to push those events in yourself.

And that kind of thing is already there, so the appeal that Serverless event driven systems in the cloud have (because the providers give you all of this out of the box) is much harder to achieve when you have to do that yourself.

We're actually talking to everyone you mentioned. I'd love to see some "on-premise" Serverless infrastructure as well, the biggest issue with that is still the event system as a Serverless infrastructure really mostly makes sense if you can do things like "when you upload something to this bucket run this function". This is hard to replicate in an on-premise system.

Absolutely not. We definitely want to support all of those providers, but as those integrations aren't in the Framework yet we decided to remove the logos until we actually support them.

Not just because users want those, but for us its important to become more provider independent as we don't otherwise have a defensible product. So multi-provider is definitely coming and we're in constant contact with many providers.

The Serverless Framework is at the core of all our monetisation strategies, so we need the Framework to be spread to as many developers and into as many teams as possible and allow for way more complex infrastructure to be built. So by necessity we'll be pushing really hard on moving the framework forward.

I don't think the needs of an open source community stay in stark contrast to VC funding model, because without the Framework getting a lot of traction our other products aren't as interesting. So we'll be working on getting that traction. And we can't do this just by ourselves. We wouldn't be here without the Contributor community (literally because they implement so many features) so without good communication, outreach, support, ... we won't be able to grow fast enough.

I can only tell you that it is our true intention to push the framework forward very hard and build monetisation around it as much as we can to build this into a long term sustainable company. The more help and feedback we get to build the right commercial products and get great revenue (so we can give our Investors as well as our Team a return as well) the happier everyone is, including the community.

1) What's the schedule on the documentation for best practices for SLS in production?

These are the goals for the next releases, giving you better tooling and best practices to go from a few services to many services.

2) What's an example workflow ? (something involving multiple devs, testing, CI etc.)

Thats still relatively standard, with good testing, CI, CD , ... but we'll also add more blogposts and docs around that.

And lastly, What's the timeline on adding support to Google Cloud Functions (in alpha) and Azure Functions?

Can't give an exact timeline, but we're working with both to be ready once GCF goes into production and working with Azure to get support into Serverless as well. Really also depends on talking to more users to understand how they want to use those providers.

Thanks, appreciate the shoutout!

There certainly are other open source tools like ansible, Chef, Puppet, Hashicorp, MongoDB (and many more) that have started out as an Open Source project and are still OSS champions.

We have many plans for monetisation and are working closely with small to enterprise scale companies on building products and services around the Framework that help you once your infrastructure has reached a large scale. More info to come in the future.

Great work on this. We're actually moving in a similar direction at Serverless with full Cloudformation support in our current development branch for all the reasons you listed. Would love to chat sometime, email is in my account page.

Hey Ben, we're going to build completely on top of Cloudformation in the next version of Serverless. Currently starting to work on it. If you're interested would love to get your feedback: florian@serverless.com

They aren't even close to each other in featuers. All the various additional Services AWS supports go way beyond what Google has at the moment. Numerous Database offerings, Queueing, transcoder, ... Go way beyond what Google has in place.

And no the ability to run it yourself on Google is not the same.

Codeship - Boston, MA or Vienna, Austria

At Codeship we build a continuous Deployment service. Our mission is to make software teams more productive by helping them to release early, often and safe. We're building for the builders.

We've been in production release for several years, have thousands of developers using the service and are growing rapidly. We've closed our Series A earlier this year.

We're looking for Rails Developers, SysAdmins/DevOps, designers and frontend developers who love building tools for other developers.

Read more about us on our Jobs Page: https://codeship.io/jobs And how we work in our Blogposts: http://blog.codeship.io/category/the-codeship-workflow

Send me an email to flo@codeship.io. You'll like it here!