adql

> In terms of how hard it is to get places you really want a delt-v map[2]. By that metric Venus is the closest at 640 m/s from Earth intercept to Venus intercept.

Well, that's also a minimum that changes over time. It might be closest at a particular moment but still not "on average"

It should be like that from the very beginning, any and all configuration management systems that chose YAML as base instead of DSL (even if DSL is just a subset of Python or Lua) have same problems.

The negative experience comes entirely from bugs in tools, not lack of features

> The number of requests sent exceeds the quota limit.

lmfao google can't host a fucking static page

Sooo if you have root on rPi you can permanently brick it by writing invalid key to OTP ?

And other point I also seen used to lie about cloud cost is saying you save so much on engineers.

...while forgetting to have sane on-call rotation for cloud you also need at least 3 people on that rotation that are also clued in on cloud operation enough. Sure they can be "developers" but if your app architecture requires so little maintenance and flea removal that they are not doing ops jobs much, chances are so would it in either rented or dedicated server env.

If the end result is the same you're just wasting components that already are builtin into most microcontroller.

And you'd need to remember to not use autonomous part of microcontroller (like a timer output) to implement it.

Considering the connected net is named "tip_control" I'd assume its PWM that is fed into MOSFET controlling the heater... and in vast majority of cases that PWM will happily run when core is hanged.

Looking at datasheet of the microcontroller PA6 does indeed go to tip_control and one of alternate functions is TIMER2_CH0, and at least glancing at code

    /* enable TIMER1 - PWM control timing*/
    timer_enable(TIMER1);
    timer_enable(TIMER2);

...

https://github.com/Ralim/IronOS/blob/1fbcdcdf987a28541524e4f...

... timer_init(TIMER2, &timer_initpara);

    /* CH0 configuration in PWM mode0 */ 
    timer_channel_output_struct_para_init(&timer_ocintpara);
    timer_ocintpara.outputstate  = TIMER_CCX_ENABLE;
    timer_ocintpara.outputnstate = TIMER_CCXN_DISABLE;
    timer_ocintpara.ocpolarity   = TIMER_OC_POLARITY_HIGH;

...

they are using it for PWM. The watchdog itself also appears to be enabled tho, so there is a chance it will kill itself the normal way

I prefer "One way to format everything", it just cuts so much needless whining if everyone just uses same formatter with little to no settings.

... and having curly bracers instead of the whitespace nonsense. Using invisible characters as flow control was never good idea.

I think that is fine if language also does directory = namespace

> and they should be upfront about that.

Do you need a screenshot and red box around the text or would you believe me if I tell you it is written on their lambda pricing page near the beginning ? It's also written in docs about configuring lambad functions so at this point it is PEBKAC/RTFM issue, not "them not being upfront"

And frankly it is done that way because they have standarized machines, scheduling CPU heavy/memory light and cpu light/memory heavy is extra complexity. I mean ,they should, but they have no real incentive to, as in most cases apps written in slower languages are also memory-fatter so it fits well enough

> If you went to a car rental and they told you we have a cheap car that's slower when you add passengers - and then you drive it to pick up your wife and it turns out it only goes 20 km/h when your wife gets in - you would be rightfully mad.

Getting lowest tier one is more like renting a 125cc bike than a car if anything. You can do plenty with that limit in efficient language too.

I kinda thought about making "monolithic lambda", where there is just interface to get the request, respond to request, logging, and maybe some queue to talk with other components, for some of my personal tools.

Basically cut down the cruft when deploying another small self-contained feature but still keep the code running (savings of few MB memory are meanigless if you just have few dozen features that might run at the same time anyway).

Then I realized it's basically reinventing the ancient idea of "application server" like JBoss and EJB... which is kinda the case for lambda anyway.

That's honestly more impressive than the UDP stuff

It's ~$1.5 chip that's comparable with other ~$1.5 ARM chips (~$1 for chip, let's say $0.5 for 512kB NOR FLASH)

In fact if you want more than say 250kB of RAM, currently the cheapest alternative on Mouser is ~$5 (STM32F730V8T6TR). And that will have less flash!

Yes, it is not a replacement for ESP32 but it isn't supposed to, it is placed squarely between arduino and ESP32 power-wise

When that wasn't true ?

> It's not really the same spot in that your paying monthly rather than upfront. Devs tend to think about total $, the business/accountants do care about Opex vs Capex.

You can buy physical servers in leasing ,turning it into opex

You can also rent them for little bit extra via managed dedicated servers from vendors like OVH.

And that you can also lease servers directly from vendors like OVH so you don't even need to bother with the "drive to datacenter and install it" part. It's more expensive but still far cheaper than cloud

That kinda begs the question "why not watchdog?". Most MCUs have one

Decision paralysis is a thing - while having digital multieffect might open you to near-unending combination of effects, exploring within limits of few single function (not neccesarily analog) pedals is less complex.

Also some say some quirks of analog designs are hard to replicate in simulation althought I haven't seen double blind tests of that so I'm mildly skeptical of that

Physical digital ones are a thing

I'm annoyed that they just call MOSFETs FETs. There are different types dammit!

>Like, did they even think about cost when designing this the first time?

Obviously no, only after managers complained.

> This is not a discussion of monolith vs serverless. This is some terrible engineering all over that was "fixed".

I feel that's like 95% of the "we migrated from X to Y and now it is better"; most of improvements coming from rewriting app/infrastructure after learning the lessons with only small part sometimes being the change in tech

well, they have no incentive to not make you pay for CPU time on your application startup

That is probably the best use case for microservices (althought I'd just call them "services" at that part).

That assuming they are big enough to warrant that in the first place.

IMO if it is a dozen unrelated endpoints but all of that still takes less than dev/month to manage it's probably entirely wasted effort to "fix it"

And if any of them grows to warrant dev/month or more.... separate that one and only that one out of that.

When they say k8s is "easy" they mean "for developers", not people/automation running it.

Like, compared to implementing hitless rollback over bare metal services k8s way is "easy", just set some stuff in YAML and have proper healtchecks in your app.

They really don't unless you routinely put a bunch of tiny self-contained apps.

The "pain" of figuring out how to deploy your "normal app" quickly amortizes over just how much easier and more reliable code is.

It's way too easy to just add a lot of friction if you go too far.

I also think it would be way healthier if teams acted as "maintainers" rather than "sole developer" of a service.

For example if team A wants feature from service team B manages they should be free (after communicating that so there is no confict/work duplication) to just make that feature and submit pull request to the team B.

Then team B can make sure it's up to their standard but that's shorter work than getting the whole machine of "submit a ticket for team B to add feature, find manpower to do it, and schedule work" running.

>Another pain with monoliths is that they can only be deployed if the entire monolith is passing all tests. When you cannot deploy your changes because someone else on an entirely orthogonal team broke something in the monolith which is not related to you it gets old really quick.

You can just... not allow code not passing test into master branch. They can fuck around in their own one, that's what branches are for

> Do you think the Lambda team want people to use as many of their services as possible even when it's not actually appropriate and there are better architectures and approaches available?

They most definitely want to as that would most likely mean more money (and promotions) is flowing there.

Kinda depends if you can run replication from aurora to regular database