In Linux it also needs mprotect() to change the permissions on the page so it can write it. The OpenBSD man page[0] indicate that it supports this as well, though notes that not all implementations are guaranteed to allow it, but my guess is it would generally work.
It's not required on linux, if the ELF headers are set up such that the page is mapped rwx to begin with. (but rwx mappings are generally frowned upon from a security perspective)
It's more like doing Linux services the UNIX(TM) way since it's more similar to other UNIX service managers like SMF from Solaris or SRC from AIX in the integration -- NT's service manager requires an active event loop which responds to messages.
As an aside, the reason I don't like systemd is because it's inferior to its UNIX counterparts -- especially SMF -- for system management.
It improves the efficiency for the company at the expense of all of the people who spent time applying for something other than what was stated.
For example, you could not tell them that you would or would not hire them after a certain point in time -- which is something they will ask about and you will be unable to disclose, and so you'll wrap your lie in some vague language.
If these kinds of pipeline hirings were disclosed as such then your math would be correct. But, as stated, the purposeful information asymmetry (lying by another name) means that you are externalizing the uncertainty to the job-seeker.
You're making a trade-off, not getting a free lunch -- that trade-off is just at the expense of someone you are not legally obligated to expose this to.
It isn't nice.
(disclaimer: I've never done it, but I have talked to people who have; additionally I've never applied to a ghost/pipeline rec)
My experience is that it’s quite a bit more nuanced and complex than that.
The uncertainty works both ways. I don’t know at the moment I open a position when or if someone qualified will apply or be hired. I don’t even know with precision exactly when positions open up. How long is the grace period for taking down open job positions after one is filled? 3 days? 1? An hour? Just the mechanics of filling out HR paperwork means there’s lag between reality and the job posting. If I’m constantly opening/closing positions (as one would be at a team size of 500) there’s just as much chance of a position actually being open and not having a listing as the other way around if I’m attempting to always update the posting.
I do know that a chunk of applicants will be baristas, uber drivers, and construction works, another chunk will have keyword-optimized resumes that are incomprehensible, and many more will simply be too junior for a role because everyone is aiming high hoping to make to their next move. Employers are absolutely flooded with garbage.
Similarly, when trying to hire I spend most of my time on it between resume reviews, phone screenings, and actual interviews. It’s incredibly labor intensive to hire good engineers and/or technical managers. I’m working just as hard as the applicants.
I don’t use vague language. If it’s the case that I don’t have a position open at the moment of a phone screen, I tell an applicant when and how many positions I expect to have open.
And it’s not just the time spent on the process. It takes weeks to months to restart the process after it’s shut down. You have to update job descriptions, train your talent team on what to look for in resumes, train engineers on how to do technical interviews, and may sure they are “calibrated”. If they are out of practice they fumble the interviews and the company looks bad to applicants, and they tend over-estimate an interviewee’s performance because they don’t have a recent point of comparison to work with. This means I have to do 5-10 throw-away interviews to grease the wheels. If I fully stopped a pipeline and treated each position as a special snowflake, and everyone else in the world did the same, it’d just create even _more_ overhead for all parties involved.
I’m not saying it’s a good system. But humans are human and on balance any system is going to be gamed. There’s no way around that. For every one applicant who’s only applying to jobs they are interested in and qualified for there's 10 more just spamming every posting they come across. As a hiring manager I have to deal with that reality. The only way I know to reduce that overhead is to not add more by grinding the hiring pipeline to a halt whenever a position is filled.
As a hiring manager you are being paid to do that work, while the job-seeker is doing it on speculation. These are not equal positions, even though your falsely equate them.
Think about this: If you are not externalizing the costs, why not disclose in the job listing that this job posting does not correspond to a job opening ? What do the company gain ? What does the job-seeker lose ?
As someone who has done hundreds of interviews and built a team from the ground up for my current startup as well as others, the rest of your post just strikes me as hyperbole and excuses.
I can’t speak to your experience. If you haven’t been completely inundated with junk applications you’ve discovered a process I never have, and I would love to hear about it. How do you go about hiring at scale?
100s of interviews a month is typical for my org. If you believe that’s hyperbole, I don’t know what to say. Believe as you wish.
I think that given the context that he illegally tried to retain power after losing in 2020 that many people infer something into his words about reducing the need to vote
People don't like being told "here is what was said, here is what was MEANT because you're not educated enough and can't possibly understand" did Harris zero favors.
I'm not sure in what respects you are disagreeing with me on, since I didn't mention anyone's level of education or intelligence -- I didn't mention anything about the people who interpret the statement in a benign way at all.
I added my thoughts on why people would take that statement and infer some other meaning than his literal words, since those words are said as part of a broader context. This says nothing about the people who didn't do so.
So, you starting a comment with "No" but then not addressing any point I made is confusing to me.
I also understood the title to mean writing an assembler rather than writing assembly language code, and I've never heard anyone refer to writing assembly as writing assembler (or heard anyone who writes assembly referred to as an "assembly code maker", nor anyone who writes in any language referred to as an "<language> code maker").
I could imagine such phrasing being done by non-native English speakers, of which I'm have no doubt that there are a significant number.
My (unresearched) guess is that this is simply different dialects of speakers emerging with respect to informal references over the decades.
Using “assembler” instead of “assembly” was common enough back in the day that there was no confusion. There were 100x more people writing “assembler” than writing actual “assemblers” so you know, the odds were good.
It seems to be pretty common even among native English speakers to use "writing assembler" and "writing assembly" interchangeably. If one were writing the tool that assembles to machine code, you'd say "writing an assembler".
Normally I'd agree (as a native english speaker with about twenty years of writing assembly under my belt), but the title tripped me up, too. I figured they forgot an "an" or an "s" at the end of "assembler" and i was surprised to find that no 6502 assembler was produced. It could be because I've written three different assemblers over the last two years, though, so it could be i was just projecting my own interests.
I actually prefer "writing assembly", and also think "writing assembler" is a bit confusing. But it feels like I'm several decades too late to complain about it ;)
I've never heard anyone refer to writing assembly as writing assembler
I used 'assembler' back in high school, when I was learning about the 80x86. I remember because I was 'corrected' by fellow student who had never touched assembler, assembly language, machine code mnemonics, or whatever you want to call it.
I have no idea where I got the terminology, but I was reading a lot of books and Usenet posts on the subject at the time. I'm a native English speaker, for what it's worth.
> I used 'assembler' back in high school, when I was learning about the 80x86. I remember because I was 'corrected' by fellow student who had never touched assembler, assembly language, machine code mnemonics, or whatever you want to call it.
Wow, you got the Hacker News experience 30 years in advance!
When I was doing that a lot I just patched my VNC client to send the keys for the data in the clipboard on "paste" so I could use its native "paste" command
The balance here, of course, being backwards compatability. I'd sooner kill EBCDIC, bad ASCII and Code Pages than worry about CRLF if we didn't have to care about ancient systems.
Programming languages still retain C's operator precedence hierarchy even though it was itself meant to be a backwards compatible compromise and leads to errors around logical operator expressions.
Anyways, this article is about actively breaking systems like some kind of protocol terrorist in order to achieve an outcome at any cost, if it was merely along the lines of "CRLF considered harmful in new protocols" I'd have nothing to say.
> You didn't limit your general admiration of standards to CRLF, so no, not only that.
So your position, then, is that all standards include "needless complexity?" What argument are you actually trying to make here?
> That's simply false, he isn't
Yea.. that's why the word "like" is present, it implies a near association, not a direct accusation.
> Almost all implementations of these protocols will accept a bare NL as an end-of-line mark, even if it is technically incorrect.
So, right back to my original point, then, standards prevent people from having to debug dumb issues that could have been avoided. This advice is basically "go ahead, create dumb issues, see if I care."
I may have flippantly labeled that as "protocol terrorism" but I don't think it's pure hyperbole either.
> What argument are you actually trying to make here?
That you're mistaken in your one-sided generalization of the benefits of standards.
> So your position, then, is that all standards include "needless complexity?"
No, that's just another extreme you've made up.
> Yea.. that's why the word "like" is present, it implies a near association, not a direct accusation.
Your mistake is before "like", you can't be "about actively breaking systems" when you explicitly say that no systems will be broken
> "see if I care."
That this is false is also easy to see - the author reverted a change after he realized it breaks something ancient, so clearly he does care.
> standards prevent people from having to debug dumb issues that could have been avoided.
Not to circle the conversaion back to my original response to your point: why do you think "Almost all implementations" break the standard and "accept a bare NL"? Could it be that such unintuitive limitations don't prevent anything, and people still have to debug "dumb issues" because common expectations are more powerful?
> Almost all implementations of these protocols will accept a bare NL as an end-of-line mark, even if it is technically incorrect.
See https://news.ycombinator.com/item?id=41832555 as far as HTTP/1.1 goes, it's definitely common but far from universal. The big problem with "it's 100% safe to make this change, since it doesn't break anything I know about" is that there are always a lot of things you don't know about, not all of which can be boiled down to being negligible weirdos.
Might be just my personal impression, but I'm pretty sure Chrome is extremely notorious for abusing its market leader position, including in this way. So gonna have to disagree there, from my view people do mind Chrome and its implementation particularities quite a lot.
[0] https://man.openbsd.org/mprotect.2