This article doesn't explain the benefits of the suggested approach well enough.
And the last example looks like a poor advice and contradicts previous advice: there's rarely a global condition that is enough to check once at the top: the condition usually is inside the walrus. And why do for walrus in pack {walrus.throbnicate()} instead of making throbnicate a function accepting the whole pack?
I’m not sure of by “they just suck” you meant to imply that they’re ineffective. If that’s the case, I strongly disagree. They are not used because somehow all countries pretty much agreed they’re way TOO effective and horrific. Nobody wants it used on them, so nobody uses it on anyone else.
I cannot imagine a more effective weapon than an invisible gas that melts you alive, and there are MANY chemical and bio examples of these types of weapons.
>> They are not used because somehow all countries pretty much agreed they’re way TOO effective and horrific
That’s the story but it doesn’t hold up. Chemical weapons were used as recently as the Syrian civil war. I also think if they were really effective in modern warfare, Russia would have long ago deployed them in Ukraine.
What do you mean “if they were really effective”? We still hand out CBRN gear and train in how to put necessary parts on in seconds, because that’s often how little time you get before you’re permanently incapacitated. Mustard gas alone should prove this, and that’s an OLD chemical weapon.
Nowadays we have riot control agents that can be tailored to demographics, react more violently in the presence of sweat, or contain psychoactive ingredients. Nanoparticle dispersion bypasses common gas masks and clothing protection. Even if you’re completely geared up, they can be engineered to last on surfaces for a long time, or react only in the presence of certain triggers. Imagine thinking you’re safe until someone turns on a certain light bulb and you cook inside your protective gear because you were actually exposed 12 hours earlier in an undetectable manner.
I'd encourage you to read the article. Chemical weapons are effectively useless against a well-trained "modern system" army. Part of that is the chemical warfare equipment and vehicles, but mostly it's cover-and-concealment. If you can actually find the enemy, it's much faster and simpler to use the other vastly destructive munitions that modern militaries have.
I did, and it’s really not very convincing at all. It uses an example where a terror group in Japan was able to injure thousands of people with a chemical attack, and act as if this is… not a particularly effective outcome?
Additionally, that “if you can find them” is doing some pretty heavy lifting. The range of explosives and kinetics is hilariously low, and the actual percentage of your military with the level of mobility he seems to be referring to is infinitesimal.
This argument more correctly explains why chemical weapons aren’t a great defense against precision strike groups. It also doesn’t get into detail with concepts like dropping a bomb right in the middle of a firefight knowing it literally cannot harm your own troops, short of the physical metal accidentally falling on one of your own troops.
>I did, and it’s really not very convincing at all. It uses an example where a terror group in Japan was able to injure thousands of people with a chemical attack, and act as if this is… not a particularly effective outcome?
Yes, it isn't effective outcome in terms of meeting their objective
> It also doesn’t get into detail with concepts like dropping a bomb right in the middle of a firefight knowing it literally cannot harm your own troops
That's a video games logic, it doesn't work like that in practice. Even civil grade riot control tear gas grenade is pretty traumatic because it still explodes to disperse the gas (source : implied first hand knowledge). That and warfare is messy, which means half the time half the protective gear will be destroyed from the usual exploding and shooting happening, gas gets carried away by the wind in a random direction, etc, etc.
No, it’s science. There are about a million ways to protect your own troops if that’s actually what you want to do.
It feels like you’re arguing against the idea of chemical weapons from the 1940s, rather than nearly a century later.
You don’t need protective gear. You can create sprays, lotions, inhalants, and other countermeasures that don’t stop working the second a piece of cloth rips. Shit, You could make a biological agent that avoids a DNA marker created with an mRNA vaccine. Likely not nearly as fast, but perfectly lethal.
Modern chemical weapons and biological weapons are absolutely incomparable to their Vietnam counterparts.
The ceiling for the destruction caused by biological weapons is far greater than chemical weapons. There is no chemical weapon that can hijack the victim to make more of it.
Not under the current way we do things, I don't imagine.
So the real trick here isn't the mRNA, it's the nanobubbles. Basically, you're putting these bits of mRNA into these little fat bubbles and then injecting those into the blood. Making those bubble shelf stable is really hard, hence the issues with temperature and the covid vaccine. To then make those little fat bubbles stable-ish in the blood is also a really hard thing to do. They have to get to the right places (in this baby's case, the liver) and then degrade there, drop off the mRNA, and not mess up other tissues all that much. Like, it's not terrible to make these micelles degrade in vivo, but to have them do that and not degrade in the tubes, ... wow... that is really difficult. There's a reason that Moderna is so highly valued, and it's these bubbles.
To try to then put these in a weapon that could do this though the airways would be, like, nearly impossible. Like, as in I think the second law of thermodynamics, let alone biology, and then simple industrial countermeasure like a N95 respirator, yeah, I think all of that makes it pretty much impossible to weaponize.
(Hedging my bets here: I don't know if they had to do all that with this baby, as you can kinda go from lab to baby really fast, since it's such a special case. But for mRNA based vaccines and cancer treatments, you have to deal with the shelf stable issue)
(Also, other bio people, yes, I am trying to explain to laymen here. Please chime in and tell me how I'm wrong here)
Something that a lot of people are unaware of is that US Military is allowed to do this. I forget the exact EO, but it was signed by Clinton and is in the 12333 chain of EOs. Mostly, this is used for the Anthrax vaccine. But, it does give clearance to do other forms of medical experimentation on warfighters.
No, really, I am serious here. This is true. I may have the details a bit off, so sorry there, but they can and do preform medical experiments on people without their consent. Now, to be fair, France does this too. They do sham surgeries over there. Non-consenting human medical experimentation is quite the rabbit-hole.
So, I can kinda see in the next 10 years, certainly the next 50, a routine shot given to warfighters to help them with things like blood loss, or vitamin C production, or fast twitch muscles, or whatever. The legal framework is already there and has been for a while, it's just an efficacy issue, honestly.
Thanks. I went looking and saw this in the Fil-C manifesto:
> It's even possible to allocate memory using malloc from within a signal handler (which is necessary because Fil-C heap-allocates stack allocations).
Hmm, really? All stack allocations are heap-allocated? Doesn't that make Fil-C super slow? Is there no way to do stack allocation? Or did I misread what you meant by 'stack allocations'?
It’s a GC allocation, not a traditional malloc allocation. So slower than stack allocation but substantially faster than a malloc call.
And that GC allocation only happens if the compiler can’t prove that it’s nonescaping. The overwhelming majority of what look like stack allocations in C are proved nonescaping.
Consequently, while Fil-C does have overheads, this isn’t the one I worry about.
I see! Thanks for that answer. I'm sure I'll have lots of questions, like these:
You say you don't have to instrument malloc(), but somehow you must learn of the allocation size. How?
Are aliasing bugs detected?
I assume that Fil-C is a whole-program-only option. That is, that you can't mix libraries not compiled with Fil-C and ones compiled with Fil-C. Is that right?
So one might want a whole distro built with Fil-C.
How much are you living with Fil-C? How painful is it, performance-wise?
BTW, I think your approach is remarkable and remarkably interesting. Of course, to some degree this just highlights how bad C (and C++) is (are) at being memory-safe.
Malloc is just a wrapper for zgc_alloc and passes the size through. "Not instrumenting malloc" just means that the compiler doesn't have to detect that you're calling malloc and treat it specially (this is important as many past attempts to make C memory safe did require malloc instrumentation, which meant that if you called malloc via a wrapper, those implementations would just break; Fil-C handles that just fine).
Not sure exactly what you mean by aliasing bugs. I'm assuming strict aliasing violations. Fil-C allows a limited and safe set of strict aliasing optimizations, which end up having the effect of loads/stores moving according to a memory model that is weaker than maybe you'd want. So, Fil-C doesn't detect those. Like in any clang-based compiler, Fil-C allows you to pass `-fno-strict-aliasing` if you don't want those optimizations.
That's right, you have to go all in on Fil-C. All libs have to be compiled with Fil-C. That said, separate compilation of those modules and libraries just works. Dynamic linking just works. So long as everything is Fil-C.
Yes you could build a distro that is 100% Fil-C. I think that's possible today. I just haven't had the time to do that.
All of the software I've ported to Fil-C is fast enough to be usable. You don't notice the perf "problem" unless you deliberately benchmark compute workloads (which I do - I have a large and ever-growing benchmark suite). I wrote up my thoughts about this in a recent twitter discussion: https://x.com/filpizlo/status/1920848334429810751
A bunch of us PL implementers have long "joked" that the only thing unsafe about C are the implementations of C. The language itself is fine. Fil-C sort of proves that joke true.
> Not sure exactly what you mean by aliasing bugs.
I meant that if the same allocation were accessed as different kinds of objects, as if through a union, ... I guess what I really meant to ask is: does Fil-C know the types of objects being pointed to by a pointer, and therefore also the number of elements in arrays?
So, if you store a pointer to a location in memory and then load from that location using pointer type, then you get the capability that was last stored. But if the thing stored at the location was an integer, you get an invalid capability.
So Fil-C’s “type” for an object is ever evolving. The memory returned from malloc will be nothing but invalid capabilities for each pointer width word in that allocation but as soon as you store pointers to it then the locations you stored those pointers to will be understood as being pointer locations. This makes unions and weird pointer casts just work. But you can ever type confuse an int with a pointer, or different pointer types, in a manner that would let you violate the capability model (ie achieve the kind of weird state where you can access any memory you like).
Lots of tricks under the hood to make this thread safe and not too expensive.
Sorry, you have been blocked
You are unable to access stratolaunch.com
Why have I been blocked?
This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.
What can I do to resolve this?
You can email the site owner to let them know you were blocked. Please include what you were doing when this page came up and the Cloudflare Ray ID found at the bottom of this page.
When I see an argument with a phrase like "basic premise" I know I'm reading some word mambo jambo, otherwise the author would just give their summary of that "basic premise" instead of deadlinking it (refer to something without actually referring it).
You don't have an argument yourself, you just wanted to share that you are pro some position.
There are clear factual errors in the underlying assumptions of what was stated about water fluoridation. Those are simply table stakes for having a discussion about anything at all. If one thinks that water fluoridation is useful "just for a few seconds," that it's not done outside of the United States, that it's a replacement for toothpaste, that it's a vital chemical, or that we don't fortify other foods, then they do not know enough about the topic to talk about it, let alone hold the opinion that they know better.
If someone came in with a curious mindset, that'd be one thing. But this is someone walking into a room with an agenda (get rid of fluoride) and a shocking lack of knowledge about that agenda.
>If someone came in with a curious mindset, that'd be one thing. But this is someone walking into a room with an agenda (get rid of fluoride) and a shocking lack of knowledge about that agenda.
But since "Internet People Lie About Fluoride,"[0] why are you surprised? And that's nothing new.
Why? I have no idea. Perhaps cpursley[1] could enlighten us?
Yeah, exactly - she made my point. Buy proper toothpaste with fluoride. Brush after ever meal. I understand the chemistry and am an obsessive brusher. If the Danish don't need it in their DRINKING water, nor do we.
Just brush your teeth after every meal, you will be fine like the Finns. And prob a higher IQ like them, as well (without all the unnecessary floride in the water).
PSA: brushing your teeth directly after eating is actually detrimental, because the acids in food soften the enamel on your teeth. That layer needs to harden first (wait 20-30 minutes), otherwise your toothbrush will strip it away: https://www.cuimc.columbia.edu/news/brushing-immediately-aft...
This is a significant peeve of mine. The need to explicitly specify resolution in boot managers is annoying for both laptops and machines that aren’t always used with the same monitor, because no matter what it’s going to end up in fallback with an ugly stretched resolution some portion of the time, rendering beautification with themes somewhat moot.
This limit made sense 20+ years ago but today it feels highly anachronistic, kind of like finding a corded rotary phone mounted on a wall in the kitchen of an otherwise cutting edge home. Surely it’s something that could be fixed?
May be, but this is so minor in general, that I barely care as long as it boots properly.
Way bigger annoyance is that grub still doesn't support luks2 and uses some gimped variant of libcrypto without proper hardware acceleration that decrypts boot volumes for almost a minute. That is way more serious than boot resolution annoyances.
That's also a peeve of mine. Is there a way at all for grub to use hardware acceleration there? Or maybe the bootloader isn't allowed to do such things
Yes - use newer libcrypto. They are in the process of switching, but it just takes very long. I don't see why bootloader won't be allowed to use the CPU features that accelerate decryption.
Nice! Do you have a link with the progress of this? Maybe in a mailing list or something. I can't manage to find it
Also, do you know whether grub plans to support luks2?
And maybe even veracrypt - ok this one is unlikely. (cryptsetup can read veracrypt just fine and the Linux kernel copes with it, maybe it's a matter of porting this code to grub? One issue is that grub would need to embed the number of iterations of the key derivation function somehow - the thing veracrypt calls PIM - because unlike luks, veracrypt doesn't store it in a header that can be read before unencrypting)
My pet peeve is that grub repartitions windows disks on chain load, so if it ever boots with the disks remapped, there's a chance it'll plow apart the partition table of whatever poor disk got mapped to that hd#.
It really isn't. If they were purely focused on getting training data, they would give more captchas to everyone, not just the users with no google cookies, connecting from VPN, and with weird browser configurations. The fact of the matter is that all those attributes are more "suspicious" than average, and therefore they want to up the cost for getting past the captcha.
Too many sites that used to be good installed that shit. And weird part is that on desktop only Chromium fails to pass the captcha, no issues on Firefox. But Chromium is my main browser and sometimes I'm too lazy/uncomfortable opening 2nd browser for those sites.
For me the biggest issue with archwiki adding Anubis is that it doesn't let me in when I open it on mobile. I am using Cromite: it doesn't support extensions, but has some ABP integrated in.
And the last example looks like a poor advice and contradicts previous advice: there's rarely a global condition that is enough to check once at the top: the condition usually is inside the walrus. And why do for walrus in pack {walrus.throbnicate()} instead of making throbnicate a function accepting the whole pack?
reply