You can actually make go spit out .o files and link it with your favorite linker. Bazel does this, if you ask it to.
I played a lot with experimental linkers when I was trying to get build time down for our (well, $JOB-1's) large Go binary, but they didn't help that much. The toolchain that comes with Go is quite good.
I think it depends on the codebase. There are some reflection calls that you can make that can cause dead code elimination to fail, thought I believe it's less easy to run into than it was a few years ago. One common dependency, at least in my line of work, is the Kubernetes API and it manages to both be gigantic and trigger this edge case (last I looked), so yeah, the binaries end up pretty big.
Another thing that people run into is big binaries = slow container startup times. This time is mostly spent in gzip. If you use Zstandard layers instead of gzip layers, startup time is improved. gzip decompression is actually very slow, and the OCI spec no longer mandates it.
When I was in college I wrote a computer program (yes, involving yellow text) that couldn't be photocopied because I put the "o"s in the right place to trigger the eurion-finding algorithm. People thought it was neat.
I love this site so much. I learned that there are two typologies of shoelace knots -- one falls apart instantly (https://www.fieggen.com/shoelace/grannyknot.htm), and the other is as secure as a double knot. I also learned the fast way to tie shoes, https://www.fieggen.com/shoelace/ianknot.htm. The latter is fun, I have used it every day for decades and people are always amazed when you teach them.
This is why I think things like devops benefit from the traditional computer science education. Once you see the pattern, whatever project you were assigned looks like something you've done before. And your users will appreciate the care and attention.
Interesting application! A friend of mine built a model like this to help her make her voice more feminine, and it is neat to see a similar use case here.
It is really hard to describe how slow sha256 is. Go sha256 some big files. Do you think it's disk IO that's making it take so long? It's not, you have a super fast SSD. It's sha256 that's slow.
It depends on the architecture. On ARM64, SHA-256 tends to be faster than BLAKE3. The reasons being that most modern ARM64 CPUs have native SHA-256 instructions, and lack an equivalent of AVX-512.
Furthermore, if your input files are large enough that parallelizing across multiple cores makes sense, then it's generally better to change your data model to eliminate the existence of the large inputs altogether.
For example, Git is somewhat primitive in that every file is a single object. In retrospect it would have been smarter to decompose large files into chunks using a Content Defined Chunking (CDC) algorithm, and model large files as a manifest of chunks. That way you get better deduplication. The resulting chunks can then be hashed in parallel, using a single-threaded algorithm.
As far as I know, most CDC schemes requires a single-threaded pass over the whole file to find the chunk boundaries? (You can try to "jump to the middle", but usually there's an upper bound on chunk length, so you might need to backtrack depending on what you learn later about the last chunk you skipped?) The more cores you have, the more of a bottleneck that becomes.
You can always use a divide and conquer strategy to compute the chunks. Chunk both halves of the file independently. Once that’s done, you redo the chunking around the midpoint of the file forward, until it starts to match the chunks obtained previously.
It's mixed. You get something in the neighborhood of a 3-4x speedup with SHA-NI, but the algorithm is fundamentally serial. Fully parallel algorithms like BLAKE3 and K12, which can use wide vector extensions like AVX-512, can be substantially faster (10x+) even on one core. And multithreading compounds with that, if you have enough input to keep a lot of cores occupied. On the other hand, if you're limited to one thread and older/smaller vector extensions (SSE, NEON), hardware-accelerated SHA-256 can win. It can also win in the short input regime where parallelism isn't possible (< 4 KiB for BLAKE3).
People travel with liquids they don't intend to eat. Shampoo and all that.
There is also nothing that precludes explosives from being non-toxic. Presumably your demise is near if you are carrying explosives through security. What do you care about heavy metal poisoning at that point?
But also you can fill up a water bottle after security. Wouldn't it be fairly easy to make a pen or similar innocuous item out of sodium, and drop it in a bottle of water to make an explosion?
My point is that security can never be strict enough to catch someone who's truly motivated and funded, without making it impossible to admit people at a reasonable pace, and the current rules don't really help with that except for cutting down on the riff raff terrorists. But maybe those are more common than a trained professional with high tech weapons, I don't know.
FWIW, sodium in water is such a pathetic explosion that it would mostly be an embarrassment for the would-be bomber. It wouldn’t do any meaningful damage.
An explosion with real gravitas is far more difficult to execute than people imagine. (see also: people that think ANFO is a viable explosive) This goes a long way in explaining why truly destructive bombings are rare.
The USA mostly used .50 caliber machine guns, usually with a mix of ammunition including incendiary bullets so that a hole in a fuel tank meant a large fire. Fighters from the other major combatants usually had 20mm autocannons in addition to smaller machine guns.
Allied fighters were also equipped with self-sealing fuel tanks, so a hit doesn't automatically mean it burns. I don't have any stats on it, but they wouldn't have added the self-sealing if it didn't improve the survivability.
The sensitive part for a P-51 was the cooling system. Any hit on that, and you're done.
B-17s famously endured a lot of battle damage. The usual vector of attack on them was head on, and they aimed for the cockpit. (Attacks on fighters usually aimed for the cockpit, too.)
I know that tracers were used in WW1 to set observation balloons (filled with hydrogen) afire. Tracers in WW2 were used so the gunner could direct his aim. I haven't read that they were intended for the fuel tanks, but that could be true.
109's would frequently sneak up from the rear, and if the tail gunner was not paying attention, it was an easy kill. My dad (B17 navigator) said the tail gunners, once they spotted a 109, would fire a few rounds of tracers long before the 109 was in range - just to let the pilot know they were awake and aware. It usually meant the 109 would veer off.
Incendiary ammunition is distinct from tracer, though some projectiles have both functions, and tracers have a chance of causing a fire. Incendiary projectiles usually ignite or explode after impact.
> My point is that security can never be strict enough to catch someone who's truly motivated and funded, without making it impossible to admit people at a reasonable pace, and the current rules don't really help with that except for cutting down on the riff raff terrorists.
This is the classic HN developer arrogance and oversimplification, but let's accept this as true for argument's sake. It turns out that "riff raff terrorists" are the only ones we needed to stop as there's been no successful bombings of Western airlines in 25 years, and there have been foiled attempts.
The existence of master locksmiths (and door breaching charges) doesn't mean you shouldn't lock your door at night.
Literally none of these were foiled by the security circus we all have to go through.
If anything, they are evidence that serious attempts are foiled by intelligence services long before the perpetrators get anywhere near an airport, and the others were just incompetent idiots.
Nonetheless, I hope you recognise that incompetent idiots beget more incompetent idiots, if they think they'll get away with it. You don't want e.g. a spate of bank robberies, by idiots who've heard that rubbing lemon juice on your face makes you invisible to cameras. It doesn't matter that they'll get obviously get caught, the problem is a spate of idiots attempting bank robberies (because they're filled with confidence they'll succeed) could easily get people killed.
I don't like security theatre either, and clearly the whole thing is a job creation program and an excuse for vendors to sell flashy scanner devices. But you need visible deterrents, even if most people know they're theatre.
They also act as reassurance for idiots who wouldn't fly otherwise. Idiots' money spends just as well as clever people's money, and there's a lot more idiots out there than clever people.
Because we live in a society with a free press, we have the chattering classes asking "what can we do about this threat?", and government is expected to respond. People don't like to hear from the politician "you're idiots, we don't need that, you are no less safe if we do nothing", they like to hear "we're doing XYZ to address this threat, how clever and wonderful you all are, dear citizens, for recognising it. Your safety is my top priority", then we get the https://en.wikipedia.org/wiki/Politician%27s_syllogism
A similar question is what happens if you get up to go to the bathroom, some software on your machine updates and requires you to accept the new ToS, and your cat jumps up on the keyboard and selects "accept". Are you still bound by those terms? Of course. If licenses are valid in any way (the argument is they get you out of the copyright infringement caused by copying the software from disk to memory) then it's your job to go find the license to software you use and make sure you agree to it; the little popup is just a nice way to make your aware of the terms.
> the argument is they get you out of the copyright infringement caused by copying the software from disk to memory
This is not copyright infringement in the USA:
> …it is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided… that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner
> Citing the prior Ninth Circuit case of MAI Systems Corp. v. Peak Computer, Inc., 991 F.2d 511, 518-19 (9th Cir. 1993), the district court held that RAM copying constituted "copying" under 17 U.S.C. § 106.
Actually, no, because you didn't intentionally accept the terms, and you had no reason to expect that your cat would jump on there in exactly that way.
On the other hand, if you take a laser and intentionally induce the cat to push the key, then you are bound.
> If licenses are valid in any way (the argument is they get you out of the copyright infringement caused by copying the software from disk to memory) then it's your job to go find the license to software you use and make sure you agree to it; the little popup is just a nice way to make your aware of the terms.
The way you set up the scenario, the user has no reason to even know that they're using this new version with this new license. An update has happened without their knowledge. So far as they know, they're running the old software under the old license.
You could make an equally good argument that whoever wrote the software installed software on the user's computer without the user's permission. If it's the user's fault that a cat might jump on the keyboard, why isn't it equally the software provider's fault?
... but the reality is that, taking your description at face value, nobody has done anything. The user had no expectation or intention of installing the software or accepting the new license, and the software provider had no expectation or intention of installing it without user permission, and they were both actually fairly reasonable in their expectations. Unfortunately shit happens.
Yeah. Would a reasonable person familiar with software think that there was no license agreement on the software? That's what would be litigated. "My client has only ever used GNU GPL software, he didn't know it was possible to sell software with terms and conditions imposed upon the end user." Maybe that's convincing, but probably not. That's why juries exist.
... only because you'd have no evidence of it. From a legal point of view, the question is what would come down if the judge were (somehow) convinced that it actually happened that way. Actually if a "perfect" judge were so convinced.
Probably a real judge would want to say something like "Why are all of you bozos in my courtroom wasting public money with some two-bit shrinkwrap bullshit? I was good at surfing. I could have gone pro. I hate my life..."
I played a lot with experimental linkers when I was trying to get build time down for our (well, $JOB-1's) large Go binary, but they didn't help that much. The toolchain that comes with Go is quite good.
reply