If I can get in once, I can do it again an hour later. I'd be inclined to believe that dumb recycling is not very effective against a persistent attacker.
I wonder if a crypto miner like this was a person doing the work, or just an automated thing someone wrote to scan IPs for known vulnerabilities and exploit them automatically.
Mhm, this is one of these cases I'd prefer a benchmark to be sure. Checking %2 is very performant and actually just a single bit check. I can also imagine some cpu's having a special code path for %3. In practice I would not be surprised that the double operand is actually faster than the %6. I am mobile at this moment, so not able to verify.
is_divisible_by_6(int):
test dil, 1
jne .LBB0_1
imul eax, edi, -1431655765
add eax, 715827882
cmp eax, 1431655765
setb al
ret
.LBB0_1:
xor eax, eax
ret
is_divisible_by_6_optimal(int):
imul eax, edi, -1431655765
add eax, 715827882
ror eax
cmp eax, 715827883
setb al
ret
By themselves, the mod 6 and mod 3 operations are almost identical -- in both cases the compiler used the reciprocal trick to transform the modulo into an imul+add+cmp, the only practical difference being that the %6 has one extra bit shift.
But note the branch in the first function! The original code uses the && operator, which is short-circuiting -- so from the compiler's perspective, perhaps the programmer expects that x % 2 will usually be false, and so we can skip the expensive 3 most of the time. The "suboptimal" version is potentially quite a bit faster in the best case, but also potentially quite a bit slower in the worst case (since that branch could be mispredicted). There's not really a way for the compiler to know which version is "better" without more context, so deferring to "what the programmer wrote" makes sense.
That being said, I don't know that this is really a case of "the compiler knows best" rather than just not having that kind of optimization implemented. If we write 'x % 6 && x % 3', the compiler pointlessly generates both operations. And GCC generates branchless code for 'is_divisible_by_6', which is just worse than 'is_divisible_by_6_optimal' in all cases.
What I really don't like about thread/matter is that it is becoming the de-facto standard that thread border routers are connected to the internet.
This will in time result in IoT devices that actually mandate this connection (it was already stipulated in a recent version of the protocol). The end result will be that a new protocol was created, but rather than devices being able to run on their own, we end up with beds in heating mode, ie. the garbage we were trying to avoid in the first place.
A lot of zigbee infrastructure also expect an internet connection.
These border routers also double as admins, and people want their smart home stuff to be available while they are outside their home network.
Thread devices can mandate internet connectivity the same way Wifi devices can.
Matter defines profiles and does certification that says your light bulbs cannot require an internet connection. The admin your water leak detector connects into can (and arguably should) alert you even when you are away from home, but the leak detector _itself_ cannot do that and be certified.
> A lot of zigbee infrastructure also expect an internet connection.
Like what. I have several hundred zigbee devices of almost all category you can think of, and I have never come across such a requirement. I don't understand how that would even work.
It would be interesting to see a JDK happen where all these backwards compatibility quirks are ignored, and raw performance is chased instead. A thousand of these little gains can really add up over decades. In this case there was a workaround it seems, but it feels a bit contrived to me ('missing fields are ok'?).
> but it feels a bit contrived to me ('missing fields are ok'?)
IIUC, the idea is that an object can be safely deserialized if its field set upon deserialization is a strict subset of its field set upon serialization. I think that's a sound approach, it's in line with (the second part of) the robustness principle: "be liberal in what you accept".
The moment you put TOTP in Bitwarden it is no longer a 'second factor'. Pretty bad security advice to be honest. Better to use hardware tokens or a secure phone (with enclave) instead (never SMS though).
In most cases a true second factor isn't really what any involved party cares about.
My bank (I mean, they use SMS, but pretend they use TOTP) just care about not having to spend money on support because I used "password1!" as my password for every account and lose all my money.
I just want to log in to my bank.
If I've got a long, random, unique, securely-stored password, I don't actually care about having a second factor, I'm just enabling TOTP so that I don't have to copy/paste codes from my email or phone.
> If I've got a long, random, unique, securely-stored password, I don't actually care about having a second factor
I'm not comfortable with my entire online identity being protected by a single line of defence which is a company that I'm paying a few dollars a month to. Not having to type 6 digits off a phone is a pretty minor convenience for me.
Do you then avoid syncing any passwords to your phone to avoid having your two factors in the same place? (And similarly, avoid syncing SMS to any devices where you do have passwords.)
I'm not the OP, but for me their comment sparked an association to the famous Ken Thompson lecture called 'Trusting Trust'. Could be a good starting point.
I've wanted to switch to nftables on some of my systems but found that some software or other depended on iptables (e.g. Docker Engine, Proxmox). Use nftables if you can get away with it but iptables-specific knowledge is still extremely relevant.
For the most part iptables is no more, iptables tools are now just wrappers to nftables. Technically you can still write iptables rules, and they will show up in nftables. Wouldnt recommend long term but its a good way to see the translation
> If someone doesn’t know iptables, they probably are not required to know it.
That makes no sense. Just because I do not know X, it does not necessarily follow that I am not required to know it, not at all. I might need it for my job, or my future job. I might need it for a Linux distribution I just installed, and so forth. Or perhaps I am already using iptables, but I do not know it.
Ahhhhhh at least an understanding that it exists and how it might interact with nft is probably beneficial unless they’re expecting to only ever work on greenfield equipment. If you were to walk into a job with existing IT infrastructure, there’s a solid chance that you’ll encounter iptables. If you’re looking to do a deep dive into something and learn it well, definitely nft is the way to go but being able to tweak iptables configs without needing to start over with a clean nft slate is valuable.
To your C++03 analogy, I wouldn’t recommend learning C++03, but I also wouldn’t recommend solely learning C++23 either. C++20 and 23 have some really cool stuff in them that can definitely make your code cleaner, but there’s a lot of codebases that are stuck on older versions (at $JOB one of our target platforms is stuck on C++17 and will never get an upgrade so we can’t move the codebase forward until we abandon that kit).
If the person in question has never had the need to know iptables, why would that change now?
If a job will require such knowledge, they will pick it up. Iptables is exposed as a facade to nftables, lots of the concepts just transfer over, just that iptables is the more antiquated option.
I for instance have never really used iptables in anger, but have lots of experience with nftables and pf. I’ve used both in a professional setting. People can be made aware of iptables, but unless there’s a need to know it, I wouldn’t recommend picking it up now. And you’ll know if you need to learn c++17 or iptables, or python 2.7.
For more context, I've been working pretty closely with firewalls on all desktop platforms, and I've been doing so since 2018, and I've never had know about iptables on Linux.
If you want lots of differently styled templates, template management and editing/styling capabilites in word or excel (ie. you can just ask your customer/employer/.. to make an example document), I can really recommend Carbone [0]. I've been a happy customer for a few years now. Extra advantage is also that it also offers you excel outout generation as well, which is also often a requirement in applications. They have a SaaS offering as well if you'd like. They are open source though, so you can easily run a docker container!
Saying the internet is not a place for children is like saying the street is not for children. Full of drug dealers, cars and danger!
Yet learning how to cross the street is an essential skill in life. They are also filled with flowers, pathways to playgrounds and much more. And that's why children are not forbidden on the streets.
My point being: let's educate instead of regulate. "Regulating the children" is silly and countereffective.
Are you going to drop off your children at the bar and let them mingle? The internet is filled with huge variety of adult personalities and intentions, some of which are harmful & malicious, or just plain brain numbing.
reply