bmitch3020

It's not picking, it's brute forcing every combination. Lishi and other lockpicks require tension and feedback, often one pin at a time, which is the opposite of what this tool is doing.

The spectrum comes with multiple tradeoffs, and isn't a simple "bare metal is more secure" narrative. Because as you move into VMs, containers, and code sandboxes, you lose isolation which increases risks, but you also gain capabilities to limit the application which decreases risk. So I believe the most secure approach is layered with much multiple types of isolation working together.

For example, you may isolate a specific customer to bare metal so an escape doesn't compromise other customers. But within that bare metal, you may run containers because they make it easier to work with a read only root filesystem that's also trivial to upgrade. You can also add on user namespaces and seccomp in the container to minimize the risk of a container escape. And then the application may have its own sandbox that limits individual capabilities and which API calls it can run.

Every use case is different, and some layers may not be available depending on that use case. But rather than picking one point on the spectrum, one should pick a list of technologies that best solve each use case.

I was able to get past that (Firefox on the Desktop) by clicking the "see details" button and then clicking the "ignore the risk" link. It took me a while to actually read the text too.

There's also powerline communication that these drones could use, relaying a signal to a second drone perched back in friendly territory. And if the military is going around blowing up all of their power transmission lines, that's also going to hurt them.

A jammed drone that's perched on a power line wouldn't fall out of the sky, and doesn't need to transmit 24x7, only when it detects some activity. The lack of a signal from it would itself be a signal of where the next attack is coming from. Anti-jamming weapons (missiles and autonomous drones) would also be useful, that lock on to any signal jamming sources and deliver the munitions directly to the target that's advertising itself.

I'm surprised this isn't already happening in Ukraine. They could fly small surveillance drones deep in enemy territory, perch on a power line, and send back lots of data. Not just video, but also sound and triangulating signals. This would also be useful in fog by monitoring major roads where high altitude drones and satellites would be obstructed.

NSA's National Cryptologic Museum[0] is a good one in the DC area. There's also the Smithsonian Air & Space, but that gets outside of the tech focus here.

[0]: https://www.nsa.gov/museum/

As someone that spent a fair bit of time answering questions on StackOverflow, what stood out years ago was how much the same thing would be asked every day. Countless duplicates. That has all but ceased with LLMs taking all that volume. Honestly, I don't think that's a huge loss for the knowledge base.

The other thing I've noticed lately is a strong push to get non-programming questions off StackOverflow, and on to other sites like SuperUser, ServerFault, DevOps, etc.

Unfortunately, what's left is so small I don't think there's enough to sustain a community. Without questions to answer, contributors providing the answers disappear, leaving the few questions there often unanswered.

Thanks. Here's an alternate Reuters link: http://archive.today/GWDYr

This project even depends on go-containerregistry. Also in this space is RedHat's scopeo, Microsoft's oras, and my own regctl.

And my favorite project for inspecting layers is Jon's https://oci.dag.dev/.

1. AI training companies don't care about your license, they'll still train on your software regardless.

2. Your software needs to be distributed with a license that is compatible with your dependencies. You can't add restrictions if your dependencies forbid that.

3. No one will use your project if it doesn't have an OSI license. It's not worth the time and effort to read every license and get it approved for use by the legal team. If you're doing anything useful, someone will make an alternative with an OSI license and the community will ignore your project.

C3 also pushes to YouTube: https://youtu.be/q-_YVIIrF6A

Absolutely. I say that being an OSS maintainer is a job, which can easily become a full time job, where the pay is often non-existent. If you have a separate full time job, you now have to choose:

1. Work two jobs until you burn out.

2. Quit your paying job and hope you have you don't go broke.

3. Scale back or quit maintaining OSS projects.

I think companies, governments, and societies could do a better job funding this work. But since this is a "tragedy of the commons" problem, I'm not holding my breath that this will happen before the public experiences a lot more pain from failures.

Printed letters are less appreciated because it shows less human effort. But the words are still valued if it's clear they came from someone with genuine appreciation.

In this case, the words from the LLM have no genuine appreciation, it's mocking or impersonating that appreciation. Do the people that created the prompt have some genuine appreciation for Rob Pike's work? Not directly, if they did they would have written it themselves.

It's not unlike when the CEO of a multi-national thanks all the employees for their hard work at boosting the company's profits, with a letter you know was sent by secretaries that have no idea who you really are, while the news has stories of your CEO partying on his yacht from a massive bonus, and a number of your coworkers just got laid off.

The signal to noise ratio cannot be ignored. If I ask for a list of my friends phone numbers, and a significant other can provide half of them, and a computer can provide every one of them by listing every possible phone number, the computer's output is not something we should value for being more complete.

Buildkit can be very efficient at caching, but you need to design your image build around it. Once any step encounters a cache miss, all remaining steps will too.

I'd also avoid loading the result back into the docker daemon unless you really need it there. Buildkit can output directly to a registry, or an OCI Layout, each of which will maintain the image digest and support multi-platform images (admittedly, those problems go away with the containerd storage changes happening, but it's still an additional export/import that can be skipped).

All that said, I think caching is often the wrong goal. Personally, I want reproducible builds, and those should bypass any cache to verify each step always has the same output. Also, when saving the cache, every build caches every step, even if they aren't used in future builds. As a result, for my own projects, the net result of adding a cache could be slower builds.

Instead of catching the image build steps, I think where we should be spending a lot more effort is in creating local proxies of upstream dependencies, removing the network overhead of pulling dependencies on every build. Compute intensive build steps would still be slow, but a significant number of image builds could be sped up with a proxy at the CI server level without tuning builds individually.

> The current recommendation is rules_oci, which takes the opposite approach: use only off‑the‑shelf tools...

I'm the author of one of those off the shelf tools, and the rules_oci decision here always struck me as a bit unusual. OCI is a relatively easy spec with a number of libraries that implement it. Instead of creating a custom build command that leveraged those libraries to be an efficient build tool, they found commands that could be leveraged even if image building wasn't their design.

It looks like rules_img is taking that other path with their own build command based on the go-containerregistry library. I wish them all the best with their effort.

That said, if all you need to do is add a layer to an existing base, there are tools like crane [0] and regctl [1] that do that today.

The reason other build tools typically pull the base image first is to support "RUN" build steps that execute a command inside of a container and store the filesystem changes in a new layer. If that functionality is ever added to rules_img, I expect it to have the same performance as other build tools.

[0]: https://github.com/google/go-containerregistry/blob/main/cmd...

[1]: https://regclient.org/cli/regctl/image/mod/

This story missed a glaring detail. There are simply more data centers in northern VA [0]. More than the rest of the US by a wide margin, or the entire EU+Asia. Things break here because it's where most things are.

[0]: https://www.datacenters.com/providers/amazon-aws/data-center...

That's the "initial bootstrap" announced back in 2023. Today's announcement is being discussed at https://news.ycombinator.com/item?id=46334333

This doesn't give a lot of hope for what's happening in America. But for those outside of the US, there's already a push to avoid US tech businesses. They prefer local clouds, ideally those run by non-US companies. And there's a lot of effort to shift to Linux on their government machines. While that hurts the US soft power, it improves their resilience from monopolies in the US, and I'm all for that.

Previously shared at https://news.ycombinator.com/item?id=46291509

Previously shared at https://news.ycombinator.com/item?id=46291509

No changes for now based on a combination of:

1. Lots of external references to the GitHub repository would need to be updated. (I probably should have used a vanity URL for the Go module name, but it's a bit late for that now.) 2. They haven't started charging for open source projects yet. (Not that other behaviors of GitHub make me happy.) 3. Some of my usage involves projects where I'm a maintainer but not the project owner.

I support the concept of taxing wealth, but I've yet to find a good way to implement it. The two biggest issues are that wealth is easily moved to places where it can't be taxed, and those making the tax decisions are easily influenced by those with wealth.

Wealth moves in lots of ways. Yes, as has been pointed out, we over value stock assets. When you own a significant percentage of a company, you can't just sell that ownership at the last trading price (the stock price would quickly crash). Wealth is also moved between national borders, allowing the wealthy to shop for the lowest tax location to stash their funds. Property can't be moved, but it can be financed with debt, making it taxed at effectively 0%. And the other side of that debt may just be an overseas shell company. There will be entire industries formed around avoiding a wealth tax, funded by the wealthy.

But probably the most capital efficient way to avoid the wealth tax is to buy politicians, influence the elections, and invest in lobbyist, which the wealthy do in the US to avoid taxes. Until money is removed from politics, I'm not holding out any hope that we'll find a way to tax the wealthy.

Missing from the article is any details on ventilation. You need fresh air to survive, which means non-water tight holes will be somewhere on that thing. Normally on a boat, they would be on the part that's above water. On a spinning ball, that wouldn't be an option.

My best guess is that it will be integrated in the center tube. Buoyancy ensures the center of the ball is usually above water, and one end of the tube would always be above water.

I'm a fan of the Go proverb "a little copying is better than a little dependency"[1] and also the "rule of three"[2] when designing a shared dependency.

I think the JS developers could take a lesson from the Go proverb. I often write something from scratch to avoid a dependency because of the overhead of maintaining dependencies (or dealing with dependencies that cease to be maintained). If I only need a half dozen lines of code, I'm not going to import a dependency with a couple hundred lines of code, including lots of features I don't need.

The "rule of three" helps avoid premature abstractions. Put the code directly in your project instead of in a library the first time. The second time, copy what you need. And the third time, figure out what's common between all the uses, and then build the abstraction that fits all the projects. The avoids over-optimizing on a single use case and refactoring/deprecating APIs that are already in use.

[1]: https://go-proverbs.github.io/ [2]: https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...

A detail not included here, but important for people interested in the sea level, is the effects of the wind. Lots of places along the east coast of the US experience mild tides, but a steady wind in the right direction will push sea levels up in various bays and inlets. The storm surge of a hurricane turns it up to 11.

I'd like to see a website that ranks vehicles by make and model. That would influence shopping behaviors, and consumers would influence manufacturer behaviors.