I wrote a small program in Algol 68 once. It was horrible because it didn't even have heap allocation in the language, so things you'd think of doing in C (e.g., tree data structures) just didn't work. That and all the compiler errors were pure numerical codes which you had to go look up in the manual (not provided). And forget about getting line numbers.
I am very much glad I wasn't alive at the time this was the state of the art.
> It's probably too much to ask corporations to dump money into it as it would not be a legitimate business expense.
Um, excuse me?
Ok, let's suppose you've got a product that depends on open source project X. For simplicity let's say it's a direct dependency, though I think everything here applies to indirect ones as well.
Let's consider the options.
Option 1: never pay a dime for it. This works in so far as someone else picks up the bill. So really there are two sub-cases:
Option 1(a): the project is successful enough that it's self-sustaining. What this really means is that someone else (or multiple someone elses) picked up the bill. Congrats, you lucked out.
Option 1(b): the project is insufficiently funded and either dies or has a major security breach. Now you end up paying either for the security breach fallout and/or to replace the component, possibly on short notice, with something else. Or you maintain it yourself and start paying that cost, again possibly on short notice.
Is that really worth it? Do you think so? I'm betting all those costs are higher than it would have cost to maintain it in the first place. Because anything you do in an emergency is more expensive, and you're paying the cost of losing all the context in the development of the project itself (if someone leaves before you start maintaining it).
Option 2: pay for the software in the first place, making the cost predictable and avoiding a low-probability high-impact failure mode. Honestly, given all the risk management companies do, this seems worth it to me. At least if the dependency is critical enough.
Obviously you won't do this with any random open source project. But that's sort of the point: companies are making economic decisions all the time about what they really care about. If they aren't paying, that means they're happy with the inverse lottery[1] of the failed open source project model.
[1]: An inverse lottery is one where most of the time you get nothing, but rarely you lose big.
Option 2: Fork the code and do whatever they want with it.
Option 3: Directly employ open source project maintainers instead of donating to the project. They can exert at least some control over project direction that way.
Most enterprises don't even have a budget line item for open source project donations.
> Most enterprises don't even have a budget line item for open source project donations.
But it's common that they have employees who are assigned to working on the open source project. That's an item in the budget, it just isn't labeled "open source project donations".
If you could only drive electric-based cars around your own neighborhood, the usage modes would also be entirely different and they never would have taken off either. (As, case in point, did effectively happen in the era of electric golf carts. It wasn't until they got real cars with real car range that things were comparable enough to challenge the status quo.)
I don't understand the question. We are talking about the way it in fact works. I'm guessing that nobody at the FAA or FCC has any misunderstanding regarding this fact.
Also phones don't meaningfully actually interfere with modern avionics. If your safety on the flight actually depended on hundreds of people clicking a button consistently every time the majority of planes wouldn't make it.
I guess I got turned off by the visually loud Akamai branding on their landing page, and the talk of "cloud" on that page made me think they'd done away with the old Linode VPS product entirely. But it's good to know it still exists. Thanks.
I'll need to look into the other clouds. But as for Amazon, the page about their Elastic IP price change clarifies that the free tier includes 12 months only, making the IP itself a nontrivial fraction of the total cost to run an instance:
I'm running a Common Lisp webserver with (I believe) nginx in front. It's fairly low maintenance, but it is dynamic web content (the entire point is to generate names on request), so I unless the CDN has some sort of function interface, I don't see how that would work.
If you can rewrite that part of it as a JS function, you can probably host it as a free or very very cheap serverless function on Cloudflare or Vercel. Either would also be able to host the static parts of your site for free or very cheap.
Vercel is a AWS and other cloud whitelabeler. Cloudflare has their own networks.
Yeah, the static portion is trivial. The trouble with the dynamic portion is that I use a proprietary C/C++ library that I'd have to replace. I suppose in this day and age I ought to be able to do better with some of the modern deep learning techniques that are available, but I haven't been able to invest the effort to figure that out yet.
... well except it stores up to 15 bytes inline rather than using the UTF-8 trick to cram an extra byte. (But maybe it can't; or at least, ByteYarn really can only store 15 bytes, even though Yarn could store 16 bytes maybe, but this would pose problems when converting between those types because I suppose this conversion is zero cost)
The optimal size will depend on the application. It's certainly reasonable that in some applications, many/most strings would be under 24 bytes and thus the small string optimization in many of these implementations would be beneficial. Perhaps in some other application strings are closer to 32 bytes (or something else) and then a larger stack size would be warranted. And in yet other applications, strings are large and no small string optimizations will make any difference, and if anything will slow the application down with unnecessary bookkeeping.
I do find it surprising that none of the implementations in the various comments linked in this thread seem to provide user-tunable sizes; or at least I haven't seen it. Because I can certainly imagine cases where the optimal size is > 24.
I am very much glad I wasn't alive at the time this was the state of the art.
reply