I have given up on spending more time reviewing PRs and help fixing bad decisions made by AI because all it does is encouraging the same thing without learning. Next PR will most likely contain similar design / code problems.
I can't speak for all orgs but at the end of the day, the only metric that my org cares about is how AI is improving our work. Holding the line for quality is definitely a good thing, but when your org doesn't care about the pressure on PR reviewers, and the effort it took to fix those PR mistakes or their repeat, those reviews are only helping the loop case and that AI is without flaws. I am not saying AI is a bad thing all together, but when the org ignores those metrics, I am only contributing and helping to prove that the other side is right.
Might be harsh to say but not bothering to fix the spacing in the ai generated ascii diagram tells me how much i should be taking this project seriously.
I can see the argument of parents or guardians ensuring the device is properly set for their child, but I feel like age is not the right information to use. But I agree, it's definitely not well thought out.
I feel like if we assume this is in good faith, and they want to make sure adults can ensure minors don't have access to certain content, why would they use age as the information?
This can be solved, or even have been solved by having Parental Control feature like in IOS which provides finer options than what you would get with age.
This could OK if this was requiring that any device or operating system have access to parental control in any capacity (either by default or via third party application) and limited for things that would be used by minors so that VMs or other stuff don't have to worry about this. Or, they could mandate products to indicate that the feature exist. That way, a parent can decide what to give their child.
to me, it's both the slippery slope argument and the lack of real reason other than "protecting minors". operating systems were designed to run the program/programs. You can make applications use this API to determine the user age, or you can just...ask the user in the application itself. I also don't see why this is a requirement rather than an option the same way I don't see why having a Microsoft account is required to install windows or access to internet (without the current workarounds) or even those password reset questions and to some extent asking for first and last name. If I want to add those information, let me do that myself or when i use said software, don't make it a hard requirement.
The bill itself sort of goes against its "purpose". If the purpose is to make a convenient API for stores to know their user, and avoid showing them certain content then why did the bill state:
"If an operator has internal clear and convincing
information that a user's age is different than the age
indicated by a signal received in accordance with this
Section, the operator shall use that information as the
primary indicator of the user's age."
because many people lie in those forms. Many people on steam will select they were born in 1900, including myself. So how will this API help? the only way for it to be useful is if they later require full verification.
I think what sets Zig apart from other low level languages is how easy it is to navigate a Zig source code. I was discouraged at the time (things probably changed now) when the best source for documentation was "read the Zig's source code". But I was impressed by how easy it was to find what I needed.
while this is due to Zig maintainers' code quality, I think a large contributing factor is the choice of syntax. As an exercise, try navigating a C, C++ and any other language source code without an IDE or LSP. things like:
- "Where did that function come from?"
- "What and where is this type?"
what do you have to do to find that out? due to the flexible ways you can declare things in C, it may take you a lot of steps to find these information. even in search, a variable and a function can share the same prefix due to the return type placement. hence why some people prefer function return types in a separate line.
Even with languages like Rust for example, finding if a type in a function parameters is an enum or struct and finding its definition can require multiple steps like search "enum Foo" or "struct Foo", in Zig i can search "const Foo" and i will immediately know what it is.
while i do hope that C gets defer and constexpr functions in the next standard or maybe better generics or enums, Zig syntax is much better to work with in my opinion.
I totally agree with the author. Sadly, I feel like that's not what the majority of LLM users tend to view LLMs. And it's definitely not what AI companies marketing.
> The key thing is to develop an intuition for questions it can usefully answer vs questions that are at a level of detail where the lossiness matters
the problem is that in order to develop an intuition for questions that LLMs can answer, the user will at least need to know something about the topic beforehand. I believe that this lack of initial understanding of the user input is what can lead to taking LLM output as factual. If one side of the exchange knows nothing about the subject, the other side can use jargon and even present random facts or lossy facts which can almost guarantee to impress the other side.
> The way to solve this particular problem is to make a correct example available to it.
My question is how much effort would it take to make a correct example available for the LLM before it can output quality and useful data? If the effort I put in is more than what I would get in return, then I feel like it's best to write and reason it myself.
There was a also proposal for ICANN to reserve ".internal" (earlier this year) which is what I currently use. I suppose home.arpa has the advantage of being strictly resolved in the local zone while ".internal" would be more for anything in a private network (or a large multi zone network)?
While I wish GCC would implement integrations and/or a language server, I usually do C programming in the terminal (with entr to trigger automatic rebuild on save).
I do find some false positives, but I haven't had many of them to be a deal breaker for me. Aside from what I mentioned about the errors being descriptive, I do like the defaults and that it's part of the compilation process.
for example, possible malloc null warning is on by default (which i don't think is on clang).
To me fanalyzer is one of GCC killer features over clang. It makes programming C much easier by explaining errors. The error messages also began to feel similar to Rust in terms of being developer friendly.
Yes, brave has 2 checkboxes in its settings page. One for crash reports and the other for privacy-preserving product analytics (P3A) which is what they are talking about here. Disabling those stops Brave from sending anything to brave endpoints, aside from auto update checks of course.
I think Actix used to be the goto web framework at the time is because it was the most complete, it's still a solid choice. What I think made Axum more popular aside from the features added is that it's part of the tokio-rs projects.
Not a GUI, but I am using neomutt which requires a bit of config and time to get used to. Thunderbird kept crashing for me every time i try to sign an email but i have no problems with neomutt.
I can't speak for all orgs but at the end of the day, the only metric that my org cares about is how AI is improving our work. Holding the line for quality is definitely a good thing, but when your org doesn't care about the pressure on PR reviewers, and the effort it took to fix those PR mistakes or their repeat, those reviews are only helping the loop case and that AI is without flaws. I am not saying AI is a bad thing all together, but when the org ignores those metrics, I am only contributing and helping to prove that the other side is right.