WTF Bites
-
Looks like the old tired "president's wife is a man" crap is back, this time with somewhat Scottish twist.
Or maybe the Google is
-
skimping on two fucking bytes for the error level
That's almost certainly so that it is the same length as
ERROR, which the author of the log format must've thought was more aesthetic.Yeah, but INFO gets padded with blanks.
lack of input validation?
This looks like the input validation. It logs an exception on invalid request and (hopefully) rejects it, which looks OK-ish to me; it should provide a nibble more context like also stating which client sent it and which field contains the unparseable value.
You can probably dig that out of the big-ass stacktrace that I didn't include.
spewing raw Java exceptions into log files?
That's normal. They tend to be most useful for debugging while also easiest to produce.
It's certainly normal here, but still not OK. It's fine-ish when you have a server or two where developers have root and test^Wfix shit in production, but when you have two dozen servers (or god forbid some containerized environment), a release process and clients who value a limited number of root users, you really really want centralized logging, and log shippers hate exceptions as they're basically impossible to parse.
clipping the class names for reasons nobody knows?
Were? I don't see anything clipped in your example.
What I did see Java loggers do is abbreviate the package names to single letter per level, because when the class is buried under 15 levels of packages, the message would get shifted off screen to the right.
That I can even understand. But the class is not called "orgproxy" here, it's something longer that I forgot but it's missing like 3 letters. Or maybe just a B.
skimping on two fucking bytes for the error level when total logging has been know to go into the double-digit gigabytes? Per minute that is.
True,
WARNIis a weird abbreviation; usually it's justWARN, because everybody is lazy to type out all ofWARNING.I should really hope they have methods for that that they can call whatever they like. Logging by
printf¹("WARINGN!!!!11%s", foo)would be
¹ Edith: or something javaish
-
total logging has been know to go into the double-digit gigabytes? Per minute that is.
You must be using up a truckloads of SSDs.
-
Company forced to change name that could be used to hack websites
Software firm’s director thought name using HTML would be ‘fun and playful’
-
-
It's certainly normal here, but still not OK. It's fine-ish when you have a server or two where developers have root and test^Wfix shit in production, but when you have two dozen servers (or god forbid some containerized environment), a release process and clients who value a limited number of root users, you really really want centralized logging, and log shippers hate exceptions as they're basically impossible to parse.
Log shippers, at least in my experience, don't actually ever parse the body of the message, just the time, source and level. But it's true a multi-line log message is utterly unusable in any log collector. But since the length of the line is not much of a problem otherwise, breaking them up with line separators instead of line feeds should work (except somebody would have to give a
and actually do that).That I can even understand. But the class is not called "orgproxy" here, it's something longer that I forgot but it's missing like 3 letters.
Ok, that wasn't obvious. The loggers I've seen would have abbreviated that as
o.g.f̌.b̌.p.RequestParser(or whatever letters the intermediate packages start with) instead.
-
java.lang.NumberFormatException: cant parse: CANNABIS
What kind of idiots do they have working at Java? The value is clearly 420
-
@hungrier
java.lang.BlazeItException
-
/java/lang/Object.html#hashCode()
-
total logging has been know to go into the double-digit gigabytes? Per minute that is.
You must be using up a truckloads of SSDs.
That was on a 15-node Kubernetes cluster with a whole bunch of Elasticsearch instances. It has enough RAM to buffer that much for a couple of hours ^^
But yeah, you have to start throwing away stuff pretty soon.
-
Why the flying fuck?
Android used to use this effing awful abomination rats' nest of makefiles. It was a crawling horror for sure. But it already has CMake support and there was some implementation directly in Gradle (that is used for the Java side either way). So why in the fourth (or third; I am not sure) circle of hell are they adding yet another build system‽
-
Why the flying fuck?
Android used to use this effing awful abomination rats' nest of makefiles. It was a crawling horror for sure. But it already has CMake support and there was some implementation directly in Gradle (that is used for the Java side either way). So why in the fourth (or third; I am not sure) circle of hell are they adding yet another build system‽
Someone at Google heard of "NIH syndrome", but they hadn't come up with it themselves so they made their own NIH.
Filed under: with blackjack, and hookers
-
Some programmers seem to be fascinated by build systems, and are eager to reinvent the pentagonal wheel with an off-center axis again and again.
Personally, I don't get it. At best I find build systems boring, and they often turn into infernal Rube Goldberg machines that make me want to run away screaming.
-
@Zerosquare said in WTF Bites:
Some programmers seem to be fascinated by build systems, and are eager to reinvent the pentagonal wheel with an off-center axis again and again.
Personally, I don't get it. At best I find build systems boring, and they often turn into infernal Rube Goldberg machines that make me want to run away screaming.
I mean, if someone came along with one that isn't an HP Lovecraft monstrosity and people would settle for it, that sure would be nice. But it seems all build systems are horrible to some degree.
-
@Zerosquare said in WTF Bites:
Some programmers seem to be fascinated by build systems, and are eager to reinvent the pentagonal wheel with an off-center axis again and again.
Personally, I don't get it. At best I find build systems boring, and they often turn into infernal Rube Goldberg machines that make me want to run away screaming.
It's a puzzle. Puzzles are fun! Also, the guys who came up with the system we're using now were clearly idiots. Look at all the bullshit you have to work around to get work done! I can clean this up easily.
:spongebob-later:It's not a mess, it's what you need to accommodate all the edge cases and stuff!
-
@Zerosquare said in WTF Bites:
Some programmers seem to be fascinated by build systems, and are eager to reinvent the pentagonal wheel with an off-center axis again and again.
See, the build system actually has a huge impact on the efficiency of your work. If the build is slow, waiting down slows you down disproportionately. If it requires you to remember to cast a magic incantation after changing this or that to get things properly updated, you stumble over it all the time. Whether your IDE can extract the information needed for completion to work makes a huge difference too…
@Zerosquare said in WTF Bites:
Personally, I don't get it. At best I find build systems boring
If you are working on a single library or single application written in single language, yes. I often find myself working on sets of heterogeneous components and then…
@Zerosquare said in WTF Bites:
and they often turn into infernal Rube Goldberg machines that make me want to run away screaming.
… this happens. Every language (but see below) has a tool or two that handle the typical needs of that language fairly well. Unfortunately usually it is totally pain to integrate it with the tool for that other language. So you end up with a lot of glue that soon nobody can make heads or tails of.
And that's every language… except C and C++. C and C++ have a bunch of build tools, but because of how every C or C++ application, and worse library, has three zillion options and compilation conditionals depending on the target platform, none of the tools covers the problem space that well. And that's before you consider that every other C or C++ project uses some extra tools for code generation or exotic compiler flags or something. The result is, of course, a mess.
I mean, if someone came along with one that isn't an HP Lovecraft monstrosity and people would settle for it, that sure would be nice. But it seems all build systems are horrible to some degree.
The problem of creating a generic build system is that different languages have widely different requirements and people are generally oblivious of the special issues of any other language than their preferred one or two. E.g. the Java build systems, and many of the JavaScript ones, are completely oblivious to incremental builds by checking which files changed and therefore which steps need to be re-run, because the compiler takes care of that itself, but then it's a problem to add C++ support in them, because for C++ that functionality is essential.
-
Who the fuck is buying cars like this on Facebook Marketplace?!
-
@Bulb Seems to me that the problem is trying to create a golden hammer in the first place. Make build systems for the specific language, and then have some sort of orchestrator for the different build systems. But everyone seems to try to create that silly golden hammer build system.
It will always end up being a touring complete language in the end because of all the special fuckery that goes on not only between languages, but with particulars of large, old projects.
Might just as well give Python build system libraries and get it over with.
-
a multi-line log message is utterly unusable in any log collector
Only true for the log collectors that insist on thinking that all log messages are one line long.
-
@Bulb Seems to me that the problem is trying to create a golden hammer in the first place. Make build systems for the specific language, and then have some sort of orchestrator for the different build systems. But everyone seems to try to create that silly golden hammer build system.
It will always end up being a touring complete language in the end because of all the special fuckery that goes on not only between languages, but with particulars of large, old projects.
Might just as well give Python build system libraries and get it over with.Well, problem is that
- There is a lot of duplication between the language-specific build system and the higher level orchestrator. Both need to deal with dependency chains and detecting changes and that. So to me it would make sense to take an engine for that and build the layers on top of that so they work well together. The buildroot and ptxdist sort of try that, but make isn't up to the task.
- If you don't have the same engine, the orchestrator does not have enough information about the lower layer to be able to optimize the build efficiently. I think bitbake even tries. It does not get there for the project I work on, but it might be because the people who set it up didn't really understand the hydra. And because they were adding bitbake orchestration for some targets to something that already uses the simpler but dumber ptxdist for other targets and tried to unify them, with kludgy shell scripts (of course these are very high level orchestration managing mix of build systems, so no chance for common engine).
So I would really like to see a generic core with layers for different languages on top of it. Make sort of was back in the simpler days, but it isn't up to the modern requirements—but has no replacement that would try to be similarly generic.
-
See, the build system actually has a huge impact on the efficiency of your work. If the build is slow, waiting down slows you down disproportionately.
And this is a problem?
-
If you don't have the same engine, the orchestrator does not have enough information about the lower layer to be able to optimize the build efficiently.
That''s only really a problem for C++, where builds are even now expected to take hours when the rest of the world is able to operate on the level of seconds. (Note: this isn't to say that running a test suite is fast; that's a whole 'nother kettle of fish.)
-
@HardwareGeek Yes, it totally is a problem, because after that session of swivelling chair fencing most of the important context is no longer in my working memory.
It also somewhat paradoxically is a bigger problem for me when a Java build takes two minutes, mostly taken up by maven loading all the modules, with another minute of the IDE rebuilding its indices and stuff, then when a C++ build takes two hours, and runs the test suite for eight more. Because in the later case I can plan to prepare one round of changes, fire off the build and go do something else. But three minutes are long enough to get bored and lose context, but too short to meaningfully switch to something else and back.
Also a well done C++ build might take two hours when rebuilding everything, but will still detect nothing has changed under a second, while on moderately sized project maven will take the two minutes every time even if you run it five times in a row with absolutely no change in between. And gradle is better, not really good.
-
It also somewhat paradoxically is a bigger problem for me when a Java build takes two minutes, mostly taken up by maven loading all the modules
Something's screwy with your cache on that system. Or you're using a build potato.
-
If you don't have the same engine, the orchestrator does not have enough information about the lower layer to be able to optimize the build efficiently.
That''s only really a problem for C++, where builds are even now expected to take hours when the rest of the world is able to operate on the level of seconds. (Note: this isn't to say that running a test suite is fast; that's a whole 'nother kettle of fish.)
I have biggest problem with it in Java, C# and similar languages. I've often see maven take minutes even if nothing has changed, and bitbake takes almost a minute to just process all the recipes (that there are many, but most never change).
This is where cmake + ninja really shines—the configure run is actually fairly slow, but the check whether the build script or other inputs to the build configuration changed is very fast, so it does not even initialize the slow machinery when it isn't needed.
-
@dkf The cache exists as far as I can tell, and the system is definitely not as old as potato (that would be about 20 years now). Just a bunch of wacky plugins involved.
-
@Bulb FYI, my current project takes ~10 minutes for a build. No, actually, the compile step takes 30 seconds. But uploading the construct to the AWS cloud, including setting up all the instances and provisioning them and making DNS records....that takes a long time. And even long when things fail to complete (which they do when I'm figuring out the magic incantations).
Sucks when I need to iterate fast. But I'm doing infrastructure work right now, so that means lots of setting up and taking down instances.
Oh, and the rest of my builds are all dockerized builds, which take 5-10 minutes for the big projects. Most of that time is spent in
apt-getandnpm install(side note--it's tons of fun to watch all the stream of "this project is deprecated/abandoned/DON'T USE IT" notices coming from the latter) andcomposer install(or whatever the relevant php command is).
-
-
Make build systems for the specific language, and then have some sort of orchestrator for the different build systems.
Hm, you are right. It's needed anyway because of all those projects that already have build scripts and a lot of work went into them and nobody's gonna redo them just because. A bunch of projects was converted from autotools to CMake, but that's because CMake actually supports building on Windows with standard tools (Visual C++ Compiler).
It will always end up being a touring complete language in the end because of all the special fuckery that goes on not only between languages, but with particulars of large, old projects.
Every project, even new one, wants a bit of custom logic here or there.
The problem is that the more extensible the build system is, the less do IDEs understand what is actually going on.
The CMake approach with using a full language to create the tree of dependencies and build commands and their parameters and then hand over to a dumb tool (Ninja) that can just compare timestamps quickly and run what needs to be re-run is a good compromise on this—the IDE can get the compiler options from the generated graph and only re-run the logic when new files or added or something.
Might just as well give Python build system libraries and get it over with.
That's my biggest issue with CMake. It would have been much nicer if they built the DSL on top of something existing—at least some smaller one like JavaScript or even the damned Lua if they didn't want to pull the fairly large Python along.
… actually, the Google thing, soong, is built on top of blueprint which is basically just a Go build library, so it is fairly sensible architecture. And it is delegating the actual compilation run to Ninja. It is just that they are complicating the Android build even more.
But Android build would actually especially benefit from the orchestration thing – being able to provide the toolchain information to whatever build tool you've got, because for the ‘native’ (compiled directly to machine code rather than Java bytecode) parts one often needs a bunch of external components and those come with their own build scripts reusing which would be the most effort-effective approach. Current state is that you often end up having to write your own build scripts for the third party code if you want to use it for Android.
-
-
@topspin What do you have against Go? It is a little self-inconsistent¹ programming language with lack of generics² patched up by adding complex things into the language itself³ that fails to actually make concurrent programming safer⁴, but…
¹ structs are value types, but arrays are reference types…
² rumour has it go 2.0 will get generics anyway…
³ like hash maps and channels…
⁴ it's even the trope namer for Go statement considered harmful.
-
The "Go is
" threads are 
-
Why the flying fuck?
Android used to use this effing awful abomination rats' nest of makefiles. It was a crawling horror for sure. But it already has CMake support and there was some implementation directly in Gradle (that is used for the Java side either way). So why in the fourth (or third; I am not sure) circle of hell are they adding yet another build system‽
More importantly, why is every build system terrible?
I know...
-
it's even the trope namer for Go statement considered harmful.
I was reading that just yesterday...
-
@topspin exponential distribution strikes again 😉
-
@topspin exponential distribution strikes again 😉
What do you mean by that?
-
@topspin If you have a bunch of random events in time, the intervals between them are distributed exponentially (with negative exponent), which means short intervals are much more common, i.e. the events usuall come in clusters. So encountering the same thing twice in short time is not particularly notable, it is just how chance works – but it still feels notable to us.
-
That's the main issue with what they are doing, yes.
It isn't the reason why every build system is terrible though. Every build system is terrible because each was created with a specific use-case in mind and it turns out the general problem space is large, each project needs or wants slightly different subset of it and nobody understands all of it. So chances are high no tool covers just what you want to use and you end up contorting some other things you need on top of it.
-
a multi-line log message is utterly unusable in any log collector
Only true for the log collectors that insist on thinking that all log messages are one line long.
Most of the ones I've seen know more or less complex rules to handle multi-line log entries, but as you can (and some classes do) dump arbitrary binary data as part of a stack trace, none of them is reliable.
-
@LaoC That would suggest the thing in Azure is particularly crappy (there is some configuration when you set up collecting logs from a virtual machine, but from AKS there is None™—you just enable it and that's all). Not that I would be too surprised.
-
If you have a bunch of random events in time, the intervals between them are distributed exponentially (with negative exponent)
Formally, that's a Poisson distribution, and it's absolutely how random uncorrelated events actually turn up.
-
Every build system is terrible because each was created with a specific use-case in mind and it turns out the general problem space is large, each project needs or wants slightly different subset of it and nobody understands all of it.
It's also very very difficult to write one well even for a specific case. A lot of programmers start from writing things operationally (transform file A into file B by running PQR with options XYZ) and build up, whereas it's probably better overall to work top-down in a declarative manner. The best bits of make and maven both operate in this fashion, and the word parts are always where someone decides that they know best and starts fighting against the tool. (Being good doesn't mean being short.)
The other big problem is knowing what you can cache between runs. Cache invalidation is a known hard-in-practice problem.
-
-
@HardwareGeek The best bits are the fact that you can say “if this file is older than these other files, it needs to be rebuilt” and that it can handle the transitive closure of that. It's a very powerful concept for building languages where that makes sense in the first place. (Not all languages can be couched in those terms; I know that Java doesn't fit them, and C# probably too, and LaTeX is another sinner because
.)The syntax for that is a bit ooky though (especially with pattern rules!) and the way you give the instructions for how to actually do the build step can be weird. And then there's the things you can do with includes and functions and … well, I think I'm happier not thinking about those bits.
-
: Book my press conference at the Four Seasons.
: Sure boss!
Four Seasons Total Landscaping Press Conference
Four Seasons Total Landscaping Press Conference refers to a press conference which was held by the Donald Trump 2020 presidential campaign at the parking l
-
@Atazhaia aren’t you a little late?
-
The best bits are the fact that you can say “if this file is older than these other files, it needs to be rebuilt” and that it can handle the transitive closure of that. It's a very powerful concept for building languages where that makes sense in the first place. (Not all languages can be couched in those terms; I know that Java doesn't fit them, and C# probably too, and LaTeX is another sinner because .)
The things is that all languages actually can, at varying granualrity, but it has to be generalized to “if any of these files is older than any of those other files” (which make has trouble with) and then the compiler has to sort out the strongly connected set itself.
In Java the compiler needs the whole component, but any non-trivial project will have multiple components each producing a .jar and each jar only needs to be rebuilt if any of its sources changed. C# is the same, just the bundles are called .dll. The compiler handles dependencies between the sources itself, but for components that only have one-way dependencies between them, a lot of work can still be saved by checking timestamps to see which components need to be touched at all.
-
The best bits are the fact that you can say “if this file is older than these other files, it needs to be rebuilt” and that it can handle the transitive closure of that. It's a very powerful concept for building languages where that makes sense in the first place. (Not all languages can be couched in those terms; I know that Java doesn't fit them, and C# probably too, and LaTeX is another sinner because .)
The things is that all languages actually can, at varying granualrity, but it has to be generalized to “if any of these files is older than any of those other files” (which make has trouble with)
Correct me if I'm wrong, but isn't that solved in all practical cases by simply making each file in group B depend on every file in group A?
-
@Gąska Not in make. The way make treats rules with multiple targets is too dumb to work properly in some cases.
-
Correct me if I'm wrong, but isn't that solved in all practical cases by simply making each file in group B depend on every file in group A?
You can force it, but it's really horrible and painful (BTDT back with Java 1.0). It's much easier to use a tool that understands what is going on instead. For example, if you're after a lot of the make aesthetic with Java and don't have complicated dependency issues, use ant. More complex projects are better using one of the more advanced systems like Maven.
