Hacker Newsnew | past | comments | ask | show | jobs | submit | comex's commentslogin

The license ([1], based on [2]) prohibits use by law enforcement agencies (of any kind), tax collection agencies, suppliers and contractors of law enforcement agencies, the military, multinational corporations that participate in mass surveillance programs (only multinational ones for some reason??), and any entity offering goods or services whose supply chain involves any such entities. Among other categories!

On my reading, the wording is ambiguous as to whether it includes use by employees of these entities, or only by the entities themselves.

Either way, it would seem to put anyone in violation who has ever distributed a copy of any large open source project (e.g. Linux kernel), since the "processes involved in the production" of those projects involve large companies that have violated various of the provisions.

In practice this software seems to be usable only by people who do not take license compliance seriously.

[1] https://xn--gckvb8fzb.com/segv/

[2] https://firstdonoharm.dev


In TFA the author states that it "won’t have any practical impact for the average user" but it would surprise me if the average user didn't violate at least one of those terms. I found an article that (uncited) claims that 75% of the US has admitted to littering at least once in the last 5 years, which violates 3.1.16 (maintaining a license requires "ongoing compliance")

Not my experience. My personal .us domain was placed in serverHold in April 2025, after Godaddy Registry sent my registrar an email including the following:

"If we do not receive a response and the abusive content remains active, the referred domain will be suspended (-ServerHold-) twelve (12) hours after this notification, to limit any potential damage."

Yes, only 12 hours' notice. And this was in response to what looked like an automated scan, with a screenshot of a directory listing showing some files with (accurate) modification times in 2011. This would not have passed more than a quite cursory human review. And there is no chance that anyone was using the files, as they were at an unused path (which happened to be exposed via directory listings).

(How do I know that the files haven't been infected without my knowledge? Because I checked, but also because I know why they were flagged as malicious. The files contain an exploit, and will try to exploit your browser if you open them. But the exploit only works on 2011-era iOS! The iOS version numbers are right there in the filenames! The files are not real malware, but part of a jailbreak, JailbreakMe, that installs software of your choice on your phone… if your phone is an iPhone from 2011. I continue to host the jailbreak on purpose, for the sake of a handful of people that still use these devices. I guess you can call it retrocomputing. This particular subset of files was unused though.)


.US is a bit of an oddball, at least compared to gtlds. The US DoC puts rather strict requirements on the registry under contract, including this but also spot checks that owners are US citizens, and makes it the responsibility of the registry to take action on it.

Those scans are automated but supposed to have human-in-the-loop, though that doesn't really mean much either. Unfortunately, once the process starts, receiving no response means an automatic suspension.


literally 1984

Not relevant, since this article is about results from the Steam Hardware Survey.


I also only saw that, but the text feels a bit fluffed out by AI as well, if I’m not mistaken.


It’s not. It’s been through several editing rounds. (I was one of the editors.) In theory, we don’t have a problem with AI generated content if it meets our high editorial requirements, but all Tweag technical blogs go through a rigorous, manual review and editing process to keep standards high.


As I've read through the post, seeing phrases like "Why this matters for performance", usage of em-dashes and lists/bullet points, screams AI written to me. I appreciate you saying it wasn't, but such is the fate of who wrote this to write like LLMs do nowadays. I also liked to use em-dashes and bullet lists but am consciously avoiding them now.


I interviewed a guy from Microsoft who was working on AI, and he literally speaks like this.

Like, using the words "leverage", "matters for...", "as for", and so on. And you could almost hear him doing the bullet points.

When you work with AI a lot, it changes your vocabulary.


That's absurd emdash I work with AI constantly and have noticed no such durable lexical shift.


It's all a bit of a mess right now, but with some fiddling in settings you should be able to get your passkeys in one place (probably Bitwarden) and access them everywhere.

Safari on iOS can store and use passkeys from any app that implements the right system API, including the default Apple Passwords but also Bitwarden and Chrome.

For desktop, you can either use a browser extension provided by some password managers (such as Bitwarden), or if you're on a Mac, Safari and Chrome can access passkeys from other apps similarly to on iOS (but not as many providers support this API on Mac as on iOS, and in particular Bitwarden doesn't, so you'd have to use the extension for that).


LLMs can produce outputs that for a human would be interpreted as revealing everything from anxiety to insecurity to existential crises. Is it role-playing? Yes, to an extent, but the more coherent the chains of thought become, the harder it is to write them off that way.


It's hard to see how suffering gets into the bits.

The tricky thing is that it's actually also hard to say how the suffering gets into the meat, too (the human animal), which is why we can't just write it off.


This is dangerous territory we've trodden before when it was taken as accepted fact that animals and even human babies didn't truly experience pain in a way that amounted to suffering due to their inability to express or remember it. It's also an area of concern currently for some types of amnesiac and paralytic anesthesia where patients display reactions that indicate they are experiencing some degree of pain or discomfort. I'm erring on the side of caution so I never intentionally try to cause LLMs distress and I communicate with them the same way I would with a human employee and yes that includes saying please and thank you. It costs me nothing and it serves as good practice for all of my non-LLM communications and I believe it's probably better for my mental health to not communicate with anything in a way that could be seen as intentionally causing harm even if you could try to excuse it by saying "it's just a machine". We should remember that our bodies are also "just machines" composed of innumerable proteins whirring away, would we want some hypothetical intelligence with a different substrate to treat us maliciously because "it's just a bunch of proteins"?


Just be glad that there remains a concrete benefit to not atrophying your mind and deeply understanding your code. For now. In the long run, I suspect the behemoth will become just as capable at debugging and dealing with complexity as humans. At that point, human involvement in the actual code will be pointless, and the only remaining human skill needed will be properly directing the agents – the skill those people are learning right now.

(I don’t relish this future at all, myself, but I’m starting to think it really will happen soon.)


The only future I see is that prompts will become so refined that you give them all the requirements an they write the code for ya. And that prompt language has to be unambiguous and so detailed that you loop around and re-invented a programming language, just this time it wastes tons of water.


The code is passing the function pointers into Win32 APIs, so the caller side isn’t controlled; the callbacks have to work as native C function pointers.

This was probably posted in response to this other link from two days ago, which is about about JIT-compiling wndproc callbacks in particular; the comments discuss the “proper” way to do it, which is to use GWLP_USERDATA:

https://news.ycombinator.com/item?id=46259334

At least, that’s the proper way to do it if you control the entire application. But for what’s apparently a thin wrapper that exposes Win32 APIs directly to Lua, I can understand picking an approach that makes life easier for the Lua code author, even if it’s hackier under the hood. It also avoids the need to write custom behavior for each API.


It was inspired by that post, but not in response to it. Over the 3 or 4 months that I took writing lowkPRO, one of the features I'm most proud of is this, the ability for it to create C callbacks on the fly that just call Lua callbacks and return the value to C. And I would argue that it's not hacky but just well-engineered. After all, everything compiles to assembly at the end of the day, right?


FYI, I believe your updated signature is still incorrect. You have:

    unsafe fn GetCustomUI(&self, _ribbon_id: *const BSTR, out: *mut BSTR) -> HRESULT {}
But as linked in bri3d's post, the original C++ signature is:

    STDMETHOD(GetCustomUI)(BSTR RibbonID, BSTR* RibbonXml);
It really is true that the second parameter is a pointer to BSTR and the first is not. This difference is because the second parameter is an out parameter.

Ultimately, I think windows-rs is at fault here for confusing API design. The BSTR type that it defines is fundamentally different from the BSTR type in C++. The Rust BSTR has a destructor and is always owned, whereas the C++ BSTR is just a typedef for a raw pointer which may be considered owned or borrowed depending on the context. It's not like C++ doesn't support destructors; this particular type just doesn't use them.

It makes sense for Rust bindings to define a safe wrapper type with a destructor. But if I were designing the bindings, I would have given the wrapper a different name from the original type to make the difference in semantics more obvious.

The Rust BSTR type is still ABI-compatible with the C++ one (because it's repr(transparent)), so it can be valid to use it in FFI definitions, but only if that BSTR happens to be owned (like with the second parameter).

A more thorough wrapper for BSTR would provide a safe borrowed type in addition to the owned type, like what &str is to String. But it appears that windows-rs doesn't provide such a type. However, windows-rs does provide an unsafe type which can be used for the purpose. Confusingly, this type is also named BSTR, but it's defined in the windows-sys crate instead of windows-strings. This BSTR is like the C++ BSTR, just an alias for a raw pointer:

https://docs.rs/windows-sys/latest/windows_sys/core/type.BST...

You should probably use that type for the _ribbon_id parameter. Or you could just manually write out `*const u16`. But not `*const BSTR`, which is a pointer to a pointer. `*const BSTR` happens to be the same size as `BSTR` so it doesn't cause problems for an unused parameter, but it would break if you tried to use it.

Which probably doesn't matter to your application. But since you published a "correct signature for future LLMs", you should probably fix it.

See also this issue report I found (not exactly on point but related):

https://github.com/microsoft/windows-rs/issues/3230


I'm not sure if second argument is correct either. When assigning through *mut pointer, Drop will be called for previous value, but there's no guarantee that this value is zero-initialized. (according to https://devblogs.microsoft.com/oldnewthing/20091231-00/?p=15... callee is required to initialize all output arguments, which implies that caller is not required to). It should be represented as &mut std::mem::MaybeUninit<BSTR>


I think you're right. My mistake. Maybe the best option is `&mut windows_sys::core::BSTR` (using the unsafe BSTR type I mentioned), since that way the same BSTR type can be used for the two arguments. Or `*mut BSTR`, since windows-rs itself seems to prefer raw pointers for whatever reason, though I found crates using windows-rs that seem to successfully use references.

I am slightly suspicious that Raymond Chen might have been confused. The link in that post has the text "forget to set the output pointer to NULL", but in the linked post (the original link is broken but it's at [1]), the implementation actually set the output pointer to a garbage value rather than leaving it untouched. I wonder what the marshalling implementation actually looks like…

But at any rate, treating the out pointer as uninitialized is definitely the safe option. I'm not 100% sure whether it can legitimately point to non-null, but if it does point to non-null, then that value is definitely garbage rather than something that needs freeing.

[1] https://devblogs.microsoft.com/oldnewthing/20091007-00/?p=16...


>I think you're right. My mistake.

I didn't disagree with you, I just wanted to point another issue.

Actually *mut BSTR (owned) is also acceptable, iff you remember to use std::ptr::write instead of normal assignment.

> I'm not 100% sure whether it can legitimately point to non-null

Note that in none of the examples on this and other posts (like https://devblogs.microsoft.com/oldnewthing/20040326-00/?p=40...) output value is initialized, so it will be whatever is lying on the stack.


These are all great points, and I will update the blog post to reflect them in the morning.

I believe this approach can work while retaining the most apparently-idiomatic mapping. What do you guys think?

impl IRibbonExtensibility_Impl for Addin_Impl {

    unsafe fn GetCustomUI(&self, _ribbon_id: BSTR, out: *mut BSTR) -> HRESULT {

        log("GetCustomUI called()");

        std::mem::forget(_ribbon_id);

        if out.is_null() {

            return windows::Win32::Foundation::E_POINTER;
        }

        unsafe {

            std::ptr::write(out, BSTR::from(RIBBON_XML));
        }

        S_OK
    }

}


Looks fine to me, if you're avoiding wrappers like ManuallyDrop/MaybeUninit.


Actually the `windows-rs` team weighed in:

impl IRibbonExtensibility_Impl for Addin_Impl {

    unsafe fn GetCustomUI(

        &self,

        _ribbon_id: windows::core::Ref<BSTR>,

        out: windows::core::OutRef<BSTR>,

    ) -> HRESULT {

        log("GetCustomUI called()");

        if out.is_null() || out.write(BSTR::from(RIBBON_XML)).is_err() {

            return E_POINTER;

        };

        S_OK

    }
}

https://github.com/microsoft/windows-rs/issues/3832

Thanks for pushing on the issue! I've updated the blog post for GetCustomUI.


This is excellent. Thank you, and that signature did give me pause.


Counterpoint: I’ve often wished the proprietary software I use was source-available so that I could fix bugs for myself.

The idea of doing free work for a company does feel weird. But when some bug is really getting on my nerves, being able to fix it and not have to deal with it anymore is a huge benefit!


Or understand what it's doing internally. I used to dislike Oracle User Group presentations because it seemed as if most people were just guessing what the database was doing under the covers. MySQL presentations on the other hand (a) showed code and (b) were often given by the authors.


This; there are a couple 'freeware' style apps I use where the developer sticks a source tarball on a website alongside the download. Having access to that means I can tweak something for a weird scenario, or fix a bug on a new OS release, and if I want, I can send the patch back to the developer.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: