For C++, that's only valid for some subset of types, which currently can't be expressed with type traits. "Address-free" has a close enough definition in the context of atomics.
Trivially moveable types are probably sufficient (at least, I can't construct a case where being trivially copyable is needed), but not necessary; there are many things a special member function can do without caring about the address.
In practice, the main problem is that you can't use private mappings (which are the default and for good reason); you have to use shared mapping, which are very finicky to set up and cause infelicities with `fork`. [This does make me wonder how reflinks/`copy_file_range` interact with `mmap` and the page cache.]
Really, you should just fix all your APIs to take an `iovec` array.
On linux you can use remap_file_pages[1] to setup your magic ring buffer. Yes, these days it is emulated in the kernel, but here we only care about setting up the expected duplicated mapping of anon pages instead of minimizing the allocations of VMAs.
Also linux has MADV_DONTFORK, would that allay your concerns? (there is a potential race between mmap and the madvice call, but if you are forking in a multithreaded program you have worse concerns).
> In practice, the main problem is that you can't use private mappings (which are the default and for good reason); you have to use shared mapping, which are very finicky to set up and cause infelicities with `fork`. [This does make me wonder how reflinks/`copy_file_range` interact with `mmap` and the page cache.]
Yet another reason fork was never a good design choice.
NO_NEW_PRIVS is quite irritating in a lot of contexts, since it breaks distant dependencies. For example, you can't run `ping`, so good luck debugging your networking!
> For example, you can't run `ping`, so good luck debugging your networking!
Sending ICMP Echo in userspace (over UDP) is a thing on Linux. From experience, for public Internet, where possible, it is always better to rely on TLS connects (then TCP or UDP, and then ICMP) to ascertain connectivity (lest some middleware meddle with IP or Transport replies).
> Please note that busybox can’t function with a name that is not a busybox applet name.
This is somewhat wrong. From ksh/bash/zsh, you can run:
(exec -a someappname /arbitraryexecutablepath args...)
This won't work on most ash derivatives (including /bin/sh on Debian, FreeBSD, or NetBSD), but does work on busybox ash.
The parentheses prevent the `exec` from actually replacing your current shell, which might be less important for emergency rescues, but which otherwise is often what you want with `exec -a`.
Until the dotnet packages are shipped in every major Linux distro's default repositories (it's okay if it's a 5-year-old version), we can't call C# a major language.
But apparently there aren't enough people willing to actually do the work.
Hm, it says the observer-at-the-slit experiment hasn't been performed because it would absorb the photons. But it also says the experiment can be done with larger particles, so that shouldn't be a problem ...
I have a very minimal Android phone with no Google account ever added/used on the device, and it says my chats with other Android users are using RCS ...
The phone number is associated in the other direction though (way back when Google didn't be evil and GMail required invites, I dared to trust them with it, I forget for what).
The lack of arrow shortcuts for navigation really throws me off (especially since both the mouse and the numpad are normally used by the right hand). Although cells have more than 4 neighbors, there's still a notion of direction; maybe just break ties by what is closer to the previous cell? Or use a subgrid? SGT's "bridges" and "map" puzzles may be interesting; the former doesn't care about neighbors but the puzzle guarantees indirect connectivity somehow, whereas the latter uses a subgrid. "Loopy" which has all sorts of shapes just gives up and disables it, even though good solutions exist for even for non-square grids :(.
Is your "at most 9" logic preventing loops?
I think I could probably get used to visualizing runs on my own if only the shapes weren't so irregular. In particular, the fact that there can be apparent "four corners" means it's impossible to tell which way the run actually connects; you should probably tweak the grid to ensure a minimum edge size (or maybe even forcibly align it to an orthogonal-with-diagonals grid? Either way, remember you don't need to stay Voronoi). Actually, to reduce visual clutter, maybe color the edges rather than the lines crossing them? Perhaps make odd-sided polygons blatantly different too?
Serious sudoko solvers have at least 2 kinds of pencil markings - I find "top" and "bottom" most convenient. Maybe insert an underscore at the end of the "active" set of numbers? (or overdraw for pen marks). But for puzzles complicated enough to need bifurcation, I really just need an arbitrary grid where I can put any number at any location in any order - or else an option to fork the entire puzzle.
And of course there needs to be a "fill in all pencil marks so I can work subtractitively" button.
* The switch to self-checkout overlapped with the push for reusable bags. Some sturdy reusable bags are significantly heavier than others, and at certain stores they choose to make this fail badly (this is by brand, not neighborhood). Sometimes this can be worked around by adding bags gradually when adding variable-weight items. "Skip bagging" is probably how it's supposed to be done though.
* Self-checkout forcing serialization as each item is put into the bagging area. Traditional checkout allows each item to push the previous down the belt.
* Self-checkout often has size limits, either employee-enforced or practical (e.g. by drastically shrinking the item pre-scan and bagging areas; I suppose bag-weight errors also count for this), even if this conflicts with the other major push that stores have ("spend more in one trip!")
* Some items (mostly produce) lose their label and/or don't have one in the first place, and are hard to look up too. Admittedly, this is largely a matter of competence and I've had employees make errors on the same things.
* Items with ad-hoc discounts may be handled badly in several ways ("x% off" stickers usually require employee assistance; full-blown price-replacement are more likely to work but can fail if the original barcode wasn't fully covered)
* Sometimes the scanner beeps, but it's a rejection beep rather than an acceptance beep and those of us who don't spend all day doing this can't tell the difference. If you continue scanning and it keeps beeping, it can be difficult to resynchronize once you realize the problem.
* If anything at all goes wrong with the price of an item the system does register, noticing and arranging for the fixing of it is entirely on you, while you're busy doing work. With traditional checkout, you both have another set of eyes and are not distracted during the process. IME this causes problems at least one per month, and some of the errors reek of at-least-borderline fraud (four common kinds: 1. advertised price only applies to packages of a particular shape/color/size despite literally all the writing being the same; 2. "selected varieties" arbitrary excluding certain flavors/varieties which is impossible to check unless you can make the buggy app/webpage navigate through the huge list; 3. advertising a product not actually sold in the store (or removed for just this week) but then putting a similar-looking item on the shelf; 4. arbitrary limiting a particular digital coupon to the specific store in town you have selected, even though the exact same coupon is also available to those who select the other store). With a real employee, you have someone who both prompts and knows how to simple handle things like "did you enter your rewards card correctly?" [which can be done in parallel - though on one rare occasion they actually finalized the checkout, changing it to card-reader mode before I could finish entering it!], and is always available to handle errors immediately rather than requiring you to queue for customer service. Because of how frequent errors are (and just how terrible many customer-service people are at math), on the rare occasion that a pricing error is in my favor at a grocery store, I do not feel at all guilty about just taking it (all other kinds of IRL store have thus far dealt with me honestly so I remain obligated to do the same).
For me the problem has never been about outright breakage.
For IDEs, I have often observed: the whole is less than the sum of the parts. Trying to cram them all into one UI ends up removing a lot of capabilities, and it is always more difficult to add additional parts after the fact (since we should never assume all tools can be up-to-date with a changing world), compared to simply using the tools individually.
reply