1,032,846 events, 590,171 push events, 908,331 commit messages, 70,425,856 characters
big refactor, start trying to make a pam module
This refactors damn near everything to use separate crates, including
putting the main auth logic into a crate so that it can be called
from tp-exec (a pam_exec shim that we can ship for platforms we
can't build dynamic binaries for) and pam itself. This also adds the
boilerplate for a proper pam module.
The big annoying part about this pam module is that they don't seem to have the pam_getenvlist function implemented for "dear god this is totally unsafe" kinds of reasons. However I think I have a way to at least mitigate a lot of the danger.
Signed-off-by: Christine Dodrill [email protected]
Adding my Submission for Hacktoberfest
Be fair haha im really noob with HTML CSS, i've google a lot.. xD
But thanks for this experience, i will look to make the Slack clone too (but not counting for hacktoberfest), i really enjoyed doing this one, and i think i will make it again to rework the smartphone version that i was too noob to create.
Thanks for this experience!
Fix camera centering for smaller boards
Am I shit at math? Definitely. Does the border make it look like Megazeux? Hell yeah.
fuck you
get fuckin pranked itiot. now get yo BUM. ASS. outta my repo.
Removes dead code in techwebs, alongside some truly evil macros (#61936)
fuck you kevin
api: adapter: replace INF Include/Needs hack with race loop
Apparently breaking the guarantee of "Universal INF"s in spirit receives the big tsk tsk, so this commit comes up with yet another way to set SuggestedInstanceId.
We create an SwDevice, then destroy it, and then set the SuggestedInstanceId key for the created instance. In case NetSetup got to run and actually assigned a NetCfgInstanceId, we also delete that key, so it gets created again from SuggestedInstanceId. Then, we create the SwDevice again, and this time it picks up the SuggestedInstanceId. Ideally, NetSetup never gets very far, because we race on the instance being created, but destroy the SwDevice extra fast. But if it does get far, that's a bit ugly but not a problem because we clean up NetCfgInstanceId (and hopefully it's not a problem for NLA signature accumulation). In basically all cases I can see, however, the destruction happens before NetSetup even has a chance to run, and so things work as planned.
This is too ugly for my tastes, and I'd like a better way of doing this that doesn't require two SwDevices.
Signed-off-by: Jason A. Donenfeld [email protected]
lib/sort: make swap functions more generic
Patch series "lib/sort & lib/list_sort: faster and smaller", v2.
Because CONFIG_RETPOLINE has made indirect calls much more expensive, I thought I'd try to reduce the number made by the library sort functions.
The first three patches apply to lib/sort.c.
Patch #1 is a simple optimization. The built-in swap has special cases for aligned 4- and 8-byte objects. But those are almost never used; most calls to sort() work on larger structures, which fall back to the byte-at-a-time loop. This generalizes them to aligned multiples of 4 and 8 bytes. (If nothing else, it saves an awful lot of energy by not thrashing the store buffers as much.)
Patch #2 grabs a juicy piece of low-hanging fruit. I agree that nice simple solid heapsort is preferable to more complex algorithms (sorry, Andrey), but it's possible to implement heapsort with far fewer comparisons (50% asymptotically, 25-40% reduction for realistic sizes) than the way it's been done up to now. And with some care, the code ends up smaller, as well. This is the "big win" patch.
Patch #3 adds the same sort of indirect call bypass that has been added to the net code of late. The great majority of the callers use the builtin swap functions, so replace the indirect call to sort_func with a (highly preditable) series of if() statements. Rather surprisingly, this decreased code size, as the swap functions were inlined and their prologue & epilogue code eliminated.
lib/list_sort.c is a bit trickier, as merge sort is already close to optimal, and we don't want to introduce triumphs of theory over practicality like the Ford-Johnson merge-insertion sort.
Patch #4, without changing the algorithm, chops 32% off the code size and removes the part[MAX_LIST_LENGTH+1] pointer array (and the corresponding upper limit on efficiently sortable input size).
Patch #5 improves the algorithm. The previous code is already optimal for power-of-two (or slightly smaller) size inputs, but when the input size is just over a power of 2, there's a very unbalanced final merge.
There are, in the literature, several algorithms which solve this, but they all depend on the "breadth-first" merge order which was replaced by commit 835cc0c8477f with a more cache-friendly "depth-first" order. Some hard thinking came up with a depth-first algorithm which defers merges as little as possible while avoiding bad merges. This saves 0.2*n compares, averaged over all sizes.
The code size increase is minimal (64 bytes on x86-64, reducing the net savings to 26%), but the comments expanded significantly to document the clever algorithm.
TESTING NOTES: I have some ugly user-space benchmarking code which I used for testing before moving this code into the kernel. Shout if you want a copy.
I'm running this code right now, with CONFIG_TEST_SORT and CONFIG_TEST_LIST_SORT, but I confess I haven't rebooted since the last round of minor edits to quell checkpatch. I figure there will be at least one round of comments and final testing.
This patch (of 5):
Rather than having special-case swap functions for 4- and 8-byte objects, special-case aligned multiples of 4 or 8 bytes. This speeds up most users of sort() by avoiding fallback to the byte copy loop.
Despite what ca96ab859ab4 ("lib/sort: Add 64 bit swap function") claims, very few users of sort() sort pointers (or pointer-sized objects); most sort structures containing at least two words. (E.g. drivers/acpi/fan.c:acpi_fan_get_fps() sorts an array of 40-byte struct acpi_fan_fps.)
The functions also got renamed to reflect the fact that they support multiple words. In the great tradition of bikeshedding, the names were by far the most contentious issue during review of this patch series.
x86-64 code size 872 -> 886 bytes (+14)
With feedback from Andy Shevchenko, Rasmus Villemoes and Geert Uytterhoeven.
Change-Id: I41a3e385e23541a26b37492a0b60b7faf6ff0613 Link: http://lkml.kernel.org/r/f24f932df3a7fa1973c1084154f1cea596bcf341.1552704200.git.lkml@sdf.org Signed-off-by: George Spelvin [email protected] Acked-by: Andrey Abramov [email protected] Acked-by: Rasmus Villemoes [email protected] Reviewed-by: Andy Shevchenko [email protected] Cc: Rasmus Villemoes [email protected] Cc: Geert Uytterhoeven [email protected] Cc: Daniel Wagner [email protected] Cc: Don Mullis [email protected] Cc: Dave Chinner [email protected] Signed-off-by: Andrew Morton [email protected] Signed-off-by: Linus Torvalds [email protected] Signed-off-by: Panchajanya1999 [email protected] Signed-off-by: Angga [email protected]
"9:45pm. https://youtu.be/44HBr8O-kPk?t=404
I've just realized that the guy was using Photoshop. Take a look at the top left corner. Visually PS and AI looked so similar that it never occurred to me to actually check what program he is using. I just assumed it was the Illustrator. That settles that mystery. I'll have to go for freeform gradients, I can't just blend colors like the dude did. Well, actually, it might be possible if I make a cutout of the surounding layer and blend that instead. But the actual gradient tools would be more ergonomic.
Freeform gradients are a wonderful thing so I should use them.
That settles one mystery.
9:50pm. Tomorrow I will watch a few more videos and then get cracking. Apart from not really knowing how to combine different artworks into something unique - so far I've only seen traced portraits, it bothers me that I only have two tracks composed in my head. They caught my attention and I want to create them, but I'll need more. At least a dozen or two.
10:05pm. This is a bit fun. I've figured out the third one. I was trying to figure out something to represent transcendence, but nothing is coming to me. It is too nebulous as a concept, and I can't associate a melody to it.
Even though it was by accident, I figured out the Violence track.
So far I have Boredom (At School), Doom (For NPCs) and (Transcendent) Violence.
It is really coming together well in my mind. This is really a new experience for me, if I was just my old self doing just writing I would never have reached this level. I would have just languished where I was before.
There is power in attempting to what was thought to be beyond one's grasp.
10:10pm. This could turn out really well.
The Boredom track especially will be very catchy. In fact the whole school sequences will give a voice to a feeling never ellucidated before. I think just the intro being done properly will grasp the hearts of those who play it.
Yeah, the ingredients are all there to create a roaring flame that will lift me higher in my air baloon, but it is still up to luck. That is the nature of the market. To ensure the success of the game, I must never indulge. This time I'll be a pro from start to finish.
10:20pm. I am actually having a lot of fun listening to Boredom track in my mind. The only thing I feel towards it is longing.
10:40pm. Maybe longing is what should be the motif of the Transcendence song. (Longing For) Transcendence.
Let me take a look at this. After that I'll watch slime.
I've played Vigil: Longest Night for a while, but its gameplay is not that good. It's artwork is well done, but that is it."
remove useless shit
every JS developer who pulls in anything that tries to build node-gyp on my machine needs to die a horrible, agonizing, slow death
fuck you byond fuck you fuck you fuck you fuck you fuck you
Merge bitcoin/bitcoin#21711: guix: Add full installation and usage documentation
fac4814106c796b8786dd90053513cc35142dfe5 doc/release-process: Add torrent creation details (Carl Dong) 5d24cc3d82dad6812f8370c3ccc7c2b5a6c12c11 guix/INSTALL: Guix installs init scripts in libdir (Carl Dong) 5da2ee49d5b44de803b671aedbdd14e5c1d71ea9 guix/INSTALL: Add coreutils/inotify-dir-recreate troubleshooting (Carl Dong) 318c60700b7bbb7ec09a29bf037e7c2787646be6 guix: Adapt release-process.md to new Guix process (Carl Dong) fcab35b2292f9221eaba521740e8b3b2511a8b78 guix-attest: Produce and sign normalized documents (Carl Dong) c2541fd0ca99481a5a792a8f2772925d64fb0491 guix: Overhaul README (Carl Dong) 46ce6ce3782dfbd8f9d26dc2ba0f284755e75f2d tree-wide: Rename gitian-keys to builder-keys (Carl Dong) fc4f8449f34e32b0b9ac9d218d6c3264b02467ba guix: Update various check_tools lists (Carl Dong) 263220a85c1df218431fafbda07c8b23ccc4ce4d guix: Check for a sane services database (Carl Dong)
Pull request description:
Based on: #21462
Keeping the README in one file so that it's easy to search through. Will add more jumping links later so navigation is easier.
Current TODOs:
- Shell installer option: prompt user to re-login for
/etc/profile.dentry to be picked up - Binary tarball option: prompt user to create
/etc/profile.dentry and re-login - Fanquake docker option: complete section
- Arch Linux AUR option: prompt to start
guix-daemon-latestunit after finishing "optional setup" section - Building from source option: Insert dependency tree diagram that I made
- Building from source option: redo sectioning, kind of a mess right now
- Optional setup: make clear which parts are only needed if building from source
- Workaround 1 for GnuTLS: perhaps mention how to remove Guix build farm's key
- Overall (after everything): Make the links work.
Note to self: wherever possible, tell user how to check that something is true rather than branching by installation option.
ACKs for top commit: fanquake: ACK fac4814106c796b8786dd90053513cc35142dfe5 - going to go ahead and merge this now. It's a lot of documentation, and could probably be nit-picked / improved further, however, that can continue over the next few weeks. I'm sure more (backportable) improvements / clarifications will be made while we progress through RCs towards a new release.
Tree-SHA512: dc46c0ecdfc67c7c7743ca26e4a603eb3f54adbf81be2f4c1f4c20577ebb84b5250b9c9ec89c0e9860337ab1c7cff94d7963c603287267deecfe1cd987fa070a