Re: You think it was just another isolated incident....?
They're playing the long game; plotting to kill you.
692 publicly visible posts • joined 3 Aug 2020
You gesture here towards the relationship between design, documentation, and tests.
Say there is a function `int AppendFile(Filename, Message)` with no other documentation. How do you test this function? There is the obvious "verify the contents of the file just written", but what else? Say the file does not exist, should the function create it? If that is an undocumented situation Then the best you can do is try it few times and decide that whatever it does now is "correct".
One of the many drawbacks of this is that you don't know what is undocumented behavior (still possibly needs to be tested) and what is undefined behavior (doesn't need to be tested). Arguably, since the user has been told nothing, all of this is both undefined and undocumented...poor test writer now gets to guess at which is which.
A function with no documentation makes no promises and has no bugs.
I have a very real example of this.
We needed to reliably generate a callback anytime a 3D camera changed position or orientation (there were of course context and other requirements that complexified this).
The solution was very simple; after every "step" of the display thread, we would check if the transform for the camera had changed and generate a callback if it had. Overall this took maybe an hour to implement.
The randomized test took a week to write. A few of the complexifying factors:
1. Most user functions that could change the camera were processed asynchronously.
2. Some operations which were nominally setting the camera wouldn't actually change the matrix (for example, setting it to the same position twice) and therefore were not expected to generate a callback.
3. The test couldn't check if that had happened, because requesting information about the camera would force the test thread to synchronize with the display thread, defeating the purpose of the test.
4. If you wrote to the camera twice in a row, those two operations might get merged. We didn't guarantee that writing to the camera twice would generate two callbacks.
5. We DID guarantee that the LAST callback would reflect the final state of the camera, so of course that had to be verified in the test
I find the focus on code coverage to be spurious.
My former boss once mentioned that she had run a tool to check our codepath coverage and it was getting close to %100.
I observed that one of the bugs that had been reported recently was `if the user makes a box editable, all subsequently created shapes will default to the colour blue`.
"Do any of our tests actually check that the default color is unchanged?"
We concluded that they did not.
Code coverage is useful as a tool for making sure you don't crash. It's not at all helpful for making sure that your code does what you expect; your `verification coverage` so to speak.
Yes, those are concerns, but they are long term concerns. They do not mean that the sanctions are not having the intended effect. It is a logical and expected consequence that if you cut off a nation's supply of some critical resource, they will develop alternatives as quickly as possible and your leverage will eventually slip away. That's one of the trade-offs you know you are making going in. The measures for success are the degree to which the sanction impacts the nation's ability to operate, and how long it takes them to develop the alternatives.
Now that being said, I think what you are arguing for here is that even if the sanctions are successful, they are still a mistake. Obviously that's something we can only really know in hindsight, but I feel like the threat of China using this to fund further chip development is middling at best. If it's something China really wants to do, they are going to make it happen. I doubt that Russian business is going to be the major factor that pushes China's chips to meet or exceed the performance of western designs.
I'm quite sure there was a meeting when discussing the sanctions in which somebody said something like:
"...and Russia will probably started getting processors from China. Here's a report on the current state of their CPU development, with projections for their performance in the next 5, 10, and 20 years under various conditions. In making a decision, we should balance the short-term impact of the sanctions against any possible long-term affects on these projections."
The point is, if given a choice you would not build a server using Loongson chips. You would use Intel or AMD. That off-brand chips are being considered means the sanctions are working, insofar as they are preventing Russia from obtaining the higher quality hardware. That is one of the goals of sanctions.
Imagine the Russians soldiers were all being transported in Trabants. You would not say "sanctions on APCs aren't working, look they are just using Trabants!". You'd say "sanctions on APCs are working, they are reduced to using Trabants".
The point is, the heated seat doesn't need an EXTRA battery. Ultimately, the source of energy is the main battery, and it goes through the intermediary of the 12V system.
Just as the heater in an ICE car is "free" because the waste heat it uses is going to be generated anyway, the 12V battery in an electric car is "free" in that you are going to need it whether you have heated seats or not.
But yes, thank you for pointing out this detail as I did skim over it.
Jesus. Of course I meant it was thermodynamically "free", but that doesn't mean that Austin won't charge you for it. For reference, the farking TRABANT had hot air (but no fan as I understand it, they just let you open a port from the engine compartment to the passenger cabin).
Why would you need extra batteries exclusively for powering the heated seat? In an ICE car they are run off the alternator, or the existing battery if the engine is turned off. In an electric car, devices like heated seats and air conditioning are run off the main battery, so if you don't use them you get more range.
You are looking at 2-3 kg for heated seats, which is not nothing but also not much, it's mostly just some wiring and resistive elements. They don't use power when they are turned off (assuming competent electrical design). Certainly they consume a comfortable amount of energy when turned on, but of course in an electric car so does the hot air (with an ICE you get that "for free").
I think you will find that in Canada, heated seats are well appreciated.
Because we assume that if your job cannot be done from home, then this conversation is not relevant to you. Would you like every single post about WFH to end with "unless of course your job can't be done from home, in which case you will have to go to work"? That seems redundant, given that it is intensly obvious.
Yes, seriously this is terrible. You should be able to operate a car completely by feel under normal circumstances, for reasons that should require no explanation.
I just bought a current-gen Mazda3. One of the things I like about it is that the screen is not a touch screen, it's all done with physical controls. Of course, aside from nav (which it doesn't fecking include)...all I really want is aux-in and a volume knob.
4 wheels and a motive source has gotten really unessecarily complicated.
Heh, I had a similar experience with an Indigo2 I bought off eBay a while back. I sent the password file to a friend who is into encryption, he was able to sort them all out. Unfortunately it was primarily a networked machine, so there was nothing interesting on the drive :(
Also, it's so big/heavy/loud that I basically never use it p_p
Had one not too long ago. 30-something year old company acquired by massive corporation. Large number of employees have been there for decades. Less than one-year in, manager for the division (meaning multiple acquired companies) sends an email about how a few years ago "we" were only recently a "startup" (as in that division, the parent is vast), and how far "we" had come in the industry in such a short time. You know, by buying a bunch of people who had basically participated in building said industry from the earliest days of the PC.
Tone-deaf is right, I couldn't believe it. I wasn't even alive when some of these people started working here, I and I was offended.
The other thing keep these off commercial jetliners of course is that when you burn fuel, the fuel is gone. A battery is just dead weight. Consider that airliners which have to make emergency landings just after take off generally need to dump fuel to do so safely. What are you going to do with a battery, chuck it out the window into the sea? Actually, probably yes that...
Also on that subject, I suppose I would expect to see batteries in airlines as modular things that get swapped between each flight (no down time for charging). You would also be able to specify "I only need half-capacity for this trip", just as pilots do with fuel.
There is a lot in the economics of flying that would need to change for battery powered air liners.
I basically want the following:
1. A "markup" editor for confluence pages, because they clearly contain all kinds of bullshit formatting behind the scenes that can be very difficult to mainpulate the the "what you see is sometimes what you get" editor.
2. The ability to share specific pages within a space with external teams, while leaving pages higher up protected (for example, you don't need access to my whole space, but I can give you access to a specific spec sheet nested in some page structure somewhere).
3. Images with captions
4. A GUI for providing links to page anchors.
There are probably other things, but that's the gist of it. None of those involve machine learning.
That bit about "because they can" is so important. Unless you explicitly state in your documentation that something is undefined behaviour, you must do something intelligent. I find myself using that phrase often; "it won't WORK, but it will do something intelligent".
Even ignoring that you should expect users to do anything they are allowed to do, I feel that a system which does not handle all inputs is probably not well thought-through and generalized in its implementation. In general, a well made piece of software will have few edge cases because it will have systems which naturally handle most possible inputs.
That last point may be a pipe dream, but it's one I'm going to stick with :p
Never mind code coverage...you can test %100 of the lines, but you may not be testing all differentiated scenarios, or verifying all expected behaviour. Chasing the dream of "actually testing everything" is a significant endeavour, requiring you to foresee all permutations and expected outputs.
Deciding how much time to devote to tests is always a balancing act.
Totally not in a company that didn't do this, recently acquired by a company that does.
Totally not infuriated by dealling with people in said other company.
Me: "Oh, Edna has a problem that affects their next release and which involves my module, I will drop everything and spend working with them to fix it with no ticket."
Droid: "Sorry, I can't give you access to project B because this ticket was only for project A. Please close this ticket and create a new one for project B." - after they tried to close the ticket and it was reopened by my boss 3 times.