> in what universe does it make any sense for the bank to go to the store or stores you purchased from to demand the money back rather than to you, the borrower?
It's a common legal strategy to sue those with deep pockets, regardless of whether they bear the greatest responsibility, in order to get more money. Makes perfect sense because they (the store in your example) actually have the cash. Are you going to sue the gambler or the casino?
Another strategy is aggregation. If you can combine cases into a single case, the payout can be larger for similar effort - but once again this depends on ability to pay.
Going one step further, if the seller is part of an illegal cartel or pyramid scheme, the government might be able to justify seizing its assets, or perhaps collecting punitive damages.
That seems like a good support lifetime. macOS 26 is the last version of macOS which will run on x86 systems, which Apple sold until 2023. (Security patches will probably go through 2028 though?)
Machines are thousands of times faster now, yet C++ compilation is still slow somehow (templates? optimization? disinterest in compiler/linker performance? who knows?) Saving grace is having tons of cores and memory for parallel builds. Linking is still slow, though.
Of course Pascal compilers (Turbo Pascal etc.) could be blazingly fast since Pascal was designed to be compiled in a single pass, but presumably linking was faster as well. I wonder how Delphi or current Pascal compilers compare? (Pascal also supports bounded strings and array bounds checks IIRC.)
> I wonder how Delphi or current Pascal compilers compare?
Just did a full build of our main Delphi application on my work laptop, sporting an Intel i7-1260P. It compiled and linked just shy of 1.9 million lines of code in 31 seconds. So, still quite fast.
IIRC Multics (among other systems) had both segmentation and paging, and a unified memory/storage architecture.
[I had thought that Multics' "ls" command abbreviation stood for "list segments" but the full name of the command seems to have been just "list". Sadly Unix/Linux didn't retain the dual full name (list, copy, move...) + abbreviated name (ls, cp, mv...) for common commands, using abbreviated names exclusively.]
Correct. 'Segments' are the Proper Unit to think about a bag of bits doing a computation; pages sitting under segments is how VM systems worked to only load the active parts of segments; that's kind of what defined Demand Paging. We have got to get back to the garden here, we need to start valuing security and safety at least as much as raw speed. https://en.wikipedia.org/wiki/Multics?useskin=vector Tagged memory, Capabilities (highly granular), and, yes, segments. Probably needs a marketing refresh (renaming) so as to not be immediately discarded.
Both this and parent comment about PA-RISC are very interesting.
As noted, stack growing up doesn't prevent all stack overflows, but it makes it less trivially easy to overwrite a return address. Bounded strings also made it less trivially easy to create string buffer overflows.
Maybe it is sometimes part of a person's identity. But people who have quit using tobacco or other drugs are typically called "ex-smokers" or "former users/addicts", respectively. (Even though "smoker" is still a somewhat "cool" identity in popular culture, with many movie villains - and some heroes - still smoking.)
Without trying to make it sound judgemental I know literal dozens of people who stopped smoking and it hardly comes up in conversation anymore - I think I have like 2 friends left who smoke, out of... more than 50%? And several of them smoked for 10 years or more.
Maybe it's because most people don't just randomly are offered cigarettes or because it went from a "50% of the population" to "10% of the population in this age group".
I'm not saying that sober alcoholics are making a big deal out of it, it just feels different - maybe because it is seen as a lot more problematic than being a smoker? Or harder to quit. Or because it's rarer.
Good point - cigarettes are increasingly harder to find, and are banned in many places (restaurants) where alcohol is readily available, and associated with sociability. There even seem to be more marijuana shops vs. tobacco shops (or liquor stores for that matter) in some places, and the former are advertised while tobacco advertising is banned. On the other hand, while smoking may be in decline, I still see (and smell) vaping everywhere.
First hit is free; it is a cool hobby though and I like how it combines arts and crafts with gaming, strategy, world lore/building and storytelling, as you noted.
Also the skills are likely transferrable to RPG minis as well as general model building and painting.
I think custom game pieces for basically any tabletop game are a killer app for 3d printers. Also custom scenery and minis for RPGs (for example a mini customized for a player character, a custom monster, a key NPC, etc.)
Probably good for making doll house (or action figure hideout) furniture and accessories as well, though I expect part of the charm of that hobby is making tiny furnishings etc. out of realistic materials like wood, fabric, or ceramic.
And of course for creating replacement components for any toy or model as needed.
The PL/I stack growing up rather than down reduced potential impact of stack overflows in Multics (and PL/I already had better memory safety, with bounded strings, etc.) TFA's author would probably have appreciated the segmented memory architecture as well.
There is no reason why the C/C++ stack can't grow up rather than down. On paged hardware, both the stack and heap could (and probably should) grow up. "C's stack should grow up", one might say.
x86-64 call instruction decrements the stack pointer to push the return address. x86-64 push instructions decrement the stack pointer. The push instructions are easy to work around because most compilers already just push the entire stack frame at once and then do offset accesses, but the call instruction would be kind of annoying.
ARM does not suffer from that problem due to the usage of link registers and generic pre/post-modify. RISC-V is probably also safe, but I have not looked specifically.
> [x86] call instruction would be kind of annoying
I wonder what the best way to do it (on current x86) would be. The stupid simple way might be to adjust SP before the call instruction, and that seems to me like something that would be relatively efficient (simple addition instruction, issued very early).
Some architectures had CALL that was just "STR [SP], IP" without anything else, and it was up to the called procedure to adjust the stack pointer further to allocate for its local variables and the return slot for further calls. The RET instruction would still normally take an immediate (just as e.g. x86/x64's RET does) and additionally adjust the stack pointer by its value (either before or after loading the return address from the tip of the stack).
> Android users highlight a better system. On that platform, developers must separate promotional, transactional, and service-related notifications into channels. You can silence the ads while keeping delivery alerts or account updates.
> Notifications were designed to inform. Instead, they’ve become another tool to sell. Unless platforms enforce stricter controls or let users fine-tune preferences, the problem will only grow.
It's a common legal strategy to sue those with deep pockets, regardless of whether they bear the greatest responsibility, in order to get more money. Makes perfect sense because they (the store in your example) actually have the cash. Are you going to sue the gambler or the casino?
Another strategy is aggregation. If you can combine cases into a single case, the payout can be larger for similar effort - but once again this depends on ability to pay.
Going one step further, if the seller is part of an illegal cartel or pyramid scheme, the government might be able to justify seizing its assets, or perhaps collecting punitive damages.
reply