Recent submissions

Comment · 17 hours ago
Naturally, it is not in LinkedIn’s interest to change this; the corporation’s behavior is logical and understandable. But that’s not the real question. What about the community’s reaction? Has this simply been accepted as a given—normalized and justified? And what about the rank-and-file support staff who send you a template—telling you that you’re writing from the wrong email address and that you should use the one linked to your account—do they know they are peddling a blatant lie? Or do they not know? Or perhaps they simply choose not to know? "We were just following orders; we didn't know anything." I am narrowing the scope of the issue as much as possible: I am not discussing why accounts end up "restricted"—whether that’s fair or not—nor am I addressing other problems. I am focusing solely on this one specific aspect.
Comment · 18 hours ago
I don’t know. But how do you explain the fact that this remains almost unknown, even though this system behavior has existed for years? For instance, try asking ChatGPT or Gemini about this —the AI don’t know, which is quite telling.
Comment · 29 days ago
Sorry for the off-topic post, but since you're from Cisco... is there someone I could speak with regarding the Senior Software Engineer - Windows (Duo) position (ID 2023286: https://careers.cisco.com/global/en/job/2023286/Senior-Softw...)?

I am a low-level Windows developer with extensive knowledge of Windows internals, Win32/NT APIs, debugging, research, etc., and—most importantly—expertise in the Windows logon area, credential providers, and related technologies.

Comment · 29 days ago
I’m simply looking for a job—nothing more. I posted updates on LinkedIn solely to draw attention to myself, hoping to turn that into a position; writing articles for their own sake doesn't really interest me. In reality, though, it hasn't helped at all. I’m trying to reach out only regarding roles where I possess—in my view—extensive knowledge and experience in the key area. It feels impossible to land these roles without an inside contact, which is why I asked about Duo Security. Then again, to be honest, even that usually doesn't help—but I try to seize even a hypothetical chance.
Comment · 29 days ago
Comment · 1 month ago
Everyone has their own strengths and weaknesses. I’m a developer. I’m good at writing and debugging code. But writing articles isn't my thing—even on my native language, not say already on English (despite the language itself isn't the main issue here). I used to post technical posts on LinkedIn. Not in the style of The Old New Thing, but just about things that were somewhat interesting and not widely known. The posts weren't high-quality, but they did earn me over 2,300 followers there. However, a year ago, LinkedIn deleted my account. So, all of that is gone forever (I didn't back it up anywhere else, and I don't have a personal website). That means my claim about the LinkedIn posts can't be verified anymore. I’ve written a few article-like pieces on my GitHub—for example, https://github.com/rbmm/tbal (or https://github.com/rbmm/StateMachineState). They were nothing special—not top-tier quality. A few years ago, I collaborated with someone, and we wrote some articles together for his site (I provided the technical info, and he did the writing): https://dennisbabkin.com/blog/author/?a=rbmm (We haven't worked together for several years now). To me, it’s nothing remarkable. In any case, my main "creative output" was on LinkedIn. It never even crossed my mind that the platform could delete everything. When your account gets flagged as "restricted," it doesn't just switch to read-only mode where you lose access; it means a total wipe—everything gets deleted: all public posts, all conversations (including the ones with other people). For instance, I wrote about my framework for writing shellcode in C++ simply and efficiently using native code—okay, I think it’s the best implementation of its kind available publicly. I used to write about various other utilities and research projects of mine, amusing PoCs, and little-known techniques. At least there’s still Stack Overflow with its objective reputation (rating) system—though, in reality, it doesn't bring me anything, and the topic I primarily answered questions on (WinAPI) is pretty much dead these days. That leaves GitHub (obviously, I don't make all my projects public) and the occasional YouTube video.

Thanks for the comments.

Comment · 1 month ago
I watched a few videos—maybe that’s because it’s a very niche topic, and you personally aren't involved in this specific field. Actually, my question had two parts. The first was general—less of a specific question and more of a general observation. I believe the current selection process is deeply flawed for both sides. It’s particularly bad for unconventional candidates (though that’s always been the case). The search for a résumé—which has to follow a specific format rather than just any style—has become an end in itself, even though it’s merely a tool, not the actual goal. And now, it seems like tons of people are using AI to write "perfect" résumés and heavily embellish their knowledge and experience. (Personally, I don't get the point of lying; if they believe you and hire you, that kind of lie—about your actual capabilities—will be exposed immediately. What do you gain in the end other than disgrace?) This breaks the process even further.

The second part was strictly personal. I’m wondering if there’s any way to get in touch with the team handling this position—bypassing the standard process. I say this because I genuinely possess unique knowledge and experience in the key required areas (low-level Windows development, credential providers, debugging all of that) and had some public proof of this—like my Stack Overflow ranking, for instance, which—unlike a résumé—can't be faked (and can look up "rbmm windows"). but, I can't even apply for the position or make myself known. So, I was asking if anyone happens to know people there (despite slim the extremally low, i nothing have to lost).

Thanks for the whoishiring link. My expertise is in a very narrow, specialized field. There are incredibly few job openings that actually suit me (I don't just "apply" (not in direct sense) for everything; I only target roles where I truly have specialized knowledge and experience). There are literally only a handful of them. However, it has now become absolutely impossible to reach them (following the loss of LinkedIn)—though I suspect there are very few people with deep expertise in such fields too.

Comment · 1 month ago
Comment · 1 month ago
the question isn't how to find a job opening, but rather how to effectively apply for one (assuming you have the relevant knowledge and experience).
Comment · 2 years ago
yes. after any thread request exclusive access to lock, the sequential shared acquire request will block. this iswell known fact, i hope. this is example when shared request will be blocked, despite shared owner(s) now inside lock

also look my 2 comments on reddit: https://www.reddit.com/r/cpp/comments/1b55686/comment/ktfhjs... and https://www.reddit.com/r/cpp/comments/1b55686/comment/ktfggu...

if say true - i here in very strange position. i am by self under debugger research exacly what happens in concrete case and create repro code. i think that implementation of the RtlReleaseSRWLockExclusive is not the best and may be really containing "bug" as i in more details describe in comment on reddit. but from another side, if you want pure formal c++ rules - can you explain - in what exactly was bug in concre case ? what rule/guarantee is violated ? why demo code decide that ALL shared waiters can at once acquire the lock. formal documentation not state this. this intuitive must be true, because no exclusive request more. but.. i really dont know. and i also for fun create own implementation of SRW lock ( if someone interested to look -https://github.com/rbmm/PushLock ) which free from this roblem - i always ( hope) do only single atomic change to lock state during api call. and finally - sorry for my english and too long answer

Comment · 2 years ago
of course - SRW lock allow shared access only if no waiters ( request to exclusive access) on lock. so even if lock in shared mode, new shared request can block, if was waiter(exclusive) already. in case OP no exactly this, but anyway - i be say that shared access is only hint to system, that it can optimize access - and allow multiple shared threads inside lock. but this was not always
Comment · 2 years ago
"other threads can share-acquire the same lock without waiting." can but not always and mandatory. you really allow to system enter another shared requestor. but only allow,not demand. system not let shared requestor enter to lock, if before it the exclusive request will be. after first exclusive request - all next shared request will block, util this exclusive request not acquire and then release lock. can be and some another reason, in the end - this is only optimization - you only *allow* multiple shared enter at once. so i be not say that this is implementation bug
Comment · 2 years ago
what is shared mode ? this is by fact optimization for speed, if we need read-only access to data, we allow to system let another thread into the section that requests shared access also

allow but NOT DEMAND this. If one thread has acquired the shared lock , other thread can acquire the shared lock too. but only CAN. in some case system not let another thread enter to lock, despite it also request share access. one case: if another rthread request exclusive acess - he begin wait and after this - any thread which acquire even shared access to lock - also begin wait

If lock_shared is called by a thread that already owns the mutex in any mode (exclusive or shared), the behavior is undefined.

and

Shared mode SRW locks should not be acquired recursively as this can lead to deadlocks when combined with exclusive acquisition.

why is this ? because if between 2 calls to lock_shared ( AcquireSRWLockShared ) another thread call AcquireSRWLockExclusive - the second call is block.

the code in example make assumption that ALL threads can enter to lock at once. that if one thread enter to lock in shared mode, another thread also ALWAYS can enter to lock in shared mode (if no exclusive requests). but i not view clear formalization of such requirement. and we must not based on this.

i be will add next rule:

thread inside lock must not wait on another thread to enter this lock

this is obvivius for exlusive access, but not obvivous to shared. but must be cleare stated along with the recursive rule ( should not be acquired recursively as this can lead to deadlocks, even in shared mode)

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton