fkn

A thousand novel mistakes.

The two cases, they knew what it was and they did it maliciously. They didn’t know what they were doing and got socially engineered in the process. Both cases are cause for failure.

Sure. But for an entry level interview as a pen tester… Scanning with Kali should be an easy task.

Using Kali? Easy if you have training. The capstone for our security course a decade ago was too find and exploit 5 remote machines (4 on the same network, 1 was on a second network only one of the machines had access to) in an hour with Kali. I found all 5 but could only exploit 3 of them. If I didn’t have to exploit any of them 7 would be reasonably easy to find.

Kali basically has a library of known exploits and you just run the scanner on a target.

This isn’t novel exploit discovery. This is “which of these 10 windows machines hasn’t been updated in 3 years?”

Win12 confirmed 2044 release date.

Win12 confirmed as a Linux mint cinnamon derivative distro.

I too have forgotten to memset my structs in c++ tensorflow after prototyping in python.

I don’t think either is actually true. I know many programmers who can fix a problem once the bug is identified but wouldn’t be able to find it themselves nor would they be able to determine if a bug is exploitable without significant coaching.

Exploit finding is a specific skill set that requires thinking about multiple levels of abstraction simultaneously (or intentionally methodically). I have found that most programmers simply don’t do this.

I think the definition of “good” comes into play here, because the vast majority of programmers need to dependably discover solutions to problems that other people find. Ingenuity and multilevel abstract thinking are not critically important and many of these engineers who reliably fix problems without hand holding are good engineers in my book.

I suppose that it could be argued that finding the source of a bug from a bug report requires detective skills, but even this is mostly guided inspection with modern tooling.

I… Mean… You obviously don’t, but whatever.

Sorry. I apologize.

It’s frustrating trying to explain the same thing over and over again…

The tokens are how drm works. The process of DRM is token validation and enforcement of intellectual property rights granted by tokens.

I don’t know how else to explain it. It feels like I am back at my original post. I don’t know if you understand any better or if you still have misconceptions about what NFTs are or what DRM is or if you still think there is some magic in NFTs.

Again, all of this already existed and will continue to exist with or without blockchain. There is very little novel in the implementation details of the tokens. The people who got the idea for "nft"s didn’t come up with a new idea. This isn’t some new math. The only portion of NFTs that is new is the cooperative signing… Which again, isn’t a new concept either.

Right now, everything you described… Literally all of it… Ubisoft implements for their launcher and enforce with their drm solution.

Nfts, digital tokens, already exist. Their use, in the protection of copyright, is called drm. “Nfts” bring nothing new to the table of digital rights or copyright… And a whole host of stupidity.

Without knowing the exact model it’s difficult to know for certain but you can buy off brand refill kits with chips. The printer may intentionally degrade quality with the aftermarket chips (and may never reset itself even if you return to official toner)… HP is just a terrible company.

This story is literally every experienced Linux users first horror story.

I still remember the first time I broke my xorg config on my shiny new slackware 10 install in early 2005.

Have LTS kernels started backporting non security fixes like this? To be fair I haven’t looked at this in over a decade but this kind of patch wouldn’t have been backported then.

This is one of those comments that causes Arch to get the reputation that it does. You aren’t wrong and you probably don’t intend to be off-putting but here we are.

Red Hat and Debian both backport security fixes but don’t backport things like laptop device support. It can take a year or more for versions of those distros to gain the kind of functionality that is looking for.

This is an excellent answer. My eli5 addition is this:

It depends on your distro. Distros that do more hand holding and more compatibility without additional operator involvement will be more likely to backport or use a stable kernel with backports like these. Examples: Ubuntu/Fedora/Mint. Distros that focus on system stability will take much longer to integrate backports like these, ex: Debian. And masochists will tell you to do it yourself, ex: lfs, arch.

You couldn’t pay me to use this…

You are making just such a weird argument and it sounds like you are retroactively trying to salvage a bad position because you made a mistake.

1. If you care strongly about audio quality. A built-in doesn't have any quality guarantees… why then does usb vs hat matter?

2. If quality is your concern why bring up price in the first part? It is blatantly obvious that cheap parts *might" equate to cheap quality. This is blatantly obvious.

3. Obviously there will be USB solutions that are equal or better solutions than prebuilt rpi dac hats since the primary dac hats are exceptionally niche.

This response just sounds like you got caught out in your mistake/bad argument. Why be a dick about it?