That means when one goes out of whack, someone will notice. E.g. let's say the mathematical property is correct, but someone optimizes some behavior. Without tests or verification that could break production or worse: not break it, but break security without anybody noticing.
Exactly. As a media tech guy, my best feedback during the past decade of work was always linked to some lazy fuckup of someone else that I "heroically" rushed in to fix by fixing some noob level misuse.
Meanwhile the actually most heroic work I did was literal PCB level repair of a piece of ancient equipment whose function my boss wouldn't even understand, but the failure of which would stop our main room to a grinding halt. I then had to repeatedly ask to replace that equipment with a new replacement.
The highly visible work is often not the one that really counts, especially if you do not understand the subject matter.
Fixing something that’s visibly and publicly broken (or able to be sold) gets immediate praise. Preventing that issue before it occurs is thankless and invisible.
There are people doing that invisible work in every org. They normally become visible around a week after they quit.
Well and this goes further. You will find that some people will only chose to do the visible work. And this will often get great feedback from superiors, although it is the metaphorical equivalent of running around with a fire extinguisher and waiting for fire to pop up in an environment littered with flammable garbage, instead of — you know — ensuring that a fire doesn't start to begin with. So being celebrated for leaving everything at the brink of collapse, they will just do that, while ensuring to be in the spotlight when the shit inevitably hits the fan.
This can become so perverted that the number of extinguished fires is treated as some sort of metric for success by management, instead of seeing it as the failure it is.
Feel free to replace this with "all nighters" in other jobs. Who is more dedicated to the job, the person that just does it all in time with plenty of room for mistakes and unforseen circumstances or the one who slacks around 90% of the duration and then squeezes in some all nighters in the last hours? If your project has to rely on all nighters without good reason¹ this just indicates bad planning to me.
¹: There are legit reasons why working through the night is needed, e.g. the work you do can only be done during the night or there are legit last minute problems that nobody could have planned for. But if you literally have those every time, they are to be expected and are to be scheduled for during normal working hours.
The inverse-square law is only valid if the source is a point.
That means for many sources it is either the wrong law (e.g. loudspeaker array¹, long neon bulbs) because of the shape or it falls apart as you go so close to the source that a significant arc-angle is covered by the source itself meaning the law is no longer accurate. E.g. if you move ever closer to a light source with some diameter, at some point the result will look more and more like an area source and less like a point source. If you move so close that your entire horizon is covered by the light source it would be absurd to apply that formula since whatever is in front of the lamp gets the light from multiple directions now.
As such it is a great and useful simplification, but knowing the limits is equally important.
¹: this array tech is is used to get a more even level falloff from the combined wavefront so you don't have to blast off the ears of the front row while being barely audible in the back.
The main problem is that most business are run by people who have no believe at all that you could run a successful company without tricking people into buying your product. That means they don't even try. The rare exception are companies where rhe founder is e.g. a principled engineer, or some German family business that does nothing but ball bearings in the 4th generation and their business model is basically to be the best at ball bearings. Something like that.
But so many publicly traded companies appear to basically have become stock gambling dens that accidentally produce some products on the side out of legacy reasons.
Many are of the kind that use quality only as a marketing statement and when it comes to the engineering choice they will not even shell out 10 cents more for stainless screws to hold the thing together.
The reasons why there is little quality products is because the incentives all point in the other direction for most companies. And where they don't it is usually a special niche product or the intrinsic values of one or a few individuals making the choice to put their ideals above their wallet.
If we want this to change we have to change the incentive structure.
This is data that will be relevant for every single victim for decades to come and they will pay for this regularly, and it cannot be undone.
What amount per person is acceptable for a thing that simply should never happen?
I don't think "this will ruin my and my bosses life"-levels are over the top at all. Don't wanna risk it, then don't store the data. Usually for most purposes it would be e ough to store that yes, someone has a legit drivers license, which types of vehicles it is for and how long it is valid (if there is a limit).
We don't get to this kind of data reduction if people don't see data as the liability it sometimes is for their customers.
Yes but here is the catch. Surveillance comes with the incentives to us it for the personal gain. Or to phrase this differently: knowledge is power and thus the people who are already in power have good motivation to accumulate as much knowledge as possible in order to stay in power.
It is very easy to take the philosophical stance where every concept can be totally detached from the incentives it creates and the social dynamics it is part of. It is easy to take that stance, but it is very hard to use that stance to explain reality, because reality plays by more complex rules.
Please, always consider the status quo and the incentives involved instead of stating the surveillance equivalent of "weapons don't kill, people do".
This is btw. a very important consideration when you are teaching literally anything.
Telling people to imagine a cone, then a plane, then rotating the other slightly and slice through the cone without touching the base, and then looking at a normal angle at the 2D shape of the resulting intersecting surface is a really good way to explain ellipses.
IF the person you're talking to can do all these steps. Turns out some people can rotate a cow in their head and some can't. If you cannot, a drawing or animation can help a lot to get the point across. Now I haven't gotten a problem with imagination at all, but I can only imagine how hard some subjects might be if you can't do that in your head.
I would be very curious about a bit more concrete and substential criticism what is bad (or good) about how the both versions, that goes beyond general arguments like:
Just because it is Rust, it is not safe!
It worked before, don't replace it!
etc.
Not that these are not valid points of criticism, but in my opinion if we have two core utils we can (and should) pick the better one after careful continous evaluation. And if the old one is the better one on the day of the release, so be it. Having two competing solutions can have benefits for everybody looking for the best core utils they can get in the long run.
I had to reimplement and reverse engineer old tech myself as part of my dayjob and had those engineers seen my results it probably would have improved their work as well, since I usually found oddities that they probably did not intend to be that way. This means my work on their work could be seen as another pair of eyeballs, bullet-proofing their original work, instead of seeing me as a threat. That additional pair of eyeballs is crucial to open source software.
This is why it is sad that too much about this whole discussion feels like yet another culture war, heated on the stove of social media figures looking to convert heat into ad revenue.
Which is why I would love to have more concrete points of technical criticism of specific bits maybe even to specific lines in the code or specific reproducable behavior.
If we go the culture-war route nobody wins, if we discuss both solutions on their merits, we all can win.
I think a lot of the actual issues they're encountering are that the underlying POSIX APIs have a lot of sharp edges which the older versions of the tools have had enough time to work around, while the newer ones are generally running into the same rakes that have been there for decades. It takes a fair amount of time for those to be found and dealt with (though it also takes use, so it's a bit chicken-and-egg).
For varying definitions of broken. I know multiple people from broken regions of the world, who would dream to have it like the US. Then there are others who claim their system is broken and only a protest vote will send the sign, while where they live has one of thr highest standards of living in the world.
The absolute level of broken is mostly irrelevant, what counts is the direction of travel.
I can't shake the feeling that this is a bit like asking how someone got shot during a game of Russian Roulette. You have a bullet in the chamber and you roll, of course shooting the bullet may be a possible outcome.
LLMS with an access to a shell will at occasion do things that the shell allows them that have dire consequences. The only way to prevent that is to not put the bullet in the chamber.
That is worth the hassle for some applications.
reply