From a non-technical user’s pov kinda true.

But not true at all when you enumerate the actual responsibilities of an OS.

The terminal

Not really. Today at work that error appeared to me. As a software developer of course I have access to terminal, I use it every day.

I just closed the message and opened the terminal again, and it worked.

This is Microsoft’s fault, not any other’s.

Is there anything in the LLMs code preventing it from emitting copyrighted code? Nobody outside LLM companies know, but I’m willing to bet there isn’t.

Therefore, LLMs DO emit copyrighted code. Due to them being trained on copyrighted code and the statistical nature of LLMs.

Does the LLM tell its users that the code it outputted has copyright? I’m not aware of any instance of that happening. In fact, LLMs are probably programmed to not put a copyright header at the start of files, even if the code it “learnt” from had them. So in the literal sense, it is stripping the code of copyright notices.

Does the justice system prosecute LLMs for outputting copyrighted code? No it doesn’t.

I don’t know what definition you use for “strip X of copyright” but I’d say if you can copy something openly and nobody does anything against it, you are stripping it’s copyright.

No you can’t. In the same way you can’t watch a Mickey mouse movie and then draw your own Mickey mouse from what you recall from the movie.

Copying can be done manually by memory, it doesn’t need to be a 1:1 match. Otherwise you could take a GPL licensed file, change the name of 1 variable, and make it proprietary code.

LLMs are just fancy lossy compression algorithms you can interact with. If I save a Netflix series in my hard drive, then re encode it, it is still protected by copyright, even if the bytes don’t match.

Logs’ purpose is to tell you what actually happened in the system. I don’t think it is a good idea to use something that “hallucinates” to tell you what really happened.

Generally agree. Except:

Logs that are a “debug diary” are not useless. Their purpose is to debug. That’s why there’s log levels. If you are not interested in that, filter by log levels above debug.

Also, the different formats for fields I see as a necessary evil. Generally, more logs (of verbose log levels) = more good. Which means that there should be as frictionless to write as possible. Forcing a specific format just means that there will be less logs being written.

The json (or any other consistent format) logs seem to be a good idea, but I would keep it to a single debug level (maybe info+error?). So if you want to get wide events, you filter by these log levels to get the full compact picture. But if you are following a debug log chain, it seems a pain to have to search for the “message” field on a potentially order-independent format instead of just reading the log.

TL;DR

Log levels have different purposes, and so they should have different requirements.

Someone on Microsoft probably needed an excuse for their pay increase.

“I rebuilt/had the idea to rebuilt the taskbar” sounds a lot better to managers than “I maintained the taskbar”.

In my case, I don’t usually encounter cases where I can’t just ?. But when I do, just make an error enum (kinda like thiserror) that encapsulates the possible errors + possibly adds more.

On the call site, just convert to string if I don’t care about specifics (anyhow-style).

I don’t find this much painful.

Concise: not much on the declaration side, since you have to create an entire enum for each function in worst-case scenario. But on code side, it’s just .map_err(MyError)?.

Type-safe: can’t beat errors as enum values wrapped in Result.

Composable: i don’t think you can beat rust enums in composability.

I don’t use anyhow/thiserror, so I’m not sure. But I believe thiserror fixes the conciseness issue for this.

“not having mandatory parenthesis in if statements is hazardous, so I prefer to write C instead of rust, because I really care about safety” < that’s how you sound.

Rust allows you to choose whatever method you want.

• Early return propagating the error
• Early return ignoring the error (maybe by returning a default value)
• Explicit handling by if-else (or match) to distinguish between error and not error cases.
• Early return and turn the error into another type that is easier to handle by the caller.
• Assume there is no error, and just panic if there is. (.unwrap)

There are only 2 error handling methods that you cannot do:

• Exceptions
• Ignore the error and continue execution

And that is because both of them are bad because they allow you to do the second one, when .unwrap is just there and better.

If your concept of “not ugly” is “I just want to see the happy path” then you either write bad code that is “not ugly” or write good code that is “ugly”. Because there is no language that allows you to handle errors while not having error handling code near where the errors are produced.

Most of the times you can just let ... else (which is basically a custom ? if you need if let ... else it’s because you actually need 2 branching code paths. In any other language you also do if ... else when you have 2 different code branches. I don’t see why this is a rust-specific issue.

I’d say it’s much more influential the names of the identifiers of the standard library.

A language with function keyword that names it’s stdlib functions strstr and strtok will inspire way worse naming than on that has fn keyword with stdlib functions str::contains and str::split.

We could search for a random crate on crates.io and see what identifiers people actually use, or we could spread misinformation on Lemmy.

You used macro_rules, which is not common at all. Most rust files don’t contain any macro definition.

This code doesn’t even compile. There is a random function definition, and then there are loose statements not inside any code block.

The loop is also annotated, which is not common at all, and when loops are annotated it’s a blessing for readability. Additionally, the loop (+annotation) is indented for some reason.

And the loop doesn’t contain any codeblock. Just an opening bracket.

Also, the function definition contains a lifetime annotation. While they are not uncommon, I wouldn’t say the average rust function contains them. Of course their frequency changes a lot depending on context, but in my experience most functions I write/read don’t have lifetime annotations at all.

Yes, what you wrote somewhat resembles rust. But it is in no way average rust code.

Not to be confused with glibc. Where the g does actually stand for gnu.

One of the techniques I’ve seen it’s like a “password”. So for example if you write a lot the phrase “aunt bridge sold the orangutan potatoes” and then a bunch of nonsense after that, then you’re likely the only source of that phrase. So it learns that after that phrase, it has to write nonsense.

I don’t see how this would be very useful, since then it wouldn’t say the phrase in the first place, so the poison wouldn’t be triggered.

EDIT: maybe it could be like a building process. You have to also put “aunt bridge” together many times, then “bridge sold” and so on, so every time it writes “aunt”, it has a chance to fall into the next trap, untill it reaches absolute nonsense.

the shape of the gap is almost the same as the peak in “other”. So that peak is probably “windows but we messed up with data collection” or “some browser in windows changed its user agent”.

How dare they collect data and display it in an accurate manner! They should just start by putting Linux at 50% and then move the lines a little bit.

But they can’t say “I’m going to rewrite this in that other language” because that’s the thing they hate about rust, so if they said that it would be too obvious that they’re full of shit.

Any body could just go to down detector. And of course effectively check the status of cloud flare based on if downdetector shows this page themselves.