> German has to be used if a single German employee wants that.
I'm not sure about this statement. See [1]:
"The Regional Labor Court (Landesarbeitsgericht - LAG) of Nuremberg had to rule on a motion by a works council, in which the latter demanded that the discussions held with it be conducted only in German. At the same time, it demanded that all communication between the branch management and the employees be conducted in German. The Regional Court rejected both motions of the works council."
Yes, but translation must be provided when requested.
"Contrary to the view of the works council, communication in English is also not an obstruction of the works council. The court explained that it is crucial how the works council receives the communication. In the disputed case, texts were previously translated into the German language. Face-to-face conversations were translated by those present into German or into English for the branch manager. This was not objectionable, since the risk of a wrong translation was at the expense of the employer."
I think I understand what const generics are. But I fail to see a use case for it, other than using them in array literals and abstractions over arrays.
In the graphics programming I've done as a hobby, if I have a struct that contains a buffer for an image (say 1024px x 1024px = a buffer array of length 1048576), and have functions that operate on that buffer, etc, I either have to:
1) Create a Vec (separate allocation)
2) Make 1024 or 1048576 a global constant that every relevant struct and function references directly (whole program must use the same size at once; forget about exposing it as a library)
With const generics I can make all that code generic over the buffer resolution, meaning I can trivially use multiple different versions within the same build, without doing extra allocations, and I could even expose that code as a library for others to use at whatever resolution they wish
This is, literally, the exact same reason I use const generics. I was so excited when I started using them on Rust beta and could shave off some allocations!
I'm allocating a megabyte inline. I can put the containing struct on the heap if I need to (I may be doing that; can't remember), but I don't want that to be the concern of the struct itself.
For example: what if I decide at some point to create a Vec of this struct? I don't want each of those elements then also putting their internal buffers into separate allocations on the heap, when the Vec itself is already on the heap. I want the struct to be as "flat" as possible, and to only allocate for the sake of the stack as a final step when the use-case demands it
In emulators I often have to implement various FIFOs with a fixed word size (8 bits, 16bits, 32bits etc...) and depth (16, 32 or 64 elements etc...).
I could very easily make the word size generic, but not the depth. So I either had to make the depth dynamic (pretty expensive if you have hundreds of thousands of FIFO operations per second) or hack around it somehow.
Now I can just make the depth a generic parameter.
You can also abuse these types of generics to force the compiler to generate specialized versions of some methods in order to get better performance (at the cost of binary size) without having to manually create a bunch of variants of the same code.
Not OP, but my use case is serializing an array. Implementations were provided by the library for serializing arrays of `T` for lengths 0 through 31. I had an array of `[T; 32]`, so i couldn't serialize my array.
With const generics, the library provided implementations for all `[T; N]`, so my code worked out of the box with no headache.
Well, array literals are very convenient in some areas.
Matrix types can be cleaned up across projects, one widespread area being 3d graphics. Previously, you either had to create a separate type for each matrix size, or use a backing vector (of vectors); the first solution is ugly (because of redundancy), the second is potentially underperformant (in cases where one wants to avoid dynamic allocations as much as possible).
> Unfortunately this has a serious downside: asyncio locks are associated with the loop where they were created. Since the lock variable is global, maybe_initialize() can only be called from the same loop that loaded the module. asyncio.run() creates a new loop so it’s incompatible.
I work on several async projects, but I never had to use multiple event loops. What are use cases for using multiple event loops?
There may be other use cases, but it can be a useful pattern for mixing async code into a non-async project. In the specific places where using async for some task makes sense, you would just spawn a thread with an event loop, then push work into the new loop from non-async code using run_coroutine_threadsafe.
There is another interesting section in the document[1]. The city introduces the "Munich Open Source Sabatical". The city will pay professional programmers for 3 till 6 months to work on open source projects that benefit the community.
> Die Stadt München unterstützt die Entwicklung von Open Source-Projekten mit einem "Munich Open Source Sabbatical". Professionelle Programmierer*innen, die sich für drei oder sechs Monate ganz auf die Fortentwicklung eines Open Source-Projektes kon-zentrieren möchten, können sich dafür auf ein städtisches bezahltes Stipendium bewerben. Die Projekte müssen einen kommunalen Nutzen haben.
The document doesn’t say how much. I guess, it’s just an umbrella document. More detailed regulations will be eventually adopted. That said, my estimate would be 500€ max per month.
that would not work. 500€ is not enough to pay rent in most places.
it would have to something that covers your current living expenses, no matter how high they are, because unless you are young and single with a lot of flexibility, you are not going to be able to put a hold on all those expenses.
therefore the two reasonable options are: the government continues to pay your current salary, or it pays what you'd get if they'd hire you. the latter would disadvantage high earners, but that is somewhat reasonable.
anything less would unlikely get any people interested.
Im assuming that by "only" you mean there's limited impact. However, if the malicious package steals user keys, the harm can spread to the packages that may have received way more downloads.
> DO NOT. Ever. Buy. A smart lock. You’re better off with the “dumb” ones with keys.
Well, physical locks are not necessary harder to pick lock than electronic locks. Buy your self a pick lock set, practice a bit and be amazed how many locks you can pick.
The same rule applies to smart locks as applies to dumb locks: A lock does no more than keep an honest man, honest.
Any monkey can buy lock picks and pick a door lock. It's not hard. Generally if you buy a decent rake, it'll open most locks quickly. It's arguably much more work to hack the _smart_ side of a lock than it is to just pick the _dumb_ part.
The caveat here is that smart locks are often "picked" en masse - once you break one in a lab, you can immediately and silently do the same to the rest globally. This is similar to software hacking.
The guidance here should be to only purchase smart locks from vendors that you can trust to patch zero-days quickly. How you qualify a vendor as such is a mystery - I don't know that there's been enough zero days on smart locks to verify.
LPL is an amazing lock picker, anyone with this level of skill is much better off working as a locksmith or a security consultant.
Most B&E’s aren’t exactly executed by master thieves they aren’t single pin picking your locks.
When selecting a door lock or a pad lock you should care only that it can be raked or bypassed, for bike locks you should also care that it can’t be easily cut.
For the most part your door is likely going to be the weakest link as most people don’t have reinforced doors and door frames.
I happen to like a challenge, and I can say through experience that picking any modern reasonably priced lock is not something you learn in a week. Besides, the vast majority of burglars do not pick locks - they pry open doors or windows, and if they cannot they either find a different house or break a window.
LPL is one of the best pickers in the world. He's one of about 10 people I know of who's ever picked a Mul-T-Lock MT5+, for example. His picking attacks are by no means typical. He also practices picking each lock before making the pick on video. That makes for better (faster) video, but is less real-world. Bosnianbill does more real-world style picking (and is only very slightly behind LPL in skill).
LPL's real good videos are his physical attacks. Whether it's twisting, core pulling, or breaking out the Ramset, all are more likely than a criminal trying to SPP a lock.
Lockpickinglawyer is an absolute expert in his field though.
There's a difference between using a lock that requires an expert to pick, vs a smart lock that requires an expert to write an app that anyone can use to hack the lock.
One of the problems with many "smart" locks is that they tend to be made by people that don't have a lot of experience making locks. Many smart locks are vulnerable to many types of physical attack, including very old exploits that most locks (even many cheap locks) defend against.
For example, here[1] is a "keyless bluetooth padlock" that can be opened trivially by rapping the locking pall with any hammar-like tool ("rock"). (it also has far too much around the shackle, so can also be opened with a a simple shim (e.g. a small cutout from a cola can). Another common problem are locks that don't seal their electronics securely, so they can be attacked by simply unscrewing a panel, ripping out the electronics. and touching the battery wires to the locking pal's actuator.
However, that type of problem are simply poor designs. In theory, in the future better designs could be made that include protections against well-known attack methods similar to what is already included in many "regular" locks.
A fundamental concern with locks that depend on radio (or worse, the internet) is what the lock does when when the radio/internet communication fails (for any reason). Does the lock fail-open, or fail-closed[2]? Did the lock even address this important question? Does the lock open if someone unplugs the router? Or does it trap people behind the lock if a fire destroys the cable/DSL modem? Physical locks also have failure-mode concerns, but they tend to be limited to something happening locally, With "smart" devices, you are adding remote resources (like the internet router in another room, or remote servers, etc) as a critical component of the lock's security. That is a terrible idea if you that remote resource is intrinsically outside your control.
There are limits to how secure your house can (should) be without violating fire regulations (if applicable) - or safety.
If there's a fire or medical emergency (heart attack, allergic reaction/anaphylactic shock etc) - you generally don't want it to be too hard to break in...
The lock is only as good as the door it's attached to.. and the doors in a lot of new construction (especially in suburban McMansions) is really bad. You could probably kick most of 'em in.
Agreed. I've also learned the hard way that a heavy boot kicks through a door and windows are made of this easy to break material. Given access and time/privacy, there aren't many things that are secure from people that want inside.
Very interesting write up! But how likely is it to have control over the DNS-server someone uses? You either need to setup a malicious one and let the victim use your server. Or you've to hack the DNS-server the victim already is using.
This attack doesn't need control over the victim's DNS server. It uses attacker-controlled domain names to access private IPs via XHR. The DNS rebinding bypasses the standard CORS protection (without this protection the attacker could've used the IP directly). This attack is very easy to protect against (validate the Host header), but lots of IOT devices don't do this.
It is pretty easy to setup if you know the basic of administrating a GNU/Linux or BSD machine. It is better if you also know a bit about security on those system too (at least how to configure the firewall).
When it come to the legal part, it depends.
Being a exit-node can be very tricky. In some country, you will have to register has a telecommunication provider in order not to be considered liable for whatever comes out of your relay.
Being a guard-node (the "entry" node for tor client) is usually safe but can still create some trouble. For example, the virus WannaCry was using Tor to connect to its C&C servers.
Due to this, some Tor guard node got seized by the French police because they saw WannaCry connect to the IP of those guard node and I guessed, decided that it was necessary to seize them for their investigations ...
But you can configure your node to never be chosen has a guard node and to be just a relay and not a exit node. The node will be the middle man between a guard and a exit node and that should be completely safe, unless you live in a country where technology to circumvent censorship are prohibited.
A TOR relay is pretty safe. You're just a middle-man and have no clue about what's going on.
Your IP is still going into every single blacklist of corporate gateways though (because F5, etc. don't care): so don't host multiple services on that IP/server.
An exit node is the most dangerous position to be in, because that's were all the bad stuff can be seen.
The GP didn't necessarily say he was running an exit relay, only that he was running a relay of some kind. As far as I know it's a lot less perilous to run a middle relay.
I'm not sure about this statement. See [1]:
"The Regional Labor Court (Landesarbeitsgericht - LAG) of Nuremberg had to rule on a motion by a works council, in which the latter demanded that the discussions held with it be conducted only in German. At the same time, it demanded that all communication between the branch management and the employees be conducted in German. The Regional Court rejected both motions of the works council."
[1]: https://www.heuking.de/en/news-events/newsletter-articles/de...