That's how the oldest European universities worked originally, the students hired the teachers. I don't remember how long that system lasted or exactly why it ended, but the history might be instructive.
That capability should be added to acme.sh, etc so that it automatically runs with minimal privileges for the invoked task. But people seem to assume privilege management is the sole responsibility of the packager or caller, despite the tool itself being better placed to know precisely which privileges are needed for the particular task it's performing.
acme-client on OpenBSD does this, using privilege separated processes that each in turn use pledge and unveil. You wouldn't know without looking at the source code because it's entirely transparent.
I'd say it's usually on the packager (or caller) because specying privileges depends on the platform you run on, which is better known by the packager or caler
Morally, maybe? It's what people tend to implicitly assume when a large chain displaces local mom & pops. You can argue it's for the greater good in the long-term, but that doesn't settle the question of the immediate injuries. Is it the fault of the stock boy who lost his job that he worked for a less efficient employer? Maybe?
The whole encyclical's argument is that morality requires an accounting and response to the pain inflicted upon each individual, and human morality is a distinct set of rules and norms than economic, physical, or even civil laws. I think it also follows that it's not just, e.g., Walmart or OpenAI who bares some responsibility for ameliorating temporary suffering. And to the extent people use the encyclical as fodder in the usual anti-corporate rhetoric, then that's unfortunate.
And this is coming from the Catholic church. It turns alot of people off who in isolated contexts often perceive hypocrisy, but in its charity it has always considered the personal responsibility of those receiving it. It understands the struggles and inherent tensions that comes from trying to square individualized justice & mercy, selflessness, and the "greater good".
Assuming that's token cost upstream, and given the multiplication factor in tokens processed per query, that seems like maybe a few thousand requests per second at most? It's impressive but for a 50 person startup team expending millions per month, that seems about on par.
Would it be as impressive if the context were an email provider accepting thousands of message per second, or even one accepting thousands of messages per second and submitting them upstream for spam detection? The token count might even be higher in that case, but rightly or wrongly I think it would get a yawn on HN.
It says more about how far the industry has come these days in terms of scale on the one hand, but also on the other hand the huge blowup in data and processing for nominally simple requests. Nonetheless I'm sure the team is exceptionally skilled and it's certainly a laudable accomplishment.
The Justinian Plague was as bad or worse, but rather than result in flourishing it ushered in the beginning of the end of the Roman Empire and the start of the so-called Dark Ages. So maybe the Black Plague was an important element, but if so also had to have happened at the confluence of other critical events.
According to William Rosen in "Justinian's Flea," this plague also led to an agricultural revolution and population explosion in Western Europe.
<quote>
One cannot, of course, “know” this in the same way that one can know the date of the battle of Poitiers; applying economic analysis to the spotty record of commerce during late antiquity is a tricky business. However, as can be seen in a subtly reasoned 2003 paper by two development economists, Ronald Findlay of Columbia and Mats Lundahl of the University of Stockholm, it is compelling, as well, despite its reliance on a number of simplifications.
</quote>
If we are limiting causes to things that would lead to an event every time no matter what other conditions exist, then we aren't going to ever have any causes.
This would be like saying "well drunk driving doesn't cause accidents because I drive drunk once and didn't get in a crash"
That's a super interesting question and I agree! I am only saying the modern period of compound economic growth clearly started at the black plague with good explanations as to why.
Why other events did not have the same effects are very interesting questions for economic history.
This reminded me of ISO 7816-4 BER-TLV encodings, which uses the format defined in ISO/IEC 8825-1 (ASN.1 related spec). Length integer values of 0-127 are encoded in 1 byte. If the high bit is set, then the first 7 bits tell you the number of subsequent octets. So there's no offsetting involved, making it slightly less compact, but also dead simple.
EDIT: BUT, BER-TLV does permit overlong encodings. And I once found and reported a Yubikey 4 bug related to this. My source code comment for the workaround:
-- The Yubikey 4 has an off-by-one bug which
-- declares tag length of 255 (for the 0x53 outer
-- tag of a certficate DO) when there are only 254
-- bytes remaining in the reply. The reply is
-- chained across two packets, but the off-by-one is
-- probably related to the over-long encoded length
-- (0x82 0x00 0xff instead of 0x81 0xff).
--
-- [snip packet captures]
--
-- Yubico's ykpiv_fetch_object function in ykpiv.c
-- (confirmed 1.4.3-1.5.0) contains a read (memmove)
-- overflow when the declared inner BER-TLV length
-- (of the 0x53 tag) is longer than what was
-- received over the wire. That makes Yubico's
-- library oblivious to the issue. Relatedly, the
-- set_length function has an off-by-one bug (length
-- < 0xff instead of length <= 0xff) which produces
-- an over-long encoded length. That doesn't by
-- itself explain why the Yubikey 4 transmits a
-- truncated logical reply unless the same code is
-- being used.
Crushing only because their cadence is so slow compared to SpaceX. Their process seems much closer to the highly risk averse methodology of traditional incumbents than to SpaceX's style. Failure becomes a self-fulfilling prophecy.
Rockets are ridiculously complex. Slow-and-steady wins the race makes sense for many individual components, depending on how well understood the problem domain is, and your ability to rigorously model things. But if you take that approach when testing all the thousands of components together, which is simply just too complex to exhaustively model[1], you'll never get anywhere. You have to be prepared to not only break some eggs in epic fashion, but to break many as quickly as you can, so you can parallelize your problem solving and iterate faster.
[1] At least without a large multiple in time and monetary expenditure that ends up costing more than even the US (government and private capital combined) is prepared to spend.
No, this would be crushing regardless. Even if Blue Origin had dozens of rockets ready to go, they can't fly without without the pad, which will take around a year to repair (based on previous examples).
This was an issue already in the Soviet times, with a couple cases of early rocket explosions destroying the pad and causing long delays, including one spectacular N1 explosion leveling its pad and needing lengthy expensive rebuild.
As a result they went to extensive lengths to avoid pad damage, including never terminating rocket thrust in the first (IIRC) 60 seconds of flight. Better let the rocket crash into something nearby than to explode at the pad.
> As a result they went to extensive lengths to avoid pad damage, including never terminating rocket thrust in the first (IIRC) 60 seconds of flight.
I was pondering this very thing. Was there a way to learn the same info as this static fire that didn't risk all the pad infrastructure? I get that the tower, fueling systems, deluge, etc all have to work together in a real launch but given the immense schedule and dollar cost of losing the pad, how much less valid would bifurcated tests be? Like each sub-system is tested in-place on the pad without firing the rocket and then static firing itself is done on a more expendable test pad? Maybe even a test pad that's only designed to only survive long enough to get the necessary data before melting and losing the rocket.
Or alternatively, as you mentioned, when it's time to test full fuel load, skip the "static" part and do everything possible to get the rocket up and away ASAP.
The alternative is you don't find out about a problem until it destroys a customer payload. That's better than losing the launch pad, but it depends on the actual probability of each event happening.
What if a static fire reduces your chance of losing a customer payload from 20% to 0.2%, but increases your chance of losing the pad from 1% to 2%?
And note: If they had skipped a static fire and gone straight for a launch, they would have lost the pad anyway, since the explosion happened at ignition.
If one pad is the bottleneck, and the goal is to ramp up to be a spacex competitor, then build more than one...
Falcon has shown the playbook, and the demand for launch... The goal should be 2-4 launch sites in the medium term; with a second site very early to avoid exactly this.
Until recently, SpaceX only acquired new pads because they needed a completely new launch site (SLC-4 in Vandenberg) or needed to launch a vehicle that their existing pad(s) didn't support (Falcon Heavy for LC-39A, Starship for Pad A in Boca Chica/Starbase). Currently, Blue Origin's only orbital launch vehicle is New Glenn, and their Vandenberg pad is still under construction.
Launch pads are not something you just buy on a whim to keep around just in case you need them. They're very expensive pieces of infrastructure that you only acquire when you have an actual, known need. That's how every launch provider that I know of behaves, including SpaceX.
I don't disagree at all, but I'm quite curious where the cost actually comes from. Even including all the harnessing and other hardware, it doesn't seem like something that should be a bank-breaker when we're casually talking about vehicles worth tens of millions of dollars blowing up, if not being discarded after a single launch.
If you’re NASA, the cost comes from a cost+ contract with an incompetent vendor.
If your Blue Origin, the cost comes from each launch complex being essentially bespoke and
built on-site.
If you’re SpaceX, you plan ahead to use lego construction,
mass produce the pieces, the tanks, etc in a factory setting, and assemble the pieces on-site for much less and much faster.
I'm guessing its a combination of needing to acquire a massive amount of land among a limited number of candidate locations and then layering logistical constraints on top of that.
SpaceX is "in the process" of a lot of things, not all of which pan out. So far the cases that have actually started serious construction are in Cape Canaveral, and will absolutely be necessary assuming Starship becomes operational (because the number of launches SpaceX is allowed to do from Starbase is limited).
Except that they are a competitor trying to catch up; it's not enough to follow what spacex did. They need to target where spacex will be when their own product is mature.
> if you take that approach when testing all the thousands of components together, which is simply just too complex to exhaustively model[1], you'll never get anywhere.
This is exactly why ideas like test-driven development don't work well as a general approach.
Most realistic systems exhibit non-linear interactions where correctness is not compositional. Local correctness does not compose upward in any meaningful sense. Top-down design (working backward from the customer) allows for you to perform what is effectively one big global search. Bottom-up design (TDD) requires many local searches that all have to fit together perfectly at the very end. With units & composition, the consequences of component A's interactions with component B may not be considered until nearly the end of the project. If you are testing an integrated vertical, you will discover these interactions much earlier.
That's not how TDD works. You test the whole chain and all the components with tests and you can move from top to bottom with TDD, it's actually how you should do it.
There's a disconnect between TDD using all sorts of tests (unit, integration, hardware-in-the-loop, in-field, etc.) and TDD using unit tests only. Unit tests provide the least value/line of test code of all types of tests. They're important, since they can catch bugs earlier than other sorts of tests that can't be caught by a type system, but not sufficient to catch most bugs.
Not true. In early rocket days, soviets tried to use "move fast and break things" approach. They even put artillery generals in charge, who very much liked the approach.
The problem became apparent with several failed launches of moon lander, when rockets blew up or failed to deploy payload. So engineers spent month of assembling a lander that just got burnt. And when it reached its destination, it failed to perform, because they didn't test it separately extensively.
Then they realized it is faster to spend a lot of time testing each part on the ground instead of launching it all together when any bug would prevent even testing the rest.
Well, they just had a failure, so that spells great success, right?
I'm unclear on the point of why having a rocket blow up when you're being slow and careful is more of a setback than having one blow up when you aren't.
Information theory. If you are doing lots of small, incremental tests, burning through a lot of hardware doing all sorts of characterization and qualifying tests, learning a little bit from each one, you can make steady progress, finding your mistakes as you go.
If instead you try to work out everything in painstaking detail, build a small number of prototypes that your calculations assure you should work, and one blow sup, you learn that...your calculations are wrong.
Imagine developing software with no CI tests, where you only get to run one full system test every couple of months. Slow and careful means avoiding lots and lots of early learning opportunities.
> Crushing only because their cadence is so slow compared to SpaceX. Their process seems much closer to the highly risk averse methodology of traditional incumbents than to SpaceX's style. Failure becomes a self-fulfilling prophecy.
This is a silly perspective. Some reports suggest SpaceX's 1-year budget is around 20 times the yearly budget of Blue Origin. Of course SpaceX can afford to blow up rocket after rocket. The radical difference is not methodologies, but how much cash is being thrown at the project.
For perspective, apparently the whole lunar lander program ran on a 1-year budget much similar to SpaceX's, and thus 20 times larger than Blue Origin's. Where they also highly risk- averse?
Or just make it more difficult to squat obvious namespaces, and add an identity management system (like PGP Web of Trust, but simpler) so you can limit yourself to trusted packages, e.g. packages vouched by your preferred set of root signers who publish compilations of trusted publisher keys.
Expecting a kitchen sink approach for a low-level language can't work out. In low level systems languages your algorithms and interfaces are (or should be) much more tightly bound to specific solutions. It's much easier for abstraction to become excessive and counterproductive.
> so you can limit yourself to trusted packages, e.g. packages vouched by your preferred set of root signers who publish compilations of trusted publisher keys.
This is really not good enough. The real gigantic problem with supply chain risk is not that you get tricked to use a package by bad actor, it is that if everyone using gazillion packages by known good authors, that makes all those known good authors with upload rights for their own packages into exploitable vulnerabilities for all the software that depends on their libraries. So far, this has mostly looked like someone stealing creds and sneakily uploading compromised versions, if the situation persists it will eventually get worse with organized crime attacking and using rubber hose cryptoanalysis on devs. There is too much value hanging on too wobbly a foundation here, the situation is not stable and it needs to change.
The C++ standard library is terrible because it was designed from nothing with no actual real-world testing. IMHO the best path forwards for Rust is that when crates become established and "complete" with little further development needed, they should eventually be merged into some large conglomerated library with an actual organization behind it. This doesn't necessarily need to be the standard library that ships with the language. Yes, this would end up like Python, where eventually there would be 4 http clients in there with 3 of them deprecated, but that would still be better than the present state of affairs.
The C++ std lib is no longer terrible. It is really at a usable level these days. Not fun, but totally bearable. The motivation for C++ has never been the quality of the language or the std lib anyways, so it can happily chug along in many places (including the browser I am typing this on).
I disagree about merging existing "done" libraries into a mega library. That can work to some extent, but that approach will not produce something lasting (in the sense that it will remain without the need for changes for a long time). The way to achieve a lasting mega library is by putting all the pieces you need, and constantly working to increase the consistency between them. Somewhat like turning a long winded rambling into a much denser article.
Going from a set of good and working libraries to a large CONSISTENT library would be substantially laborious. Hence the need for someone with deep pockets to take it on. (There are other ways for that to happen but those are rarer).
It worked well for C++ during its first decade, each compiler had quite nice frameworks with kitchen sink approach.
It went out of favour since the 2000's, because of the raise of ecosystems like Java and .NET, followed by everyone with exception of Microsoft, going for other systems programming languages on their desktop and mobile OS platforms.
Also the consequence that we eventually got reduced to GCC, clang, and MSVC, and only one of them cares about frameworks. The other exception being C++ Builder, but that one is largely ignored outside big corporations.
C++ (the language) and its extreme complexities (each perhaps added for a good reason at the time, and then held together with backward compatibility as glue) reduced itself to gcc and clang. Not the std lib. The std lib is, de facto, removing some of the complexity.
Recent C++, together with a couple of major libraries, and with a good style guide and a matching lint (that removes / restricts many footguns) is far better than it was, 15-20 years ago. While it is not exactly cool, it can be totally bearable.
My point is the current success can be "copied over" to rust by cloning (or otherwise obtaining) a good base std lib, and a few domain specific comprehensive libraries. That doesn't even need to affect the existing ecosystem. There can be several parallel ecosystems and each one can be relatively thriving (one doing nodejs style YOLO, one doing enterprise extreme best-practices, one doing efficient embedded or OS level work, etc.). However, apart from the nodejs style community, the rest will benefit [heavily] from a base library that is well designed and NOT subject to change. Even a travesty such as a vibe-cloned golang std lib would be an improvement over the current situation.
> Recent C++, together with a couple of major libraries, and with a good style guide and a matching lint (that removes / restricts many footguns) is far better than it was, 15-20 years ago. While it is not exactly cool, it can be totally bearable.
Which is the main reason why despite its warts, C++ is my go to systems language, when I need to do something outside Java, C#, node. It is anyway for "unsafe stuff" for the most part.
Additionally being the systems language those runtimes rely on, and for stuff like GPGPU.
Always use static analysers and hardened runtime, it isn't Rust, but still so much better than C.
> My point is the current success can be "copied over" to rust by cloning (or otherwise obtaining) a good base std lib,
That I agree as well, it cannot be that for basic stuff like general purpose error handling, or handling macros, we need to rely on third party crates. Or that for all pratical purposes, tokio is the async runtime.
Honestly, at fundamental level, it is less of that need being dependent on third parties, and more of not having at least ONE set of consistent libraries (or one big library). To me the real value add of golang's std lib is not that it is developed by the language authored (that is maybe the third or fourth key point). The first one is the existence of one set (or 1.5, heh, if you consider golang.org/x slightly different) of libraries that are polished and hammered to be consistent together (primarily by spending an enormous effort on simplicity, but also on repeated polishes prior to the first notable public release and some thenafter). This is at the core of what I think rust needs right now to break through and penetrate into real C++ and golang circles.
Or, as prep school teachers and college professors told students who asked the question "How long does the paper have to be?", "Short if you have a lot of time and long if you don't.
I (now) fondly remember getting my first English paper back as a hs freshman with an F. Shook me to my core. I had, after all, gotten into this good school as one of the select few. That was a good lesson and it's served me pretty well.
reply