Could someone give an ELI5 on this? I know talloc's snprintf test is broken, but I'm not sure what the point is.
It’s hard work printing nothing
41–50 of 79 posts
Re: It’s hard work printing nothing
#42Earlier quoted context omitted.
Eh, in Ruby, just installing Rails is like 80 dependencies. Would be surprised if Django wasn't 40+
Django itself has no requirements besides the standard library: % pip freeze Django==1.10 That's after a pip install in a fresh virtual environment.
Rails itself is broken up into smaller packages, so you can only load parts of Rails if you want. Very few apps actually do. (and that's only like 8 of the 80)
Re: It’s hard work printing nothing
#43Earlier quoted context omitted.
> Here is one example of an ironic piece of waste: Sam Leffler's graphics/libtiff is one of the 122 packages on the road to www/firefox, yet the resulting Firefox browser does not render TIFF images. For reasons I have not tried to uncover, 10 of the 122 packages need Perl and seven need Python; one of them, devel/glib20, needs both languages for reasons I cannot even imagine. This is a better read than the linked ar…
That's rich coming from PHK, whose software requires a full C compiler as a runtime dependency. The reason Firefox pulls libtiff is simply because it uses a generic image manipulation library (libgdk-pixbuf), which in my system it's also used by many other applications - which do require TIFF support. I guess if you have a desktop with only FF installed that may be a waste, but how many people really have FF and not…
That's a very sensible requirement. It says in the docs exactly what they use it for. Not like they put in a bunch of other dependencies and some 3rd degree dependency pulled in a C compiler.
Re: It’s hard work printing nothing
#44Earlier quoted context omitted.
> Here is one example of an ironic piece of waste: Sam Leffler's graphics/libtiff is one of the 122 packages on the road to www/firefox, yet the resulting Firefox browser does not render TIFF images. For reasons I have not tried to uncover, 10 of the 122 packages need Perl and seven need Python; one of them, devel/glib20, needs both languages for reasons I cannot even imagine. This is a better read than the linked ar…
The firefox example is not true. Firefox can render tiffs inside PDFs.
I don't believe that was true when the article was written.
Re: It’s hard work printing nothing
#45There’s an argument to be made that silly error messages are better than crashing browsers There's an argument, but it's a really lousy one. If you're passing NULL as a string to printf, your code is broken . A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong .
I agree with this 100%. Crashes are a way of not-so-subtly reminding you that your code is still buggy, and exactly where it crashed is usually a good indicator of where to start debugging.
Rule of Repair: Repair what you can — but when you must fail, fail noisily and as soon as possible.
To take this example to the extreme, imagine if the default state of the runtime/OS were configured so that invalid memory accesses didn't cause segfaults, but e.g. yielded -1 or 0 or some other value and simply let the code continue... by the time you see something wrong, it's probably very far away from what originally caused it.
It's funny to see OpenBSD's printf doing this explicit null-checking and that they are considering to remove it, when AFAIK Microsoft's C library printf has always done the IMHO sane thing of just reading and writing to whatever addresses it's been given --- and if they turn out to be invalid, like null, then it crashes as it should.
Re: It’s hard work printing nothing
#46Earlier quoted context omitted.
I think not a single actual application is completely well formed. They all work on luck. Especially in the embedded world. Btw, my android just rebooted.
"In the embedded world" covers a huge area, including mission-critical avionics code, which likely has much higher safety standard than, say, Android.
Although from hearing about the Apollo Guidance Computer, it's just as much of a miracle they were able to get it to work without any debugging or compilers, with basically one shot to write the program to ROM.
Re: It’s hard work printing nothing
#47The more I see of what goes on under the covers, the more surprised I am that anything works at all. As an example, every gtk+ program I run spews thousands of errors to the console. Why? Are they bad? The programs seem to run anyway, never crashing more than one would expect. So … why the console spam?
I think not a single actual application is completely well formed. They all work on luck. Especially in the embedded world. Btw, my android just rebooted.
Wow. How do you put up with that kind of behavior from such a mission critical device like a phone?
Re: It’s hard work printing nothing
#48I always thought low-level programmers (C, C++, assembly, etc.) cared more about minimal abstractions and minimizing dependencies. But it turns out it's the same story no matter what level of the stack you are on. Currently working on a project with 200+ requirements in requirements.txt and growing. Before anyone says microservices just realize that you have taken the same programmers that made this mess and shoveled…
I always thought low-level programmers (C, C++, assembly, etc.) cared more about minimal abstractions and minimizing dependencies.
There are two types of "low-level programmers" I've encountered: there those who truly "think low-level" and enjoy it, the ones who will avoid huge amounts of abstraction and general inefficiency in favour of small, efficient and usually very simple solutions; and those who may be using a low-level language, but are actually using it from the mindset of someone who loves abstraction and libraries more than anything else. I'm in the former group.
Re: It’s hard work printing nothing
#49There’s an argument to be made that silly error messages are better than crashing browsers There's an argument, but it's a really lousy one. If you're passing NULL as a string to printf, your code is broken . A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong .
The bogus UI message showing "(null)" is a pretty obvious flag that a bug needs to be tracked down and fixed too - potentially better than a crash, because this way you'll have a pretty decent idea where to start looking for the bug before you even fire up the debugger.
Re: It’s hard work printing nothing
#50There’s an argument to be made that silly error messages are better than crashing browsers There's an argument, but it's a really lousy one. If you're passing NULL as a string to printf, your code is broken . A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong .
> "A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong."
Not necessarily. Wrong is relative and can have either small or large costs, and crashing also has a cost to the user (and to the developers if they lose users.)
As an example, I play a very old video game (Descent). One of the major problems with one of the modern source ports is that the game crashed under certain conditions -- like if it received a malformed data packet. This is a game that's already fairly tolerant to lost data, so just dropping a bad packet is an acceptable result. By comparison, crashing in the middle of a competitive match is a much worse result, because it affects things like momentum and where various powerups have been left around the map.
It would be great to fix the bug that was resulting in malformed packets -- but the cost of directly affecting a high-stakes match is not worth it. I'd rather tolerate a fraction of a percent of lost data every game for the next 20 years than ever have a high-stakes match where the result was tainted by a badly-timed crash.