In a gig last year, I needed to improve the build turnaround times on a Jenkins system. After learning everything I could about Jenkins, I realized the correct answer was to delete it and rewrite my own version that ran on the local system, which was way, way faster and much easier to debug and maintain.
Not having to commit/upload your code to a build server and then wait to get an executable/package back is an enormous time-saver just in that overhead alone, but even the build itself was faster, even though it was written entirely in bashscript.
I hope this works out, but it's easy to see how it can be abused. When those abuses are addressed, the fix will undoubtedly lean on the usual fundamentals behind investing in both non-profit and for-profit ventures: due diligence on the idea and team deploying it, taking risks, hard work, and a good bit of luck.
I've been playing for almost 30 years, and I think I've ascended about 40-50 times total. My latest 3.6 install, I've ascended 11 times so far, as Wizard, Monk, Knight, Archeologist, and Samurai. Pretty sure I ascended in the high 20s on previous install w/ 3.4, and I know I have ascended at least once with every character in 3.4 (Tourist was easier than I thought it would be). Can't remember my install before that.
I concur with others. Elbereth was useless w/o a wand of fire in 3.6.0. Taught me to learn new survival habits, like staying much closer to my pet and making sure I can always go from burdened to unburdened by dropping only a sack.
Ascending is mostly luck and discipline, and the discipline comes from practice and focus. I find playing nethack calming, and it's a good way to measure how well I'm able to stay in the moment. If I die stupid, it's usually because I'm not all there.
If I'm doing something new, and I am uncertain about what my odds are, I'll read the source code.
I've only modified the source in 3.6.0 to create a general random number generator using a more robust (and more consistent) algorithm than is likely used in most libc variants. My interest there was mainly in perfect cross-platform state reproducability given the same key sequence.
Agreed. Switching to vegan brought my TP use way down. Becoming gluten-free, however, was so transformative down there that I'm still having trouble adjusting.
I usually tear off the sheets before I'm done, so that if I go multiple rounds, my TP is prepped. Usually, that means I tear off 3-4 strips of 2 squares each if it's thick paper, or strips of 3 squares if thin. After going gluten-free, I rarely end up using all the strips, and I'd say about a third the time, I'm done after using my first two squares of it, so the rest is wasted.
I find a great substitute is olive oil where I'd use butter for non-cooking (eg. instead of butter on pasta or instead of butter on bread). It's not quite as tasty but still a huge improvement over dry, and it's healthier.
For cooking, I understand olive oil is unhealthy (I think you create carcinogens as a side-effect), as are many other oils, but that coconut oil doesn't do this because of its different melting temperature.
> For cooking, I understand olive oil is unhealthy (I think you create carcinogens as a side-effect), as are many other oils, but that coconut oil doesn't do this because of its different melting temperature.
I believe the situation with oil is a bit more complicated than that, and you're generally fine with olive oil unless you make it smoke, which is fairly non-trivial to do, despite its low smoking point. There seems to be some debate on the topic: http://www.seriouseats.com/2015/03/cooking-with-olive-oil-fa...
Coconut oil in particular actually has a low smoking point. If you want to be safe, you want Avocado oil.
I encourage you to try some top-shelf olive oil, if you haven't already -- I find that it blows butter out of the water in most cases.
I initially felt the same way as you wrt tastiness, but had a friend bring me back a tin of oil from Italy recently and whoooo boy it's just the most phenomenal thing. Add a bit of salt & pepper to a shallow bowl of oil for dipping bread.
Totally agreed with this. Faces have further to go. We're not out of the uncanny valley yet.
We're also unable to create emergent materials right now, because we don't right now (and may never) have the horsepower to do molecular-level simulation to find out how light interacts with the surface. For similar reasons, breaking something open like an egg, a log, or slicing open flesh is never going to yield truly emergent results. To some degree, they'll always have to be artistically approximated on a case-by-case basis. Those approximations may have increasingly sophisticated interactions as time goes on, but I am reasonably confident they'll never truly simulate things at the molecular level.
Wont replace monitors, but you can do that now if you like. The main limitations are battery life and minimum font size (really pixel density on your retina).
I learned when writing bash scripts for cygwin under Windows that Windows doesn't support copy-on-write fork()'s. This means that any new process is extremely expensive to fork, because it copies the memory from the process it was forking from, even if it doesn't need it.
As a result, I did as much as I could using only bash internals, and very rarely did I use pipes, because they always fork()'d a bash subshell in addition to whatever the process was.
In about 7k lines of bash script written to completely automate the iterative development of two games with a shared game engine featuring dockerized server containers, I was able to avoid using sed in almost all of it. When I did use it (pretty sure only two places), it was basically for mass substitution of variables inside of text files, and the multi-line syntax worked very nicely for this, as I could form the sed line with a loop over all the variables I wanted to replace.
It turns out for most bash scripts, you can do the most common sed substitutions using bash's rich variable substitution expressions. For instance, you see in a lot of bash scripts calling commands like "dirname" and "basename" to get the directory and filename of paths. There's a much faster way to do this in bash:
That dir line means "delete the shortest string that matches /* from the end of the string". That file line means "delete the longest string matching */ from the start of the string." That other line means "replace the word stuff with the word other in this string".
Capitalism is a an extremely old game design, an MMO created to solve the complex barter chain problem. One of the game's many exploits is that sociopaths (and anyone they train through reward to override their sense of empathy) have an unfair advantage.
The key to the exploit is at the heart of the core gameplay mechanic, which is that every transaction in capitalism is a codec that decimates the complex history and state of the values and liabilities of a good or service down to a single number- the price.
So hiding the abuses of others is one of the many exploits you can hide in the compression artifacts of this global codec. The key workarounds for the exploits in scalar money commerce come in the form of laws, regulations, and investigative journalism. These are all extremely high-latency, low-reliability workarounds.
Scalar money commerce was invented as a low-tech, distributed hack to solve the complex barter chain problem. It worked, but it always had issues, and it didn't scale well.
We need to evolve beyond this primitive system of commerce that decimates everything to a single number at each transaction to one that journals state with long vectors of information tracking millions of dimensions of value and liability, and that uses more sophisticated game design and graph algorithms to solve complex barter chain problems.
In a gig last year, I needed to improve the build turnaround times on a Jenkins system. After learning everything I could about Jenkins, I realized the correct answer was to delete it and rewrite my own version that ran on the local system, which was way, way faster and much easier to debug and maintain.
Not having to commit/upload your code to a build server and then wait to get an executable/package back is an enormous time-saver just in that overhead alone, but even the build itself was faster, even though it was written entirely in bashscript.
Go figure.