|
is netdata decent monitoring for servers on a home network? i don't want to deploy prometheus and write collectors for it just to get basic sys info
|
#
?
Mar 7, 2021 18:12
|
|
|
|
| # ? Jun 7, 2024 17:35 |
|
|
my homie dhall posted:what are the problems with it and what did you replace it with? we didn't have any problems per se, it was just more than we needed grpc was introduced alongside plain old http polling in order to support fancier features. those fancier features never materialized, so the extra resources server-side were pure cost. we flipped the flag back to plain http in the client many months ago, and last week we finally tore out the (dormant) client grpc code and deps. bought us a couple mb back in compiled app size too
|
|
#
?
Mar 7, 2021 18:15
|
|
|
my homie dhall posted:what are the problems with it and what did you replace it with? people in my company are also looking at teams building lovely rest apis and have somehow come to the conclusion that moving to grpc will magically solve this (i assume because grpc somehow increases team quality)
|
|
#
?
Mar 7, 2021 18:17
|
|
|
all serialization formats are stupid, so just use json because at least then it'll be well-supported stupid. if the size is a problem, that's why every platform has transparent gzip support
|
|
#
?
Mar 7, 2021 18:23
|
|
|
Blinkz0rz posted:is netdata decent monitoring for servers on a home network? i don't want to deploy prometheus and write collectors for it just to get basic sys info yeah it's perfect for home servers if you dont wanna futz around with the more complete tools. it offers a lot out of the box.
|
|
#
?
Mar 7, 2021 18:36
|
|
|
Arcsech posted:all serialization formats are stupid, so just use json because at least then it'll be well-supported stupid. if the size is a problem, that's why every platform has transparent gzip support sure, as long as you don’t mind having to roll your own encoding layer on top of json strings because its number type is a footgun just waiting to go off and it doesn’t have much else. hope you have good
|
|
#
?
Mar 7, 2021 18:49
|
|
|
Soricidus posted:formats that support ... validation.  like as if anyone is going to use that.And like all messaging that assumes the sending app is not just pushing out garbage anyway.
|
|
#
?
Mar 7, 2021 18:57
|
|
|
pokeyman posted:we didn't have any problems per se, it was just more than we needed oh was this a native (?) app calling stuff over grpc? yeah that has always seemed really bad, though it's frustrating bc theoretically protobufs could provide that source of type-truth-for-clients-and-servers i've described wanting for apis i am bullish on us using it for internal service communications for that reason. grpc still seems like the most complicated possible way to get to my dream of "autogenerating clients for service to service communication" but at least it looks way more robust than swagger/json schema generation nonsense but, sadly, still no answers for frontend/native clients. grpc-web seems stupid and requires setting up a special proxy. graphql also offers a type schema to generate against but graphql still seems like a loving disaster zone to me, especially on clients
|
|
#
?
Mar 7, 2021 19:14
|
|
|
abraham linksys posted:oh was this a native (?) app calling stuff over grpc? yeah that has always seemed really bad, though it's frustrating bc theoretically protobufs could provide that source of type-truth-for-clients-and-servers i've described wanting for apis yeah native android and ios apps talking to a server via grpc
|
|
#
?
Mar 7, 2021 19:28
|
|
|
abraham linksys posted:oh was this a native (?) app calling stuff over grpc? yeah that has always seemed really bad, though it's frustrating bc theoretically protobufs could provide that source of type-truth-for-clients-and-servers i've described wanting for apis there are two hurdles to using grpc in your internet-facing apis : 1. if you have third party clients they will gently caress it up badly. do you want to train the entire world that integrates with you on how to use grpc in their favorite language 2. authentication is a clusterfuck and the advice for any use case that doesn’t exactly match something google needs is “there’s an interface you can implement”, which is Enterprise for “go gently caress yourself”. combined with point 1 it means that grpc is almost never the best choice for an internet facing API not to mention that even in 2021 you will find weird corners of your infrastructure that still don’t support http/2 properly
|
|
#
?
Mar 7, 2021 19:46
|
|
|
https://reasonablypolymorphic.com/blog/protos-are-wrong/index.html Protobufs bad, supposedly, although I'm not entirely sure i agree with the point being made, rather i think the general problem is not specific to protobufs' lovely type system per se (although it sounds like the type system could be better). The problem is that working on database skins is really loving dull, and I'm not a rockstar programmer or whatever so that's basically all I ever do for a living, though it certainly puts a lot of bread on the table so I'm not going to complain too much. It all boils down to dozens and dozens of record types that have to be managed and cross-mapped in triplicate: the on-wire form, the on-database form, and the form that you actually work with inside your application. This mapping and validation process is incredibly loving dull, so people invariably try to make shortcuts by making some of those forms do double duty (or god forbid triple duty). There have been countless attempts at writing tools that automate the process of mapping and validating these three forms and every single one of them sucks out loud.
|
|
#
?
Mar 7, 2021 19:52
|
|
|
Nomnom Cookie posted:not to mention that even in 2021 you will find weird corners of your infrastructure that still don’t support http/2 properly we have also been having fun with this  though not related to grpc
|
|
#
?
Mar 7, 2021 19:56
|
|
|
gently caress http/2 as well by the way let's complicate the poo poo out of a fundamental protocol in ways that have absolutely no benefit to anybody but the most massive network services by a complete coincidence this protocol is being promoted by a massive network service http/3: and this... is to go even further beyond! yeeeaaarggghhh!!!! *breaks loose from tcp entirely*
|
|
#
?
Mar 7, 2021 19:59
|
|
|
Sapozhnik posted:The problem is that working on database skins is really loving dull, and I'm not a rockstar programmer or whatever so that's basically all I ever do for a living, though it certainly puts a lot of bread on the table so I'm not going to complain too much. It all boils down to dozens and dozens of record types that have to be managed and cross-mapped in triplicate: the on-wire form, the on-database form, and the form that you actually work with inside your application. This mapping and validation process is incredibly loving dull, so people invariably try to make shortcuts by making some of those forms do double duty (or god forbid triple duty). There have been countless attempts at writing tools that automate the process of mapping and validating these three forms and every single one of them sucks out loud. this is a very good summation of the problems i've been running into over... well, the past couple years, frankly i think in my head i map a lot of these problems into "now i'm maintaining multiple sets of types" because not having static types lets you be a lot more loose with this poo poo: most of the time in a frontend you're just cramming the json you get from an endpoint into some state store (maybe with, like, an id -> entity json map, but not much transformation beyond that). once you start typing those things you get back then youre maintaining that third representation though
|
|
#
?
Mar 7, 2021 20:13
|
|
|
Sapozhnik posted:https://reasonablypolymorphic.com/blog/protos-are-wrong/index.html It’s an overly whiny article that misses larger flaws with protobufs, like maps are implemented in the worst possible way in the API that makes them so slow just because the developer was lazy. Some people need a binary messaging protocol and protobufs is reasonable enough to get there. I would propose that JSON sits on one side and Simple Binary Encoding sits at the other, and if one has needs for validated interop I could see schema based XML having a home, but these days try to avoid anything else. Like MsgPack can interop with JSON, so it almost has an excuse.
|
|
#
?
Mar 7, 2021 20:48
|
|
|
the true comedy option is capn proto, done by the same dude
|
|
#
?
Mar 7, 2021 20:51
|
|
|
protobuf/thrift/avro/msgpack/etc are great for service-to-service communication that crosses organizational boundaries because the contract comes first they're the perfect application of conway's law
|
|
#
?
Mar 7, 2021 20:53
|
|
|
Sapozhnik posted:https://reasonablypolymorphic.com/blog/protos-are-wrong/index.html there's some fp wank in there but it does touch on a very subtle problem what i am holding right now in my left hand? 'nothing' is an answer, 'i don't know' is an answer. those are not the same answers, and attempts to pretend they are the same leads to hilarious errors because silent type coercion is the devil i don't want to have to commune with the great spirits to determine if 0 really means 0 or it's unset instead. those are different and if you put that plang garbage into my nice static types i will be mad. proto3 does that to you
|
|
#
?
Mar 7, 2021 21:00
|
|
|
Brain Candy posted:i don't want to have to commune with the great spirits to determine if 0 really means 0 or it's unset instead. those are different and if you put that plang garbage into my nice static types i will be mad. proto3 does that to you tbf there's no plang i've ever seen that doesn't have, yknow, a meaningful null value that anything can be set to (or in javascript's case two meaningful values if you really want to differentiate between null and unset )go, on the other hand...
|
|
#
?
Mar 7, 2021 21:09
|
|
|
Brain Candy posted:i don't want to have to commune with the great spirits to determine if 0 really means 0 or it's unset instead. those are different and if you put that plang garbage into my nice static types i will be mad. proto3 does that to you this is by far the worst thing about go. if you have pre:type foo struct {
MyInt int `json:"myInt"`
}
the answer may surprise and horrify you https://play.golang.com/p/pFT9T08BOjD
|
|
#
?
Mar 7, 2021 21:12
|
|
|
any time backend devs (rightfully) mock the amount of packages any node app has to pull in to assemble something resembling a standard library, i do remember that poo poo like https://github.com/guregu/null exists and it's not like there aren't similarly embarrassing dependencies in all the "more robust" languages as well
|
|
#
?
Mar 7, 2021 21:14
|
|
|
it's mind blowing that go can have a nil value and still have no concept of a nil string, numeric, or time type that has no type-equivalent value unless you use a pointer which brings with it a whole other world of pain
|
|
#
?
Mar 7, 2021 21:19
|
|
|
Go is bad compared to Rust.
|
|
#
?
Mar 7, 2021 21:22
|
|
|
Blinkz0rz posted:it's mind blowing that go can have a nil value and still have no concept of a nil string, numeric, or time type that has no type-equivalent value unless you use a pointer which brings with it a whole other world of pain nil isn't in the domain of integers so i can give it a pass for that and other value types but doesn't go also lack a reasonable Maybe/Option type
|
|
#
?
Mar 7, 2021 21:23
|
|
|
Nomnom Cookie posted:but doesn't go also lack a reasonable Maybe/Option type your options are either to use a nil pointer which has weird problems when you then want to pass that value to a function that only accepts an int, or, like, only parse out scalar values from functions that will return an err value so you just ignore the return value if one is present i guess??? it loving sucks like it's loving wild that the sample Blinkz0rz posted doesn't, at minimum, return an error value when that field is entirely missing
|
|
#
?
Mar 7, 2021 21:26
|
|
|
Nomnom Cookie posted:nil isn't in the domain of integers so i can give it a pass for that and other value types still doesn't excuse deserializing null to 0
|
|
#
?
Mar 7, 2021 21:26
|
|
|
abraham linksys posted:your options are either to use a nil pointer which has weird problems when you then want to pass that value to a function that only accepts an int, or, like, only parse out scalar values from functions that will return an err value so you just ignore the return value if one is present i guess??? it loving sucks if you have nil and want to call a function that takes an int, like....yeah. you have to figure out what to do then? because you need a value and don't have one. i mean you'll run into the same thing in java if you have Integer and need int. gotta handle that null somehow. i think i might be misunderstanding you but i do agree with you and blinkz0rz that it's completely insane to turn a null into a 0. that's php level poo poo
|
|
#
?
Mar 7, 2021 22:19
|
|
|
quote:(or in javascript's case two meaningful values if you really want to differentiate between null and unset this is a correct ontology in theory, but in practice is making a billion dollar mistake twice imo, for the same reason that checked exceptions are wrong in java. it's not that they couldn't be used correctly, but they won't. attempts to berate or shame your user base into doing it right are a nerd fantasy Nomnom Cookie posted:nil isn't in the domain of integers so i can give it a pass for that and other value types well isn't go just getting templates/generics now? literally impossible to have an applicative Maybe before that
|
|
#
?
Mar 8, 2021 00:16
|
|
|
Brain Candy posted:there's some fp wank in there but it does touch on a very subtle problem "some" is an understatement, lol the entire article is "what if instead of a serialisation format that made the stuff you want to do easy, it was a bunch of fp wank that made it tediously difficult? wouldn't that be so much better?" the author seems to think that "writing generic, bug-free, polymorphic code over protobuffers" should be the primary thing that protobufs are designed for, at the expense of other use cases like "I want to set these particular request parameters on the query I'm sending to the backend". in reality, what the author wants is a thing that should never be designed for ever by anyone and attempting to write anything like that should be highly discouraged.
|
|
#
?
Mar 8, 2021 00:50
|
|
|
redleader posted:big call when *gestures at broad range of other serialization formats* avro originates from hadoop's internal serialization format which says 'we have these packed binaries, lets describe them using a json schema'. of course transferring this json schema between all the parties that need it is both required and left as an exercise left to the reader, and if the schema doesnt align then the data is rendered unreadable. i assume avro's origin is also why any sort of field evolution support, something that normally is a core feature for serialization, feels like it's been bolted on to avro as an afterthought at least with e.g. protobuf the encoding has enough metadata that without the schema you can at least decode "an unknown string with field id 69", and protobuf strongly recommends (and in proto3 forces) optional fields so that schema evolution is possible, whereas in avro marking a field as optional is effectively accomplished by defining its type to be a union of null and whatever the desired type is i mean maybe if your other option is writing C structs directly to local disk, then maybe avro is an upgrade from that, since that's what it was originally used for but not by much
|
|
#
?
Mar 8, 2021 01:13
|
|
|
Brain Candy posted:well isn't go just getting templates/generics now? literally impossible to have an applicative Maybe before that i am not a big types nerd so idk. i was thinking maybe they had some nice syntax for dealing with pointers so you could get a similar effect to a decent type system, in this limited area
|
|
#
?
Mar 8, 2021 01:37
|
|
|
having any kind of schema that is full of optional fields is also as good as not having an schema at all
|
|
#
?
Mar 8, 2021 01:39
|
|
|
Sagacity posted:having any kind of schema that is full of optional fields is also as good as not having an schema at all is it your actual proposition that there is no difference between an rdbms table with all fields nullable and a mongo collection?
|
|
#
?
Mar 8, 2021 01:41
|
|
|
Jabor posted:"some" is an understatement, lol i think that's overly harsh even if the author is a dork. it's fine to want a rigid formal spec in comms. a message contract can save a ton of pain by validating things as at the edges. the more of the practical contract that's implicit, the more work i'll have to do to make sure it was followed and i don't have time for that if a computer can do it schemas can be good, types can be good it's just that protobufs are the go of serialization, lukewarm; not as easy to use as json, not as safe to use as validated xml, not as small as asn.1, not as fast as slamming bytes into a struct. mediocre all around and going to make you mad if you care about one of those qualities in particular
|
|
#
?
Mar 8, 2021 02:02
|
|
|
Brain Candy posted:i think that's overly harsh even if the author is a dork. it's fine to want a rigid formal spec in comms. a message contract can save a ton of pain by validating things as at the edges. the more of the practical contract that's implicit, the more work i'll have to do to make sure it was followed and i don't have time for that if a computer can do it i think it's pretty deserved when the author is saying "just model repeated fields as a series of cons cells (and the underlying serialisation could be something completely different if you're worried about wire size)" as though that's somehow a reasonable structure that people actually want to interact with when they're writing serialisation code combo that with the attitude later in the article of "why are you even using a serialisation library if you still need to write serialisation code instead of getting it for free" suggests that they have never actually written any boring bread-and-butter "this is actually the primary use case for the libraries" code, ever, let alone have any first-hand experience with evolving an api over time.
|
|
#
?
Mar 8, 2021 02:24
|
|
|
All I really want is an IDL for wire formats. Type systems are not validators but I do want something that will at least get the data into my type system so that I'm not ducking ClassCastException and NullPointerException being vomited out of every expression once I get down to the actual validation part. Validation cannot be DSLed away anyway, your validation rules are going to include things like "Refers to the ID of some related entity X that must exist and that the user must have permission to access" or "the total quantity of bleeps and blorps requested must not exceed six". I don't really care that much about the actual on-the-wire representation compared to the set of types that it allows me to express.
|
|
#
?
Mar 8, 2021 02:37
|
|
|
Jabor posted:i think it's pretty deserved when the author is saying "just model repeated fields as a series of cons cells (and the underlying serialisation could be something completely different if you're worried about wire size)" as though that's somehow a reasonable structure that people actually want to interact with when they're writing serialisation code lists and optionals are fine? you're missing the point, it's not that you'd need to make them yourself, it's that google could have made them for you using a much simpler rule set a rule set that also would let you make more things if you wanted to make things? instead you have keywords that don't compose because they are bespoke solutions. i guarantee they didn't do that because no one ones to make a non-trivial compiler for protobufs and the spec was grown as it was used, but i think it's a fair criticism of what you can express with what you were given if you want to make a map of lists, for example, gently caress you, make a custom holder type. two maps of lists that vary by the type of list? gently caress you copy-paste-mutate the first one. does this sound familar?
|
|
#
?
Mar 8, 2021 03:12
|
|
|
make custom types for lists is a garbage holdover from two decades ago and anyone using a dynamic language can justifiably laugh at you for it
|
|
#
?
Mar 8, 2021 03:24
|
|
|
no-one should give a poo poo about composability of abstractions, it's a serialization format. build your abstractions on top of it when you're validating + turning it into application objects. and the absolute last thing anybody should want is a compiler that does non-trivial and unpredictable things to transform your serialization format into bytes on a wire.
|
|
#
?
Mar 8, 2021 03:43
|
|
|
|
| # ? Jun 7, 2024 17:35 |
|
|
bob dobbs is dead posted:the true comedy option is capn proto, done by the same dude
|
|
#
?
Mar 8, 2021 04:33
|
|
