It had some good results but made up a command called `cargo publish --workspace` when asked about publishing a Rust workspace project to crates.io -- that command would be handy, but doesn't exist. Overall 7/10
I agree with the article. The SAT is a chance for any student, regardless of background, to demonstrate academic skills and the ability to succeed. I was one of those students -- my SAT score got me a full merit scholarship. I wasn't as polished or accomplished as other students around me, but I was able to show that yes, I am smart, and that I can succeed academically at the college level. I did go to a korean after-school program to help study for it though.
I feel like instead of dropping the test they could provide free resources to students to prepare for it. At least get them familiar with the structure of the test and encourage them to do the best they can. A lot of kids like those in the article would stand to benefit.
The only winner from getting rid of the test is rich, stupid kids that don't do well regardless of how much prep they get. They then go on to cheat and BS their way through college and use their network to land jobs. Poor and disenfranchised students will continue to be marginalized.
Just find a new gig. I also worked from 2019-2022 for a company without a raise for 3 years. Arguably, I stayed six months too long, but we were doing some greenfield stuff that was actually fun.
There's no need to over-analyze or justify it either. Get a 20% minimum bump by switching employers, like every other person here would do.
The papers are all based in cryptography and zero-knowledge proofs specifically. I would argue they are in the first category you described. They seem to be descriptive and walk through a problem but there are no experiments or anything, just theorems and proofs. I get lost pretty easily
I think I'm on the "just trust that the papers you receive are the state of the art in this field and think about how to implement their conclusions in software" path. I actually prefer that, because I'm not really much of an academic. I would prefer to focus on the code and implementation details versus the theory stuff.
Distilling it down from a really abstract level to something to implement is hard though. To be fair, I'm just starting out with this so it should get easier from here I suppose.
I would agree. I'm actually quite a few years out of school though, I have around 5 years of experience. I do have a bit of graduate-level experience but basically never did any real kind of research. That's why I think I'm struggling lol.
I find it a bit surprising that only a few people knew about this code change. I expect other engineers found that piece of code and probably didn't ask any questions. It's normal after working on a codebase for a while to explore all the different branches. It takes a few years though, from what I gather the codebase was only 2-3 years old, so it's possible no one noticed.
I think this revelation points to the further guilt of SBF and his excuse that "he was incompetent" will fall face down under scrutiny.
Containers are great tools that can encapsulate an application and its dependencies, allowing apps to run anywhere in a streamlined way. Some container images contain commands to start a long-lived binary, whereas others may simply contain data that needs to be available in the environment (for example, a Kubernetes cluster). For example, operator-framework bundles and crossplane packages both use container images to store Kubernetes manifests. These manifests are unpacked on-cluster and made available to end users.
One of the downsides of using container images to store data is that they are necessarily opaque. There's no way to quickly tell what's inside the image, although the hash digest is useful in seeing whether the image has changed from a previous version. The options are to use docker cp or something similar using podman or containerd.
Using docker cp by itself can be cumbersome. Say you have a remote image somewhere in a registry. You have to pull the image, create a container from that image, and only then run docker cp <container-id> using an unintuitive syntax for selecting what should be copied to the local filesystem.
dcp is a simple binary that attempts to simplify this workflow. A user can simply say dcp <image-name> and it can extract the contents of that image onto the local filesystem. It can also just print the contents of the image to stdout, and not create any local files.
I'm actually running into this issue right now, in the context of a test that I'm writing. The test needs to copy some data out of an image. The image contains a full filesystem, and some of the files are read-only. The copy is done via docker cp, which requires elevated privileges on the host to copy read-only files (see https://github.com/moby/moby/issues/35987 for more info).
As a result, the test needs to be run using sudo to work correctly. The test environment is containerized, so there is a Dockerfile, but as the article mentioned the user in the container should not be root. Is there any plausible way around this? Updating the image is not under my control, and changing the copy code is also riskier than I would like.
Since this is in the context of CI, the threat is lower than live production, but still....
Interesting how they enforce the namespaced scope for ACK custom resources. This is a logical design choice but makes it trickier for operators to use.
Say I have an operator watching all namespaces on the cluster. Since operator CRDs are global in scope it makes sense for some operators to be installed as singletons. A CR for this operator gets created in some namespace, and it wants to talk to s3 -- it has to bring along its own s3 credentials and only that CR is allowed to use the s3 bucket? You can imagine a scenario where multiple CRs across namespaces want access to the same s3 bucket.
A dilemma that we are running into at work is that we have all our software open source and readily available on github but use an internal bug tracker to manage bugs picked up by QE and other people in our org. These bugs are given significantly higher priority than our GH issues and we end up with a pile of GH issues that no one has the time or ability to adequately track. As our team recently set up its own open source working group and generally is making open source contributions in other projects a higher priority I see this problem getting worse. Does anyone have any suggestions how to overcome such an issue?
And I guess I'd just like to add my two cents: sometimes your issues are not being adequately triaged because the project is using another system for bug tracking and the engineers are slammed fixing those bugs instead lol.
How much of being a 10x dev comes down to understanding the existing system really well and being able to iterate quickly?
I wouldn't call myself a 10x dev but at my last startup I was very productive, definitely more than expected at my skill level, because early on I had a lot of access to the people who designed our (undocumented, untested, and buggy) backend system. Then when I got a feature ticket (consisting of 3 words) I was able to quickly bang it out and deliver it, whereas other more senior engineers struggled because they didn't fully understand how the backend microservices actually worked and talked to each other.
Now I work at a big tech co and I'm in the latter position: I have a hard time understanding our complex CI/CD, and don't have nearly as much understanding of all the existing components. As a result I'm not nearly as productive and back to feeling like a 1x or 0.1x dev.
I mostly read fiction books and technical O'Reilly stuff. Would highly recommend both. Reading books is infinitely more relaxing than browsing content online aimlessly.
It's a fair criticism of the older versions of Go - it did not have good dependency management out of the box. Probably due to the famous Google monorepo and how they did not need to tackle that issue head on themselves. However the past few years Go has really addressed this problem, first through the dep project (which has your standard .lock file for pinning dependencies similar to Node) and now go modules (included in the latest Go versions). Now you get dependency management out of the box. Your point is valid but does not reflect the modern state of Go.