Restartable windows, or more generically introspection windows, are a really useful technique you can apply in any situation where you understand or control the sources of preemption. The earliest uses of this technique in operating systems that I am aware of are ~25 years old.
The key insight is that the preempter can introspect the program counter of the code being preempted (which is now stable since it was preempted) and act accordingly. The simplest mechanism is to reset their program counter if in a critical section. The more generic mechanism is to jump them to a supplied address. This allows you to do things like hard abort and more.
You can further remove the need for the preempter to understand the preempted code by having the preempted code create a self-introspection code snippet and supplying that with the program counter at preemption. So the preempter just vectors them to their own code which knows how to interpret its own state at any preemption point.
Yep, it is a fairly old technique with a lot of of general applicability beyond just allowing mutex elision for usage of per-core data structures amidst potential core migration. But apparently using your own expert knowledge and actually explaining things and describing generalizations is worthy of flagging these days.
Their popularity is a fad. You are talking about their popularity when they first released in the US. They faded significantly for at least a decade if not two until seeing a recent resurgence so massive even random corner stores carry pokemon card packs these days.
What gets me is that no one actually plays the game or cares about the cards. They buy them purely to resell them to someone else later for more. It's just like crypto in physical form.
When my kids open a pack they usually don't even look at what cards they get. They spread them out just enough to see the border - which is enough to tell whether you've gotten a rare card or not. I'm sure they've thrown plenty of cards in the junk bin without ever once looking at them.
The "special art rare" ones are admittedly pretty cool, and those do get taken out and looked at from time to time. Usually when friends come over.
If it mattered they would not be using C without any of those tools or techniques. Therefore, it is empirically proven that it either does not matter or they are deploying code unfit for purpose and should not be writing such code.
And that is precisely what they said:
> Ideally people who don't care about secrurity [sic] should not write code when security matters.
The absence of legal consequences further supports the fact that it does not matter.
It does certainly matter, it needed to go beyond what is acceptable for governments and security agencies to finally start reacting, since Morris worm came to be.
Naturally the move fast and break things culture sees it otherwise.
A key problem in the US is that in a unionized job you are legally required to be represented by the union. Union membership is non-voluntary.
If you think you are part of that top percentage or even if you think that the union is not representing your interests, tough luck. It is illegal to quit or reorganize like-minded individuals to form your own that better represents you. To reform the union you need to get 50% of the members to vote for change instead of just forming a new, smaller organization that represents your interests.
This is in contrast to many European unions where you can choose to join because you think they provide worthwhile benefits. Or you can choose to not join because it does not. Unions need to compete on benefits to their members and are thus incentivized to provide better benefits.
Voluntary unions have a free rider problem. You may choose to join the union because you believe it's the right thing to do, but the benefits are rarely worth the dues. Non-members also benefit from collective bargaining, but they have a bit more money to spend.
Legal representation is probably the main exception. Other benefits you could just pay on your own, but unions are the easiest way to get access to lawyers specialized in labor issues, and they will often represent you for free.
The bigger difference between American and European unions is that Europe tends to treat union membership as sensitive personal information. Your employer has no legitimate reason to know whether you are a union member, and it's not allowed to ask. The union is also generally not allowed to tell its members which of their colleagues are members. Many of the issues surrounding American unions just disappear when union membership has no impact on your daily job.
Voluntary unions do not have a free rider problem. That is only the case if you legally require collective bargaining to apply to non-union members (as is the case in the US).
For instance, in Germany [1] collective bargaining agreements are agreements between employers and unions, and are only required to be applied to union members. Companys may voluntarily choose to extend those same benefits to non-union members. Despite the fact that unions are voluntary in Germany, they still have significant union membership as a whole and German unions are frequently held up as a good example of the benefits of unions to both workers and society which is evidence against the claim that it is necessary to legally enforce union membership.
There are plenty of incentives, practical reasons, and even legal requirements for extending the benefits to non-members. Germany also has a mechanism for declaring a collective bargaining agreement generally binding, which means that it applies to everyone working in the field in every company.
Also in the US, when Unions were starting to get going, the "good" ones that stood on principles and tried to do right by their members had their leadership harassed and even murdered by oligarchs and the government. The corruptible ones were allowed to exist, and be corrupted as another means of control, and for the anti-union people to point at as proof that unions "don't work".
Reading up on this has been eye-opening, they didn't teach much about it in school, except maybe a paragraph in the history textbook about the Ludlow Massacre. They don't mention at all the IWW or other leftist unions from the 1910s and 20s. If they mention the Taft–Hartley Act, they don't talk about how it targeted "communist" union leaders, and left "capitalist" unions alone.
What a inane comment. They gave you a link that literally spoonfeeds the data and you complain because you can not be bothered to read until what is literally the second sentence in the article before accusing them of making statements in bad faith without supporting data.
> Starbase, a sprawling launch-and-manufacturing site that recently incorporated as its own Texas city, logged injury rates that were almost 6x higher than the average for comparable space vehicle-manufacturing outfits and nearly 3x higher than aerospace manufacturing as a whole in 2024, according to Occupational Safety and Health Administration (OSHA) data released in May.
Literally the second sentence which answers all of the questions you just posed and invalidates your accusations in the second paragraph. Geez.
What are you talking about? Injury rate at Starbase (Brownsville) was 6x higher than industry average in 2022 [1].
Furthermore, you have gotten the burden of proof backwards. The default presumption is non-safety. The burden of proof is on insiders (who have all the access) to robustly demonstrate in a clear and convincing manner that things are safe, not on outsiders (who only have limited access) to demonstrate in a clear and convincing manner that things are dangerous.
So, please present your evidence that their injury or fatality rate is normal. Absence of evidence defaults to your claim it is safe being unsupported.
edit:
codingdave comment has a more recent link that also determines 2023 and 2024 also had injury rates multiple times higher than industry average.
Mining, quarrying, and oil and gas extraction: 1.2
Coal mining: 3.1
Heavy and civil engineering construction: 1.8
Animal slaughtering and processing: 3.2
Wood product manufacturing (inc. sawmills): 4.2
Foundries: 5.1
Aerospace product and parts manufacturing: 1.6
Rail transportation: 3.4
Judging solely by the aforementioned linked data, at 4.8, Brownsville should be shut down by management to do a safety intervention. McGregor and Hawthorne should be under the limelight, too. Redmond and CC seem good.
I am baffled you can even get to six figure LoC implementing QUIC. Having done the majority of a QUIC implementation before deciding I needed to design a new protocol that fixes QUIC's performance limitations, a minimal, but fully functional and performant implementation with zero dependencys (except for cryptography) should only take maybe 5,000 lines.
If you use the default parameters with such a implementation you will likely cap out at a pretty slow ~10 Gbps/core, but if you reduce the ACK frequency you can probably get to ~30-50 Gbps/core without too much trouble.
They do, it is a draft [1]. There are other design flaws that also limit data path performance (ignoring encryption) to probably something on the order of just 30-50 Gbps/core though I would not be too surprised if you could get ~100 Gbps/core in a well-behaved case.
I mean, you would think that all those people he killed as the person in charge of deploying knowingly dangerously defective self-driving software for profit would have had a impact. But executives seem to just skate on killing customers to line their own pockets these days. Just "following orders" I guess.
Yes, he was [1] director of AI and Autopilot Vision at Tesla, directly poached and reporting to Elon Musk on the most important headline feature of Tesla directly managed by Elon Musk.
He had both the technical and executive authority to determine if the product was fit for customer usage. He had direct executive responsibility for the product on the road between 2017-2022.
If he, the lead architect and executive responsible felt the product was dangerous and then he was overridden, he can not get away with claiming he was “just following orders”, he had a moral duty to not sign-off or quit otherwise he is clearly complicit in deploying a dangerous product for his own self-enrichment.
When people talk about engineering ethics, this is literally a completely uncontroversial textbook example. The only way you accept this is if you do not want ethics in engineering.
Furthermore, he was extremely hireable with numerous job opportunitys available to him. He would not be destitute or even particularly worse off if he did quit for ethical reasons. Any self-preservation defense is also invalid.
Andrej Karpathy is a reason* Tesla doesn’t have Lidar and thus is a reason Tesla self driving isn’t nearly as safe as it could be?
He heard Elon say “I drive with eyes, so cars just need eyes” & shipped?
:( happy to have my impressions corrected (but I was kind of pretending it’s a 2026 scenario where you could slap Lidar, ship a Waymo, if you were just willing to spend the friggin MONEY - 2017 was too early for most any “self” driving IIRC)
-
*edit - in a scenario where his refusal to skip Lidar catalyzed change
According to ABET they do if they want the degree to be accredited. We had two classes for my SE degree. From Criterion 3. Student Outcomes:
"2. an ability to apply engineering design to produce solutions that meet specified needs with consideration of public health, safety, and welfare, as well as global, cultural, social, environmental, and economic factors."
"4. an ability to recognize ethical and professional responsibilities in engineering situations and make informed judgments, which must consider the impact of engineering solutions in global, economic, environmental, and societal contexts."
Passing a mandatory class != believing in its message and acting on it.
Unfortunately, rather important courses like engineering ethics have become lumped in with mandatory DEI objectives and similar 'grievance studies' requirements, classes which many suffer through quietly, regurgitating the Correct responses while they count the minutes until they can get back to more substantive classwork. Some undergraduates may unfortunately gloss over ethics just as they gloss over lectures on privilege.
A order of magnitude is a factor of 10x. Multiple orders of magnitude is at least 100x.
SpaceX Falcon 9 has a launch cost of 74 M$ with a payload to LEO of 22,800 kg for a launch cost of ~3,200 $/kg to LEO.
So you are incorrectly claiming that space launch costs were 320,000 $/kg. Elon Musk is a habitual liar, but you should try not to be one as well as it demonstrates your argument to be based in ignorance and deception.
Falcon Heavy reusable is the most $ efficient system at around $1500 $/kg. The Space Shuttle costs were $54,000 $/kg. If you want to nitpick that that's "only" a 97% cost reduction instead of a 99%... well that's the sort of good faith debate I've come to expect from the aforementioned vocal minority in any topic related to Elon, and with all the class you've already demonstrated in your post.
Why are you deceptively bringing up the Space Shuttle? That was never intended to be a serious cost-effective launch vehicle. Also, why are you deceptively talking about 97% and 99% like the difference between 30x and 100x is not a factor of 3?
The Ariane 5, first launching in 2003 which is 7 years earlier than the first Falcon 9 launch, had a launch cost of ~150 M$ in 2015 with a payload to LEO of ~16,000 kg for a cost of 10,000 $/kg. The Soyuz-2, first launching in 2004 which is 6 years earlier than the first Falcon 9 launch, had a launch cost of ~35 M$ with a payload to LEO of ~8,000 kg for a cost of ~4,500 $/kg.
The truth is 3-6% of your claim of 100x cost improvement.
Because the Space Shuttle is what SpaceX replaced. A 97% discount relative to that is what SpaceX has managed, after a commercial profit margin. 99% is 2 orders of magnitude. So you're here bickering over 2% with all the class that one would expect.
No it did not. Nobody launched their commercial satellites on Space Shuttles. Soyuz, Atlas, Proton, Delta, Long March, Ariane; those are commercial launch vehicles. Even considering crewed missions we can look to ISS crew missions which were half Soyuz missions and then entirely Soyuz missions between 2009-2020.
And again, you do not seem to understand how percentages work. If I have a thing that costs 1,000 $ and I find a 99% cost reduction it is now 10 $. A 97% cost reduction means it is 30 $. That is a 3x difference. The difference between 1% and 3% is a factor of 3x. That is half of a order of magnitude right there and here you are claiming it is small.
So you are wrong on history, wrong on comparables, and wrong on math to defend a man who runs a company that is legally, and I quote a actual legal decision: a "greviously reprehensible... grossly racist workplace"[1]. But, you know, racism man good because he slightly lowered the cost of cruise ship internet I guess.
You're engaging in some wild freak out mental gymnastics here. Seriously, just read your paragraph about me not understanding percents, and tell me you don't get hard-core Chewbacca Defense [1] vibes. It seriously reads not only like satire, but pretty good satire! You just need to add a QED to the end. lol
And don't trust flatterbots to argue for you. They hallucinate regularly and just make you look more absurd. The Space Shuttle was flying crewed missions to the ISS until 2011. The reason they stopped is because the Space Shuttle had been retired and commercial crew began, which was ultimately won by SpaceX. Well SpaceX and Boeing in an overt act of insiderism, but Boeing is still - 15 years later - trying to figure out how this whole space thingy works.
The alternatives you mention were never commercially viable against SpaceX. All not only cost multiple times more but come with significantly worse reliability records as well as lacking the payload capacity of something like Falcon Heavy for those missions that require it. And when you look at things like the Soyuz, the sticker price doesn't matter so much as the price companies were obligated to pay. They offered cheap internal launches, and charged dramatically higher rates for foreign launchers - including NASA. By the end NASA was paying $90mil/seat.
Yes, you clearly do not understand how percentages work given that you continue to argue that the difference between 30x and 100x is just "2%".
You are correct that there were Space Shuttle missions to the vicinity of the ISS until 2011. I was talking about ISS crew rotation missions where the last Space Shuttle mission was STS-129 in 2009. The Space Shuttle was still used for ISS assembly flights until 2011. I was using crew rotation missions to highlight that not just commercial satellite launches, but also one of the other important class of missions, crew rotation, also regularly used alternatives to the Space Shuttle disproving your point that the Space Shuttle had some sort of magical monopoly on launches and thus the only alternative to compare against.
You were the one arguing that alternatives cost over 100x more than SpaceX. Even deceptively comparing against the Space Shuttle you were still off by a factor of 3x and comparing against actual competitors your claim is off by a factor of 16x-30x. Your claim is egregiously wrong. Continuing to argue it means you are either completely ignorant or utterly biased or both. I am done here.
I said that the difference between a 99% saving and a 97% was 2%. You're the one engaging in freak out mental gymnastics to try to turn that into 'ACTUAAAALLLY... that's like a 300% difference and the proof is that Elon kicked my dog.'
And no, I obviously know you're just grabbing nonsense from your flatterbot of choice. The tell tale is being easily confused on basic points, making rather nonsensical statements, being oddly precise about irrelevant esoteric details, and then finding yourself in a situation where you're left trying to recombobulate it all back into something sensical, which you're not quite succeeding at. Your post above is borderline incoherent, even moreso than the 97% to 99% = 300% nonsense.
Your communication channel between Alice and Bob is, itself, a capability (or a collection of capabilitys) that grants Bob memory write, Alice memory read, but does not grant the ability to transmit a capability from Bob to Alice.
Absent a misunderstanding on your part, the only way I can coherently interpret your argument is that you are arguing that the presence of kernel data structures mediating the handles somehow makes it not a capability system. That there is some background element mediating the validity of your capability representation and thus that is just a MAC layer; unless you can write the byte representation of your handle into memory and somebody else can read it out and then have access to that resource it is not a capability.
One, that allows forging capabilitys unless they are cryptographically secure against collisions.
Two, the actual essence of capabilitys is not being bearer tokens, it is non-construction. Capabilitys are derived from existing capabilitys, not manifested into existence. They have provenance. It is the OS equivalent of not allowing programs to cast arbitrary integers to pointers and thus manifesting pointers into existence which breaks basically every high level memory safety guarantee. You do not allow programs to cast arbitrary data into handles to resources which is what ambient authority systems effectively require.
I'm going to first apologize for engaging in rhetorical sleight of hand myself, since I indulged in a bit of the hand-wavy argumentation that happens so often in these nit-picky debates. I'm going to respond cleanly here mostly to sharpen my own argumentative saw.
The original PSOS paper makes a few claims that are in tension with one another, and then buries the lede about how that tension can be addressed. Here's a few passages, directly quoted from the paper:
> [...] there are several important pragmatic reasons why PSOS capabilities are useful as a naming and protection mechanism for supporting abstract objects.
> 1. The capability mechanism has a very simple implementation. This allows capabilities to be built into the system at the lowest level of abstraction, thus making capabilities available for the most primitive objects.
> 2. Capabilities are uniform in size, making them easy to manage.
> 3. The inclusion of access rights in capabilities permits efficient fine-grained control of access to objects.
> 4. Capabilities can be written into storage (including secondary storage) and retrieved from storage in the same manner as other data, and therefore have many of the properties of other data.
Item 4 above is the one that should draw the most attention. I don't think anyone would contest the claim that PSOS has wonderful ergonomics for managing access to resources, but the moment you want to impose a system-wide access control policy then you must add another security mechanism, completely outside the capability abstraction, that adds some friction. This is fully acknowledged by the PSOS authors, although frankly they buried the lede since this is the only thing that the secure systems folks really cared about at the time. From the section on Store permissions:
> Because simplicity of the basic capability mechanism is extremely important to achieve the goals of PSOS, any means for restricting the propagation of capabilities should not add complexity to the capability mechanism. [...] A few access rights (only one is currently used by PSOS itself) are reserved as store permissions. This is the only burden placed on the capability mechanism.
> By properly choosing the segments that are capability store limited, some very useful restrictions on the propagation of capabilities can be achieved. The restriction used in PSOS is not allowing a process to pass certain capabilities to other processes or to place these capabilities in storage locations (e.g., a directory or interprocess communication channel) accessible to other processes. [...] The store permission mechanism has been selected as primitive in the system because it achieves the desired result with negligible additional complexity or cost.
This appears as claim 8 in the summary section of the paper near the end:
> Propagation of capabilities can be restricted by use of capability store permissions. The passage of a capability to other users can be prevented by not including process store permission in that capability's access rights.
Ok, so that's the PSOS paper and it's claims. Boebert's paper--really a note, since it is a mere 3 pages--states its argument in fairly direct terms:
> The attack is made possible by an inherent attribute of pure capability machines: the right to exercise access carries with it the right to propagate that access. Thus even if an omniscient oracle correctly creates capabilities, it cannot control their further propagation. If extra mechanisms are imposed to impose this control, the machine is no longer an unmodified capability machine.
The only issue here is, perhaps, semantic: Boebert (correctly) states that an unmodified capability machine cannot provide what is considered a very basic mandatory security policy, but the PSOS folks already acknowledged this by stating that the system needs a capability store permission manager for mandatory security policy enforcement. The phrasing that they used--"the store permission mechanism has been selected as primitive in the system"--is the bait-and-switch where they treat it like part of the capability model rather than making it clear that it is an entirely distinct mechanism that must be composed with pure capabilities to achieve the (genuinely difficult) security properties that systems designers were seeking.
I suspect the horse is already dead it's worth double-tapping to make sure, so let's continue. The Myths paper muddies the waters further by making this claim after supposedly debunking Boebert:
> Boebert’s result is valid in any capability system that cannot distinguish between data transfer and capability transfer. But partitioned and type-enforced capability systems do not have this problem, and password capability systems have been engineered to avoid this problem [1, 11].
> Moreover, it has been formally verified that any capability system enforcing independent controls on data transfer and capability transfer can enforce both confinement and the *-Property [22].
This is the motivation for their paper, which is stated unambiguously:
> Boebert [1] and Karger [9] have argued that unmodified capability systems cannot enforce even basic mandatory access controls such as the *-property. Both have proposed solutions in the form of hybrid protection architectures. Karger has also argued that unmodified capability systems cannot enforce confinement [8]. Given that EROS is a pure capability system, and that its security design rests on its ability to enforce confinement, a rigorous verification of the EROS confinement mechanism is necessary.
For some reason, they decide to respond to these claims in the Related work section, just before their conclusion, although they do address them head-on:
> Boebert [1] and Karger [9] show that pure capability systems cannot enforce the *-property. While their conclusion is correct, capability systems do provide sufficient strength to construct mandatory policies at a higher level of abstraction with reasonable performance, as has been done in KeySafe [14].
> Karger has also shown that unmodified capability systems cannot enforce the confinement policy [8]. The apparent discrepancy results from differences in term definition. Karger’s confinement policy is a mandatory access control policy: "this piece of information must not be disclosed to that set of unauthorized parties." That is, it is a policy concerning the flow of information to subjects. Lampson’s confinement problem [10] imposes a weaker constraint: information can flow out of the subsystem only through authorized channels. That is, in the Lampson definition the channels define an encapsulation boundary to be enforced.
> We believe that the KeySafe architecture can enforce both the *-property and Karger’s confinement policy, but this does not directly contradict their claims. KeySafe is a reference monitor built on top of a more primitive capability mechanism; such a reference monitor constitutes a modified capability system in the sense of Karger’s discussion.
It's worth questioning whether the Myths authors were justified in citing this paper the way they did. But either way, I think it's pretty clear that once you pin down a precise definition of the terms used in the discussion, there is little disagreement among any of these authors. However, in casual arguments this precision is lost and you end up with a situation where two things are true at the same time but people choose to talk about only one at a time and think they're winning arguments:
1. An unmodified capability machine cannot enforce the *-property or mandatory access control confinement policies.
2. Modifying a capability machine to enforce such policies (and provide proof of enforcement) is straightforward because there is a single clearly-defined interface through which the systems may be composed.
My stance is that the PSOS folks screwed up their marketing. They really do have a superior product, so to speak, but they tried to downplay the fact that it did not provide a solution to the genuinely difficult problem of enforcing MAC policies (which was really about reference monitor discipline, not capabilities or ACLs). The right pitch for ocap design is "we offer a cleaner, more compositional, more auditable substrate for authority management--which is itself a substantial contribution and worth caring about--and on top of that substrate you can build the same MAC policies you'd build on any other substrate, but with better starting axioms and clearer proof structures." That's a contribution that doesn't need to be defended against Boebert because it doesn't claim (or appear to claim) what Boebert showed couldn't be claimed.
The key insight is that the preempter can introspect the program counter of the code being preempted (which is now stable since it was preempted) and act accordingly. The simplest mechanism is to reset their program counter if in a critical section. The more generic mechanism is to jump them to a supplied address. This allows you to do things like hard abort and more.
You can further remove the need for the preempter to understand the preempted code by having the preempted code create a self-introspection code snippet and supplying that with the program counter at preemption. So the preempter just vectors them to their own code which knows how to interpret its own state at any preemption point.
reply