Leans center-right. Candid. Publicly supported Trump. Other stuff that just makes him a normal person circa 90s but really turns some people off in 2025.
I wouldn't say they aren't savvy. Many aren't, but also I don't blame them. Often you can buy a perfectly reasonable device and then they ad spying and adverts after you bought it. Most reviewers also don't talk about this stuff, and there are no standards for any of it (unlike e.g. energy consumption).
I went with Philips Hue smart lighting specifically because it could work without an account or any internet access for the bulbs or hub.
Guess what became required this year? At least it seems I can still use them offline if I don't use the official app. But the official app is now just a popup requiring me to create an account. I'm not sure if I could add new lights using third party apps. Not like I'm ever buying a Hue product again though.
I recently reviewed a PR that I suspect is AI generated. It added a function that doesn't appear to be called from anywhere.
It's shit because AI is absolutely not on the level of a good developer yet. So it changes the expectation. If a PR is not AI generated then there is a reasonable expectation that a vaguely competent human has actually thought about it. If it's AI generated then the expectation is that they didn't really think about it at all and are just hoping the AI got it right (which it very often doesn't). It's rude because you're essentially pawning off work that the author should have done to the reviewer.
Obviously not everyone dumps raw AI generated code straight into a PR, so I don't have any problem with using AI in general. But if I can tell that your code is AI generated (as you easily can in the cases you linked), then you've definitely done it wrong.
> Sadly, the real issue here is with the banks and the payment processors
I disagree. The issue is these huge platforms can arbitrarily ban people and consumers have no recourse.
This sort of thing wasn't really possible before the internet age. We need new laws to deal with it.
Banks are nothing to do with this. You could have your Steam/Google/Apple/etc. account summarily executed for any reason; it doesn't have to be money-related.
> This sort of thing wasn't really possible before the internet age. We need new laws to deal with it.
Yes, it was and it always has been[1]
>I disagree. The issue is these huge platforms can arbitrarily ban people and consumers have no recourse
This is par for course with every single EULA ever. I will say in the case of Steam it's hard pressed to find your account completely disabled and unable to play the games you rightfully purchased. I think the worst-case scenario is that you will be banned from engaging with the steam online community which restricts your ability to play with other users on steam
Redlining is the example that I am giving to show this has long been the behavior of businesses and unless its racist it's not illegal. Also read your EULAs
What makes you think this is ineptitude? They know exactly what they're doing.
The mistake HN commenters make is thinking "But TLS is encryption too! They can't ban Signal without also banning TLS!". They absolutely can if they want to.
It's amazing the number of people that thing shell scripts should be anything other than throwaway single-person hacks.
They should probably go through their whole system and verify that there aren't more shell scripts being used, e.g. in the init system. Ideally a default distro would have zero shell scripts.
Probably not a joke. In the same way people want to get away from the C language due to its propensity to memory vulnerabilities, shell scripts have their own share of footguns, the most common being a variable not being quoted when it should (which is exactly the issue described in this advisory).
It doesn't mean getting away from scripting languages; it means getting away from shell scripts in particular (the parent poster said specifically "zero shell scripts"). If the script in question was written in Lua, or heck even Javascript, this particular issue most probably wouldn't have happened, since these scripting languages do not require the programmer to manually quote every single variable use.
That's fine; I just thought it was weird to say that we should check to see whether any shell scripts are used in the BSD init system. We know there are; it was a deliberate design decision at the time, even if we might now wish for it to be different.
Not a joke. I knew they used to use a pile of janky shell scripts for their init system. I didn't know they still do. That's disappointing.
And cesarb is correct - the issue isn't scripts; it's shell scripts, especially Bash and similar. Something like Deno/Typescript would be a decent option for example. Nushell is probably acceptable.
Even Python - while a terrible choice - is a better option than shell scripts.
The issue is POSIX standardizing legacy stuff like shells, thereby tempting people to write "portable" software, leading these technologies to ossify and stick with us for half a century and counting. Someone comes along and builds something better but gets threatened for not following "the UNIX way".
This is a very good point. I wonder how hard it would be to get POSIX to standardise a scripting language that isn't awful.
Probably never going to happen. There is a dearth of good scripting languages, and I would imagine any POSIX committee is like 98% greybeard naysayers who think 70s Unix was the pinnacle of computing.
POSIX does not specify the init/rc script system, so it's not a factor here at all. A POSIX-compliant system could use Python scripts. macOS (which is UNIX 03 certified) uses launchd. A POSIX system has to ship the shell, not use it.
And FreeBSD isn't actually POSIX-certified anyway!
The real consideration here is simply that there are tons of existing rc scripts for BSDs, and switching them all would be a large task.
Unfortunately your joke has wooshed over quite a few heads but what you say is true. The shell should be one of the most reliable parts of your operating system. Why on earth would you NOT trust the primary interface of your OS? Makes no sense.
I'm not sure I follow you but it wasn't a joke. Shell scripts are notoriously error-prone. I absolutely do not trust shell script authors to get everything right.
Also the shell isn't even "the primary interface of your OS". For Linux that's the Linux ABI, or arguably libc.
Unless you meant "human interface", in which case also no - KDE is the primary interface of my OS.
> I'm not sure I follow you but it wasn't a joke. Shell scripts are notoriously error-prone. I absolutely do not trust shell script authors to get everything right.
This is an extremely naive take as are the rest of your comments. Any language in the wrong hands is error prone.
"error-prone" means bugs are more likely than the alternatives. It doesn't mean that the alternatives completely eliminate the possibility of bugs. Come on.
It doesn't need to be, but there are some advantages in being able to have system startup scripts in the same language that you do one-liners in at the terminal.
I've always believed sh, csh, bash, etc, are very bad programming languages that require excessive efforts to learn how to write code in without unintentionally introducing bugs, including security holes.
If you want all-singing, all-dancing opaque binaries to handle every conceivable configuration eventuality, MacOS and Windows are <-- that way. Or, you could have patience, and sometime soon systemd will likely expand to cover your use-case.
> Although we gave away 11.5 billion build minutes (~$184 million) to support OSS last year
Interesting, I was trying to estimate how much they spent on free actions per year. I thought it would be around $100m. This is the first actual number I've seen.
I expect the $184 million figure is the sale price rather than the actual cost to GitHub, and given that competitors offer the same service for 3-10x less it's probably more like $80m overall I'd guess.
Still a pretty huge amount of money that I don't think any competitors can really hope to match.
Nah they have definitely reduced massively. I suspect that's just because as models get more powerful their answers are just more likely to be true rather than hallucinations.
I don't think anyone has found any new techniques to prevent them. But maybe we don't need that anyway if models just get so good that they naturally don't hallucinate much.
Not in my experience. For example models often say "no you can't do that" now whereas they used to always say you could do things and just hallucinate something if it was impossible. Of course sometimes they say you can't do things when you can (e.g. ChatGPT told me you can't execute commands at the top level of a Makefile a few months ago), but it's definitely less.
> They're just not as egregious.
Uhm yeah, that's what I'm saying. The hallucination situation has improved.
Parent was writing about a university LECTURE which is different from a TEXTBOOK (which is different from primary sources), so yeah, consulting other sources is checking the facts.
Oh I see what you're saying. It was slightly ambiguous.
But in any case, I didn't read a single textbook at uni; it was all lecture notes provided by the lecturers (fill-in-the-gaps actually which worked waaaay better than you'd think). So the answer is still no - I didn't fact check them and I didn't need to because they didn't wildly hallucinate like AI does.
reply