mowfask
Where are all the training-data poisoning repositories? Those set up so the next generation LLMs will be trained to include malware in the code they generate. Isn't that the new kind of supply-chain attack that's probably happening right now?
Super useful for running e.g. timing measurements and quick-and-dirty plotting. Or grepping through millions of signal transitions to pin down a nasty race condition.
https://community.chocolatey.org/packages/docker-engine
https://community.chocolatey.org/packages/docker-cli
So it seems the Docker Inc. enterprise licensing is all based on the "Docker Desktop" UI. Can someone confirm this?
I'm still at it, using an STM32 part with 40KB of RAM. Have never touched Smalltalk, instead I'm using Rust. It's going ok, though I'm only at day 12.
1. Instrument 2. Measure 3. Interpret 4. Act
Iterate as necessary.
I have come to see this pattern working on electronics design, embedded software, industrial control systems, networking and webapp backends.
Breaking it down:
1. Instrument
Understand subsystems and their interfaces. Use tooling around these interfaces to trace the interplay between subsystems. Make sure all tooling is synchronized so you can correlate information across tools via timestamps. If you can't instrument remotely, bite the bullet and reproduce locally. This ties back into the design phase: Design interfaces to be instrumentable, ideally remotely. Test points on PCBs, traceable APIs in software, using network protocols that tools like wireshark can decode. Pub/Sub systems are great for this, as you can easily add another subscriber for instrumenting all communication. Don't rely on "what happens to be available" for instrumentation. AWS CloudWatch will miss that one crucial piece of information. Your oscilloscope tip will not make reliable contact on a QFN pad. Simply stated: Become good at interfaces and make them accessible.
2. Measure
Take the time to properly run tests and gather data. For issues in systems spanning mechanical, electrical, digital and software domains, you won't have one tool to do it all for you. Data preparation and cross correlation will be a manual process in most cases. That is ok.
3. Interpret
This is about understanding your problem and digging down from high-level symptoms to low-level root causes. Don't jump to conclusions. Let the data sink in to identify second order effects. Don't rush it because of pressure from your boss or the customer.
4. Act
Now that you understand your problem at a deeper level, it should be straightforward to apply corrective action. This might not solve the issue yet, but you will get closer to the root cause.
Two notes:
* Never stop after step 4! Always iterate once more so you can be confident the issues is actually solved and not just hidden by some effect.
* If you're a team player, document each step. A short note and screenshot in an issue tracker go a long way.
About engineering mindsets:
I find it infuriating when people calling themselves engineers don't follow any practice like this. Yes, you can solve problems through sheer experience or by hitting your head against the wall for long enough. Alone. On simple systems. But working together on complex systems you have to apply some methodology. Doesn't have to be my methodology, just not no methodology. For me a big red flag is when engineers don't understanding why something works. Not understanding why something doesn't work is ok. We are human and systems are complex. But getting something to work, wondering why it does and then sending it to the customer? That's not engineering, that's tinkering. It's asking for trouble.
We use to chop 1m (~3feet) logs of a lot more compact wood (oak, beech), and this looks like a toy to me. Has anyone seen it used on more serious logs?
So it wasn't for economical reasons, after all!
That would mean they should have put into place institutions protecting them from said spying. Which would be taking (defensive) military action because of the actions of an allied government. Now what kind of alliance is that?!
TrueCrypt container which contains sensible project-data;
.ssh somewhere on that container with ~/.ssh linking to it;
Keepass for passwords, it's quite convinient.
Maybe Pray or something similar, haven't set it up myself yet...
EDIT: Watch it closely and you'll see the bug.
EDIT2: Okay, not really the bug, but @op: how about changing setInterval to 864ms? It really looks nicer ;)
On the other hand, more competition is probably healthy for this market...
Everyone is just talking about how to keep the children occupied with technology. I really think this is the wrong approach, there is so much more to learn and explore than stupid pixels on a screen.
When we were young my parents had the attitude that it's very important to get a "feel for the earth", in a very literal way. That's why we spend as much time outside as possible. One of the few things I remember about primary school: I was the only one who knew potatoes grow below ground. Where has this world come, that our children know so little about even the most basic stuff??
Actually, without the movable frame system hives wouldn't have much of a chance to survive (At least in our part of Germany). My only hive died this winter, because there was too much honey in it. When the hive cools down to the lower 20°C range in winter the honey crystallizes and becomes too hard for the bees to eat. If done properly, taking the honey and feeding the right syrup (which is not just sugar and water) will keep them alive, as it doesn't crystallize.
I'm quite sure the cell foundation you get in here are of natural size and I have not experienced any problems with the bees building natural combs for drones. Here again the frame system is just great for helping the hive: It allows for the drone combs to be removed after the cells have been sealed, which reduces Varroa, as these prefer drones as hosts.
Another considerable advantage of Langstroth vs. classical skeps: You don't have to kill the hive to get honey/wax. Plus you get pure honey and not some honey - dead bee - crushed larvae - coctail.
1) Build that next big thing everyone uses, which improves peoples lives (which probably only is in the list because I spend too much time on HN)
2) Help people in a very direct manner. A great example for this is Johnny Long, who stopped hacking for money and went to Uganda, using his energy and skills to help those who need it most.
3) Have and raise children. To me this seems to be the most commonly chosen path, mostly because it's only natural. But if you think about it, having children and raising them to be goodhearted, responsible persons with a high moral self-demand [1] is a honorable way of improving the future of our world. Thinking about it this way, though, will probably make the decision of having children myself one day really hard, the responsibility seems remarkable.
That said, it probably comes down to what it always comes down to in life: strike an appropriate balance between all factors of life.
[1] It's really hard to say what makes a good person. I hope you get the idea :)