296 karma · joined February 19, 2010
Then senders' incentive will become to make the subject line into clickbait for the content, so that you'll open the message. So instead of subjects like "Order placed", "Order paid", "Order shipped", "Order out for delivery" you'll get uniform subjects along the lines of "IMPORTANT UPDATE TO YOUR ORDER". You will lose efficiency getting through your emails, and over time the metric will lose its indicativeness. Everybody loses.
https://pypi.org/project/jsonmason/
"maybe doing something depending on context for some nodes in a nested structure by using transforms or side-effects while iterating over the regularized representation of the structure's nodes"
It's a library but also includes CLI utilities that do the same as gron. Well, I hope without that memory ballooning problem described in sibling comments.
But this would require coordination in POSIX, in the terminals, and in programs using the terminal :-/
But the advantage would be that then you'd be able to put your terminal into this safe mode by default. And the terminal can alert you when a program is writing out control codes that are being ignored, and then you can whitelist them and/or get those programs fixed to fence off their sections of "I'm going to output data from god-knows-where now" with this new terminal mode.
It's not going to happen but we can dream ;-)
I emailed the Tar maintainers privately because I thought they might consider it a security vulnerability, however mild. They fixed it promptly but didn't want to make a CVE fuss out of it.
Demo: https://media.ccc.de/v/all-systems-go-2023-225-making-a-magi...
Background and utility to put such messages in tar archives: https://curiosities.nontrivialpursuit.org/tarvertise-put-a-m...
You can see for yourself whether you have the fix:
Fast featureful terminals (for instance, Kitty):
curl -s https://obfusc.gavagai.nl/roll.tar.xz | unxz | tar tf -
Less featureful terminals: curl -s https://obfusc.gavagai.nl/compatroll.tar.xz | unxz | tar tf -
Slow and featureless terminals: curl -s https://obfusc.gavagai.nl/compatroll-lowfps.tar.xz | unxz | tar tf -The human body does not convert heat to work. We do something entirely different (look up the "ATP/ADP cycle").
But yeah there are certainly conversion losses in the conversion of egg sandwiches to labor. 25% or so. Which is actually pretty good; you won't be able to match that with a steam machine built over the weekend (start with solving the problem of setting eggs on fire?).
Yes — but it will always, ALWAYS launch your shell as (typically) defined in /etc/passwd, and will pass it two string arguments: "-c" "and your particular command with arguments and all". Go strace it, go look at the argument vector, you'll see. Thus if your shell is bash, zsh, tcsh, dash, sh, whatever: the moment that it sees and tokenizes "and your particular command with arguments and all", you'll have lost.
The only winning move is not to play.
> Configuring ssh to run a dedicated command line is probably an underutilized, underrated mode of operation.
Perhaps, but in any case, it doesn't save you. As I explained above, your shell runs first, so you've already lost. Maybe it's not underrated, maybe it's rated exactly right because of this problem!
But what if I tell you you can make your problems go away. You juuuuuust have to use this very special shell. I don't want to be downvoted for linking it for a third time on this page, so I won't. Thus: see my other comments on this page :-)
There's another way to look at it.
For project estimations I've made people give up on the whole fiction of estimates by simply confronting them with the fact that maybe it's going to be very easy (eg, there's an API for it already, or there's a nice library), or maybe it'll be quite hard (eg, it may require writing a sqlite extension, or using multipath TCP, or something else you haven't done before).
That's a probability cost landscape with two peaks! And the number you get by interpolating between the peaks will be the most wrong.
Makes some people's heads explode, because they want to slot a single number into a field, and you're just not giving it.
Some others will see the light and leave you to your explorations, after which you'll sync with them on your findings and where to go from there.
The README contains my own explanation of the phenomenon.
I wish there were some kind of "modern tech" technical review panel on board in, say, EU and US regulatory institutions. Not to impose or forbid certain changes, but to curate an evilness score. Publicly.
And then if a monopolistic company consistently enshittifies things, when the time comes to apply a penalty (for some anti-competitive legal reason), the regulators will apply the reputation ("evilness") score as a multiplier (or divider, if you will) on the sum of the fine.
Evilness can't be measured and expressed fully objectively. So citizens should be able to override a reputation score mutation (remember, they're public) through a referendum.
An advantage of this approach would be that it could increase citizen awareness that things don't have to be this shitty. I'm occasionally amazed by how friends and colleagues put up with being pushed around by their OSes, their apps, their phones, sometimes to the point that cognitive dissonance makes them into apostate apologists.
Of course without the big fat asterisk of "actually, we have no idea what our false positive ratio is. So they could be 9000 prospective customers that we blocked."
And then the customer will think "oh wow good service, all those baddies blocked, better stay in the warm embrace of this service or who knows what will happen to my site".
https://pypi.org/project/DBSamizdat
In a nutshell it allows you to keep DB functions, triggers and views around as Python classes, so you can version them together with the rest of your application code. The DB state gets updated for you (in the right dependency order) whenever you change them.
It can also run without Django.
For prose of course it wouldn't be acceptable if you can't use your full language, but this is a filesystem, and we're talking identifiers, not prose. We accept that for a wide range of everyday things — I don't think many people are getting worked up about web forms not accepting their phone numbers when entered in Latin numerals.
Using bytestring labels sans normalization is just the rational choice, and actually quite accommodating. People _can_ use their natural language. If you can encode your prose in bytes, then there you go, that'll be your filename ;-) and if you can't remember what diacritic-combining strategy you used when you created the file, and can't manage to fopen() it anymore by typing out the filename, use a file picker or search. And then, perhaps, go "that was a hassle, I'll avoid those fu͝n͜n͏y͝ sq̧u͜igg̶l̢įȩş for my next filename, computer are stupid" - not the end of the world, not the worst outcome.
Stops you from what? I'm not sure what you mean there. No one mentioned inhuman. Someone, not me, instantiated a "labels for humans" concept and I roll with that, for the sake of conversation.
>> Primary keys? > Do those accept any bytes in a bag?
Well, a "bag" (unordered) would not be the right term, but we understand what the original author meant (a bytestring), so: Yes, in fact they do. For instance, PostgreSQL:
create table bla (joyfulkey bytea PRIMARY KEY)
We don't want identifiers mangled. Should you be so unfortunate to have to use bytestrings as primary keys, then they'll come out the way you put them in. Because they're unambiguous identifiers. Not prose.
> So you just want normalisation-preserving filesystem?
I want an identity-preserving filesystem. And I have it!
> But I see that you care so little about human users that you think they should learn to avoid Á outside of letters to grandma...
I care a lot about human users. I give them nice file pickers so that they can easily choose to open files named ÁÁÁ.docx. Or search for those, using a system where both query and index is normalized (as is the common approach). And the other kind of users, also human, who find they care about the identity of files since they're writing that search engine and have to pass them in an argument vector to get the PDF viewer to open the file that the user found, will be most happy if they don't need to worry about the file system second-guessing them on identities.
PS There's a lot of you-this you-that ad-hominem things in your comments. That's not really the best way to hold a discussion.
"But that's subjecting the user to limitations of the system!" you might object, and while you'd be right we should also ponder whether a filesystem is a word processor or a system for locating data using filenames as identifiers, and consequently, what sound handling of identifiers is.
And let's be realistic. Most users will choose the file to open from a file picker dialog. fopen() is not their interface, their interface is a file picker.
The intersection of people for whom fopen() is their interface (no file pickers) but for whom learning lessons on the value of using unambiguous identifiers is somehow out of reach, would be exceedingly small.
A filename is an identity and if identities are ambiguous, you run into trouble, examples in this thread abound.
Putting it another way, do you work with relational databases? Primary keys? Those are identities. I don't even want to think about a world in which I can't roundtrip data through a database and have things NOT come out the way I put them in. "Human labels" or not ;-)
Of course it's fine to search for things case-insensitively or otherwise normalized. And so we have "find -iname" and "locate -i" etc. etc. That's totally reasonable.
Coming in From the Cold: Untold Stories from the Cold War: The Moscow Signal and Havana Syndrome
Episode webpage: https://ciftc.libsyn.com/the-moscow-signal-and-havana-syndro...
Media file: https://traffic.libsyn.com/secure/ciftc/CIFTC_October_2022_m...
Basically, portraying rules (that are to your disadvantage) as some kind of laws of nature. So for instance:
"To continue, you need to install the app".
Instead of
"We're not letting you read more of this since we think you're webbrowsing this on mobile and want you to install our app"
Quite often we're indeed being lied to as if we're little children.
But in this exceptional case, the "Fun disabled by administrator", it's frank! That must be because its this third party, the "administrator", which is to blame for the restriction. Were it google themselves setting the rules of the game, they would probably not frame it in the same way.