HN user

mubou

322 karma
Posts0
Comments166
View on HN
No posts found.

There isn't a yes-or-no answer to this. Some things I would consider:

1. Does this add additional complexity? How much more time/effort would it take to implement the feature? And most importantly, how much added effort would it take to maintain the feature? (Would adding this feature become a burden later?)

2. Can we be sure that the feature, as we would implement it now with our limited information, will meet future requirements, or would we perhaps be implementing something one way only for it to turn out that it would have been better implemented another way once there's an actual, defined usecase for it? (Remember that once you add something to an API, it can be hard to change or remove it later.)

Sorry, should have been more clear. I meant "AI" in the sense that people refer to anything using machine learning as "AI". (Honestly "AI" is such a meaningless term. LLMs are anything but intelligent.) But I agree. For most tasks, a non-gen AI model trained specifically for that task is significantly better. People are just taking the output of gen AI and using it as-is, rather than treating it as a tool to be leveraged as part of something larger and programmatic, like all ML before it.

Automating tasks is exactly what AI/ML should be used for. My concern is that they're going to be using LLMs to "translate" other-language articles into English and vice versa. LLMs are horrendously bad at this, compared to models trained specifically for translation tasks. They make shit up, invent phrases that weren't in the source text, etc., and with how much blind faith people put in ChatGPT, you can be sure a lot of those hallucinations will go unchecked.

The funny part is, Wikipedia is the #1 data set used for all sorts of machine learning training (not just LLMs). I hope they at least mark articles that were translated/edited by AI, because otherwise the AI machine is gonna start feeding back into itself sooner or later.

Holy shit, this could actually cause people to get permanently locked out of their accounts, depending on how the website is configured. Imagine not knowing your login credentials are stored in Place A and then you delete Place A, unwittingly deleting your only login along with it.

This is already a worrisome possibility with security keys -- if you have Windows Hello enabled, the dialog you get when adding a security key to an account might sometimes be to add it to your TPM, but it's not clear that's what Windows is asking so you might put your creds on your CPU while thinking that they're going on the Yubikey; imagine what happens then when you upgrade your computer?

Users need to know where their logins are stored. Making these things "transparent to the user" in the name of ease of use (treating users like toddlers) is the wrong approach. I realize the average user doesn't understand the technical side here, but that just means we need to do better as devs and designers, not throw in the towel and make decisions for the user.

You can also set this in your browser with the _reduce motion_ parameter.

Unfortunately there's no way to set this per-site, at least in Chrome. Similarly, if you disable animations in Windows, you also disable all animations and transitions in websites that support prefers-reduced-motion, causing some sites to feel janky as a result.

They really need to add a per-site toggle for that, and a browser-level option to ignore the OS' setting. Turning off animations in Word shouldn't turn them off in Google Calendar.

I bet you could do something generic like this in languages that have deferred execution like C#'s IEnumerable. Something like

    foreach (Node node in EnumerateNodes(root, x => x != null, x => [x.Left, x.Right]))
where EnumerateNodes uses `yield return` (i.e. is a generator) and calls itself recursively. Though it'd probably be easier / better performance to write an implementation specific to each node type.

Oh, my bad, thought you meant it was built in markdown, like MDX or something.

I wish you could do all this in plain markdown; putting things side-by-side in a github readme can be tricky. Have to resort to sub/superscript hacks just to make image captions.

Anyway, looks nice.

how it's impossible to get Google to show English results in a non-English-speaking country

It's ridiculous because there's even a language option in the search settings, but it does nothing. I had to change my country to United States just to get it to stop giving me non-English technical documentation and wiki articles. But that means in order to get local results for stores etc I have to use Bing/DDG instead.

Does Kagi solve this problem somehow? Like, can I make it give me non-English results for local things and English results for everything else?

It's important to point out that the concept of "linking" is not mentioned in the GPL's definition of "Program" or "covered work", nor is it used as a determiner to decide if the viral nature applies to your work or not. That's a common misconception that people who've read about GPL but never read the actual license text have. I point that out here only because the developer here mentioned it, but it's irrelevant.

The viral nature applies if you "convey a work based on the Program, or the modifications to produce it from the Program" unless it is "a compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program" [0].

If that sounds vague enough to be interpreted in a lot of different ways to you, you're right. Even the FSF themselves admit it would be up to a court to decide[1] (which unfortunately in a lot of cases means whoever has the most money wins).

tl;dr - When in doubt, assume you need to make your work GPL too.

[0] https://www.gnu.org/licenses/gpl-3.0.en.html

[1] https://www.gnu.org/licenses/gpl-faq.html#MereAggregation

Not sure how useful this is IRL, but it's pretty elegant, for being able to reproduce both JSX and React's hook style in so little code. Rather than a React alternative per se (since this obviously lacks a vDOM), it almost feels like it could fill a similar role that Knockout did back in the day: making it easy to add some interactivity to a page in a more declarative way than plain DOM handling, but without bringing in a full framework.

Here's a codepen if anyone else wants to try it out: https://codepen.io/mubou/pen/pvvWyGO

I was thinking more "is it possible to contact them." When I googled RTEMS I found that it's originally an OS for missile systems from 1993 O_o

But I disagree. It's not extorting money to sue someone who stole your code and deliberately removed your copyright notices. The open source license only gives you the right to use the work for commercial purposes AS LONG AS you comply with the terms of the license. If you don't, then you're illegally profiting off stolen work. You can't violate the terms of a contract while still benefiting from it.

I don't know how much was stolen here, but if it's foundational enough to the project that HBC had to give up development, then they might have a case, but IANAL. Not doing anything though would mean letting them get away with their ill-gotten gains (again - if true), and I just don't think that's right. Like I said, I've seen similar things happen before and it pisses me off.

Is RTEMS an active project? They should file a copyright complaint and have the libogc repo taken down if this is true. If it were me, I'd lawyer up and throw the book at them.

LibOGC accepts donations via Patreon, which means -- if the allegations are true -- they're profiting off stolen code. RTEMS could and should sue for damages.

This isn't the first time I've seen an open source project stolen by someone trying to pass it off as their own work while accepting Patreon donations. I'd like to see some justice every now and then...

Plenty of devs work on both web and mobile in their day-to-day, or do web development at work then go home and work on a mobile app. Unfortunately most companies separate the two into different teams with zero cross-collaboration, so frontend devs get no opportunity to work on the app or vice versa, but that's the organization's fault, not the developers'. Same with frontend and backend. If you're capable of learning more than one language/framework, you're capable of doing both web and mobile. The rest is mostly just grasping differences in UX design (and owning a Mac). Don't limit yourself just because your colleagues can only do one thing. Most people simply never have the opportunity or interest to practice outside their specialty.

types are deferred until parse time; the app knows what it wants.

Thank you! Types have no business in a configuration format when the app already has a defined schema. Most formats try to convey all of the information needed to reconstruct an object, but that's totally unnecessary and only serves to complicate the syntax and introduce unnecessary errors/mishandlings.

Are there any other config syntaxes that do this? Besides ad-hoc INI, that is.