The problem is - users pay for Windows only once

That is not in the slightest true. They pay once per computer. And people go through multiple computers in their lifetime. So it is not at all tied to birthrate.

Very few people buy licenses directly. Most people buy it pre-installed with an OEM license that is tied to that computer.

Think it is an old blackarch logo - an arch based pentesting distro.

Yes magnets can affect HDDs. But it needs to be very strong and close to the HDD. I wouldn't worry unless you are directly attaching it to you HDD and even then it probably won't do much if anything at all.

Remember HDDs already have strong permanent magnets inside them. Probably way stronger then the one on the bottom of that support.

What is wrong with a file for this? Sounds more like a local log or debug output that a single thread in a single process would be creating. A file is fine for high volume append only data like this. The only big issue is the format of that data.

What benefit would a database bring here?

That is the type of thinking that causes a massive amount of CVEs in those languages.

Tldr; their flagship goals are:

2024 edition: (1) supporting -> impl Trait and async fn in traits by aligning capture behavior; (2) permitting (async) generators to be added in the future by reserving the gen keyword; and (3) altering fallback for the ! type.

Async: support for async closures and Send bounds.

Rust in the Linux kernel: focus on the unstable features it uses so it can progress out of the experimental phase.

And highlights other goals:

• Stabilize cargo-script
• Improving Rust's borrow checker to support conditional returns and other patterns
• Move parallel front end closer to stability
• Ergonomic ref counting
• Implementing "merged doctests"

With a link to a list of 23 other goals

This is an absolute terrible post :/ I cannot believe he thinks that is a good argument at all. It basically boils down to:

Here is a new feature modern languages are starting to adopt.

You might thing that is a good thing. Lists various reasonable reasons it might be a good thing.

The question is: Whose job is it to manage that risk? Is it the language’s job? Or is it the programmer’s job?

And then moves on to the next thing in the same pattern. He lists loads of reasonable reasons you might want the feature gives no reasons you would not want it and but says everything in a way to lead you into thinking you are wrong to think you want these new features while his only true arguments are why you do want them...

It makes no sense.

I fundamentally disagree with pseudocode and all the arguments made out on this um, paper? It is written by a educator who has seen lots of shitty unreadable student code which is about the only time pseudocode makes sense to write. But even then, if they cannot form what they want in code what makes making them form what they want in words any better?

But spending ten minutes to think out carefully the pros and cons of different approaches to the goal can save you hours of time debugging and refactoring your code later on.

I find the opposite. Spending time writing pseudocode leads to far more time wasting on things that don't work. One of the biggest problems with pseudocode is YOU CANNOT RUN THE CODE. Not until you have fully finished thinking about it and then converted it to actual code. Only then can you tell if the code even does what you want. No, far better to write a small segment of code and then incrementally build and test it little by little. Then I can verify my ideas are taking me in the right direction and not resulting in some weird behavior due to some broken assumption I made early on.

Incremental development is the way to go. Just test things as you write them. Don't write the whole program (and then rewrite it again in an actual language) before you ever even run it. Write a small bit, test it, refactor and continue. You cannot do that with pseudocode and it is vastly harder to debug something that is complete rather than incrementally checking it at every stage as you progress.

Pseudocode makes low-level design reviews easier and reduces the need to review the code itself.

No, no it does not. You NEED to review the source code to see if it does what the person thought it would do. This step cannot be skipped. So what value does pseudocode add then? The code should be readable enough on its own without basically doubling the amount of lines you need to read. Plus NO ONE READS COMMENTS. This comes from 15+ years in the industry. More often then not I see comments that are out of date and no longer describe the code they are talking about. It is a lot of effort to keep comments in sync with code and not worth the effort. There should be no pseudocode comments in your code at the review stage.

Pseudocode supports the idea of iterative refinement

Iterative refinement is vastly better when you get feedback on what you have written. The best place to get that is to run the code and see what it does (either manually or via testing). You cannot do that with pseudocode. Only hope that you can spot a problem, which more often then not you will not. If you write actual code you can run it and see if it fails and how it fails.

Pseudocode makes changes easier. A few lines of pseudocode are easier to change than a page of code

That is a false comparison, why would you only have a few lines of pseudocode and a whole page of code? Surely your psudocode will roughly match the number of lines of actual code? Otherwise what is the point in it and how will it help you spot any problems? You can always write real code as a series of function calls to hide away the implementations if you want a similar approach.

Pseudocode minimizes commenting effort

Not writing comments minimizes commenting effort. Comments should be used sparingly to describe things that cannot be describe in code. IMO the only comments worth while (at least ones that are not doc blocks) are ones that describe external factors. Like "this is to work around this bug ". Or "we tried the more obvious solution here X but found it caused problems Y" or "this is actually required due to this weird undocumented behavior". Comments that just describe the code are a waste of time and effort as you now have your code defined twice. Once where people will read in the actual code and once where people will ignore and will slowly rot and worst start to lie. The number of times I have seen a comment contradict the code and have no clue if the code or the comment is right... More often it is the code that is write and the comment is hideously out of date. That just becomes wasted effort trying to figure things out.

With other approaches, design is separated from the code, and when one changes, the two fall out of agreement... As long as the inline comments are maintained, the pseudocode’s documentation of the design will be accurate.

That is a big if there, IF they get maintained. Which they wont. It is far too much effort to edit the code twice. No one wants to do that and so no one does do that. Just read the code if you want to know what the code is doing and reject PRs for code the is unreadable.

The only people I ever see arguing for psudocode are professors that have never worked in the industry and spend far more time reading crappy students code than anything else. I have never seen anyone actually do this in production systems.

So, if you just use the system API, then this means logging with syslog(3). Learn how to use it.

This is old advice. These days just log to stdout, no need for your process to understand syslog, systemd, containers and modern systems just capture stdout and forward that where it needs to do. Then all applications can be simple and it us up to the system to handle them in a consistent way.

NOTICE level: this will certainly be the level at which the program will run when in production

I have never see anyone use this log level ever. Most use or default to Info or Warn. Even the author later says

I run my server code at level INFO usually, but my desktop programs run at level DEBUG.

If your message uses a special charset or even UTF-8, it might not render correctly at the end, but worst it could be corrupted in transit and become unreadable.

I don't know if this is true anymore. UTF-8 is ubiquitous these days and I would be surprised if any logging system could not handle it, or at least any modern one. I am very tempted to start adding some emoji to my logs to find out though.

User 54543 successfully registered e-mail user@domain.com

Now that is a big no no. Never ever log PII data if you don't want a world of hurt later on.

2013-01-12 17:49:37,656 [T1] INFO c.d.g.UserRequest User plays {'user':1334563, 'card':'4 of spade', 'game':23425656}

I do not like that at all. The message should not contain json. Most logging libraries let you add context in a consistent way and can output the whole log line in Json. Having escaped json in json because you decided to add json manually is a pain, just use the tools you are given properly.

Add timestamps either in UTC or local time plus offset

Never log in local time. DST fucks shit up when you do that. Use UTC for everything and convert when displayed if needed, but always store dates in UTC.

Think of Your Audience

Very much this. I have seen far too many error message that give fuck all context to the problem and require diving through source code to figure out the hell went wrong. Think about how logs will be read without the context of the source code at hand.

“We found that adults with hearing loss who regularly used hearing aids had a 24% lower risk of mortality than those who never wore them,” said Janet Choi, MD, MPH, an otolaryngologist with Keck Medicine and lead researcher of the study. “These results are exciting because they suggest that hearing aids may play a protective role in people’s health and prevent early death.”

While the study did not examine why hearing aids may help those who need them live longer, Choi points to recent research linking hearing aid use with lowered levels of depression and dementia. She speculates that the improvements in mental health and cognition that come with improved hearing can promote better overall health, which may improve life span.

This is the classic causation vs correlation problem with these studies. I can also speculate: Did the hearing aid actually do anything at all - or do the people that go to the doctors for a hearing aid also go to the doctors for other problems they might have and so get more treatment for other conditions? That seems far more likely to have a bigger effect IMO.

I think you are mistaken - censorship is the goal, kids are the excuse. If they really cared about kids safety there is a lot more they could be doing to actually protect them.

Back when this statement was made - 11 years ago - nvidia were a lot worst, especially for the kernel developers. A lot has change, and improved in those 11 years.

But people still like to hang on to the old hate and don't see or want to see any progress being actually made. I an fairly sure that Linus even said they were not as bad as they used to be. But I cannot find that quote amongst all the results for that one angry statement he made - people and media much prefer to hate on things than actually see things improve.