1,321,062 events, 738,793 push events, 1,056,051 commit messages, 67,715,295 characters
Commit
Success button are beautiful! Love not like! You've got to try this! 100 happily paying pilots at aircrft.com who could not imagine life before aircrft.com
Merge pull request #4 from RyderBelserion/master
Fuck you github
Better README (#51)
- Update README.md
Added Gentoo
- Update README.md
- Changed yum to dnf, because yum fucking sucks
- Added a little tip to accelerate build process
- Added a Previews section with a YouTube video
- Added Lutris section
- Modified Steam section
- Changed most of the README to make it more user-friendly and easier to read in general
-
Update README.md
-
Update README.md
Fedora and Gentoo update
- Update README.md
- there is no need to build from source
- i do not want the AUR link in the README, see #20
Closes #49 Closes #50
Co-authored-by: DadSchoorse [email protected]
open: introduce openat2(2) syscall
/* Background. */ For a very long time, extending openat(2) with new features has been incredibly frustrating. This stems from the fact that openat(2) is possibly the most famous counter-example to the mantra "don't silently accept garbage from userspace" -- it doesn't check whether unknown flags are present1.
This means that (generally) the addition of new flags to openat(2) has been fraught with backwards-compatibility issues (O_TMPFILE has to be defined as __O_TMPFILE|O_DIRECTORY|[O_RDWR or O_WRONLY] to ensure old kernels gave errors, since it's insecure to silently ignore the flag2). All new security-related flags therefore have a tough road to being added to openat(2).
Userspace also has a hard time figuring out whether a particular flag is supported on a particular kernel. While it is now possible with contemporary kernels (thanks to [3]), older kernels will expose unknown flag bits through fcntl(F_GETFL). Giving a clear -EINVAL during openat(2) time matches modern syscall designs and is far more fool-proof.
In addition, the newly-added path resolution restriction LOOKUP flags (which we would like to expose to user-space) don't feel related to the pre-existing O_* flag set -- they affect all components of path lookup. We'd therefore like to add a new flag argument.
Adding a new syscall allows us to finally fix the flag-ignoring problem, and we can make it extensible enough so that we will hopefully never need an openat3(2).
/* Syscall Prototype. / /
- open_how is an extensible structure (similar in interface to
- clone3(2) or sched_setattr(2)). The size parameter must be set to
- sizeof(struct open_how), to allow for future extensions. All future
- extensions will be appended to open_how, with their zero value
- acting as a no-op default. / struct open_how { / ... */ };
int openat2(int dfd, const char *pathname, struct open_how *how, size_t size);
/* Description. */ The initial version of 'struct open_how' contains the following fields:
flags Used to specify openat(2)-style flags. However, any unknown flag bits or otherwise incorrect flag combinations (like O_PATH|O_RDWR) will result in -EINVAL. In addition, this field is 64-bits wide to allow for more O_ flags than currently permitted with openat(2).
mode The file mode for O_CREAT or O_TMPFILE.
Must be set to zero if flags does not contain O_CREAT or O_TMPFILE.
resolve Restrict path resolution (in contrast to O_* flags they affect all path components). The current set of flags are as follows (at the moment, all of the RESOLVE_ flags are implemented as just passing the corresponding LOOKUP_ flag).
RESOLVE_NO_XDEV => LOOKUP_NO_XDEV
RESOLVE_NO_SYMLINKS => LOOKUP_NO_SYMLINKS
RESOLVE_NO_MAGICLINKS => LOOKUP_NO_MAGICLINKS
RESOLVE_BENEATH => LOOKUP_BENEATH
RESOLVE_IN_ROOT => LOOKUP_IN_ROOT
open_how does not contain an embedded size field, because it is of little benefit (userspace can figure out the kernel open_how size at runtime fairly easily without it). It also only contains u64s (even though ->mode arguably should be a u16) to avoid having padding fields which are never used in the future.
Note that as a result of the new how->flags handling, O_PATH|O_TMPFILE is no longer permitted for openat(2). As far as I can tell, this has always been a bug and appears to not be used by userspace (and I've not seen any problems on my machines by disallowing it). If it turns out this breaks something, we can special-case it and only permit it for openat(2) but not openat2(2).
After input from Florian Weimer, the new open_how and flag definitions are inside a separate header from uapi/linux/fcntl.h, to avoid problems that glibc has with importing that header.
/* Testing. */ In a follow-up patch there are over 200 selftests which ensure that this syscall has the correct semantics and will correctly handle several attack scenarios.
In addition, I've written a userspace library[4] which provides convenient wrappers around openat2(RESOLVE_IN_ROOT) (this is necessary because no other syscalls support RESOLVE_IN_ROOT, and thus lots of care must be taken when using RESOLVE_IN_ROOT'd file descriptors with other syscalls). During the development of this patch, I've run numerous verification tests using libpathrs (showing that the API is reasonably usable by userspace).
/* Future Work. */ Additional RESOLVE_ flags have been suggested during the review period. These can be easily implemented separately (such as blocking auto-mount during resolution).
Furthermore, there are some other proposed changes to the openat(2) interface (the most obvious example is magic-link hardening[5]) which would be a good opportunity to add a way for userspace to restrict how O_PATH file descriptors can be re-opened.
Another possible avenue of future work would be some kind of CHECK_FIELDS[6] flag which causes the kernel to indicate to userspace which openat2(2) flags and fields are supported by the current kernel (to avoid userspace having to go through several guesses to figure it out).
[3]: commit 629e014bb834 ("fs: completely ignore unknown open flags") [4]: https://sourceware.org/bugzilla/show_bug.cgi?id=17523 [5]: https://lore.kernel.org/lkml/[email protected]/ [6]: https://youtu.be/ggD-eb3yPVs
Suggested-by: Christian Brauner [email protected] Signed-off-by: Aleksa Sarai [email protected] Signed-off-by: Al Viro [email protected]
arm: Move to upstream udelay via timer implementation
This is a squash of a handful of changes and reverts of the Qualcomm specific implementation:
Revert "arm: Implement a timer based __delay() loop"
This reverts commit 976eafa8b18252876e15f861944acf693b07ce7e.
Revert "arm: Allow machines to override __delay()"
This reverts commit bc0ef8ab167272890f1aab62928b04a9aeb87ce9.
Revert "arm: Translate delay.S into (mostly) C"
This reverts commit 8d5868d8205d10a0a8e423f53e9cc9bb3e9d1a34.
ARM: 7451/1: arch timer: implement read_current_timer and get_cycles
This patch implements read_current_timer using the architected timers when they are selected via CONFIG_ARM_ARCH_TIMER. If they are detected not to be usable at runtime, we return -ENXIO to the caller.
Furthermore, if read_current_timer is exported then we can implement get_cycles in terms of it for use as both an entropy source and for implementing __udelay and friends.
Tested-by: Shinya Kuribayashi [email protected] Reviewed-by: Stephen Boyd [email protected] Signed-off-by: Will Deacon [email protected] Signed-off-by: Russell King [email protected]
ARM: 7452/1: delay: allow timer-based delay implementation to be selected
This patch allows a timer-based delay implementation to be selected by switching the delay routines over to use get_cycles, which is implemented in terms of read_current_timer. This further allows us to skip the loop calibration and have a consistent delay function in the face of core frequency scaling.
To avoid the pain of dealing with memory-mapped counters, this implementation uses the co-processor interface to the architected timers when they are available. The previous loop-based implementation is kept around for CPUs without the architected timers and we retain both the maximum delay (2ms) and the corresponding conversion factors for determining the number of loops required for a given interval. Since the indirection of the timer routines will only work when called from C, the sa1100 sleep routines are modified to branch to the loop-based delay functions directly.
Tested-by: Shinya Kuribayashi [email protected] Reviewed-by: Stephen Boyd [email protected] Signed-off-by: Will Deacon [email protected] Signed-off-by: Russell King [email protected]
ARM: delay: set loops_per_jiffy when moving to timer-based loop
The delay functions may be called by some platforms between switching to the timer-based delay loop but before calibration. In this case, the initial loops_per_jiffy may not be suitable for the timer (although a compromise may be achievable) and delay times may be considered too inaccurate.
This patch updates loops_per_jiffy when switching to the timer-based delay loop so that delays are consistent prior to calibration.
Signed-off-by: Will Deacon [email protected]
ARM: delay: add registration mechanism for delay timer sources
The current timer-based delay loop relies on the architected timer to initiate the switch away from the polling-based implementation. This is unfortunate for platforms without the architected timers but with a suitable delay source (that is, constant frequency, always powered-up and ticking as long as the CPUs are online).
This patch introduces a registration mechanism for the delay timer (which provides an unconditional read_current_timer implementation) and updates the architected timer code to use the new interface.
Signed-off-by: Jonathan Austin [email protected] Signed-off-by: Will Deacon [email protected]
ARM: export default read_current_timer
read_current_timer is used by get_cycles since "ARM: 7538/1: delay: add registration mechanism for delay timer sources", and get_cycles can be used by device drivers in loadable modules, so it has to be exported.
Without this patch, building imote2_defconfig fails with
ERROR: "read_current_timer" [crypto/tcrypt.ko] undefined!
Signed-off-by: Arnd Bergmann [email protected] Cc: Stephen Boyd [email protected] Cc: Jonathan Austin [email protected] Cc: Will Deacon [email protected] Cc: Russell King [email protected]
Change-Id: If1ad095d6852f5966ea995856103e06de6ab2f59 Signed-off-by: Stephen Boyd [email protected]
Conflicts: arch/arm/lib/delay.c
"10:05am. I got up 20m ago. Let me see if I can go through vol 9 and then I will start.
So far, my impression of Dendro is that it is really good. Especially the characterization - Hell General acting like a cartoon villain and then being shown to be a 10 year old kid throwing a tantrum after getting BTFOd is quite credible. The author is quite talented to be able to show this. Dendro is more than just the MC being thrown in some fantasy world and being given powers - the border between the world is there, and it is getting used.
10:20am. Ok, focus me. Waste time in the right way.
Right now, I am reading Dendro, but decided to check out this thread on a whim.
"Look into sparse evolutionary training, it’s using genetic algorithms to configure networks for learning. Also symbolic regression is starting to gain popularity again as more modern uses have been published last year. Type those in using google scholar and you’ll see some cool stuff. The SET technique above was published in Nature I believe. If you have troubles let me know I can find the papers for you ❤️"
This stuff is new to me, I'll definitely keep it in mind. I never really looked into symbolic regression for real either though the talk by Lipshuts that I watched way before I started this quest really sold me on its potential.
After everything is done, I will really be innovating in the direction of using evolution together with NNs.
https://www.reddit.com/r/MachineLearning/comments/eqdad9/d_a_sober_look_at_bayesian_neural_networks/
I'll look at this at a later date, let me get back to my vacationing.
1:25pm. Done with vol 9. I've really been indulging myself for the past 1.5 weeks.
I think that starting next week I will try taking things a bit more seriously. The way things are going is taking too long, so I get to testing the new language soon. I'll roll up my sleeves and put in a few extra hours if possible and get back to my old pace.
1:30pm. I really can't keep working on the language forever.
I need to get back into ML.
So for the near term, at least finishing the first half should be my main priority. Even if I decide to skip typechecking for some reason, I still need to beef up Spiral's compilation speeds. So that is work that absolutely needs to be done.
1:35pm. Just one more time. I will evolve the language one final time and then try again.
The way I was approaching ML reminds me of how in the past I'd approached roguelike games like Diablo. At that time the degree of caution needed to win at roguelikes was completely foreign to me.
Games like Angband I've tried getting into many, many times and every time I would get creamed and die. Back when I was a kid I liked using cheats, and I like exploring immersive worlds and collecting stuff. The challenge was secondary.
Me becoming capable of beating Angband, DCSS, DoomRL is a fairly recent phenomenon.
I guess when I decided to become a trader it brought a change in my mindset and approach towards the games. It is not just that I had a fundamentally different approach to these games - I did. It is also that I had changed my affinities - I started to enjoy playing in the new style. And that made a world of difference in my survivability.
It is really a pity that I could never get anywhere with trading. If you are aiming for longer term, beating the market is not too hard, but you'll never get anywhere with 3k which was my situation. I've seen good daytraders do it as a challenge, but they already had the necessary skills developed from before.
But that is a thing of the past now. If my AI plan succeeds, I will never have to trade again anyway, at least as far as financial instruments are concerned.
1:45pm. For the past 5 years I've been slowly building my skills. I've ignored all the shortcuts and did all the exercises.
I think I know a lot in both ML and PL now.
Just like with roguelikes, it is not that even back then I was too dumb to really beat them. It is just that I've been approaching ML too much like regular programming and am getting irate when I get pushback from reality.
Sure, I might not know how NNs and CFR really work. I cannot reason it out.
In the future there might be some genius who can do these things that I cannot.
1:50pm. But at a certain point one needs to accept that there are classes of algorithms that are simple, but due to various reasons (such as working in continuous spaces) cannot be reasoned about.
It is like - suppose I did not understand basic addition of natural numbers. Then I'd get obsessed about mastering the 'fundamentals', crack open the books and get down to the bare circuits.
I'd find that addition can be done in terms of various logic circuits and train myself to reason about them in those terms.
And yet, while this effort might gain me that reasoning ability, I would be no closer to understanding at all.
It is like a being with no visual system trying to understand geometry.
...
No doubt there are higher levels of intelligence not allowed to humans that might allow shedding light on these basic algorithms, but I can honestly say that I gave it my best shot. Whatever understanding I wanted to unearth with my 2019 effort is certainly beyond my ability.
Hard thinking and great effort will not suffice here.
1:55pm. Instead I will accept that what I had was simply naivety and change my approach to something more befitting of a person living in this era.
I'll think of ML as science itself, and think of backprop as nothing more than greedy improvement. I'll assume that there is no secret sauce - rather what I need to do is increase the roboustness of it in various domains through the sheer weight of my programming skill.
Forget about money and ML both.
What I need to do is find a way to make an expression of science. Reach the new perspective and grasp it. Program in a altogether different manner.
Leave the others to waste their time trying to fiddle with the rules and architectures.
This is in fact what I said I would do, but I got completely obsessed with gaining 'understanding'. The end result is that the more I learned, the further I move away from it.
2pm. If I moved with the assumption that algorithms were understanding itself - this is something that everybody deep down already believes and acts upon anyway, then I would have not gotten so completely lost. I would not have started crying blood and fuming fire as soon as I realized what a scam modern math is.
...
I really am deeply regretful that I could not realize all of this soon. Before I even stared work on ML, I should have realized that I do not really understand even much simpler algorithms that work in rational spaces. Had I done so, I would not have wasted so much time trying to drill a hole through reality.
I want redemption for this sin.
And the best way to do this is to dedicate myself wholly to programming once more.
This time, I won't ask for money, understanding, recognition or anything else from the art.
2:05pm. When I was a kid, I realized something deep in my core. At that point I did not know about the Singularity or anything like that, but I could tell - the era I lived in was special.
The games that can be played on the computer are special.
The world beyond the screen is the world the God only knows.
2:10pm. I need to do it. Failures and victories do not matter.
What is important is that I express my understanding of what understanding really is.
Do I really want to give up here and be a monkey for the rest of my life? Or do I want to act as one of the predecessors to the Inspired?
Things such as life can be left to lesser creatures. I have the boundary to break."
Set scrollview on the power menu
So why? Because fuck you that's why...
No, you need this for if and when we decide to add more items to the power menu and the density is too high. Previously if you had more than 5 items, it would cut you off. So you either had to decide which 5 items you wanted or deal with the jank. That's no longer the case.
-
Added a landscape view so we can set a horizontal scrollview
-
Made the power menu dialog all one color. Josh and I talked about this and I previously made the case to keep it the same but after thinking it over, it looks better all one color.
Change-Id: I8ec4b1a85994251126433cea0640e000af78c65d
Illegal Wall Jumping
Tweaks:
- Armory given another touch-up. Bullpups are back, but with lower firepower. The description explains it. Additionally, there's two boxes of twelve flares, totalling twenty-four if you can't count. Two boxes of twelve grenades in the hard armoury, along with four Bullpup mags.
- First pass of random illegal loot. Probably messed it up right good, but, we'll see. The stuff spawns where you'd expect illegal loot to spawn.
- Liaison has been given some love. They get their old one-way handgun back, alongside a cyanide pill instead of generic 'toxins'.
Created Text For URL [www.nation.co.ke/lifestyle/saturday/I-lost-the-love-of-my-life-and-only-one-thing-saved-me/1216-5422088-75xvtc/index.html]
fuck you moregit add large_flask_application/my_project/puppies/views.py !
fuck you git add large_flask_application/app.py git add large_flask_application/app.py
Update Depth3D.fx
Depth3D: Harden to help prevent cheating. -=let me know if I can do more=-
+Cursor Is now Bound to the 3D image only. +Removed Depth Buffer Debug view to keep users from using this to cheat. +Basic VR Compatibility added so that it can be used with VR Desktop apps. +Basic Theater Mode added for Cellphone VR users. +Renamed many items in the UI to help new users with controlling this shader. +New Depth Detection Code. +New Screen Boundary Detection added. +Edge Handling added from SuperDepth3D
Fixed issues with the UI in Freestyle and automated many functions as I could to reduce UI clutter. The idea was to keep as much of the functionality as possible without sacrificing too much.
Fixed issues with NV System that was causing a black screen on my Testers PC. This was not easy, I had to remote into a user's pc halfway across the world since I needed someone with an NV Card that was able to help me. Seems like this may be an issue for me with porting my other shaders. Thank you, Durante - aka Dorinte & TheGordinho - aka Gordinho
The goal of Depth3D to allow users to experience the world of 3D Gaming by adding real depth to your game. -=This shader requires depth access to work=-
This shader will work with 3D TV, 3D Monitors, and the NEW VR HMDs. The VR Theater experience worth exploring in VR. Here are two free applications for VR Headsets That I seen people use that anyone can try. Virtual Space https://store.steampowered.com/app/703480/Virtual_Space/ Big Screen https://bigscreenvr.com/help/gettingstarted/sbs3d/
Older games and non-VR games can benefit from being played again with Stereo3D. I have been working on My 3D Shader for some time now and learned how to improve things over time even with limitations. My hope is to share this experience with as many people as possible. I would like this shader to be considered as a standard shader to be used as openly as NV discontinued 3DVision Stereo Software. Since I know many users in the 3D community still enjoy 3D gaming.
Please let me know if there is anything I can change. That can help. Thank you.
Noted Issues One of the things that bug me with Depth3D It's hard to use for new users. So I will be making better tutorials when I have the hardware to do so for VR.
Testing custom races, might fail idk, this is so fucking stupid i just slapped this shit in.
cmd, p2p: What in god's name have you brought upon this cursed land.