The first time I saw perfectly valid Unicode take down an RSS reader (in ~2003), it was an ü that did it. I have taken to calling that the kaboomlaut in unit tests.
The are quite a lot of "gotchas" with passwords being Unicode though. One of my favourite tricks is to include a null byte in passwords and see what happens. Sudo treats it as the end of the string. Passwd gives "token manipulation error" and nopes out. Many websites seem to fail in interesting ways...
I've run into a service where having a password longer than 15 characters _truncates_ it but the password change dialog does not so it's stuck in limbo.
The PayPal forgot password form had this bug just a couple years ago. I changed my password to a generated one. And it was too long. But it didn’t tell me. Just silently truncated.
I used the password reset to change it. This time I used a pretty short password I could type (to rule out a weird copy-paste bug or something). Logged in, went to the change password option and THAT page informed me there was a character limit.
I would consider setting a (high) limit for a password a good practice. No one wants an attacker to run a megabyte of password data through your slow password hash. It should be a limit that normal users never reach, but something like 100 chars seems entirely reasonable.
Some web frameworks have such limits built-in.
Django for example has a limit of 4096 characters for password input, which should be more than enough for anyone, including people using long random-generated passwords from password managers
The reasonable thing to do is to prehash the user password on the client with a Unicode normalization and a SHA-512 pass.
This way you can have strong input validation server side but also allow almost arbitrary inputs client side.
PS: you likely could also salt the client side hashing and use bcrypt, but bcrypt has a quite short maximum length and I am not sure if it would provide significantly better security here.
I know of banks which, in 2023, requires exactly 8 digits, the first four being numbers, the other four later letters. No digit can be repeated. Also no consecutive numbers.
It's like they're deliberately trying to reduce the pool of valid inputs.
Not only this, but they also have a sadistic trait against their users. My password on another site (a bank too, IIRC) requires the password not to have my email username and consecutive, or repeated letters. My email username is "u" (as is u@example.com) and I usually generate a 50 or 70 characters long password. There is usually a "u" (they check the case, too). And come characters are repeated in the whole password.
So I reduce the length, significantly, sometimes to 8 characters.
The people who make rules in security in some areas are complete idiots.
A bank I used until about 2018 (no idea if they've fixed this yet - I left) had an exactly 6 character password, and when you used telephone banking it just needed the 6 digits that corresponded to that word. Those 6 numbers also worked online, so at best they were turning all passwords into numbers before hashing them, ensuring there are less than 900000 different possible passwords, which was trivially easy to brute force in 2015, nevermind today.
Bruteforcing should not work as the attempts are either throttled, or lock the account. Provided that they are in place, otherwise the account is wide open.
This i what happens with the 4 digits of a CC PIN and the 3 attempts before the card switches into PUK mode.
One site I went to lowercased my password before storing it unencrypted in the DB, which I only discovered after failing to log in and asking for a password reset mail, so it helpfully emailed me my clear text lowercased password.
I worked at a place that did this, case-insensitive passwords and all. The worst part? They had unencrypted production database backups on all of their dev laptops, the majority of which left the premises after every night. I couldn't get a figure of how many laptops were lost but statistically speaking there had to have been at least 3 lost laptops with unencrypted production database backups per year using industry statistics.
Eventually I convinced leadership to invest in basic security after conservative but still embarrassingly high 6-to-7-figure estimates of annual loss expectancy that only took a measly 5 figures a year to eliminate 75% of the risk, but the company only went around to it a long while after I left the place.
I think the lesson is "stop asking for permission and just do want is right". It's rare that a manager needs to approve a PR - would be a culture smell for me in an org.
It was an online store I bought something from quite a few years back. I would hope most stores are using more modern back ends nowadays that doesn't allow this to happen.
This was, at least a few years ago, the case with Blizzard's Battle.net passwords. I picked a nice secure passphrase, but had to cut it off mid-word because of this truncation. (I think the behavior was for it simply to take the first 16 characters of whatever you typed in the password field, so typing the full passphrase didn't fail, but I wasn't confident that that would remain true in all cases, so I made a habit of only typing the first 16 chars.)
I believe the British Airways site still does something similar to this, or it did until very recently if it's been fixed. Add a password that is too long, it gets truncated and the truncated version saved with no warning or error.
It took me several password reset attempts to realise what was going on, as my literally just set and password manager-saved password didn't work.
I think in BA's case the password input also had a character limit on it, which is ultimately how I realised what was happening, even though there was no info anywhere that such a limit existed.
In C, strings are nul terminated. Thus when at some point your password is passed along a tool written in C (or any language with the same behaviour) it’ll be truncated at that position.
A bigger deal happens with ambiguities concerning composed versus decomposed characters. Linux and Windows tend to prefer writing composed characters, whereas Mac OS will prefer writing decomposed characters. The letter é will have two distinct byte sequences to represent the same character (more precisely, the same grapheme).
If Unicode weren't broken it wouldn't need any "normalization functions".
And no, I don't have anything better to propose at the moment. Unicode is a mess, but currently without realistic alternatives.
Still I would like to live long enough to see that we finally manage to create some proper text format without all kinds of crazy gotchas and deficiencies.
Are you suggesting that a better version of Unicode does not allow combining characters? [1]
Some languages have an explosive amount of characters if you regard each possible modifier in combination with each base character, some of which aren't practically used. By allowing the composition of modifiers and base letters, all the historically used ones are available, and all the odd ones are technically expressible.
I'm not sure how you encode all the world's languages, live and dead ones, without a few gotchas and deficiencies.
What would an always-normalized Unicode look like, if not either having really, really many characters, or having a non-trivial syntax?
One solution to allow combination characters, but only in a normalised way is to only allow one of the same modifiers, and only allow modifiers in the normal order. This makes parsing Unicode quite complex. If you allow for non-normalised Unicode and write a post-processor that normalises, you get to status quo.
So either you are suggesting to disallow non-normalised Unicode with the current definition, or something different altogether. I can't imagine what that alternative looks like.
(Also, I'm a Unicode fanboy. Sorry for the intensity.)
I think normalization and compound glyphs are orthogonal concepts.
The point would be to have only one canonical binary representation. A representation that is also free of all kinds of "compromises" which are only there for legacy reasons…
Additionally the whole madness should be resolved that Unicode mixes content, representation, and layout (especially as it fails miserably at all of them).
Than there are the problems that Unicode is actually incapable of representing all kinds of scripts. (Just think for example about stuff written top-to-bottom, and not LTR / RTL). Some "unimportant" things like Math can't be represented in Unicode also…
And I won't even talk about the issue that the committee was taken over by some political movement, namely the woke fraction.
I think it's actually a kind of joke that we still didn't mange to invent some sane text format for computers. Unicode doesn't cut it.
But frankly I admit that we won't get anywhere — as even Unicode is full of madness it works "good enough" by now through even more layers of madness on top, so we won't get rid of it ever again. That ship sailed I fear. Still I can't stop banging my head when I hear about things like issues with normalization, something that shouldn't exist in the first place in a sane world.
It depends on the encoding: In UTF-16, a lot of characters have 0x00 as part of their encoding. That's the null byte, even if the software isn't technically supposed to see it that way, so it's a valid test. (Easy, too: Any character that's also in ASCII will be represented with a 0x00 byte in UTF-16.) Of course, UTF-8 solves that problem, plus the problem of surrogate pairs.
When AOL 4.0 came out they added the ability to embed images in emails, and there was a super fun bug where you could put a certain unicode char into the file name of an image and it would blue screen the recipient if they opened the email. Fun times.
Sounds 'normal' if the website was built in a recent stack in recent years.
The shipping backend might run on a mainframe, almost if not fully unchanged from 40-50 years ago and blissfully unaware of anything but the mainframe quivalent of your standard ASCII.
You can see large stores run all their inventory and such on mainframes. If you ever look over someone's shoulder. My insurance also does but it looks like they don't because it has a nice standard Windows look on the 'inside' of the window. Looked at the title bar and yep, it's just a 3270 terminal emulator that renders fields as nice standard windows input fields that follow whatever theme your computer is set to instead of your telltale black background "DOS" look.
As I remember it, the RSS readers under test did not correctly handle encodings, blissfully ignorant of the difference between UTF-8 and Latin-1. Many had processing pipelines that did not preserve encoding.
What was the point of this post? No, this program isn't a replacement for sudo; it's closer to a reimplementation of su. The post links to 3 CVEs and talks about Rust, but only one of the CVEs was a memory safety bug, the others are a logic error and a race condition, neither of which are protected by Rust (sadly).
That's a memory safety issue that caused by a race condition. Rust prevents memory safety issues, but not race conditions. The race condition in one of the CVEs is in the filesystem, not in sudo.
Rust does prevent memory race conditions, but of course, only within the address space of the process and only for memory read and written to exclusively by rust code.
I feel obliged to mention doas[1], which is a sudo alternative from openBSD. It is written in c, but tries to be smaller and easier to configure. I am not qualified to vouch for or against it, but it is interesting.
I have moved over to doas a while back and it is really amazing. Why? Because it JUST WORKS. I do not need to learn a configuration language to understand what is going on. It does very little and that is exactly what 80% of the users need. We should use more software like that. Simplicity is the best design pattern.
My existence is split between OpenBSD and Linux. What I really want is OpenBSD than runs Steam and Proton—nothing more.
OpenBSD has maintained exceptionally good taste when it comes to change. When they rip out and replace a "classic" utility, they invariably make a modern classic: openssh, pf, doas
When others rip out a system and replace wholesale, they often just do the hard work to secure the existing thing: Wayland vs. Xenocara
I don't know that there's any objective way to know ahead of time whether replacement or repair is the right approach. But the fact that such a relatively small project such as OpenBSD has managed such outsized positive impact across the open source landscape speaks volumes to their intuitions here.
I noticed and enjoy that both sudo and doas use each side of a standard qwerty keyboard to type, though doas uses 3 keys on the left while sudo has two on the left and two on the right. It made the transition a little easier for my muscle memory.
I didn’t learn anything from this post about why to use this sudo replacement except that it’s written in Rust and that it handles errors. Am I missing something?
I was thinking the same. But then I thought about it more and wondered why you need to enter your own password if you're already logged on. If an attacker is already in the system, it can install key logger and whatnot without the root password. And the xn--ts9h program can have the Unix permission so that only the user can run it.
Insider threat, attacker not in the system, you leave your terminal unlocked and are away. Someone walks passed and tries to install something from you terminal?
While it leads to slightly more chance of traceability, I've seen one line "curl | sh" which install a tool which transmit everything you type, or just your password (when you next type it) off to a remote server, so once you've left a terminal unattended you are in trouble anyway.
This is one place when windows can be much better, as users can't catch ctrl+alt+del, so you can always press that before logging in.
There is the mental function signalling "hang on, you're about to do something unsafe. Are you sure you want to do this?"
But I think there are some scenarios where it serves a practical security purpose as well:
- You're in an office, went away to grab a coffee and left the screen unlocked (bad!). Without sudo, a malicious person could indeed quickly install a backdoor or keylogger and take over your system.
- you're executing a third-party script on your user account. Without a password prompt, that script could trivially escalate its privileges by embedding sudo commands. With a password prompt, you'll hopefully stop and ask yourself why the script is asking for your password.
Basically, you actually cannot assuming that every running on a user account is really authorised by that user. So asking for the password is an attempt to reaffirm that it's really the user who gave that command.
> If an attacker is already in the system, it can install key logger and whatnot without the root password.
Yes, but that would require the attacker to, well, run sudo...
If I'm not mistaken, especially with x11, it is trivial to install a keylogger without root password. Just a process in the background that listen to your keys and send them over the wire.
(And you can add that program in the list of program to run while logging in)
For some more serious alternatives, I have heard of many people finding doas to be a drop in replacement. Furthermore, I've heard some people suggest neither doas nor sudo, but instead using an SSH server to gain root access to your local machine. It could listen on localhost and use key-based auth to allow root logins...
Using key-based auth without encrypting the key with a password sounds like a bad idea, as then any program running on the host can trivially gain root privileges.
Any program running as your user on your personal machine can trivially gain root privileges, by dropping a program called "sudo" in your personal PATH, putting a "sudo" command in your .bashrc, man-in-the-middle a shell (how do you know that last command actually completed?), or hijacking any of the graphical programs that trivially ask you for your UNIX password to do anything (Discord/Slack/... updater, Steam, ...)
When do any of those programs ask you for your password? I've never had any of them ask for my Unix password, ever. Is that just a macOS thing with self-updaters?
I'm using Ubuntu/KDE/Plasma. "Discover" is the GUI app that prompts you to install system updates, and will ask for your password when you do (to run apt/dpkg as root). Discord doesn't directly ask for my password, it downloads a .deb from somewhere and opens it, and I get prompted for my password then. Not much different IMHO.
I'm using Debian(Testing)/KDE/Plasma. (What was the point here?)
I don't have any "Discover" installed as it's not needed for anything. There's aptitude…
Regarding Discord: Discord is a virus. I try to avoid it. (And since you can't register without getting naked and showing the virus your telephone number it's not difficult to avoid ;-)).
That just means you're fully transparent to them. (Likely they have linked other accounts / IIP data behind the scenes; using it form a phone will have that effect obviously).
It's almost impossible to register an anonymous account there. Even if you find a throw-away SMS number that works to register (which is hard enough) a few hours later they will block that account again and require a fresh number to unlock. I've given up even trying to register there; but plan to fill out some GDPR complains soon. Thanks for reminding me to do so…
More likely it just means they have an old account from when they weren’t as hung ho about it all and now they don’t delete it on a whim because it’s longstanding without issue. Same thing with mine, beyond it’s desperate for that phone number for things lately.
Those are poklit popups, similar to UAC on Windows. The program doesn't get your password, but depending on what kind of access it requested, it could give it root access. If implemented correctly, the popup should say "wants to install a package" or "wants to mount drive X", which runs a predefined action on behalf of the app and doesn't actually give it any elevated permissions.
Of course, like UAC, an app could just make its own prompt that looks like the real deal and steal the password, but that seems to be an unsolved problem on every platform.
You can close some gaps, but at the end of the day you can't expect that you'll run malicious code but it won't do this or that. For example the X server allows any client to listen for key events or hook into other windows.
In the enterprise key management can become a bitch really quickly. Good luck updating 10.000 servers every time an admin leaves.
For them ssh certificates are much better because you can simply revoke them, and new certs don't have to be added to each server.
At home I still use keys though, but as an enterprise admin I see the issues. Even at home it's kinda annoying having to add a new yubikey to 20 servers.
You can, but you still need to set up a secure infrastructure to manage all the requests going back and forth.
And most enterprises already have a completely functional and secured PKI, usually with the whole HSM deal and everything. It's plug and play and works with your existing infra.
Last month's electricity bill was about 75€ including electric heating, VAT and fixed charges. I do get 2 hours free per day during which I run the heading full blast at the moment, and other high energy stuff.
Most of my servers are not always on, some are in the cloud and some are virtual.
The ones that run 24/7 are NUCs which have excellent idle energy usage. The bigger ones are HP microservers but like I said those just run when I need them (there's about 100 TB of archive storage in them).
And then I have some raspberries to run my home Assistant and some other stuff. All in All I have about 10 real 'servers', 5 running 24/7, the rest are remote or virtual (one of the NUCs is an ESXi). Plenty of resources for a decent home lab.
With the recent increase in electricity prices I did move one of the microservers from 24/7 to on-demand.
> Last month's electricity bill was about 75€ including electric heating, VAT and fixed charges.
Damn, I'm double+ that a month with turning everything off at the plug each night and during the day when not on. Just one of the benefits of living in post-brexit UK, with a lame useless gov... Anyway nevermind. Always wanted to do the home assistant thing with one of my rpi, but can't afford it just now.
It is not as much the enterprise security industry as it is better security for all. Problem with the current implementation with ssh keys is that there are non-trivial problems with it. For example how do you revoke a key? It is not possible in a central AAA service to revoke access for a user like it is possible for other kind of auth systems. Ssh and ssh keys were designed in an era where security was not really the primary concern. I think Facebook DevOps team had some detailed article how they manage ssh access to fb production with keys.
The main problem with SSH keys is that they are good at small scales, but at larger scales the abstractions start to be really leaky. Distributing SSH keys across hundreds of machines is a nontrivial task. Not to mention the lack of audit logging in opensshd and the lack of session recording (these requirements suck but acronym compliance means you need them anyways).
It's also kind of the wrong tool for the job anyways. I'd love to see tools that are more built to purpose for what you are _actually doing with the servers_ instead of giving people a REPL and telling them to go nuts.
> It's also kind of the wrong tool for the job anyways. I'd love to see tools that are more built to purpose for what you are _actually doing with the servers_ instead of giving people a REPL and telling them to go nuts.
On the other hand, if you knew what I'd need to do with the servers, I probably wouldn't need to do it. It's really hard to investigate problems without tools. Nobody is going to make a graph for how much cpu poorly configured docker/datadog are wasting rereading the same 1GB of json logs once or twice a minute, because nobody thought it would be meaningful, but watching top in one window, and running lsof at the right time to see what's being read, and whatever performance tools are hanging out to confirm.
Ah the dream of easy to administer, perfectly adapted fine grained access permissions that can predict the future of exactly what an authorized user can run and needs to do.
It never works because of the lack of precog, ticket walls, escalation over policy requiring reviews, and other bureaucracy.
What they end up replacing ssh with (teleport or aws ssm are the two I've been forced to use) are slow, spotty, crash frequently, and who knows what vulnerabilities they have.
If all these companies trying to get rid of sshd want to slap their own daemon on to replace it, why not keep sshd and simply have a deamon that manages the keys and not throw out the entire tool chain?
The most fun thing with teleport and aws-ssm: to use it you had to bring up a web page to authenticate. There goes any hope of automation at scale. Because in a world where you're supposed to treat servers like cattle, let's impose (and I mean impose) a regime that forces you to access them one at a time manually, especially in critical situations.
> Distributing SSH keys across hundreds of machines is a nontrivial task.
In what sense? If you're distributing public keys to hundreds of servers, go nuts. Put them in git repos and clone them.
If you're distributing private keys to hundreds of clients, why do you ever need to do this? Assuming you do (and I'm just missing something), then I see your point but if you ensure they're encrypted with the user's pass phrase and you have a procedure for ensuring their permissions are set to 0x600, what's the problem?
Yeah, the trickiest part is getting new users to check in their keys to git if git is authenticated with ssh keys. And if you need sudo to install keys, you've gotta use autopw[1] or something similar, and at least autopw is single threaded, so if you've got more like thousands of servers, it's a bit messy. Smarter people than I setup full automation for this kind of stuff, but then you have to trust the automation.
> what would happen if you gave a company an unpronounceable name and it took off.
As long as it's an actual company taking money/paying for services, you'll have to register it, so it will have a pronounceable name.
Reminds me of "Love symbol" formerly know as "Prince". The symbol is great, but you'll have to register as an artist to get the money, you'll be signing contracts, etc., so whatever clever symbol you find, at some point a standard writable name will be settled on.
If there's a 1:1 mapping from some emoji to one of the basic Chinese logograms, we should just reuse the pronunciation of the latter as the name of the emoji. This one could be "qiu", for example.
The wechat shortcode for their similar face is 可怜.
As far as I know, it is not used for begging (and therefore couldn't be called 求); the one time it was used to me, it seemed to express something more like "ouch!".
It does have a name. The most common of which being being ぴえん (pien). The English name is pleading face, but I hear the Japanese word for it much more in practice.
I just always login as root. No sudo or other programs needed, no security vulnerabilities, no complexity. Clearly the most secure solution as it's widely known that using the setuid bit is a security problem.
Yes, OTOH I don't mind others using sudo or setuid root permissions. I once hacked a payment terminal because someone thought it would be a good idea to put setuid root on pppd :) (we needed to do a bit more than the official SDK api allowed us)
Usually the majority gets it. And the worst that can happen is that some people will downvote you, or call you an idiot. I'm not especially concerned about this.
I don't see how it's an accessibility issue, except to help out those with a deficient sense of humour.
regarding accessibility..from what I have heard, other cultures have much different styles of sarcasm which might impede their ability to understand that something you have said is sarcastic. e.g. Japan is known to have a reputation of not understanding American sarcasm, but has it's own style of sarcasm. (see https://linguaholic.com/linguablog/sarcasm-in-japanese/)
so, I guess announcing your sarcasm makes sense in an international accessibility sense, particularly when some of the normal cues are not present (tone of voice, facial expression, eyes rolling)
Communicating across cultures is always bound to lead to the occasional misunderstanding, even more so over text. When writing something "dry" such as documentation it's probably a good idea to keep that in mind, but making jokes worse just so that a few more people can perhaps maybe possibly understand it is where I draw the line.
I always liked Debian’s really. The first thing it does is make one system call to see if you can open a file in /etc with write permissions. If you can’t then it crashes immediately without doing anything else. The attack surface is very small.
sudo’s notion of some people being able to do some things but not others just doesn’t seem very relevant these days, and never really sat nicely with me in my multi user Unix host days either. I was much more in favor of giving people multiple system accounts and letting the system auth (ssh) handle who can do what.
Now of course we all have umpteen complete hosts each, and the security boundaries are at the virtualisation layer. Passwordless sudo all ‘round!
Typing emoji is a pain, but the chat suggests that that might be an advantage:
> Using this program requires you to be able to type an emoji. Most attack code is of such poor quality that they are unable to run commands named with emoji.
The best part is that it's a joke that has enough merit to it that it's worth being taken seriously. That makes for good satire. I love writing surrealism, it's a very hard balance to meet.
> The best part is that it's a joke that has enough merit to it that it's worth being taken seriously. That makes for good satire. I love writing surrealism, it's a very hard balance to meet.
> This comment section not understanding where I was being satirical.
That means you didn't meet it[1].
[1]That balance you were talking about. You missed it. If too few people understand your content, it's not the people that's the problem. As someone attempting to present an argument, the onus is on the presenter to make the argument readable, not on the reader to squint until it gets readable.
IOW, if you can't be bothered to write your message well, why did you expect other people to be bothered to read it at all?
What makes you say "too few" understood? It's a balance, right? So if plenty of people understand, and the right people didn't understand, then it's right on target.
And it looks to me like lots of people understood.
Yeah! First I read the HN comments and saw how pissed many people were. That helped set the tune for the article (read: it helped me handle my own triggers) and it was a lot more fun that way.
I think the author intended it as a valid criticism, though it's hard to tell given the passé stylistic choice that calls back to early internet (I am nostalgic for those days sometimes). However I disagree with that as it's just one more, fairly silly, obstacle to overcome. If this "replacement" ever did, theoretically, been seen as suitable, all that would happen would be that attack code would suddenly see an increase in quality.
If you've done any research into quality malware, exploits and the like (both domestic and foreign), the quality and often elegant solutions they come up with will not be somehow kneecapped by an emoji. It also only needs to support inputting one emoji in the event that someone uses this out in the field; not hard to do in shellcode.
> If this "replacement" ever did, theoretically, been seen as suitable, all that would happen would be that attack code would suddenly see an increase in quality.
This is where I believe security-through-obscurity is underrated. As long as you're small enough that targeted attacks aren't part of your threat model, merely being unique affords a great deal of safety. Your wierdo jerry-rigged authentication system may not be particularly robust, but it's more likely than any mainstream product to repel an automated attack.
In the event that something is seen as suitable; i'm assuming it would see some adoption (that's the assumption I wrote the comment under).
However I do agree, at least against automated attacks; there will be a bit more security. Though if you are doing anything serious that draws attention, at that point obscurity is all but putting off the enevitable failure if you are ever targetted.
For anyone wondering, this is basically a young millennial / gen z meme. The emoji is usually pronounced "pwease", as in a childlike pronunciation of "please"
Therefore the command is basically just asking very nicely, hoping to get one's way
Alternatively, a good chunk of my twitter feed would call this the bottom emoji, without attempting to give it a pronunciation. I don't think any particular pronunciation has consensus, but various groups of people imbue it different meanings.
Yeah, I always read this as "bottom emoji" in my internal monologue, and that is how I search for it if I need to copy & paste it on a laptop or desktop lol.
At least among Gen-Z, it's less an indicator of sexual orientation, and more so one's sexual position. I am friends with a (hetero) couple where the male is the bottom. She pegs him because that what they like. He is not attracted to men, but also does not enjoy being sexually dominant.
I'm on the spectrum, and I can't tell 99% of these things apart. Looks like a sad face to me. no different then the 500 other sad face emoji's I find.
I'll stick with =(
> I'm on the spectrum, and I can't tell 99% of these things apart
If it's any consolation, I'm not, and I don't know exactly what a lot of the face-emojis are supposed to be expressing unless I see a text representation of them or otherwise have them explained.
Yeah, many are just too small to distinguish clearly. I actually thought it was "rolling eyes". That's kind of how it renders for me in Firefox anyway, but if I zoom in a lot I see it's not.
I also find tiny body-text-sized emojis hard to grok. A thing that’s helped me is heavily focusing on context and trying to imagine the human speaker/writer making the same face in said context—i.e. relating it to their apparent emotional state or other clues in their language. It’s like learning vocabulary from scratch all over again, with some prior learning pathways as a shortcut.
I don’t know if that’ll help you (or anyone), and I have other problems with meatspace facial expressions (partial face blindness, probably partly attributable to finding eye contact uncomfortable; although weirdly enough trying to “get” emojis has helped on both these fronts to some small extent). So … idk if this will help but I took all this time typing it so here we are.
> I also find tiny body-text-sized emojis hard to grok.
This depends a lot on emoji font. Apple's 3D-ish, highly colorful, rasterized emoji are very difficult to discern at small sizes, for example, unless you already know what they are.
More stylized emoji fonts, like EmojiOne or emoji that are drawn basically the same way as text glyphs, like in Symbola, are way, way easier to read, especially at small sizes.
If you're on an Apple device, though, you're close to fucked, since the operating system just ignores your font choices when it comes to emoji. The best you can do is carefully hack the actual files for the Apple Color Emoji font on macOS, which requires you to disable SIP and will cause lots of app crashes if you do it wrong. But if you're using an OS that has some respect for you and your choices, try a different emoji font!
Wait what, this is some kind of emoji/face? It shows up as a grey solid box that is slightly wider than tall for me, so not even the typical "glyph missing" thing...
Edit: ok apparently this is indeed the placeholder for missing emoji in Firefox for Android at least.
> I'm on the spectrum, and I can't tell 99% of these things apart. Looks like a sad face to me. no different then the 500 other sad face emoji's I find. I'll stick with =(
If it's any consolation, I don't think anyone could infer that from the emoji itself. The meaning is like a subculture's slang.
I don't use emojis, so I only know the very basic ones (which I consider to be obfuscated emoticons).
It is pretty obvious that it is a face doing the sad puppy eyes, like the one a young niece might do after I refuse to buy her some ice cream. I didn't even know it's meant to be underground, impenetrable slang.
It might be an emoji-font thing. Might be easier to tell what's up in some than others. I know I've seen emoji I sent from Apple devices on Android phones and been all "LOL WTF that's not what I sent at all" so that is sometimes a factor.
Anyway, this is one reason why I prefer images and anigifs for expressing emotion in chats.
The Twitter version of it is what I'm seeing from this blog (Firefox on Ubuntu), which to me does look a lot more like "exasperated eyeroll" than "puppy-dog-eyes pleading".
If you don't already know, you can usually copy/paste to your favorite search engine and one of the first results is often the page explaining the unicode character, including those all-caps formal names of them.
The nice thing about emojis being in Unicode is that you can copy/paste them and look them up, unlike embedded images. The reference name in the Unicode database conveys the original intent of the people who submitted it for standardization, at least.
$ apt-get install vim
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
$ fuck
sudo apt-get install vim
[sudo] password for nvbn:
Reading package lists... Done
Judging just from that, I'd have taken the meaning as "verge of crying" or "my pet just unexpectedly died"
Until I read that comment I was having real trouble figuring out WTF it had to do with running commands. I thought it might be some practical joke tool that automatically modifies your commands such that they'll make you sad when they run.
people have different perceptions, interpretations, and understandings of things. Your comment comes across as pretty insulting. clear communication is necessary and helpful
Would like to note that I happened to see someone I know use this over the weekend and it was unambiguously intended as the "verge of crying" meaning I guessed previously, not "puppy dog eyes". LOL.
To me at 2–3 mm it looked more like sleep deprived baggy eyelids (or maybe candy corn eyes, but what does that mean?). I read the whole post thinking the program was named after exhaustion, not pleading.
I just polled the room and most guesses were that it’s sadness/sorrow.
Depending on font. Inside my web browser, it appears to be looking up. On my web browser's title bar (so rendered by my window manager...), it appears to be looking down, or maybe straight forward. Fonts make a big difference on interpretation too.
I remember a few years back, there was a problem where Apple implemented "GRINNING FACE" in such a way that Apple users interpreted it as a sarcasm indicator, but most others would look just like a standard smiling face, leading to quite a number of awkward exchanges when non-Apple users would read things such as "Yes, let's burn it all down :)" instead of "Yes, let's burn it all down :|"
Disregarding the "browser" column (could be anything, it's what your browser renders the text as), only the Twitter font has the "looking up" variant that you think is normal. I'd rather say the straight-ahead look is the norm for most font designers when interpreting the "FACE WITH PLEADING EYES" description of the character.
They wrote it in 1980 for unix; what exactly would you like them to have used?
> (as far as I can tell) have no intention of rewriting it in Rust
Since it will be less than a paragraph before you start ranting about how "obscure targets that nobody uses won't be able to leech off of the rest of the ecosystem by holding back any chance to let us have a modicum of nice things", I trust you, who would surely never be a "leech", have written an actual replacement or submitted patches to start improving the situation? Or perhaps are funding such efforts?
> I did write an actual replacement. It's what TFA is about :)
That is obviously not a replacement; either we take the serious approach of "sudo allows only authorized users to run things as root" and yours doesn't control access, or we take the nonserious approach of "sudo has so many bugs that it just gives people access" in which case we hardly need to bother rewriting it.
And then use su or whatever to control access to the actual root account? You'll always need some amount of access to it, although I suppose you're correct that in a truly well-functioning system it would be needed much less since everybody would be in enough groups to get access to the stuff they actually need.
Because the entire value-prop of sudo is ubiquity and mindshare. There are as many replacements for sudo as there are Rust developers. Any one of them is probably fine.
The hard part is solving the coordination problem among millions of humans to just pick one and standardize on it. All that work is eliminated in an instant if you just convince the sudo maintainers to bless and ship one.
I think there's a security problem with this command. The command does not verify it's called as [xn--ts9h], it really needs to verify args[0] equals the name of the command, otherwise you could call it though a link or mapping, etc. The article states that the name is important for security, so I'm submitting this bug as critical.
Wait? it doesn't make any sense. So any userspace program can call `setuid(0)` and `execv()`? Why is there sudo in the first place? I am not getting it.
Sudo exists as an elaborate ACL scheme implemented in user-space which takes advantage of the setuid+root permission scheme implemented in the Unix kernel to allow granularly granting root access to non-root users.
But any program can be setuid and/or setgid to any user/group and it will then run as that effective user/group by any user with permission to execute that program.
There are handful of programs that are setuid root because they need to do things like open raw sockets that non-root users can't do, ping being the canonical example. Finding buffer overflows in these programs has been a source of privilege escalation security bugs.
Fortunately these days programs like ping can use more focused alternatives to setuid, like CAP_NET_RAW, to greatly reduce attack surface.
But also we’ve largely given up on Unix users as a security barrier in many places, instead using things like VMs as the interface between different tenants in hosting providers and clouds and such. The age of untrusted shell accounts shared Unix servers is ending, if not over already. Passwordless sudo on a cloud VM is probably the norm now.
Presuming charitably that you mean the more interesting question of "why is this a program rather than a thing other programs do internally when they realize they need elevation": well, two reasons:
1. any program can call fopen(2) and fwrite(2), and yet cat(1) exists. Unix plumbing is mostly there for cases where you're linking programs together in ways those programs didn't expect.
2. Privilege separation. You don't want big, complex programs running as root. You want big, complex programs running as your user, speaking to tiny little well-hardened programs running as root over a pipe, where the tiny-little program can only do one thing.
For example, you might have seen the pattern of piping things into `sudo tee [file owned by root]` in order to be able to write to a file that's owned by root. This fits both of the above considerations: moving the privilege into "tee" rather than having whatever command is generating the text, exposes less of a vulnerability surface; and also, it's `sudo tee` rather than tee(1) itself performing elevation, because tee(1) itself was written a decade or two before this pattern emerged, and so has no idea it could be used this way.
I have a poem that I published which has a Japanese title (宝石の十字架). The journal that published it put that in the URL: https://www.invisiblecitylit.com/poetry/宝石の十字架/ and not surprisingly, many URL parsers don’t like the Japanese text.¹ I really need to get around to changing the link that I have in my publications list to use the URL encoded version of the title so that it's easier to share on systems that don’t like the Japanese there.
1. Although, if I remember correctly, URLs are not supposed to have characters outside of ASCII 33–126 in them (and some of those within the range are also disallowed), although as the link to my poem shows, those restrictions aren’t always enforced.
Ahh, that is because that isn't a valid URI - it is an IRI.
The space of IRI implementations is quite sparse, mostly limited to browsers (and often rather spotty within the browsers as well). So a page hyperlink or paste into a browser bar will turn it into a URI behind the scenes, but it is unlikely another program or script will handle them.
In fact, I believe WHATWG defines that hyperlinks are URI, not IRI - so the generated HTML in this case by HN is not valid.
IRI are of dubious value - they exist in a space where users are expected to understand and evaluate the legitimacy of an identifier by sight. That said, this is about the best we have for web domains, so (for example) I think all major browsers do render internationalized domain names in their address bar.
Beyond the usual ASCII stuff, the standard allows you to have all nonsurrogate characters between U+00A0 and U+10FFFD in the path of a URL within HTML. The standard has browsers internally percent-encode them. It's also dumped the IRI/URI terminology and just uses URL.
That table shows whether the ccTLD itself has an IDN form e.g. 宝石の十字架.日本. You can register 宝石の十字架.jp just fine (obviously, if you think about how IDNA works).
my favorite way to plumb an old / unmaintained program or workflow is to put some emoji in as an input parameter, and see where the logs start exploding
I came here to make a similar comment! A good smell test for whether a piece of software "has its act together" is to send it emoji where it expects text and observe whether it handles it gracefully or shits the bed. It's 2023 and so much bad software still assumes text = ASCII or at best assumes text = ISO-8859-1.
If I recall correctly, `guake` had/has a downstream issue where the terminal would crash because a dependency of a dependency of a dependency was 15+ years old, had no maintainers, no one wanted to take it over, and would hard crash if it encountered emojis.
The build-around was having to fiddle with a bunch of core system stuff (super descriptive on my part) with lots of overloading system packages and just... no thanks.
I did it once; never doing it again because then you have to deal with having a non-standard system from then on. Switched to `kitty` and have no problems with emojis.
tl;dr: If you are designing a CLI tool, please refrain from emojis.
There is a lot of complaining in this thread about the website, the idea, and the author but I have to say I really enjoyed this webpage. There was a another website posted recently [0] that a different style than most things posted here which I also enjoyed. I don't understand why people get so up in arms about things like this. I thought the in-article conversations were fun and playful and added to my enjoyment of the post.
It all comes across as very "bah humbug", "get off my lawn", "I hate fun". I'm not going to say I wish the whole internet looked like this site or that other site but I do enjoy something different than the same look everywhere and I like seeing people try new/different things.
Thanks! That's exactly the point of it! I'm going to be working on the CSS this weekend on stream (the images being so big for longer conversations take up too much screen real estate), but in general the idea is to have a combination of the Socratic method of dialogue based teaching combined with a few consistently written characters; not to mention it helps move out parentheticals to break up giant walls of text. I don't have any page explaining each of the characters and their tropes, but here's a small list:
Mara: the student that knows a fair bit but isn't afraid to call the teacher out on their shit, also used for most parentheticals
Cadey: the teacher that learns from student questions, also a bit of a self-insert to de-emphasize certain parentheticals
Numa: the shitposter that really does mean well, but communicates in shitposts, memes, and similar
Aoi: the idealist that has difficulty accepting the state of the world as it is
With these I create tension between the characters to help illustrate the point. Aoi was added for this article and helps to ground the satire in a sense of reality by being disgusted by this tool.
> the idea is to have a combination of the Socratic method of dialogue based teaching combined with a few consistently written characters
This is, of course, how the original Socratic dialogues are written, too! There are characters with distinctive personalities and points of view who (re)appear in multiple dialogues.
Maybe a lot of STEM folks here have never read Plato or other/later philosophical dialogues, or they never got a sense for how they can be useful. Maybe how it's interleaved with the main body of text is confusing for people as well?
Either way, I think the main idea of the format is good. Maybe some small formatting tweaks or a link at the top like 'how to read this document' would help get new readers to grok the format.
I'm gonna work on the CSS on stream this weekend. It's something that usually comes up in bad faith so I haven't really prioritized acting on it. However I think I finally understand enough CSS to do it properly.
It looks good to me! It's easier for me to tell that the main body is totally separate from the dialogue now. (Before, I wasn't totally sure if the main body was just one of the people in the dialogue monologuing sometimes, although I usually assumed it wasn't.)
Very readable, still fits with the theme, and helps clarify the genre. :)
The dialog could probably use some left/right padding or an alternate font to indicate it's not part of the main text. Initially I found it a bit unclear, and also hard to skim the article.
I really like your style as well and have throughly enjoyed several of your articles in the past (a lot of your articles on nixos for example).
I have no problem at all with the presentation of this article. As always your characters make the article really gripping to read imo, like taking part in a good conversation.
But I did not like the way you handled the topic as much this time. I know that it is supposed to be confrontational and a bit in the face. That is the joke. Being nonchalant about is kinda fun, but when that is part of what actually is quite hard criticism of someone else's work it starts to sound very arrogant. But I don't know.
> <Cadey> I don't know about the code quality standards of the sudo project, but overall I don't see them doing any concerted effort to try to migrate away from C (or to reduce the complexity of sudo) and there are frequent security vulnerabilities that result in attackers getting root access anyways. I really wish the industry as a whole would take languages like Rust a bit more seriously and start actually moving towards programs being safer to use because security vulnerabilities in core infrastructure result in emergency patches. It was disappointing to see an attempt at using Rust in an important Python library torpedoed by users of obscure architectures not supporting Rust. Maybe the solution there is to use WebAssembly as a compile target instead of making everything be native code. I wouldn't wish hppa's reverse stack growth on anyone trying to write a compiler though.
Which was edited from this:
> <Cadey> God I wish they did. They wrote the program in C, (as far as I can tell) have no intention of rewriting it in Rust, and it's had many viable attacks over the years that allowed attackers to gain root privileges and worse. It's also debatable if the entire concept of privilege separation as implemented in Linux and UNIX was a bad idea to begin with but we're stuck with it because of an endless ball of legacy programs controlled by egotistical open source people that refuse to change because then obscure targets that nobody uses won't be able to leech off of the rest of the ecosystem by holding back any chance to let us have a modicum of nice things.
I don't care about their website design (it's better than a number of "serious" websites I've visited) and I don't care about their characters, especially since it's a literally ancient way to explore philosophical issues and being a furry is morally better than being a pederast, as the Ancient Greeks were.
That already happens to anyone that tries to stay on the same system indefinitely.
Personally I'm used to it and I think security is more important than indefinite hardware support. Installing the same software on newer hardware is fine.
If you're going to be working on CSS anyways, I noticed that the tables on the pronoun page could use a little bit of padding—the text is touching the table borders (https://vgel.me/imgshare/xe-pronouns-no-padding.png)
Hey! I would definitely recommend putting this somewhere on your website.
I have been encountering it now and then - mostly on Nix/NixOS topics (by the way, thank you very much for some very useful articles!), and while I don't have any issues with the format, those characters were a kind of small and a little bit weird (not in a bad way, just... unusual) mystery, making me wonder "who are those, what's the story/going on here besides the obvious dialogue format?". Not much, of course, just a minor casual curiosity, but made me look into the footer/about section if there was anything in there.
Fun style to read, but without knowing what level of sarcasm I'm supposed to assign to the peanut gallery characters (or to the main author voice), I'm left wondering whether there is a point beyond "sudo should be written in Rust?"
Having a password or a key or any other nonsense to run sudo is security theater.
If you do not want all applications to have real root access, use Qubes to isolate applications into VMs, or at the very least have your daily driver user not have root access and have a separate admin user.
Yes, it took me some thinking but it's the conclusion I arrived at as well; the password is useless because as soon as somebody or something can run a bad process it's game over, first of all because all the files I really care about are owned by and writeable by me, and secondly because the bad process can just mess with .bashrc and get root access later. About the only benefit I could think of is slowing down an opportunistic attacker that finds my device unlocked, but even that could be game over with a quick `curl ... | bash` if the attacker is prepared enough. 'Security theater' was my conclusion as well, and I was surprised by it, why is everybody doing this?
People who use emojis aren't the type to lookup the official meaning. In other words, actual use is at times very different from the official description.
I just open a root shell with `sudo -i` when I need to do some admin stuff… But that's not the point.
If the post is a joke it's not a good one. Sudo has issue, sure. But this tool is even worse! You could just start working as root user the whole time, like many people do (or did) under Windows, but we all should know where this will end.
The developer didn't do anybody a favor creating this. He will be imho directly responsible for any harm done by this tool.
People should really think upfront about the consequences of their stupid jokes.
People are dying these days form "changeless" on TikTok that are often also just stupid jokes put online by even more stupid people without any sense of responsibility. I see parallels here to be honest.
This is a beautiful website with awesome anime-style cartoon formatting. The palette is really nice, well-selected too.
Sadly, the writing style interpersed with the cartoon dialogues is so insufferable and distracting that I learned absolutely nothing. My ADHD didn't help either.
Browser address bars will typically convert and render URI as IRI, because they need to convey the domain name to the user (because we don't have a better way to handle reputation on the web).
I replaced "sudo" in all my systems a long time ago with an alias to "machinectl shell .host" which is IMHO far superior to it, as it doesn't just spawn a new shell as a privileged process, but instead initializes a full user-session and then spawns a shell in this user-session.
This doesn't carry the risk of tainting the new session with the context of the initiating shell (pwd, env, ...) and doesn't only feel like a full login, but actually provides everything that's part of a login session (systemd and DBus user-sessions, shared session context with other shells of the same user, etc).
Sudo's -i option is able to provide you with a shell in the same state that it'd be if it were a fresh login. I've burned this into my fingers a long time ago.
Also, in most configurations you have to specifically whitelist environment variables for them to surivive a "sudo" call.
But that only works if theres a password on root, which is generally seen as ill advised. But was how every distro did it in the olden days before there was a sudo group.
This is going way over my head. Am I the only one here who just puts everyone in sudoers and does NOPASSWD? Where are these multi-user systems where you don't really trust everyone who has access?
Is this not so microaggression really necessary at the top of every post?
it sounds rude and it is not an efficient way of communicating the relevant
information.
>Hello. Before commenting about the author, please read this page that explains >the >pronouns that you should be using. tl;dr: the author of this website is NOT >male. >Please do not use "he" or "him" when referring to the author.
How about
> Hi. I am nonbinary.
> I prefer the following gender identity pronoun pairs
>(xe/xer),(they/them),(she/her)
>If you would like to know more here is a link.
I am autistic and all I want is an efficient way to address this issue
I dont care about the politics.
Just give me a universal, drama free, efficient way of addressing you and
I will do so.
We should just make that a HTML Meta tag
<gender identity pronoun pairs>
or microschema
HTML will need ways to convey such information in an orderly and efficient manner.
Or we could just reduce infinite to 1
One pronoun pair to bind then all.
.
Hu? (For HuMAN) (so only Hu)
In some languages you address people in different a different manner
depending on age. and some based on age and perceived status.
(and in most some variant if married or not).
All of that can be removed.
Age,Married Status and so on is not required knowledge.
Gender identify is also not required knowledge.
It only shows up for people that visit via Hacker News with ads disabled. If you don't want to give me ad impressions, then when you visit it gives you a nudge to be civil when commenting on the article.
Is there anything I can do to change it so that it's better?
If you don't want to see that message, please disable your ad blocker.
Interesting, was there a reason to target that specific user group with the message, or is it just filling space that would have been populated by an ad?
Normally that has a "please disable your ad blocker to help this blog be self-sustaining or donate on patreon" message. But Hacker News users spew so much venom and vitriol (see OP in this thread) that I am a bit more pointed and blunt with the nag messages. Going by the numbers of hits vs as impressions my hypothesis is that the biggest assholes block ads.
I did the math for last year and somehow my blog actually made a small profit! It's nowhere near enough to make me want to quit my dayjob, but it's at least enough that the excess can pay for all my video game purchases. I need to finish that article detailing the blog's finances for 2022.
I mean clearly this is all quite tongue in cheek but:
> It's also debatable if the entire concept of privilege separation as implemented in Linux and UNIX was a bad idea to begin with but we're stuck with it because of an endless ball of legacy programs controlled by egotistical open source people that refuse to change […]
Not a very charitable way to describe volunteers who don’t want to learn the flavor-of-the-month language to reimplement their old projects. Maybe if there were some folks who knew rust and were interested in doing this kind of work it would get done.
Honestly, I don't think you should take anything the author of this wrote seriously, the most charitable interpretation is that most of their work is a form of satire.
Speaking as the author of the work, most of _this post_ is satire meant to make you think about the existing security boundaries involved in privilege escalation. It is a false problem. The part about being annoyed that sudo is still written in C is coming from a sense of exasperation that there's still more predictable memory safety bugs involved with sudo because it's still written in C. The comment about python-cryptography failing to move to Rust because of random Gentoo uses holding it back was from a sense of exasperation that we can't have "nice things". I'm tired of having to emergency patch everything because we as an industry can't make our fundamental security tools _measurably safer_ with languages like Rust.
>
<Cadey> I don't know about the code quality standards of the sudo project, but overall I don't see them doing any concerted effort to try to migrate away from C and there are frequent security vulnerabilities that result in attackers getting root access anyways. I really wish the industry as a whole would take languages like Rust a bit more seriously and start actually moving towards programs being safer to use because security vulnerabilities in core infrastructure result in emergency patches. It was disappointing to see an attempt at using Rust in an important Python library torpedoed by users of obscure architectures not supporting Rust. Maybe the solution there is to use WebAssembly as a compile target instead of making everything be native code. I wouldn't wish hppa's reverse stack growth on anyone trying to write a compiler though.
FWIW as one of the original complainers this seems like a perfectly good edit to me.
Also the overall article was quite interesting and I think the template is really accessible and fun to read. If I knew there would be a bunch of ancillary complaining this thread, I probably would have kept quiet!
I feel that where I work. I'm outnumbered in wanting to write web servers with high-level, non-performance-sensitive business logic in something other than C++. We keep having memory safety problems, but more importantly, it's really slow to develop this way and doesn't match the skillset we're hiring. However, these people are being paid.
The common reason our most senior engineers tell me isn't even that it's too late to switch, it's that "C++ is perfectly fine as long as you use it right" and "it doesn't matter what the outside world uses" and "performance."
The satire came through loud and strong. Perhaps consider that feedback from hn is somewhat biased on the spectrum? I thought the style was a refreshing change.
I think in my next post about this I'm going to have a giant banner for HN visitors that will block you from reading the article that says "THIS ARTICLE IS SATIRE" just to see how that changes what people say in the comments. I doubt it will have the impact I want though.
Odd that you left off the rest of that quote ("...because then obscure targets that nobody uses won't be able to leech off of the rest of the ecosystem by holding back any chance to let us have a modicum of nice things") which links to: https://lwn.net/Articles/845535/
> Maybe if there were some folks who knew rust and were interested in doing this kind of work
In this specific example, "this kind of work" would involve porting Rust to 5+ obsolete CPU architectures. Not exactly rewarding work.
They didn’t write in paragraphs, it is more like a collection of IRC posts or something. Here’s the whole post thingy:
> God I wish they did. They wrote the program in C, (as far as I can tell) have no intention of rewriting it in Rust, and it's had many viable attacks over the years that allowed attackers to gain root privileges and worse. It's also debatable if the entire concept of privilege separation as implemented in Linux and UNIX was a bad idea to begin with but we're stuck with it because of an endless ball of legacy programs controlled by egotistical open source people that refuse to change because then obscure targets that nobody uses won't be able to leech off of the rest of the ecosystem by holding back any chance to let us have a modicum of nice things.
So, I guess fair enough. I will expand it slightly to say: it is an uncharitable way of describing volunteers who don’t feel like learning a new language and reimplementing their old projects while also overturning a huge ecosystem of software.
It's obviously a (failed) attempt to be funny by being very sarcastic. No one is stupid enough to this that writing it in Rust was even an option in the days unix was written - especially considering the types of people that would know how to write C and Rust for kernels.
> The part about being annoyed that sudo is still written in C is coming from a sense of exasperation that there's still more predictable memory safety bugs involved with sudo because it's still written in C.
The paragraph quoted is about the language choice, too, just that part was snipped off because it's long. It's one ball of a paragraph that goes in all directions, citing debian and gentoo's troubles with rust support[1] and calling them leeches for wanting to support obscure architectures. Not a fun read.
I do think it's funny how this is the only comment in the thread that isn't greyed out.
I wonder if there would be a way to lose the 'value' of a downvote if the account in question predominantly downvotes a specific opinion too much (a form of abuse i think). The assumption being that, "ok, you downvoted three posts, that were all very incendiary; though the other 40+ you've downvoted were all that way, statically the chance that those posts are all offensive is unlikely."
Would be interesting to see; I don't hate Rust, but I don't appreciate the zealous nature of most of their advocates, and for me personally, there's nothing fun about writing in Rust. It's also a bit too bloated for my tastes, i would never want to run it in lowlevel personally. Yet most of the time I stay away from threads talking about Rust, because i just get sent to the bottom fairly quickly, on most sites that encourage discussion.
I mean, I heard it put this way and it has always stuck with me: every conversation here is implicitly inclusive of @dang. He’s wholly responsible for the vibes at large, and in the past several years it has become blindingly clear that he has no issues or qualms with Rusticles overtaking any thread they choose. I could write a scathing 10k word treatise on any topic with a single pithy remark about Rust in it somewhere and he’d allow the discussion to be dominated by the Rust tangent that would inevitably multiply in the comments here.
The chilling effect is as you describe, that I often feel discouraged from contributing my knowledge, experience or opinions because of the blatant manipulation of conversations by Rusticles and the apparently contentedness by dang for that to be the defining angle of discussion here.
HN should have tags. Every article gets tagged by users with high karma counts, by some sort of ranked consensus (maybe a rust tag, python tag, database tag, politics tag, etc) and users could just list tags they want muted in their settings.
Instead, I’ll be told about the HN guidelines and some minutia in this comment that is somehow worse than a thousand idiots hijacking literally every conversation about a particular topic.
Unfortunately that's often a result of administration. He does have notable ownership of how certain things are, and you do see his bias peak through in many different ways.
You mention the "chilling effect" that does exist, and you aren't the only one, I've seen a lot of comments like yours not just on this site, but on pretty much any site that sees any advocacy for the Rust they promote.
I think there might be some value in filtering through something like a GreaseMonkey extension; which I've been debating for a good while if i should just make. Simply allow to remove listings from the HN page that inlude 'blacklisted' domains and filter key words. Such as "rust" in the title would see a removal.
But yeah, I think there is a place for Rust, just not where we see it for the most part, and i am increasingly bothered by the issues it presents for the Linux community (which was disregarded by the article posted hilariously enough, they can't even show respect for the communities they cause issues for, a core inidicator of narccistic behavior).
Guess I haven't been on enough HN Rust threads yet. My assessment of Rust's vibe comes just from reading the docs and online help when I was using it in a project years ago. It feels like C where they're just trying to get stuff done. I don't have strong opinions on Rust or Golang, and I don't use either one regularly. In that project, I ended up doing most of my work in some FFI'd C code.
I do judge language communities based on the code reviewers at work. Python and Java people are chill, C++ people are obsessive, and Golang people are obsessed with not using C++. N/A for Rust or NodeJS.
That is a healthy option imo, it's not a terrible lang or anything like that; it just gets way more praise and has seen too much growth that it has yet to earn.
My preference is C for personal projects; I like the freedom.
C# because I work with .NET a lot; some might say too much, i get weary of it sometimes. Python is kind of goofy, but it's useful and easy enough to use that I don't mind it's presence in my work.
I will never work with Java professionally ever again if I can help it; I don't like the JVM; working with Android was the final killing blow, i hate mobile dev. simply because they often have me work with ART and i just can't do it with any real enjoyment. Golang is odd, and I have yet to find any real use for it.
The Rust community is pretty unsettling in their dedication, and they seem to actively lie if you question it's usefulness in a specific situation, so i'm weary of their advice.
NodeJS is useful, but truly awful to maintain after the fact. It's also quite nonsensical; I would still spend the extra time just using php or python (with flask), Node is also far too bloated and the bottlenecks seem to make my life only more difficult anytime I try to make something even remotely performant without just throwing load-balancers onto every node website I've ever worked on... not worth it.
NIM is by far my favorite; I don't know why, but I love it, it's the language i would build if I had the time. And... C++ has way too many options to do one thing that it confuses most solutions when I've ran into problems, it's just too much.
Something I've learned over the years is that the choice of tool, before you even start on a project, must be taken seriously; if you mess that up, you will be paying for it for potentially years to come.
IMO there’s a widespread belief that these upvote/downvote systems are fundamentally stupid, which is actually true, but I think it also holds back the implementations a bit.
I’d love to see for example a site that treats them as endorcements or something. The logic could be something like: keep track of the graph of who upvotes what. When you upvote somebody, you reinforce the link between the two of you. Then, when showing posts, rather than just using the raw scores, measure the weight of the edges connecting two users or something like that.
Also have a button that, if you see a post you don’t like, shows you the edges connecting you to it so you can re-evaluate them and cut some.
Or something like that. I’m sure this is open to abuse. But the idea would be that you aren’t just generating like a gamified “high score” for comments, but trying to build a collection of people that you find or are likely to find interesting. It might even help reduce abuse of the voting system, in that people playing “let’s all upvote each other” games will just become an isolated clique, maybe?
There is pagerank, which is still easy to game when accounts are free. I like HN's system well enough, mainly cause it doesn't show comment scores except your own. It's not like the toxicity-inducing thing on Reddit.
I also made my own social network for links where "liking" something = reposting it, and you only see stuff posted/reposted from people you directly follow. There's no globally popular stuff. Not comparable to HN, though.
Hint: If you make a comment that is confrontational but makes no other points, many (if not all) of the people downvoting you are not your opponent, they're someone unrelated who thinks you made an annoying comment. Those downvotes prove absolutely nothing about your opponent.
Well, now we're gonna get nitpicky :) Unicode is plain text, therefore emoji are in the set qualified as "plain text." "ASCII text" may be more accurate.
I'd say your first description, "text-obsessive", was the most accurate.
"Plain text" is a technical term, which generally means raw unicode (or some other character encoding) without additional markup. Emojis are unicode, and can exist in plain text files.
"Text" does not necessarily mean unicode, nor any type of character encoding. The books on my bookshelf are filled with text. If any of those books contain emoji, I would consider the emoji to be an illustration, not text.
(This is a silly discussion but also the sort of thing I have fun thinking about.)
I swear I saw a heart emoji a few months ago in a comment at the bottom of a long thread. Not sure if it was a bug, an easter egg, or maybe a figment of my imagination.
Also I wonder if you have a secret dashboard full of buttons to control this website, and now there's a "Enable emojis for 10 seconds" button, next to "Subtract 1 karma to anyone with a custom topcolor" and "Promote a random Lisp post to the front page"
It might have been a rendering of U+2661 ♡ or U+2665 ♥ or U+2764 (this last one does get stripped by HN) which are not emoji but may be rendered as such by the browser.
That does keep things interesting (as long as it's not super common) though i do wonder how it looked previously (did it just strip the emoji or is there like a ":pwease:" dropped in?
Technically speaking, no, HN doesn't render any titles. Your browser is displaying U+1F97A, which is sent over-the-wire as the bytes \xF0\x9F\xA5\xBA (UTF-8 encoding).
"Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting."
It seems informal and a waste of my time. I'm reminded of the biographical wordarrheah at the head of recipes these days. I. Don't. Care. I'm too old and I don't have time for this.
Not just recipes. Ad driven and SEO industries have made every thing you search for 90% irrelevant bs. I used to be able to search for a PHP function or howto and just see the code. Now to learn something in JS I have to scroll through 500-1000 words of bloat for 10 lines of code when I just want the name of a function or the common way of doing things. This sucks.
You must be a blast at parties held by the professionally offended.
Wrong scale of time. Comments take <2 minutes. Reading an article can take >10 minutes. Additionally, the complaining is less than 5% of my commenting time. I use it mainly to bolster opinions not already commended.
And let's ask ourselves what exactly prompts folks to need to comment their disdain for only certain types of articles and not the countless dozens of others they filter through regularly. We'll never know!
Good news! I'm going to be adding another furry character to the website thanks to this comment. Feel proud, you've had a positive impact on the wallet of a furry artist.
Her articles repeatedly top Hackernews. And her audience largely shares or graciously accepts her predilections. Do you know how many of the most powerful people on the internet are furries/otherkin?
Normally this is just tangentially related and not for Hacker News but I feel this time it needs a bit of attention.
My brain melted in the first minutes trying to read this article. I honestly just couldn't. It feels like I'm reading a mentally ill extremelly schizophrenic write-up on the recent sudo vulnerabilities, makes me lose sanity.
Has anyone actually managed to read this? How is this on the front page? (Not a rethoric question).
It's just the classical socratic method applied to characters that you particularly don't identify with. Fasterthanlime's bear and why's guide have often been praised here for the same thing (the interludes break up the long, boring blocks of text that deep dives often lose readers on,) and it's trivial to use a Reading Mode or skip them for the legitimately interesting technical information within.
Unfortunately reading mode didn't remove the characters for me, it actually made them occupy the whole screen LOL (Fennec on Android if anyone is wondering). I don't have that much of a problem with the conversational format as long as it's used in an appropriate context, but this one was really intrusive and broke the flow of the text, since I'm reading mostly for entertainment I decided it wasn't worth the time.
I'll do what I can. I fear the problem will boil down to not having control of CSS in reader mode (which is understandable, really) and I may need to admit how my CDN serves the sticker files to serve lower quality assets. I hope it's a simple fix. Gonna do the fix live on Twitch tomorrow: https://twitch.tv/princessxen
It's actually rather simple. You read one bit of text, and then you read the next. It's a dialogue, if you've ever read a book the format should be familiar.
Disconsidering the sarcasm in your answer I should note I am familiar with the format, I was noting this one specifically was really bad and I just couldn't follow it, specially because of the figures (although that's not really the topic of my question). Just to clarify further: I was asking because I was curious if anyone thought different about it and how they decided to approach the reading.
> It's unusual that there can't be negative feedback about a website.
I didn't say that there couldn't be negative disagreement. Am I allowed to disagree with you and say that it's fine?
> I want to read the content, but I can't. The website is too distracting.
You can't read the text because there are little icons off on the side? I guess you can read it in elinks; it appears to load fine there. Someone upthread also posted a uBlock-style rule to filter them out.
> Is that a valid problem for you, oh great oracle?
No, it isn't; I'm not convinced that it's that bad to begin with, and if you really care the tools are available to it yourself.
> I didn't say that there couldn't be negative disagreement.
> What's the problem? What's the actual problem?
You're not as personable as you think you are with such a confrontational attitude towards feedback on a website you support. The website is distracting to enough folks that it matters. Period.
I'm not sure I understand the weird fan crowd we have here for the site in question. This thread is rife with folks who are ecstatic to defend the author for exercising artistic license, yet incapable of understanding or receiving valid feedback on said artistic license. And these folks aren't even the author!
If you put it in public, anything is fair game.
> if you really care the tools are available to it yourself.
I cared enough to leave feedback for the author, I'm not going to go out of my way to read text peppered with distracting weeb shit. I don't expect folks to sift through my unusual interests to get to my points.
Not pretending anything, I don't actually see the problem. They're clearly fictional talking heads that exist purely as a narrative device; why should I care if one of them is a girl with cat ears and another one is a fox/wolf(?)?
> Sexual attraction to furry characters is a polarizing issue. In one survey with 4,300 furry respondents, 37% answered that sexual attraction is important in their furry activities, 38% were ambivalent, and 24% answered that it has little or nothing to do with their furry activities.
So I'm reading "no reason to assume it's a sexual thing without specific contextual evidence", which I'm not seeing here.
Consider it like dressing up, with nice clothes. Sexual attraction is an important aspect of dressing up to some people, but that's only part of the time, and just generically being dressed up is not a sex thing.
Well that's the point I didn't get it because it also said that the author is not female, which doesn't exclude that person from having the ability to ask for people to call the author with a female pronoun. Me actually using it and respecting that ask is another thing as it is completely up to me if I'm going to do it or not, and honestly if it's respectfully requested with due reasoning I'm okay with it. I did read the page and make the effort to understand which one the author was looking for me to use but eventually I just bounced from the page as I figured I wasn't that interested in the content of the blog post anyways.
I think the website is excellent, and it’s a joy every time I see Xe’s posts here or anywhere. If you don’t like the way it’s presented, but you do sincerely want more information on the topic it presents, there is a vast (world wide!) web full of information. Surely you’ll have better luck finding it if you look for it rather, than spending that time trashing something that isn’t your cup of tea.
I think (hope) this is for the other poster and others of a similar mind, but in case I flubbed saying so: I think your site and its furry content is rad, and do not personally want to see anything different.
I assume you've never been to East Asia in general or Japan in particular. Furries are regular business there. Heck, in Korea, at a police station, they characterized the police man/woman as rabbits.
We don't know where the author is from. However, the website loaded pretty fast, didn't have the 4524 trackers, a Signup/Enroll/Whatever Popup, or prioritize 70% of the page for content other than the blog post.
I'll take the furries over the regular shit one's browse everyday.
I had a hard time reading this just cause of the longwindedness, not cause of the images. But it didn't assault me with popups and GDPR crap, or make my laptop sound like an airplane taking off.
Not block all images, just on the site. It takes a few seconds.
I think it's valid advice in this case, because they seem to be quite upset specifically at the furries, and not at the conversational structure of the post.
I invited them to view content less triggering to them. I’d link some directly but I’m on mobile so that’s a lot of bother for someone who probably isn’t looking in good faith, and well… their search engine is either the same as mine or functionally equivalent.
I’m going to give you the benefit of the doubt that you mean this in good faith, even though I don’t think you do. What is the damage, and how doesn’t the site owner explaining how to consume their site without furries address it?
The damage might be permanent and irreversible psychological and emotional scaring. The trigger warning needs to come before the objectionable content is seen of course.
A trigger warning is a statement made prior to sharing potentially disturbing content. That content might include graphic references to topics such as sexual abuse, self-harm, furies, violence, eating disorders, and so on, and can take the form of an image, video clip, audio clip, or piece of text.
In an academic context, the instructor delivers these messages in order to allow students to prepare emotionally for the content or to decide to forgo interacting with the content.
I think it isn’t necessary to give them the benefit of the doubt, they’ve brought up the language of triggering despite the original post just being sort of annoyed. In fact the original post explicitly says they don’t care about “furry shit” as they put it.
How does one discern "sort of annoying" and "triggering"? Sounds like they are coping with severe trauma to me personally. It isn't cool to minimize others peoples pain like this.
It's much too late for that, friend. We're everywhere --- in your libraries, your coffee shops, your orange sites. Save yourself lest you join our number. :p
Or you could just, you know, not read the author's stuff? They're posted here enough that you know it's going to be there. No one is demanding you read it and then share your brilliant takes on sexuality with us.
You know it's a terrible take when it can be turned around on you. That is, "if you don't like comments no one is demanding you read them and share your brilliant takes on opposition to mixing sexuality into technical matters".
I know I'm an old fart but this is yet another reason why I don't want my servers supporting UTF-8.
LC_ALL=C
It's important and NECESSARY to be inclusive, and as long as nginx can still provide the UTF-8 characters I don't care; but there is no way I can allow anything other then US ASCII to be on the terminal.
That actually didn't work not too long ago. I don't remember if it was git or less, but "unicode" characters it would end up getting reified as, e.g., "<U+1234>", as I recall.
