1,686,183 events recorded by gharchive.org of which 1,686,183 were push events containing 2,491,668 commit messages that amount to 182,550,823 characters filtered with words.py@e23d022007... to these 37 messages:
Merge branch 'main' of https://github.com/SeonminKim1/SMOPS
- 'main' of https://github.com/SeonminKim1/SMOPS: Delete Trash Files Fuck you Mac
Makes setting a machine GC properly if not unset properly (#17840)
-
Makes setting a machine GC properly if not unset properly
-
Forgot one. Fuck you borer code
[MDB IGNORE] The Tilening V2 - Damaged Tile Overlays Edition (#67761)
About The Pull Request
Hello once more! As we near summer, I continued to reminisce on several PRs done throughout last year! One of them was the controversial, but rather positive Tilening V1, as done by me and Twaticus a while back (#58932), and felt I could've done a better job with how it was presented.
And thus, thanks to @Fikou encouraging me with a very interesting find of a previous tile resprite attempt, I've successfully done it!
Ladies and Gentlemen, I present to you all, Tilening Version Two! image
Now this isn't your run of the mill tile resprite. While I did improve the appearance of several tiles I haven't touched last time (including the showroom/freezer tiles now), I decided to do something special that most mappers shall appreciate!
Don't you hate it when of all damaged states, there's only ones for grey tiles when we have white, black, terracotta and a bunch of other materials? Don't you wish they were overlays instead?
Well golly gee do I have good news for you! image image
After painstakingly spending at least several hours trying to learn enough code to pull it off, I have successfully made it so most tiles display transparent versions of damage overlays over them! This means mappers can express their creativity that much better! And thanks to how the code is written, its super easy to snowflake certain tile types to make them use unique damaged states (looking at you wooden tiles), so fret not in that aspect.
Credits to: @WJohn For actually making those damaged overlays! Wouldn't've done the PR if it wasn't for you. @dragomagol, @RigglePrime and @LemonInTheDark for helping me out in a VC at 10 PM to 12 AM troubleshooting the code to make this improvement work! Why It's Good For The Game
The shading is done better as compared to last time, making them feel more cubical and less like a pancake when seen from above! This PR also makes it so that we never ever have to touch damaged tiles ever again potentially, saving up some RSC regarding icons.
However, due to how damaged tiles are currently mapped in, rather than overlayed as I envision in the future, it'll require a PR by San to be merged later that should make it safe to remove these icons. Changelog
cl PositiveEntropy, WJohnston, Dragomagol, LemonInTheDark, Riggle imageadd: Resprites most variety of tiles into a better shaded version! code: Damaged floors are now damaged overlays, meaning that most tiles should properly display a damaged state! /cl
1.2
skills and such: revive interaction speed increase to 4.5s overkill aced duration increase to 12s to reduce weapon swap annoyance further inspire rework: get rid of ranged revive, instead separate the revive part of basic version into aced with 3x faster manual revive (results in 1.5s) -- kinda experimental so might get adjusted in the future
weapons: m1014 / predator touch-ups: pickup rate nerf, increase predator rof to benelli level, increase recoil even further frenchman revolver pickup adjusted to fit its damage class lmg touch ups: adjustments to new "lmg", increase horizontal recoil on all lmgs, decrease damage on 120dmg lmgs down to 100dmg, fix a stupid mistake increase damage on dmr kits to allow for ovka one shot heavy breakpoint
enemies: flashbang rework: 0.75s cook time, full vanilla flash effect strength, has a white glow enemy flash usage cooldown increased to compensate for their threat gas nade duration is now 45s instead of 40s increase damage falloff on enemy shotgunners decrease rate of fire on green dozers down to a max of 60rpm
Add files via upload
Those days, many boys use beautiful girls' photos as avatars in forums. So it is pretty hard to tell the gender of a user at the first glance. Last year, our hero went to a forum and had a nice chat with a beauty (he thought so). After that they talked very often and eventually they became a couple in the network.
But yesterday, he came to see "her" in the real world and found out "she" is actually a very strong man! Our hero is very sad and he is too tired to love again now. So he came up with a way to recognize users' genders by their user names.
This is his method: if the number of distinct characters in one's user name is odd, then he is a male, otherwise she is a female. You are given the string that denotes the user name, please help our hero to determine the gender of this user by his method.
Input The first line contains a non-empty string, that contains only lowercase English letters — the user name. This string contains at most 100 letters.
Output If it is a female by our hero's method, print "CHAT WITH HER!" (without the quotes), otherwise, print "IGNORE HIM!" (without the quotes).
Resonance cascade polishening, bugfixes and better logging (#67488)
This PR rewrites almost all messages related to cascade events. Some messages felt kinda clunky to read or could have been written better. Overall, the new messages add to the experience as a cascade being a terrifying event in a way that I felt the old ones missed, and they make the event feel overall a lot sharper.
While looking at the resonance cascade code, I noticed that there a lot of stuff about cascades in the air which was not touched on. So, as I do, this PR evolved into a polish and roundup PR for cascades. There was a lot of stuff still hanging out relating to the event, and although the big backend of it sits, there was still a bit left to be completed. Therefore this PR deserves more the title of the "Resonance cascade POLISHENING" instead of the "REFLAVAHRING". But yeah, you ever go on a massive tangent before?
regular expression generating sex cum download fuck you
Libro 6 - Unidad 1
Page 3
- What do you mean by merriment? Activities that are enjoyable or funny.
- What is the meaning of slate? Blackboard.
- What´s a resolution? A decision to do something or to behave in a certain manner.
- When is celebrated New Year´s Day? On January 1st.
- How do people celebrate New year´s Day? Usually with their families, involving traditions.
Page 4
- When is valentine´s Day? IT´S ON FEBRUARY 14TH.
- What do people do on that day? THEY GIVE CARDS, LETTERS, FLOWERS, OR PRESENTS.
- Who is Cupid? HE IS THE ROMAN GOD OF LOVE, COMMONLY REPRESENTED AS A WINGED, NAKED INFANT BOY WITH A BOW AND ARROWS.
- Can you write the common symbols of Valentine´s day? HEARTS, ROSES, AND CUPID.
- What is the meaning of winged? HAVING WINGS LIKE AN ANGEL.
Page 5
- What is Holy Week? Is the last week of lent and is the week before.
- What is Lent? The 40 weekdays from ash wednesday until Easter.
- What do Christians remember on Good Friday? We remember that Jesus died for everyone!
- What does Holy Thursday represent? The day that the Jewish Passover was celebrated.
- What do you do on Easter Sunday? The three days after being killed,Jesus rose from the dead.
Page 6
- When is Labor Day for American workers? The first Monday of September.
- When is Labor Day in your country? Is on May 1st.
- How is also known May Day? Labor Day or international Workers’ Day.
- What is a parade? To march or walk through or around a place.
- What is the meaning of worldwide? Involving the entire world, universal.
Page 7.
- What is celebrated on May 3rd? The Day of the cross.
- How do Mexicans celebrate that day? Each year on May 3rd processions of singing pilgrims carry flowers to decorate the crosses.
- When is Day of the Cross in El Salvador? It is on May 3rd.
- Do Guatemalas celebrate the Day of the Cross in the same date? Yes, they do, like many countries in Latin America. 5.What does the cross represents? The cross where Jesus was crucified.
Page 8
- When is Mother’s Day in your country? It is on May 10th.
- When is Mother’s Day in Canada? The second Sunday of May.
- Can you tell me one way to celebrate it? Giving cards, flowers, or cakes.
- Do Chinese celebrate Mother’s Day? Yes, they do
- When is Mother’s Day in Spain? The first Sunday of May.
Merge: Performance improvements.
This patchset brings some performance improvements and the addition of the LZO-RLE algorithm to the kernel, also usable in zram (yup, tested, works but LZ4 is still ok for us).
The main performance improvement is for SWAP space: the locking has changed and the swap cache is now split in 64MB trunks. This gives us a reduction of the median page fault latency of 375%, from 15uS to 4uS, and an improvement of 192% on the swap throughput (this includes "virtual" swap devices, like zRAM!). The real world user experience improvement of this on a mobile device is seen after a day or two of usage, where it usually starts losing just a little performance due to the large amount of apps kept open in background: now I cannot notice any more performance loss and the user experience is now basically the same as if the phone was in its first 2 hours of boot life.
Other performance improvements include, in short:
UDP v4/v6: 10% more performance on single RX queue
Userspace applications will be faster when checking running time of threads
2-5% improvements on heavy multipliers (yeah, not a lot, but was totally free...)
Improvements on rare conditions during sparsetruncate of about 0.3% to a
way more rare around 20% improvement (that's never gonna happen, but there
is no performance drop anywhere).
Tested on SoMC Tama Akatsuki RoW
This was taken from Repo: https://github.com/sonyxperiadev/kernel PR: 2039 ([2.3.2.r1.4] Performance improvements)
Signed-off-by: sweetyicecare [email protected] Signed-off-by: Aoihara [email protected] Signed-off-by: rk134 [email protected]
Adding article: Twelve members of a religious group in Toowoomba, Australia have been arrested after the death of an eight-year-old girl, who Queensland police say was allegedly denied life-saving medication in the belief she would be healed by God. (62c54608b562a6b99183f88d)
MGMT-10973: Enable DNS validations if coredns or keepalived static pod manifests in day-2 connectivity-check ignition
For context, this is a service-side follow-up to openshift/assisted-installer-agent#388
During day-2 installations, we want the service to optionally perform DNS validations when the worker attempts to join none-platform clusters.
When the cluster is imported via our .../v2/clusters/import endpoint,
we have no way to know whether that cluster is a none-platform cluster
or cluster with managed networking (e.g. baremetal), so we have no way
to know whether we should perform the DNS validation or not. We wouldn't
like to have that validation on all the time, because it's unnecessarily
annoying for clusters with managed networking.
As part of our existing API connectivity-check, the service asks the agent to download the worker.ign file from the to-be-joined-cluster's machine-config-server, then send that back to the service.
The contents of that file include information that will allow the service to make an educated guess about whether the ignition originated from a cluster with managed networking or not.
Also, a new "imported" column has been added to clusters, to indicate whether they were created through a conversion or through being imported. This is important because the solution should only be applied for imported clusters, and this will provide a good way to tell apart imported from non-imported clusters.
Also, the clusterdeployments_controller can now import SNO clusters, it was an oversight that should have been done as part of 4cda26533d377f453f68783e8b2eae438734555d (#3404)
The ignition files we currently look at are:
/etc/kubernetes/manifests/coredns.yaml
/etc/kubernetes/manifests/keepalived.yaml
This is a hack - since we have no official way to know whether a worker ignition file originated from a cluster with managed networking or not, we instead rely on the presence of coredns and keepalived pod manifests to indicate that. We only expect those to be present in clusters with managed networking. To be a bit more robust, the service will consider the presence of any one of them to mean that the cluster has managed networking. This gives us better forwards compatibility if one of them gets renamed / replaced with other technologies in future OCP versions.
Another way in which this is hacky is that users could manually create static pods with the same name as part of their machine-configs, in which case we would have a false-positive detection. But that is admittedly very unlikely.
Hopefully we can negotiate with the relevant OCP teams to have a more official, stable way to have this detection - like a magic empty file placed somewhere in the ignition that we can check for the presence of. Once we have such file, we can slowly deprecate this detection mechanism and fully move to the new one by inspecting that file instead.
Couldn't replicate issue in qemu even with 100 times as many iterations. But that's what I kinda expected, even though theoretically it probably should happen if it was just about speed. I just have a gut feeling that it's not just about speed, or at least doesn't scale linearly with speed. Also cleaned up register saving for assembly interrupt handler wrappers for interrupts that need that. (Wait -- am I right that I need it for irq0 and int 0x80, but not elsewhere? I obviously need it for any routine that might not return to userspace -- you have to just save first thing, because you won't be able to save later. My model was that as long as I'm 100% sure I will iretq (or go to waitloop and never need to restore what was happening), GCC knows what regsters it uses, and it saves and restores those. I think that's true, or I'd be having lots of issues even just in kernel space! So irq0 obviously needs it, as we might task switch (or just get some kernel work done). And int 0x80 needs it because we might pause the task and not iretq to it (like if we're waiting on input). So, yeah, I see why I do it for those two and not anything else. That definitely seems right to me.
Fix low priority issues (#7413)
Thanks @svetkereMS for bringing this up, driving, and testing.
This fixes two interconnected issues. First, if a process starts at normal priority then changes to low priority, it stays at normal priority. That's good for Visual Studio, which should stay at normal priority, but we relied on passing priority from a parent process to children, which is no longer valid. This ensures that we set the priority of a process early enough that we get the desired priority in worker nodes as well.
Second, if we were already connected to normal priority worker nodes, we could keep using them. This "shuts down" (disconnects—they may keep running if nodeReuse is true) worker nodes when the priority changes between build submissions.
One non-issue (therefore not fixed) is connecting to task hosts that are low priority. Tasks host nodes currently do not store their priority or node reuse. Node reuse makes sense because it's automatically off always for task hosts, at least currently. Not storing low priority sounds problematic, but it's actually fine because we make a task host—the right priority for this build, since we just made it—and connect to it. If we make a new build with different priority, we disconnect from all nodes, including task hosts. Since nodeReuse is always false, the task host dies, and we cannot reconnect to it even though if it didn't immediately die, we could, erroneously.
On the other hand, we went a little further and didn't even specify that task hosts should take the priority assigned to them as a command line argument. That has been changed.
svetkereMS had a chance to test some of this. He raised a couple potential issues:
conhost.exe launches as normal priority. Maybe some custom task dlls or other (Mef?) extensions will do something between MSBuild start time and when its priority is adjusted. Some vulnerability if MSBuild init code improperly accounts for timing For (1), how is conhost.exe related to MSBuild? It sounds like a command prompt thing. I don't know what Mef is. For (2), what vulnerability? Too many processes starting and connecting to task hosts with different priorities simultaneously? I could imagine that being a problem but don't think it's worth worrying about unless someone complains.
He also mentioned a potential optimization if the main node stays at normal priority. Rather than making a new set of nodes, the main node could change the priority of all its nodes to the desired priority. Then it can skip the handshake, and if it's still at normal priority, it may be able to both raise and lower the priority of its children. Since there would never be more than 2x the "right" number of nodes anyway, and I don't think people will be switching rapidly back and forth, I think maybe we should file that as an issue in the backlog and get to it if we have time but not worry about it right now.
Edit: I changed "shuts down...worker nodes when the priority changes" to just changing their priority. This does not work on linux or mac. However, Visual Studio does not run on linux or mac, and VS is the only currently known customer that runs in normal priority but may change between using worker nodes at normal priority or low priority. This approach is substantially more efficient than starting new nodes for every switch, disconnecting and reconnecting, or even maintaining two separate pools for different builds.
sched/core: Fix ttwu() race
Paul reported rcutorture occasionally hitting a NULL deref:
sched_ttwu_pending() ttwu_do_wakeup() check_preempt_curr() := check_preempt_wakeup() find_matching_se() is_same_group() if (se->cfs_rq == pse->cfs_rq) <-- BOOM
Debugging showed that this only appears to happen when we take the new code-path from commit:
2ebb17717550 ("sched/core: Offload wakee task activation if it the wakee is descheduling")
and only when @cpu == smp_processor_id(). Something which should not be possible, because p->on_cpu can only be true for remote tasks. Similarly, without the new code-path from commit:
c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu")
this would've unconditionally hit:
smp_cond_load_acquire(&p->on_cpu, !VAL);
and if: 'cpu == smp_processor_id() && p->on_cpu' is possible, this would result in an instant live-lock (with IRQs disabled), something that hasn't been reported.
The NULL deref can be explained however if the task_cpu(p) load at the beginning of try_to_wake_up() returns an old value, and this old value happens to be smp_processor_id(). Further assume that the p->on_cpu load accurately returns 1, it really is still running, just not here.
Then, when we enqueue the task locally, we can crash in exactly the observed manner because p->se.cfs_rq != rq->cfs_rq, because p's cfs_rq is from the wrong CPU, therefore we'll iterate into the non-existant parents and NULL deref.
The closest semi-plausible scenario I've managed to contrive is somewhat elaborate (then again, actual reproduction takes many CPU hours of rcutorture, so it can't be anything obvious):
X->cpu = 1
rq(1)->curr = X
CPU0 CPU1 CPU2
// switch away from X
LOCK rq(1)->lock
smp_mb__after_spinlock
dequeue_task(X)
X->on_rq = 9
switch_to(Z)
X->on_cpu = 0
UNLOCK rq(1)->lock
// migrate X to cpu 0
LOCK rq(1)->lock
dequeue_task(X)
set_task_cpu(X, 0)
X->cpu = 0
UNLOCK rq(1)->lock
LOCK rq(0)->lock
enqueue_task(X)
X->on_rq = 1
UNLOCK rq(0)->lock
// switch to X
LOCK rq(0)->lock
smp_mb__after_spinlock
switch_to(X)
X->on_cpu = 1
UNLOCK rq(0)->lock
// X goes sleep
X->state = TASK_UNINTERRUPTIBLE
smp_mb(); // wake X
ttwu()
LOCK X->pi_lock
smp_mb__after_spinlock
if (p->state)
cpu = X->cpu; // =? 1
smp_rmb()
// X calls schedule()
LOCK rq(0)->lock
smp_mb__after_spinlock
dequeue_task(X)
X->on_rq = 0
if (p->on_rq)
smp_rmb();
if (p->on_cpu && ttwu_queue_wakelist(..)) [*]
smp_cond_load_acquire(&p->on_cpu, !VAL)
cpu = select_task_rq(X, X->wake_cpu, ...)
if (X->cpu != cpu)
switch_to(Y)
X->on_cpu = 0
UNLOCK rq(0)->lock
However I'm having trouble convincing myself that's actually possible on x86_64 -- after all, every LOCK implies an smp_mb() there, so if ttwu observes ->state != RUNNING, it must also observe ->cpu != 1.
(Most of the previous ttwu() races were found on very large PowerPC)
Nevertheless, this fully explains the observed failure case.
Fix it by ordering the task_cpu(p) load after the p->on_cpu load, which is easy since nothing actually uses @cpu before this.
Fixes: c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") Reported-by: Paul E. McKenney [email protected] Tested-by: Paul E. McKenney [email protected] Signed-off-by: Peter Zijlstra (Intel) [email protected] Signed-off-by: Ingo Molnar [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Fiqri Ardyansyah [email protected]
FROMGIT: bpf: Do not change gso_size during bpf_skb_change_proto()
This is technically a backwards incompatible change in behaviour, but I'm going to argue that it is very unlikely to break things, and likely to fix far more then it breaks.
In no particular order, various reasons follow:
(a) I've long had a bug assigned to myself to debug a super rare kernel crash on Android Pixel phones which can (per stacktrace) be traced back to BPF clat IPv6 to IPv4 protocol conversion causing some sort of ugly failure much later on during transmit deep in the GSO engine, AFAICT precisely because of this change to gso_size, though I've never been able to manually reproduce it. I believe it may be related to the particular network offload support of attached USB ethernet dongle being used for tethering off of an IPv6-only cellular connection. The reason might be we end up with more segments than max permitted, or with a GSO packet with only one segment... (either way we break some assumption and hit a BUG_ON)
(b) There is no check that the gso_size is > 20 when reducing it by 20, so we might end up with a negative (or underflowing) gso_size or a gso_size of 0. This can't possibly be good. Indeed this is probably somehow exploitable (or at least can result in a kernel crash) by delivering crafted packets and perhaps triggering an infinite loop or a divide by zero... As a reminder: gso_size (MSS) is related to MTU, but not directly derived from it: gso_size/MSS may be significantly smaller then one would get by deriving from local MTU. And on some NICs (which do loose MTU checking on receive, it may even potentially be larger, for example my work pc with 1500 MTU can receive 1520 byte frames [and sometimes does due to bugs in a vendor plat46 implementation]). Indeed even just going from 21 to 1 is potentially problematic because it increases the number of segments by a factor of 21 (think DoS, or some other crash due to too many segments).
(c) It's always safe to not increase the gso_size, because it doesn't result in the max packet size increasing. So the skb_increase_gso_size() call was always unnecessary for correctness (and outright undesirable, see later). As such the only part which is potentially dangerous (ie. could cause backwards compatibility issues) is the removal of the skb_decrease_gso_size() call.
(d) If the packets are ultimately destined to the local device, then there is absolutely no benefit to playing around with gso_size. It only matters if the packets will egress the device. ie. we're either forwarding, or transmitting from the device.
(e) This logic only triggers for packets which are GSO. It does not trigger for skbs which are not GSO. It will not convert a non-GSO MTU sized packet into a GSO packet (and you don't even know what the MTU is, so you can't even fix it). As such your transmit path must already be able to handle an MTU 20 bytes larger then your receive path (for IPv4 to IPv6 translation) - and indeed 28 bytes larger due to IPv4 fragments. Thus removing the skb_decrease_gso_size() call doesn't actually increase the size of the packets your transmit side must be able to handle. ie. to handle non-GSO max-MTU packets, the IPv4/IPv6 device/ route MTUs must already be set correctly. Since for example with an IPv4 egress MTU of 1500, IPv4 to IPv6 translation will already build 1520 byte IPv6 frames, so you need a 1520 byte device MTU. This means if your IPv6 device's egress MTU is 1280, your IPv4 route must be 1260 (and actually 1252, because of the need to handle fragments). This is to handle normal non-GSO packets. Thus the reduction is simply not needed for GSO packets, because when they're correctly built, they will already be the right size.
(f) TSO/GSO should be able to exactly undo GRO: the number of packets (TCP segments) should not be modified, so that TCP's MSS counting works correctly (this matters for congestion control). If protocol conversion changes the gso_size, then the number of TCP segments may increase or decrease. Packet loss after protocol conversion can result in partial loss of MSS segments that the sender sent. How's the sending TCP stack going to react to receiving ACKs/SACKs in the middle of the segments it sent?
(g) skb_{decrease,increase}_gso_size() are already no-ops for GSO_BY_FRAGS case (besides triggering WARN_ON_ONCE). This means you already cannot guarantee that gso_size (and thus resulting packet MTU) is changed. ie. you must assume it won't be changed.
(h) changing gso_size is outright buggy for UDP GSO packets, where framing matters (I believe that's also the case for SCTP, but it's already excluded by [g]). So the only remaining case is TCP, which also doesn't want it (see [f]).
(i) see also the reasoning on the previous attempt at fixing this (commit fa7b83bf3b156c767f3e4a25bbf3817b08f3ff8e) which shows that the current behaviour causes TCP packet loss:
In the forwarding path GRO -> BPF 6 to 4 -> GSO for TCP traffic, the coalesced packet payload can be > MSS, but < MSS + 20.
bpf_skb_proto_6_to_4() will upgrade the MSS and it can be > the payload length. After then tcp_gso_segment checks for the payload length if it is <= MSS. The condition is causing the packet to be dropped.
tcp_gso_segment(): [...] mss = skb_shinfo(skb)->gso_size; if (unlikely(skb->len <= mss)) goto out; [...]
Thus changing the gso_size is simply a very bad idea. Increasing is unnecessary and buggy, and decreasing can go negative.
Fixes: 6578171a7ff0 ("bpf: add bpf_skb_change_proto helper") Signed-off-by: Maciej Żenczykowski [email protected] Signed-off-by: Daniel Borkmann [email protected] Cc: Dongseok Yi [email protected] Cc: Willem de Bruijn [email protected] Link: https://lore.kernel.org/bpf/CANP3RGfjLikQ6dg=YpBU0OeHvyv7JOki7CyOUS9modaXAi-9vQ@mail.gmail.com Link: https://lore.kernel.org/bpf/[email protected]
(cherry picked from commit 364745fbe981a4370f50274475da4675661104df https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=364745fbe981a4370f50274475da4675661104df ) Test: builds, TreeHugger Bug: 188690383 Signed-off-by: Maciej Żenczykowski [email protected] Change-Id: I0ef3174cbd3caaa42d5779334a9c0bfdc9ab81f5 Signed-off-by: pri0818 [email protected]
MGMT-10973: Copy coredns & keepalived static pod manifests in day-2 connectivity-check ignition (#388)
During day-2 installations, we want the service to optionally perform DNS validations when the worker attempts to join none-platform clusters.
When the cluster is imported via our .../v2/clusters/import endpoint,
we have no way to know whether that cluster is a none-platform cluster
or cluster with managed networking (e.g. baremetal), so we have no way
to know whether we should perform the DNS validation or not. We wouldn't
like to have that validation on all the time, because it's unnecessarily
annoying for clusters with managed networking.
As part of our existing API connectivity-check, the service asks the agent to download the worker.ign file from the to-be-joined-cluster's machine-config-server, then send that back to the service.
The contents of that file include information that will allow the service to make an educated guess about whether the ignition originated from a cluster with managed networking or not.
However, that ignition file is incomplete as currently we only include necessary information in it (because that file is very big). The parts of that file that we care in this case are currently missing, so we have to modify the agent to include those files.
This commit does that. A follow-up commit will be done on the service to actually check for the presence of these files in this ignition to make the decision of whether the cluster is managed or not, and in turn turn on the necessary validations if not.
The ignition files we currently include are:
/etc/kubernetes/manifests/coredns.yaml
/etc/kubernetes/manifests/keepalived.yaml
This is a hack - since we have no official way to know whether a worker ignition file originated from a cluster with managed networking or not, we instead rely on the presence of coredns and keepalived pod manifests to indicate that. We only expect those to be present in clusters with managed networking. To be a bit more robust, the service will consider the presence of any one of them to mean that the cluster has managed networking. This gives us better forwards compatibility if one of them gets renamed / replaced with other technologies in future OCP versions.
Another way in which this is hacky is that users could manually create static pods with the same name as part of their machine-configs, in which case we would have a false-positive detection. But that is admittedly very unlikely.
Hopefully we can negotiate with the relevant OCP teams to have a more official, stable way to have this detection - like a magic empty file placed somewhere in the ignition that we can check for the presence of. Once we have such file, we can slowly deprecate this detection mechanism and fully move to the new one by inspecting that file instead.
Working on OOP, Section II.
This is a rather emotional day, my girlfriend's mother has been diagnosed with some health issues.
M3M 79 Gurgaon - A Fresh Beginning Towards A Beautiful Life
M3M Low Rise Floors Sector 79 Gurgaon is a world of premium luxury residential apartments, where expertise happens excellence in the heart of Gurugram! Dream in your own house which speaks of standards of luxury property launched by M3M Properties.
M3M Sector 79A & 79B in Gurgaon, this development comes in close proximity to your day variety and emergency sites, easing a replacement world that will assuredly make you happy. Because of places like schools, colleges, institutes, malls, shopping centers supermarkets/hypermarkets skets/hypermarkets, medical centers’’, hospitals, cinemas, restaurants, pubs, clubs, cafes, banks, ATMs, all types of public transport and more Can be reached in time. You will get this development strategically positioned at the right time, at the right place!
All M3M Upcoming Apartments in Sector 79 project are spacious, provide natural lighting, ventilation and branded fittings and fixtures, imported wood / Indian teak interior doors, UPVC / aluminum coated windows landscape view, large balcony and attractively planned doors, high-quality Spanish / Italian / Turkey provide flooring.
Fully with living and dining rooms, imported Italian marble / wooden flooring, granite/marble counters in the bedroom, a fancy Italian modular kitchen with piped gas and many provisions, high-quality emulsion paint, modular switches, video door phones, and more Electrical port placed..
This spectacular development also offers a powerful range of world-class outdoor facilities that will be loved and admired by you. Outdoor facilities include a spacious clubhouse, well-equipped gym, swimming pool, spa, yoga center, party room, lounge, multi-cuisine restaurant, indoor/outdoor sports facilities and a game for your children, multipurpose hall, and swimming pool Areas included. , Beautiful plantations, lush green gardens, 3-level security with video surveillance, efficient 3-level parking, and many more.
The M3M 79 Apartments is simply irresistible! This development is loaded with modern-day amenities that are worth your savings for a replacement apartment that will be loved for generations to come back.
You can easily choose from several payment plans with relaxed home loans at beautiful interest rates, services, and specialized assistance for a beautiful purchase. Welcome to an extra world of luxury and luxury where every component is considered to perfection!
For More Details : Visit - https://bit.ly/3bI6Atu
GENIUN BINDING SPELL TO BRING BACK YOUR LOVER
BINDING GENIUN REAL LOVE SPELL +234 7014613517
Dr. IWHEVA 7demons a Spiritual Healer, specializing in the fields of Love, Money, Power, Success, Luck and Witch Craft death spell to kill an enemy, Lost lover revenge spell. I can help you with any problem that is disturbing you or your life and business I have more than 35 years experience in the field of Spells Casting / Spiritual Healing. Over the years I have worked for thousands of clients in more than 150 countries all over the world. My services are hugely in demand which is proof of the success I am achieving on a day to day basis.Do you have love problems / issues that you need sorted out? I have a variety of love spells that will change your life forever. Have you lost a loved one? Are you in love with someone who doesn't seem to care about you? Is your loved one in love with someone else? Call or Whatsapp +234 915 604 8273 me no and I will summon all my powers to make your dreams come true.I use strong holy black magic spells and various mixtures of herbal remedies with the powerful ancestral spirits to heal and solve most of problems and terrible sicknesses. He has healed many people all over the world and according to testimonies shows he is mainly the world's best award winning healer.Do you suffer for long time with illnesses, Stresses, Poverty, Financial difficulties, Bad debts, Court cases, Body & skin sicknesses, Death Spell and Instant Death Spell and Revenge death spell, Evil witchcraft, Bad dreams, Lost lover& family, broken relationships, excessive alcohol and smoking problems, unemployment’s, Failing deals, Lost businesses, Sexual weakness, jealousy people, unprompted at job, need a child? Lose weight, Sugar diabetes, Blood pressure, Overweight, Robberies, Broken relationship and so much more.... Remember; I welcome any challenges and questions about any human life. Call or WhatsApp:+234 7014613516
realtek-poe: Fix memory leak in poe_reply_consume()
When thinking "embedded", it's a good idea to stay the fuck away from malloc(). Falling out of scope is a free garbage collector. Port config and state arrays followed this advice, but for some reason, the command queue did not.
No worries, free() is used in poe_reply_consume(). No problemo! Crisis averted! Did you spot the several failure modes which return before the free() call. In these modes, a malloc()d command is taken off the queue, and not free()d. The pointer falls out of scope and memory lost. Quod Erat Demonstratum.
To fix this, free() the command before hitting any exit paths.
Signed-off-by: Alexandru Gagniuc [email protected]
PAAS-2022: Fix APM config in migration package (fuck you CloudScripting)
Merge #81409
81409: bazel: upgrade to rules_nodejs 5.4.2 r=rickystewart,nathanstilwell,laurenbarker a=sjbarag
Please forgive the massive second commit — there's very few valid states in this progression, as building, linting, and testing either work or they don't. There's not much sense in intentionally leaving commits around that won't build in my opinion, as it makes bisecting extremely frustrating. If anyone disagrees, let me know and I can keep digging for an intermediate state!
Upgrading to Bazel's rules_nodejs 5.x exposed a flaw in our previous Bazel integration: because rules_nodejs explicitly doesn't support yarn's "workspaces" feature [1] (in which common dependencies are hoisted to the lowest common parent directory), any NPM dependencies with different major versions between db-console and cluster-ui would get flattened to a single version. This left one of those packages using an unsupported (and un-requested) version of a dependency. Removing the yarn workspace layout and using separate Bazel repositories for each JS project ensured each project received the correct dependencies, but revealed incompatibilities with the requested versions. Upgrade rules_nodejs to the latest released version, remove yarn workspaces from the pkg/ui/ tree, and fix all revealed compatibility issues.
Co-authored-by: Sean Barag [email protected]
util/timeutil: don't strip mono time in timeutil.Now
Our timeutil.Now() insists on returning UTC timestamps, for better or worse. It was doing this by calling time.Now.UTC(). The rub is that the UTC() call strips the monotonic clock reading from the timestamp. Despite repeatedly trying ([1]), I've failed to find any reasonable reason for that behavior. To work around it, this patch does unsafe trickery to get a UTC timestamp without stripping the monos.
Stripping the monos has the following downsides:
- We lose the benefits of the monotonic clock reading.
- On OSX, only the monotonic clock seems to have nanosecond resolution. If we strip it, we only get microsecond resolution. Besides generally sucking, microsecond resolution is not enough to guarantee that consecutive timeutil.Now() calls don't return the same instant. This trips up some of our tests, which assume that they can measure any duration of time.
- time.Since(t) does one less system calls when t has a monotonic reading, making it twice as fast as otherwise: https://cs.opensource.google/go/go/+/refs/tags/go1.17.2:src/time/time.go;l=878;drc=refs%2Ftags%2Fgo1.17.2
An alternative considered was setting the process' timezone to UTC in an init(): time.Local = time.UTC. That has downsides: it makes cockroach more unpleasant to link as a library, and setting the process timezone makes the timestamps not roundtrip through marshalling/unmarshalling (see [1]).
[1] https://groups.google.com/g/golang-nuts/c/dyPTdi6oem8
Manually copy trailing attributes on a resize (#12637)
This is a fairly naive fix for this bug. It's not terribly performant, but neither is resize in the first place.
When the buffer gets resized, typically we only copy the text up to the
MeasureRight point, the last printable char in the row. Then we'd just
use the last char's attributes to fill the remainder of the row.
Instead, this PR changes how reflow behaves when it gets to the end of the row. After we finish copying text, then manually walk through the attributes at the end of the row, and copy them over. This ensures that cells that just have a colored space in them get copied into the new buffer as well, and we don't just blat the last character's attributes into the rest of the row. We'll do a similar thing once we get to the last printable char in the buffer, copying the remaining attributes.
This could DEFINITELY be more performant. I think this current implementation walks the attrs on every cell, then appends the new attrs to the new ATTR_ROW. That could be optimized by just using the actual iterator. The copy after the last printable char bit is also especially bad in this regard. That could likely be a blind copy - I just wanted to get this into the world.
Finally, we now copy the final attributes to the correct buffer: the new one. We used to copy them to the old buffer, which we were about to destroy.
I'll add more gifs in the morning, not enough time to finish spinning a release Terminal build with this tonight.
Closes #32 🎉🎉🎉🎉🎉🎉🎉🎉🎉 Closes #12567
(cherry picked from commit 855e1360c0ff810decf862f1d90e15b5f49e7bbd)
Disable the VT color quirk for pwsh and modern inbox powershell (#13352)
In #6810, we introduced a "quirk" for all known versions of PowerShell that suppressed their requests for black background/gray foreground. This was done to avoid an issue in PSReadline where it would paint black bars all over the screen if the default background color wasn't the same as the ANSI black color.
Years have passed since that quirk was introduced. The underlying bug was fixed, and the fix was released broadly long ago. It's time for us to remove the quirk... almost.
Terminal still runs on versions of Windows that ship a broken version of PSReadline. We must maintain the quirk there -- the user can't do anything about it, and we would make their experience worse if we removed the quirk entirely.
PowerShell 7.0 also ships a broken version of PSReadline. It is still in support for another 6 months, but updates have been available for some time. We can encourage users to update.
Therefore, we only need the quirk for Windows PowerShell, and then only for specific versions of Windows.
Inside Windows, we don't even need that: we're guaranteed to be built alongside a fixed version of PowerShell!
Closes #6807
Update books.json
Added Friendship is Optimal Added The Mare Who Once Lived on the Moon Added A Stallion for the Time Being Added Better Living Through Science and Ponies Added Why am I Pinkie Pie?! Updated details for Fallout: Equestria - Heroes Updated details for The Enchanted Library Updated details for Fallout: Equestria (MoI) Updated details for Fallout Equestria: Project Horizons Un-expired Princess Celestia: The Changeling Queen with signup form Added The King of Love Bugs Added Best Hell Ever & Heaven of a Hell Changed Make Love Not War entry to make more sense
Refactor CDK constructs
This refactors a pretty significant chunk of constructs within the
application to just directly extend other components rather than build
compositions based on them. For a few things, we're basically just
creating pre-configured variants of another construct type (SQS Queue,
State Machine, etc) and we can handle that pretty trivially and remove
some need to make wonky .foo attribute accesses. This also makes them
easier to just pass around within the CDK app.
Notably, the API Gateway REST API is not refactored. That adds a few methods and my worry there is that we actually use some names that may eventually conflict with the underlying resource (not likely but possible) and so I kinda tried to avoid that.
Because the SfnLambdaInvokeTask was only ever created in one place, we
can also just get rid of it entirely. It wasn't doing a whole lot for
us. I think it made sense in a time where its use case was uncertain and
where we had more constructs with that pattern; today, I think we can
clean it up a bit.
This will result in resource replacement in already-deployed environments as constuct paths (and therefore CloudFormation resource logical IDs) will change. I feel that because these are mostly Queues and connecting resources this is safe but there's a chance this will gum up the pipeline and we'll either need to make some additional fixes or revert.
BACKPORT: mm/compaction: stop isolation if too many pages are isolated and we have pages to migrate
In isolate_migratepages_block, if we have too many isolated pages and nr_migratepages is not zero, we should try to migrate what we have without wasting time on isolating.
In theory it's possible that multiple parallel compactions will cause too_many_isolated() to become true even if each has isolated less than COMPACT_CLUSTER_MAX, and loop forever in the while loop. Bailing immediately prevents that.
[[email protected]: changelog addition]
Fixes: 1da2f328fa64 (“mm,thp,compaction,cma: allow THP migration for CMA allocations”) Suggested-by: Vlastimil Babka [email protected] Signed-off-by: Zi Yan [email protected] Signed-off-by: Andrew Morton [email protected] Cc: [email protected] Cc: Mel Gorman [email protected] Cc: Michal Hocko [email protected] Cc: Rik van Riel [email protected] Cc: Yang Shi [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds [email protected] [cyberknight777: backport to 4.14] Signed-off-by: Cyber Knight [email protected]
Overheat warnings to both gatling guns (#742)
-
The notorious
-
Epic
-
FUCK YOU
-
I am going to beat you with a club
clone: propagate empty remote HEAD even with other branches
Unless "--branch" was given, clone generally tries to match the local HEAD to the remote one. For most repositories, this is easy: the remote tells us which branch HEAD was pointing to, and we call our local checkout() function on that branch.
When cloning an empty repository, it's a little more tricky: we have special code that checks the transport's "unborn" extension, or falls back to our local idea of what the default branch should be. In either case, we point the new HEAD to that, and set up the branch.* config.
But that leaves one case unhandled: when the remote repository isn't empty, but its HEAD is unborn. The checkout() function is smart enough to realize we didn't fetch the remote HEAD and it bails with a warning. But we'll have ignored any information the remote gave us via the unborn extension. This leads to nonsense outcomes:
-
If the remote has its HEAD pointing to an unborn "foo" and contains another branch "bar", cloning will get branch "bar" but leave the local HEAD pointing at "master" (or whatever our local default is), which is useless. The project does not use "master" as a branch.
-
Worse, if the other branch "bar" is instead called "master" (but again, the remote HEAD is not pointing to it), then we end up with a local unborn branch "master", which is not connected to the remote "master" (it shares no history, and there's no branch.* config).
Instead, we should try to use the remote's HEAD, even if its unborn, to be consistent with the other cases.
Some notes on the implementation:
-
we don't emit any specific warning here, which is unlike the empty-repo case (which says "you appear to have cloned an empty reopsitory"). For non-bare clones, checkout() will issue a warning like:
warning: remote HEAD refers to nonexistent ref, unable to checkout
For a bare clone, it won't emit any warning at all (but will still set up HEAD appropriately). That's probably fine. There's no part of the operation we were unable to perform, so any "by the way, the remote HEAD wasn't there but we pointed our HEAD to it anyway" message would be purely informational. Though perhaps one could argue the same about the current "empty repository" message in a bare clone.
-
if the remote told us about its HEAD via the unborn extension, this is obviously the right thing to do. If they didn't, we'll fall back to our local default name. As the "unborn" extension was added in v2.31.0, we'd expect hosts which don't support it to become decreasingly common, and it may not be worth worrying too much about. But for the sake of completeness, here are some thoughts:
-
if the remote has a non-HEAD "master", we may still end up with a local "master" that isn't connected to it. This is because the "how to set local unborn HEAD" code is independent from the "did we find a remote HEAD we can checkout" code. This could be fixed, but I'm not sure it's worth caring too much about, since you'd have to really try hard to create such a situation.
-
if the remote has branches but doesn't tell us about its HEAD, we could pick one of those branches as our HEAD instead of whatever our local default is. This feels on-balance worse to me. While it might do the right thing in some cases (especially if there is only a single branch), it could certainly lead to surprising and unintuitive outcomes in others.
-
Signed-off-by: Jeff King [email protected] Signed-off-by: Junio C Hamano [email protected]
Docket 399 - AIDED AND ABETTED BY THE FIRST COUNSELOR ON DECK FOR THE ZUCKER..
AIDED AND ABETTED AT ALL TIMES TO THOSE OBSTRUCTIONS OF JUSTICE WHILE CIRCULATING VIDEOS OF MYSELF BY AND BETWEEN COUNSELORS.
Subject: Fwd: Re: 16537-714-487-492, OMISSIONS, OBSTRUCTION, FITNESS,… … ETC.
Subject: Fwd: Re: 16537-714-487-492, OMISSIONS, OBSTRUCTION, FITNESS, ETC.
-------- Forwarded Message -------- Subject: Fwd: Re: 16537-714-487-492, OMISSIONS, OBSTRUCTION, FITNESS, ETC. Date: Tue, 31 May 2022 08:18:05 -0500 From: B D2022 [email protected] To: Yana Siegel [email protected], WILLIAM BEHR [email protected], Urvashi Sinha [email protected], Thomas R. Manisero [email protected], Suzanne S. Swanson [email protected], Stephen J. Barrett [email protected], Stacey L. Seltzer [email protected], Sean Wagner [email protected], Roger R. Gottilla [email protected], Ricki Roer [email protected], Ricki Roer [email protected], [email protected] [email protected], [email protected], [email protected], Lori Semlies [email protected], Lois K. Ottombrino [email protected], Lauren M. Zink [email protected], Kathleen A. Mullins [email protected], [email protected], [email protected], Jennifer L. Sciales [email protected], Jennifer M. Provost [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], Debra Tama [email protected], Daniel F. Flores [email protected], [email protected], [email protected], [email protected], Corrine Shea [email protected], [email protected], [email protected], Ashley V. Humphries [email protected], Angelique Sabia-Candero [email protected], [email protected], Andrea Shiffman [email protected], Amy Hanrahan [email protected], [email protected], ALDEN 00066govtIdx WILSON [email protected], Alan Rubin [email protected]
-------- Forwarded Message -------- Subject: Re: 16537-714-487-492, OMISSIONS, OBSTRUCTION, FITNESS, ETC. Date: Tue, 31 May 2022 07:09:11 -0400 From: BO DINCER [email protected] To: Bo Dincer [email protected] CC: BBO 121 [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] [email protected], [email protected] [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] [email protected], [email protected] [email protected], [email protected] [email protected], [email protected] [email protected], [email protected], [email protected] [email protected], [email protected], [email protected] [email protected], [email protected], NORTHERN TRUST [email protected], David Moore [email protected], State Farm [email protected], [email protected], [email protected], [email protected], The Stanford Daily [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], Rabbi Shlomo Kugel [email protected], UNITED ARTISTS MUSIC [email protected], Dow Jones [email protected], Dow Jones [email protected], [email protected], [email protected], KEVIN ROCK [email protected], [email protected] [email protected], [email protected], Kathleen A. Mullins [email protected], Josephine Vella [email protected], Jpetit [email protected], [email protected], [email protected], [email protected], Ir-operations-team [email protected]
On Sun, May 29, 2022, 7:34 AM Bo Dincer [email protected] wrote:
I. THEY MONITORED MY LAPTOP FROM OUTSIDE OF MY APARTMENT.
- ON A 24 HOUR BASIS, RECORDED MY EVERY STEP AND MOTION.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=c3iexOlBwsgc1lnMJ2_PLUS_AqQ==
--- ASHLEY HUMPHRIES, OF WILSON , ELSER & DICKER.
" ... PLEASE CHECK THE SECURITY TAPES ... "
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=HbnFLHB3tyjhEWAYb6mOPw==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=YvkihzM1cwANtAvbUwWX_PLUS_g==
II. VIDEOTAPED ME "INSIDE OF MY APARTMENT".
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=UZsCx4RNLy/6V9gf1BkpTQ==
III. DISTRIBUTED VIDEOS OF MYSELF IN MY APARTMENT -- THE INTERIOR.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=YGRsoOyDJuc93MrOnwh5Jw==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=84wdx4RhX5LEi0sISXetBw==
IV. ATTACHED VIDEO OF MYSELF DRILLING INSIDE OF MY APARTMENT.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=5uMb/ORklCen4NaSEt6oFg==
V. ATTACHED VIDEO OF MYSELF HAMMERING INSIDE OF MY APARTMENT.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=C4X_PLUS_6_PLUS_kgBxoElZyFgKxGEQ==
VI. THEY ALSO ANNEX MY RECEIPT TO HELP BUY THEMSELVES MORE TIME AND TO DISTRACT
THE JUDGE, CLERK AND INSTEAD OF DEALING WITH THEIR TAX-EVASIONS AND ILLEGAL CONDUCT. HTF DID THEY EVEN GET AN IMAGE OF MY RECEIPT?
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=Uavl5NRQV4YHKqWUf8fyVQ==
VII. ALSO WILL SWEAR THAT THEY HAVE NO INVOLVEMENT, IN ANYTHING...
- HAVE ALSO MONITORED ME FROM THE CORRIDOR, AND THROUGH MY DOOR.
- BY ALL OF THE ATTORNEYS, COUNSELORS, AND STAFF OF SULLIVAN PROPERTIES, LP.
VIII. HAVE ALSO ANNEXED AND SWORE UNDER OATH THEY SAW ME
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=PWFQc/WFihoyIKwEunaalQ==
"... BANGING ON A RADIATOR ... "
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=oz2nfEu9a94Y3U5/kpIt5g==
IX. ALSO HAVE ANNEXED THEY "HOSTED" MY VIDEOS ON THE INTERNET --
-- USING ONE OF THEIR OWN TENANTS AS THE VIDEOGRAPHER.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=PWFQc/WFihoyIKwEunaalQ==
TRANSFERRED THE LEASES AND RENTS TO STATE FARM.
- HERE ARE SOME OF THE PROVISIONS FOR AIDING AND ABETTING TAX EVASION. BY WAY OF OBSTRUCTION, OMISSIONS, AND UNFAIR DEALINGS.
- COSTED THE INVESTORS OF STATE FARM THE GREATER OF 1.5 BILLION DOLLARS AND ALSO ONE INVESTMENT ADVISER:
- FILER 93715 - AFTER 27 YEARS RANDOMLY DECIDED TO " CEASE TO EXIST "
RE: 153974 - VIOLATION OF PRIVACY...
/S/ BO DINCER
TEL. 646-256-3609
TEL. 917-378-3467
[email protected]
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=au8qh7Dn66hrVmJ9DX_PLUS_bdg==
https://saaze2311prdsra.blob.core.windows.net/clean/f6d60b925fd3ec11a7b5002248286386/8209-$BROOKS--4776256-6109023[FILED].pdf
TAX MATTERS
https://www.irs.gov/pub/irs-utl/tax_crimes_handbook.pdf
https://www.irs.gov/pub/int_practice_units/IGA9560_11_06.pdf
-------- Forwarded Message --------
Subject: [BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER] 2d2b62: TCR 16537-714-487-492 FILED.: OMISSIONS, OBSTRUCTI...
Date: Fri, 27 May 2022 20:26:30 -0700
From: 1212-5858 <[email protected]>
To: [email protected], [email protected]
Branch: refs/heads/REQUEST-TO-BAR
Home: https://github.com/BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER
Commit: 2d2b621f9b4e59f4d0f470538b748bb148ddd8eb
BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER@2d2b621
Author: 1212-5858 <[email protected]>
Date: 2022-05-27 (Fri, 27 May 2022)
Changed paths:
A 16537-714-487-492
Log Message:
-----------
TCR 16537-714-487-492 FILED.: OMISSIONS, OBSTRUCTION, INVESTOR LOSSES AND ASSETS MISSING
NO MANDATORY ATTENDANCE REQUIRED.
2022-05-27---TCRReport 16537-714-487-492
ATTN: THE NORTHERN TRUST COMPANY.
via EMAIL: [email protected]
BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER@8db8d4c
BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER@8db8d4c#diff-f87405da5ef03c67c43c2dd391b9e8e15e36553ad5a56bf4089dd600f4d9ea7b
BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER@8db8d4c#diff-1b1e8bc23d8163d3e8fd3c1b9afe2dfa43987933ab4a255f654dfeb93d004cbe
BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER@8db8d4c#diff-a08dd2a966192670b96232cd500357a562db71af7b8082e63f0a2b2edccde936
BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER@8db8d4c#diff-f53bbf593645261d55469f485116c9a3b7cc292e56f3917741b877251f094614
AS STATED PREVIOUSLY, YES.
- I WOULD STILL LIKE TO PRESS CHARGES FOR THE VIOLATION OF PRIVACY.
BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER@12da4ef
THANK YOU.
BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER@12da4ef
OFFER @ $65,000,000.00 for out of court settlement.
UNFAIR DEALINGS AND OMMISSIONS OF MORGAN STANLEY IN AIDING AND ABETTING TO THE TAX EVASION AND LOSSES SUFFERED BY STATE FARMS FAMILY OF TICKERS: STFGX, SFITX, STFBX, SFBDX with Sullivan Properties LP and their subsidiaries - continue to avoid prosecution in this respect, and
collectively have costed INVESTORS the greater of $1.5 BILLION IN LOSSES before FINES, REGULATORY ACTION, or SETTLEMENT of a certain VIOLATION OF PRIVACY CASE
colorful, and also can be zoomed on, pixelated and in their servers, was also distributed without consent, and probably - they play with themselves watching me in their privacy.
--- $25 million was a DISCOUNT.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=fXMaXgeyzvA85ViWMmvfAQ==
https://www.sec.gov/comments/s7-14-18/s71418-4531826-176079.pdf
- obo OF SULLIVAN PROPERTIES LP HAVE ALSO "PROMISED" TO PAY THEM BACK,
SOMEWHERE ON PAGE 800 OF THE UNREGISTERED SECURITY ( THE COMBINED
AND RE-STATED PROSPECTUS ) WHICH I ALSO ANNEXED IN THE MATTER OF NYSCEF
153974/2020.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=ze6a1KA9akRV9TGfXXJT/g==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=bVk8sIt7n3kGwHqebPg0fw==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=wTG2YD2PqXuxmoKqFiESrw==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=au8qh7Dn66hrVmJ9DX_PLUS_bdg==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=/yhElCiKJ0BGv2DF/MOn4g==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=gcMSDaFzm0ynPeXZKSHgLQ==
UNFAIR DEALINGS
I. THEY MONITORED MY LAPTOP FROM OUTSIDE OF MY APARTMENT.
- ON A 24 HOUR BASIS, RECORDED MY EVERY STEP AND MOTION.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=c3iexOlBwsgc1lnMJ2_PLUS_AqQ==
ASHLEY HUMPHRIES, OF WILSON & DICKER.
" ... PLEASE CHECK THE SECURITY TAPES ... "
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=HbnFLHB3tyjhEWAYb6mOPw==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=YvkihzM1cwANtAvbUwWX_PLUS_g==
II. VIDEOTAPED ME "INDISE OF MY APARTMENT".
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=UZsCx4RNLy/6V9gf1BkpTQ==
III. DISTRIBUTED VIDEOS OF MYSELF IN MY APARTMENT -- THE INTERIOR.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=YGRsoOyDJuc93MrOnwh5Jw==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=84wdx4RhX5LEi0sISXetBw==
IV. ATTACHED VIDEO OF MYSELF DRILLING INSIDE OF MY APARTMENET.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=5uMb/ORklCen4NaSEt6oFg==
V. ATTACHED VIDEO OF MYSELF HAMMERING INSIDE OF MY APARTMENET.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=C4X_PLUS_6_PLUS_kgBxoElZyFgKxGEQ==
VI. THEY ALSO ANNEX MY RECEIPT TO HELP BUY THEMSELFVES MORE TIME AND TO DISTRACT
THE JUDGE, CLERK AND INTEAD OF DEALING WITH THEIR TAX-EVASIONS AND ILLEGAL CONDUCT.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=Uavl5NRQV4YHKqWUf8fyVQ==
VII. ALSO WILL SWEAR IN THEIR AFFIDAVITS THAT GO ON FOR PAGES THAT THEY HAVE NO INVOLVEMENT.
- HAVE ALSO MONITORED ME FROM THE CORRIDOR, AND THROUGH MY DOOR.
- BY ALL OF THE ATTORNEYS, COUNSELORS, AND STAFF OF SULLIVAN PROPERTIES, LP.
VIII. HAVE ALSO ANNEXED AND SWORE UNDER OATH THEY SAW ME
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=PWFQc/WFihoyIKwEunaalQ==
"... BANGING ON A RADIATOR ... "
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=oz2nfEu9a94Y3U5/kpIt5g==
IX. ALSO HAVE ANNEXED THEY "HOSTED" MY VIDEOS ON THE INTERNET --
-- USING ONE OF THEIR OWN TENANTS AS THE VIDEOGRAPHER.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=PWFQc/WFihoyIKwEunaalQ==
HERE ARE SOME OF THE PROVISIONS FOR AIDING AND ABETTING TAX EVASION.
BY WAY OF OBSTRUCTION, OMISSIONS, AND UNFAIR DEALINGS.
HAS COSTED THE INVESTORS OF STATE FARM THE GREATER OF 1.5 BILLION DOLLARS
AND ALSO ONE INVESTMENT ADVISER: FILER 93715
https://www.irs.gov/pub/irs-utl/tax_crimes_handbook.pdf
https://www.irs.gov/pub/int_practice_units/IGA9560_11_06.pdf
RE: 153974 - VIOLATION OF PRIVACY
/S/ BO DINCER
TEL. 646-256-3609
TEL. 917-378-3467
[email protected]
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=au8qh7Dn66hrVmJ9DX_PLUS_bdg==
https://saaze2311prdsra.blob.core.windows.net/clean/f6d60b925fd3ec11a7b5002248286386/8209-$BROOKS--4776256-6109023[FILED].pdf
93715 BROKERS AT MORGAN STANLEY - FURTHER OBSTRUCTED BY WAY OF OMISSION.
https://saaze2311prdsra.blob.core.windows.net/clean/db5e3c6a10d3ec11a7b5000d3a132789/8A5FDA9F-D641-4B62-9D15-3AF4205617AC.jpeg
December 18, 2021
https://saaze2311prdsra.blob.core.windows.net/clean/8de5f89e10d3ec11a7b5002248286421/CE48526B-6A0E-4B2A-89B9-93BD202498A9.jpeg
Docket 399 - AIDED AND ABETTED BY THE FIRST COUNSELOR ON DECK FOR THE ZUCKER..
https://saaze2311prdsra.blob.core.windows.net/clean/a463845010d3ec11a7b5000d3a1326fe/0F6C27D5-69BD-4971-91F6-A5A40317CC63.jpeg
https://saaze2311prdsra.blob.core.windows.net/clean/25aff4b997d3ec11a7b500224828654e/[STATE%20FARM%20VP%2043036]Advisers%20Investment%20Trust%20[$CIK%201516523]%20MONK[CRD%201357149].pdf
https://saaze2311prdsra.blob.core.windows.net/clean/5380dd8997d3ec11a7b5000d3a132789/[STATE%20FARM%20VP%2043036]Advisers%20Investment%20Trust%20[$CIK%201516523]%20MONK[CRD%201357149].pdf
https://saaze2311prdsra.blob.core.windows.net/clean/e9eb965d97d3ec11a7b5000d3a1326fe/[STATE%20FARM%20VP%2043036]$%203487%20$.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/25aff4b997d3ec11a7b500224828654e/[STATE%20FARM%20VP%2043036]Advisers%20Investment%20Trust%20[$CIK%201516523]%20MONK[CRD%201357149].pdf
https://saaze2311prdsra.blob.core.windows.net/clean/3bb9011795d3ec11a7b5000d3a132789/153974-2020.Docket399.FTC.StateFarmRealtyInsuranceLLC.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/ff91792a95d3ec11a7b50022482864f0/[sfVP43036]%20$2876793%20-%20david.moore%20$3487%20-%20IA%208018184.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/af081f4095d3ec11a7b50022482864f0/[STATE%20FARM%20VP%2043036]%20$3231040-2004555.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/d88e25ae5fd3ec11a7b5002248286997/StateFarmVP%20Management%20Corp-CRD%2343036.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/d88e25ae5fd3ec11a7b5002248286997/StateFarmVP%20Management%20Corp-CRD%2343036.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/d585ccd85fd3ec11a7b5000d3a1326fe/TAX%20EVASION%20%20attachments%20%252F%20Omissions.%20.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/db5e3c6a10d3ec11a7b5000d3a132789/8A5FDA9F-D641-4B62-9D15-3AF4205617AC.jpeg
https://saaze2311prdsra.blob.core.windows.net/clean/172de37992d3ec11a7b500224828654e/[sfVP%2043036]%204971235-%20$SMITH%20-%20SEMI.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/bee2b76c92d3ec11a7b5002248286997/[SF.VP%2043036]%202876793%20-%20$david%20moore%20$3487%20-%20IA%208018184.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/9194266492d3ec11a7b500224828654e/[sf%20VP%2043036-$3487]%201943922-%20$%20tipsord%20$%20STATE%20FARM%20mutual%20automobile%20insurance%20company-$3487.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/172de37992d3ec11a7b500224828654e/%5BsfVP%2043036%5D%204971235-%20$SMITH%20-%20SEMI.pdf
main
mainLINE THESE KNOWN INDIVIDUALS - AIDED AND ABETTED AS ACCESSORIES TO THE ZUCKER ENTERPRISES
mainLINE THESE KNOWN INDIVIDUALS - AIDED AND ABETTED AS ACCESSORIES TO THE ZUCKER ENTERPRISES
CONSTANTLY ARE AVOIDING PROSECUTION AND ARE AWARE AND IN POSSESSION OF ALL OF THE MATERIAL INFORMATION AS REFERENCED BELOW.
Subject: Fwd: Re: 16537-714-487-492, OMISSIONS, OBSTRUCTION, FITNESS,… … ETC. HAD TO SWITCH MY INTERNET CONNECTION AGAIN.
Subject: Fwd: Re: 16537-714-487-492, OMISSIONS, OBSTRUCTION, FITNESS, ETC.
-------- Forwarded Message -------- Subject: Fwd: Re: 16537-714-487-492, OMISSIONS, OBSTRUCTION, FITNESS, ETC. Date: Tue, 31 May 2022 08:18:05 -0500 From: B D2022 [email protected] To: Yana Siegel [email protected], WILLIAM BEHR [email protected], Urvashi Sinha [email protected], Thomas R. Manisero [email protected], Suzanne S. Swanson [email protected], Stephen J. Barrett [email protected], Stacey L. Seltzer [email protected], Sean Wagner [email protected], Roger R. Gottilla [email protected], Ricki Roer [email protected], Ricki Roer [email protected], [email protected] [email protected], [email protected], [email protected], Lori Semlies [email protected], Lois K. Ottombrino [email protected], Lauren M. Zink [email protected], Kathleen A. Mullins [email protected], [email protected], [email protected], Jennifer L. Sciales [email protected], Jennifer M. Provost [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], Debra Tama [email protected], Daniel F. Flores [email protected], [email protected], [email protected], [email protected], Corrine Shea [email protected], [email protected], [email protected], Ashley V. Humphries [email protected], Angelique Sabia-Candero [email protected], [email protected], Andrea Shiffman [email protected], Amy Hanrahan [email protected], [email protected], ALDEN 00066govtIdx WILSON [email protected], Alan Rubin [email protected]
-------- Forwarded Message -------- Subject: Re: 16537-714-487-492, OMISSIONS, OBSTRUCTION, FITNESS, ETC. Date: Tue, 31 May 2022 07:09:11 -0400 From: BO DINCER [email protected] To: Bo Dincer [email protected] CC: BBO 121 [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] [email protected], [email protected] [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] [email protected], [email protected] [email protected], [email protected] [email protected], [email protected] [email protected], [email protected], [email protected] [email protected], [email protected], [email protected] [email protected], [email protected], NORTHERN TRUST [email protected], David Moore [email protected], State Farm [email protected], [email protected], [email protected], [email protected], The Stanford Daily [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], Rabbi Shlomo Kugel [email protected], UNITED ARTISTS MUSIC [email protected], Dow Jones [email protected], Dow Jones [email protected], [email protected], [email protected], KEVIN ROCK [email protected], [email protected] [email protected], [email protected], Kathleen A. Mullins [email protected], Josephine Vella [email protected], Jpetit [email protected], [email protected], [email protected], [email protected], Ir-operations-team [email protected]
On Sun, May 29, 2022, 7:34 AM Bo Dincer [email protected] wrote:
I. THEY MONITORED MY LAPTOP FROM OUTSIDE OF MY APARTMENT.
- ON A 24 HOUR BASIS, RECORDED MY EVERY STEP AND MOTION.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=c3iexOlBwsgc1lnMJ2_PLUS_AqQ==
--- ASHLEY HUMPHRIES, OF WILSON , ELSER & DICKER.
" ... PLEASE CHECK THE SECURITY TAPES ... "
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=HbnFLHB3tyjhEWAYb6mOPw==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=YvkihzM1cwANtAvbUwWX_PLUS_g==
II. VIDEOTAPED ME "INSIDE OF MY APARTMENT".
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=UZsCx4RNLy/6V9gf1BkpTQ==
III. DISTRIBUTED VIDEOS OF MYSELF IN MY APARTMENT -- THE INTERIOR.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=YGRsoOyDJuc93MrOnwh5Jw==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=84wdx4RhX5LEi0sISXetBw==
IV. ATTACHED VIDEO OF MYSELF DRILLING INSIDE OF MY APARTMENT.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=5uMb/ORklCen4NaSEt6oFg==
V. ATTACHED VIDEO OF MYSELF HAMMERING INSIDE OF MY APARTMENT.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=C4X_PLUS_6_PLUS_kgBxoElZyFgKxGEQ==
VI. THEY ALSO ANNEX MY RECEIPT TO HELP BUY THEMSELVES MORE TIME AND TO DISTRACT
THE JUDGE, CLERK AND INSTEAD OF DEALING WITH THEIR TAX-EVASIONS AND ILLEGAL CONDUCT. HTF DID THEY EVEN GET AN IMAGE OF MY RECEIPT?
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=Uavl5NRQV4YHKqWUf8fyVQ==
VII. ALSO WILL SWEAR THAT THEY HAVE NO INVOLVEMENT, IN ANYTHING...
- HAVE ALSO MONITORED ME FROM THE CORRIDOR, AND THROUGH MY DOOR.
- BY ALL OF THE ATTORNEYS, COUNSELORS, AND STAFF OF SULLIVAN PROPERTIES, LP.
VIII. HAVE ALSO ANNEXED AND SWORE UNDER OATH THEY SAW ME
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=PWFQc/WFihoyIKwEunaalQ==
"... BANGING ON A RADIATOR ... "
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=oz2nfEu9a94Y3U5/kpIt5g==
IX. ALSO HAVE ANNEXED THEY "HOSTED" MY VIDEOS ON THE INTERNET --
-- USING ONE OF THEIR OWN TENANTS AS THE VIDEOGRAPHER.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=PWFQc/WFihoyIKwEunaalQ==
TRANSFERRED THE LEASES AND RENTS TO STATE FARM.
- HERE ARE SOME OF THE PROVISIONS FOR AIDING AND ABETTING TAX EVASION. BY WAY OF OBSTRUCTION, OMISSIONS, AND UNFAIR DEALINGS.
- COSTED THE INVESTORS OF STATE FARM THE GREATER OF 1.5 BILLION DOLLARS AND ALSO ONE INVESTMENT ADVISER:
- FILER 93715 - AFTER 27 YEARS RANDOMLY DECIDED TO " CEASE TO EXIST "
RE: 153974 - VIOLATION OF PRIVACY...
/S/ BO DINCER
TEL. 646-256-3609
TEL. 917-378-3467
[email protected]
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=au8qh7Dn66hrVmJ9DX_PLUS_bdg==
https://saaze2311prdsra.blob.core.windows.net/clean/f6d60b925fd3ec11a7b5002248286386/8209-$BROOKS--4776256-6109023[FILED].pdf
TAX MATTERS
https://www.irs.gov/pub/irs-utl/tax_crimes_handbook.pdf
https://www.irs.gov/pub/int_practice_units/IGA9560_11_06.pdf
-------- Forwarded Message --------
Subject: [BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER] 2d2b62: TCR 16537-714-487-492 FILED.: OMISSIONS, OBSTRUCTI...
Date: Fri, 27 May 2022 20:26:30 -0700
From: 1212-5858 <[email protected]>
To: [email protected], [email protected]
Branch: refs/heads/REQUEST-TO-BAR
Home: https://github.com/BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER
Commit: 2d2b621f9b4e59f4d0f470538b748bb148ddd8eb
BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER@2d2b621
Author: 1212-5858 <[email protected]>
Date: 2022-05-27 (Fri, 27 May 2022)
Changed paths:
A 16537-714-487-492
Log Message:
-----------
TCR 16537-714-487-492 FILED.: OMISSIONS, OBSTRUCTION, INVESTOR LOSSES AND ASSETS MISSING
NO MANDATORY ATTENDANCE REQUIRED.
2022-05-27---TCRReport 16537-714-487-492
ATTN: THE NORTHERN TRUST COMPANY.
via EMAIL: [email protected]
BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER@8db8d4c
BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER@8db8d4c#diff-f87405da5ef03c67c43c2dd391b9e8e15e36553ad5a56bf4089dd600f4d9ea7b
BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER@8db8d4c#diff-1b1e8bc23d8163d3e8fd3c1b9afe2dfa43987933ab4a255f654dfeb93d004cbe
BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER@8db8d4c#diff-a08dd2a966192670b96232cd500357a562db71af7b8082e63f0a2b2edccde936
BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER@8db8d4c#diff-f53bbf593645261d55469f485116c9a3b7cc292e56f3917741b877251f094614
AS STATED PREVIOUSLY, YES.
- I WOULD STILL LIKE TO PRESS CHARGES FOR THE VIOLATION OF PRIVACY.
BSCPGROUPHOLDINGSLLC/ELSER-AND-DICKER@12da4ef
THANK YOU.
UNFAIR DEALINGS AND OMMISSIONS OF MORGAN STANLEY IN AIDING AND ABETTING TO THE TAX EVASION AND LOSSES SUFFERED BY STATE FARMS FAMILY OF TICKERS: STFGX, SFITX, STFBX, SFBDX with Sullivan Properties LP and their subsidiaries - continue to avoid prosecution in this respect, and collectively have costed INVESTORS the greater of $1.5 BILLION IN LOSSES before FINES, REGULATORY ACTION, or SETTLEMENT of a certain VIOLATION OF PRIVACY CASE
colorful, and also can be zoomed on, pixelated and in their servers, was also distributed without consent, and probably - they play with themselves watching me in their privacy.
--- $25 million was a DISCOUNT.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=fXMaXgeyzvA85ViWMmvfAQ==
https://www.sec.gov/comments/s7-14-18/s71418-4531826-176079.pdf
- obo OF SULLIVAN PROPERTIES LP HAVE ALSO "PROMISED" TO PAY THEM BACK,
SOMEWHERE ON PAGE 800 OF THE UNREGISTERED SECURITY ( THE COMBINED
AND RE-STATED PROSPECTUS ) WHICH I ALSO ANNEXED IN THE MATTER OF NYSCEF
153974/2020.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=ze6a1KA9akRV9TGfXXJT/g==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=bVk8sIt7n3kGwHqebPg0fw==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=wTG2YD2PqXuxmoKqFiESrw==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=au8qh7Dn66hrVmJ9DX_PLUS_bdg==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=/yhElCiKJ0BGv2DF/MOn4g==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=gcMSDaFzm0ynPeXZKSHgLQ==
UNFAIR DEALINGS
I. THEY MONITORED MY LAPTOP FROM OUTSIDE OF MY APARTMENT.
- ON A 24 HOUR BASIS, RECORDED MY EVERY STEP AND MOTION.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=c3iexOlBwsgc1lnMJ2_PLUS_AqQ==
ASHLEY HUMPHRIES, OF WILSON & DICKER.
" ... PLEASE CHECK THE SECURITY TAPES ... "
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=HbnFLHB3tyjhEWAYb6mOPw==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=YvkihzM1cwANtAvbUwWX_PLUS_g==
II. VIDEOTAPED ME "INDISE OF MY APARTMENT".
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=UZsCx4RNLy/6V9gf1BkpTQ==
III. DISTRIBUTED VIDEOS OF MYSELF IN MY APARTMENT -- THE INTERIOR.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=YGRsoOyDJuc93MrOnwh5Jw==
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=84wdx4RhX5LEi0sISXetBw==
IV. ATTACHED VIDEO OF MYSELF DRILLING INSIDE OF MY APARTMENET.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=5uMb/ORklCen4NaSEt6oFg==
V. ATTACHED VIDEO OF MYSELF HAMMERING INSIDE OF MY APARTMENT.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=C4X_PLUS_6_PLUS_kgBxoElZyFgKxGEQ==
VI. THEY ALSO ANNEX MY RECEIPT TO HELP BUY THEMSELFVES MORE TIME AND TO DISTRACT
THE JUDGE, CLERK AND INTEAD OF DEALING WITH THEIR TAX-EVASIONS AND ILLEGAL CONDUCT.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=Uavl5NRQV4YHKqWUf8fyVQ==
VII. ALSO WILL SWEAR IN THEIR AFFIDAVITS THAT GO ON FOR PAGES THAT THEY HAVE NO INVOLVEMENT.
- HAVE ALSO MONITORED ME FROM THE CORRIDOR, AND THROUGH MY DOOR.
- BY ALL OF THE ATTORNEYS, COUNSELORS, AND STAFF OF SULLIVAN PROPERTIES, LP.
VIII. HAVE ALSO ANNEXED AND SWORE UNDER OATH THEY SAW ME
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=PWFQc/WFihoyIKwEunaalQ==
"... BANGING ON A RADIATOR ... "
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=oz2nfEu9a94Y3U5/kpIt5g==
IX. ALSO HAVE ANNEXED THEY "HOSTED" MY VIDEOS ON THE INTERNET --
-- USING ONE OF THEIR OWN TENANTS AS THE VIDEOGRAPHER.
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=PWFQc/WFihoyIKwEunaalQ==
HERE ARE SOME OF THE PROVISIONS FOR AIDING AND ABETTING TAX EVASION.
BY WAY OF OBSTRUCTION, OMISSIONS, AND UNFAIR DEALINGS.
HAS COSTED THE INVESTORS OF STATE FARM THE GREATER OF 1.5 BILLION DOLLARS
AND ALSO ONE INVESTMENT ADVISER: FILER 93715
https://www.irs.gov/pub/irs-utl/tax_crimes_handbook.pdf
https://www.irs.gov/pub/int_practice_units/IGA9560_11_06.pdf
RE: 153974 - VIOLATION OF PRIVACY
/S/ BO DINCER
TEL. 646-256-3609
TEL. 917-378-3467
[email protected]
https://iapps.courts.state.ny.us/nyscef/ViewDocument?docIndex=au8qh7Dn66hrVmJ9DX_PLUS_bdg==
https://saaze2311prdsra.blob.core.windows.net/clean/f6d60b925fd3ec11a7b5002248286386/8209-$BROOKS--4776256-6109023[FILED].pdf
93715 BROKERS AT MORGAN STANLEY - FURTHER OBSTRUCTED BY WAY OF OMISSION.
https://saaze2311prdsra.blob.core.windows.net/clean/db5e3c6a10d3ec11a7b5000d3a132789/8A5FDA9F-D641-4B62-9D15-3AF4205617AC.jpeg
December 18, 2021
https://saaze2311prdsra.blob.core.windows.net/clean/8de5f89e10d3ec11a7b5002248286421/CE48526B-6A0E-4B2A-89B9-93BD202498A9.jpeg
Docket 399 - AIDED AND ABETTED BY THE FIRST COUNSELOR ON DECK FOR THE ZUCKER..
https://saaze2311prdsra.blob.core.windows.net/clean/a463845010d3ec11a7b5000d3a1326fe/0F6C27D5-69BD-4971-91F6-A5A40317CC63.jpeg
https://saaze2311prdsra.blob.core.windows.net/clean/25aff4b997d3ec11a7b500224828654e/[STATE%20FARM%20VP%2043036]Advisers%20Investment%20Trust%20[$CIK%201516523]%20MONK[CRD%201357149].pdf
https://saaze2311prdsra.blob.core.windows.net/clean/5380dd8997d3ec11a7b5000d3a132789/[STATE%20FARM%20VP%2043036]Advisers%20Investment%20Trust%20[$CIK%201516523]%20MONK[CRD%201357149].pdf
https://saaze2311prdsra.blob.core.windows.net/clean/e9eb965d97d3ec11a7b5000d3a1326fe/[STATE%20FARM%20VP%2043036]$%203487%20$.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/25aff4b997d3ec11a7b500224828654e/[STATE%20FARM%20VP%2043036]Advisers%20Investment%20Trust%20[$CIK%201516523]%20MONK[CRD%201357149].pdf
https://saaze2311prdsra.blob.core.windows.net/clean/3bb9011795d3ec11a7b5000d3a132789/153974-2020.Docket399.FTC.StateFarmRealtyInsuranceLLC.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/ff91792a95d3ec11a7b50022482864f0/[sfVP43036]%20$2876793%20-%20david.moore%20$3487%20-%20IA%208018184.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/af081f4095d3ec11a7b50022482864f0/[STATE%20FARM%20VP%2043036]%20$3231040-2004555.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/d88e25ae5fd3ec11a7b5002248286997/StateFarmVP%20Management%20Corp-CRD%2343036.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/d88e25ae5fd3ec11a7b5002248286997/StateFarmVP%20Management%20Corp-CRD%2343036.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/d585ccd85fd3ec11a7b5000d3a1326fe/TAX%20EVASION%20%20attachments%20%252F%20Omissions.%20.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/db5e3c6a10d3ec11a7b5000d3a132789/8A5FDA9F-D641-4B62-9D15-3AF4205617AC.jpeg
https://saaze2311prdsra.blob.core.windows.net/clean/172de37992d3ec11a7b500224828654e/[sfVP%2043036]%204971235-%20$SMITH%20-%20SEMI.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/bee2b76c92d3ec11a7b5002248286997/[SF.VP%2043036]%202876793%20-%20$david%20moore%20$3487%20-%20IA%208018184.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/9194266492d3ec11a7b500224828654e/[sf%20VP%2043036-$3487]%201943922-%20$%20tipsord%20$%20STATE%20FARM%20mutual%20automobile%20insurance%20company-$3487.pdf
https://saaze2311prdsra.blob.core.windows.net/clean/172de37992d3ec11a7b500224828654e/%5BsfVP%2043036%5D%204971235-%20$SMITH%20-%20SEMI.pdf
mainLINE
Merge #18295: scripts: add MACHO lazy bindings check to security-check.py
5ca90f8b598978437340bb8467f527b9edfb2bbf scripts: add MACHO lazy bindings check to security-check.py (fanquake)
Pull request description:
This is a slightly belated follow up to #17686 and some discussion with Cory. It's not entirely clear if we should make this change due to the way the macOS dynamic loader appears to work. However I'm opening this for some discussion. Also related to #17768.
LD64 doesn't set the MH_BINDATLOAD bit in the header of MACHO executables, when building with -bind_at_load. This is in contradiction to the documentation:
-bind_at_load
Sets a bit in the mach header of the resulting binary which tells dyld to
bind all symbols when the binary is loaded, rather than lazily.The ld in Apples cctools does set the bit, however the cctools-port that we use for release builds, bundles LD64.
However; even if the linker hasn't set that bit, the dynamic loader (dyld) doesn't seem to ever check for it, and from what I understand, it looks at a different part of the header when determining whether to lazily load symbols.
Note that our release binaries are currently working as expected, and no lazy loading occurs.
Using a small program, we can observe the behaviour of the dynamic loader.
Conducted using:
clang++ --version
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin18.7.0
ld -v
@(#)PROGRAM:ld PROJECT:ld64-530
BUILD 18:57:17 Dec 13 2019
LTO support using: LLVM version 11.0.0, (clang-1100.0.33.17) (static support for 23, runtime is 23)
TAPI support using: Apple TAPI version 11.0.0 (tapi-1100.0.11)#include <iostream>
int main() {
std::cout << "Hello World!\n";
return 0;
}Compile and check the MACHO header:
clang++ test.cpp -o test
otool -vh test
...
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL LIB64 EXECUTE 16 1424 NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE
# Run and dump dynamic loader bindings:
DYLD_PRINT_BINDINGS=1 DYLD_PRINT_TO_FILE=no_bind.txt ./test
Hello World!Recompile with -bind_at_load. Note still no BINDATLOAD flag:
clang++ test.cpp -o test -Wl,-bind_at_load
otool -vh test
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL LIB64 EXECUTE 16 1424 NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE
...
DYLD_PRINT_BINDINGS=1 DYLD_PRINT_TO_FILE=bind.txt ./test
Hello World!If we diff the outputs, you can see that dyld doesn't perform any lazy bindings when the binary is compiled with -bind_at_load, even if the BINDATLOAD flag is not set:
@@ -1,11 +1,27 @@
+dyld: bind: test:0x103EDF030 = libc++.1.dylib:__ZNKSt3__16locale9use_facetERNS0_2idE, *0x103EDF030 = 0x7FFF70C9FA58
+dyld: bind: test:0x103EDF038 = libc++.1.dylib:__ZNKSt3__18ios_base6getlocEv, *0x103EDF038 = 0x7FFF70CA12C2
+dyld: bind: test:0x103EDF068 = libc++.1.dylib:__ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryC1ERS3_, *0x103EDF068 = 0x7FFF70CA12B6
+dyld: bind: test:0x103EDF070 = libc++.1.dylib:__ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryD1Ev, *0x103EDF070 = 0x7FFF70CA1528
+dyld: bind: test:0x103EDF080 = libc++.1.dylib:__ZNSt3__16localeD1Ev, *0x103EDF080 = 0x7FFF70C9FAE6
<trim>
-dyld: lazy bind: test:0x10D4AC0C8 = libsystem_platform.dylib:_strlen, *0x10D4AC0C8 = 0x7FFF73C5C6E0
-dyld: lazy bind: test:0x10D4AC068 = libc++.1.dylib:__ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryC1ERS3_, *0x10D4AC068 = 0x7FFF70CA12B6
-dyld: lazy bind: test:0x10D4AC038 = libc++.1.dylib:__ZNKSt3__18ios_base6getlocEv, *0x10D4AC038 = 0x7FFF70CA12C2
-dyld: lazy bind: test:0x10D4AC030 = libc++.1.dylib:__ZNKSt3__16locale9use_facetERNS0_2idE, *0x10D4AC030 = 0x7FFF70C9FA58
-dyld: lazy bind: test:0x10D4AC080 = libc++.1.dylib:__ZNSt3__16localeD1Ev, *0x10D4AC080 = 0x7FFF70C9FAE6
-dyld: lazy bind: test:0x10D4AC070 = libc++.1.dylib:__ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryD1Ev, *0x10D4AC070 = 0x7FFF70CA1528Note: dyld also has a DYLD_BIND_AT_LAUNCH=1 environment variable, that when set, will force any lazy bindings to be non-lazy:
dyld: forced lazy bind: test:0x10BEC8068 = libc++.1.dylib:__ZNSt3__113basic_ostreamAfter looking at the dyld source, I can't find any checks for MH_BINDATLOAD. You can see the flags it does check for, such as MH_PIE or MH_BIND_TO_WEAK here.
It seems that the lazy binding of any symbols depends on whether or not lazy_bind_size from the LC_DYLD_INFO_ONLY load command is > 0. Which was mentioned in #17686.
This PR is one of Corys commits, that I've rebased and modified to make build. I've also included an addition to the security-check.py script to check for the flag.
However, given the above, I'm not entirely sure this patch is the correct approach. If the linker no-longer inserts it, and the dynamic loader doesn't look for it, there might be little benefit to setting it. Or, maybe this is an oversight from Apple and needs some upstream discussion. Looking for some thoughts / Concept ACK/NACK.
One alternate approach we could take is to drop the patch and modify security-check.py to look for lazy_bind_size == 0 in the LC_DYLD_INFO_ONLY load command, using otool -l.
ACKs for top commit: theuni: ACK 5ca90f8b598978437340bb8467f527b9edfb2bbf
Tree-SHA512: 444022ea9d19ed74dd06dc2ab3857a9c23fbc2f6475364e8552d761b712d684b3a7114d144f20de42328d1a99403b48667ba96885121392affb2e05b834b6e1c
Adding GPS Helper Mod with author permission
Kaito [author] Jul 1 @ 1:20pm No, I had not considered it yet. Feel free to have a look. I'm kinda busy irl right now, so it would be a while before I could look.
In theory it all runs on the client, but you'll have to check the API.
Doc1979 Jun 28 @ 4:37pm Does this use server only commands? If not, have you thought of making it into a PluginLoader plugin? I was thinking of looking at your github to see if I could convert it myself, but if its already on your todo list, I'll wait
1st revision of translation
Hello! I'm a certified English/Spanish translator specialized in videogames! I look forward to keep working on this file as there are some things that can be written differently to stay as close to the original as possible whilst mantaining the effect it produces on the player! I also noticed some jokes were omitted.
Please, note these translations/revisions are valid for all Spanish speakers all around the world.
I will keep working on this file and I look forward to see the changes implemented in my favourite game!
Thank you guys, hope you enjoy it!
(If this is not the correct procedure to post translations, please let me know as well!)
OR: ORIGINAL TR: TRANSLATION RV: REVISED
Authentic British cuisine! OR
¡Auténtica receta inglesa! TR
¡Auténtica cocina inglesa! RV
Explanation: wrong translation of the word "cuisine" as it is not "recipe" but "cocina".
Cocina, in this context, does not mean "kitchen".
Try our new Biscuit and Gravy menu! OR
Prueba nuestra Galleta con Sirope! TR
¡Prueba nuestro nuevo menú, galleta con salsa! RV
Explanation: they are inviting us to try the new MENU which consists of "biscuit and gravy", not the new "Biscuit and Gravy". This is a severe mistake.
The correct translation for this is "galleta con salsa" per different cuisine articles consulted by me.
"Sirope" is "syrup" in Spanish which does not make sense as gravy is a "salsa". I changed that as well.
_
This. This is the message of cows. OR
Este es el mensaje de las vacas. TR
Este. Este es el mensaje de las vacas. RV
Explanation: fixed to look as the original, there's no need for us to avoid that repetition as the original and the translation have almost the same character length.
Feel the most nutritious taste explosion known to man. OR
Siente la más nutritiva explosión de sabor conocida. TR
Siente la explosión de sabor más nutritiva. RV
Explanation: wrong word order, passive constructions are not as common as in English. Opted for a different approach whilst keeping the meaning in mind.
I am here to tell you something mooo-tiful. OR
Estoy aquí para hablarles sobre algo delicioso. TR
Estoy aquí para contarles algo muuu-licioso. RV
Explanation: we can keep the joke in Spanish! It still makes sense and makes us laugh, why would we use "delicious"? Plus, the person speaking is not "there" to "talk" but to "tell" something. The word that is nearer to the original here would be "contar".
We sure will Tooks! For $49.99 who'd resist? OR
¡Claro Tooks! Por 49.99 dólares ¿quién puede resistirse? TR
¡Claro Tooks! Por 49.99 dólares ¿Quién podría resistirse? RV
Explanation: wrong tense for "would", also fixed the lack of mayusc inside the interrogation marks per Spanish language rules.
Ask your doctor today! OR
¡Pregunta a tu médico! TR
¡Preguntale a tu médico hoy! RV
Explanation: translator omitted "today".
It makes a difference to pick up your medication... OR
Hay una diferencia entre recoger tu medicación... TR
Hay una diferencia entre recoger su medicamento... RV
Explanation: per the "Diccionario Critico de Dudas Ingles-Español de Medicina" from translator Fernando A. Navarro, it is not recommended to use "medicación" as the word itself is a "calco léxico" from the English language.
It is preferred to use terms that are commonly used and do not have English roots like "medicamento" or "medicina". I chose to use "medicamento" since "medicina" can be mistaken for "medicine".
Welcome to my... robot laboratory. OR
Bienvenidos a mi laboratorio robot. TR
Bienvenidos a mi... laboratorio de robots. RV
Explanation: the "..." are not to be omitted as they are required to create a certain effect on the person hearing.
Slight rebalance and renamings
List of changes :
- decreased brain health to 150 (instead of 200), it's high enough that medical assistance can be given if fast but low enough that you don't want to get shot
- increased damage values of weapons to baystation/nebula level (40 for a pistol for eg)
- increased adrenalin generation when hurt (less fading in and out, you can still use your gun when hit and pain won't be such a pain in the ass, but you're less likely to get back up once the final shot hits you)
- decreased relative size of lungs from 60% to 30% so that now, getting hit in the chest won't have as much chance of damaging your poor fucking lungs (yes 60% is the original baystation number.. it makes sense, it's a large organ, but it's a pain in the ass)
- changed some names and descriptions of certain weapons and firearms to better fit established naming convention -made revolvers cycle the barrel instead of eject each shot (it's a revolver, not a damn rifle)
- slightly decreased firing delay for the mk9 revolver (slightly weaker than the mateba so slightly faster firing)
- decreased firing delay for the mk9 pistol (lower caliber, less recoil, easier to magdump)
Do not allow focus to drift from fullscreen client via focusstack()
It generally doesn't make much sense to allow focusstack() to navigate away from the selected fullscreen client, as you can't even see which client you're selecting behind it.
I have had this up for a while on the wiki as a separate patch[0], but it seems reasonable to avoid this behaviour in dwm mainline, since I'm struggling to think of any reason to navigate away from a fullscreen client other than a mistake.
0: https://dwm.suckless.org/patches/alwaysfullscreen/