speedcrunch is wonderful but I had this pet peeve with it where it had a hardcoded limit of 5 digits before it drops to scientific notation. Not very useful for shell scripts and programming.
I opened an issue while it was on bitbucket, but the response was something "yeah, that's intentional".
2) there are algorithms that calculate digits of Pi or e.
so... yes?
but if I just took any old Pi-digits algorithm and encoded it on GoL, its appearance would not be meaningful or "elegant" to our senses. You're probably asking "what does the shortest/most elegant program to calculate Pi in GoL look like, and does it maybe have some unexpected relation to other mathematical terms like, I dunno, Euler's identity or... Mandelbrot set?" And then you would probably need to answer the question "Well, how would you like the digits encoded and represented?".
All of a sudden your question becomes a bit ambiguous. Or did I misunderstand what you meant?
I mean.... I think I feel what you're asking, like... is there some primal version of Pi that can be encoded in GoL initial condition with as few bits as possible but I'm afraid that the answer is something like "well, that depends on what you mean by [...]"
yes you are right the question was ambiguous. WHat I was really looking for is if there is a way to physically derive PI out of some basic cellular automata operations. that does not necessarily have to involve circles etc. much less so about representing digits of PI itself. just that an pattern that evolves into ever more accurate values of pi (or a quantity derived from pi). this definitly must not be encoded or somehow preprogrammed into the GoL's initial condition. In fact I dont even care if the evolution rules of standard GoL are followed. just that SOME set of rules automatically produce PI-derivative.
the reason it would be cool is because then we've taken a most fundamental geometric constant and derived it from purely graph update type of mechanics. if you could do that then likely you can do a whole set of other things like physical laws.
From a cynical point of view, the point of democracy is to get the people to blame each other - for voting for the wrong party, for not voting at all, for voting for one of the two big parties or for voting for the spoiler. And thus prevent revolution or murder of politicians.
Inferring who you would vote for doesn't accomplish this as well.
What if the AI looked at all the data and voted for the representatives who'd be best to better their "master"'s life?
Although then, Zuck's, Bezos' and Musk's AI would still send out lobbyists to manipulate politicians to fuck us plebs over (Hah, the overpaid codemonkey thinks he's a pleb...).
It'll be a future when an AI orders escorts be sent to Supreme Court justices' rooms in the golf vacations paid for by the billionaire. "Data says, Justice [____] likes long haired blondes with nice buttocks, send Tiffany. She should bring beer, he likes beer.".
That is obviously not what I meant by "solving it with bash" and well you know it.
First, one often needs to set PYTHONPATH etc, and this is best done near the point of execution, in a wrapper script and not wangling around in ~/.bash_profile where it gets forgotten, and is not project-specific.
Secondly, and more importantly, your suggestion assumes the venv lives in a fixed location. This is unlikely to be the case.[1] What is preferable is something which is independent of filesystem location. The bin/run-python script is able to find its location on the filesystem, and the location of the venv relative to it.
[1] You might have a custom python distribution with a bunch of modules installed into a well-known location and therefore using that for the python in your application is a reasonable solution, but that is not what we are talking about here.
Nvidia has open-sourced the kernel module "driver", which recently have been declared stable enough for general consumption.
But the kernel-mode driver is only a small part of what you would call the graphics card driver, and the bulk of it is still very much a proprietary blob.
The true open source driver for NV cards is Noveau[1] which works ok with older cards but is slow to support newest cards and features. Performance, power mgmt and hw acceleration are usually worse or not working at all compared to the official drivers.
One of my guys made a mistake while deploying some config changes to Production and caused a short outage for a Client.
There's a post-incident meeting and the client asks "what are we going to do to prevent this from happening in the future?" - probably wanting to tick some meeting boxes.
My response: "Nothing. We're not going to do anything."
The entire room (incl. my side) looks at me. What do I mean, "Nothing?!?".
I said something like "Look, people make mistakes. This is the first time that this kind of mistake had happened. I could tell people to double-check everything, but then everything will be done twice as slowly. Inventing new policies based on a one-off like this feels like an overreaction to me. For now I'd prefer to close this one as human error - wontfix. If we see a pattern of mistakes being made then we can talk about taking steps to prevent them."
In the end the conceded that yeah, the outage wasn't so bad and what I said made sense. Felt a bit proud for pushing back :)
[preface that this response is obviously operating on very limited context]
"Wanting to tick some meeting boxes" feels a bit ungenerous. Ideally, a production outage shouldn't be a single mistake away, and it seems reasonable to suggest adding additional safeguards to prevent that from happening again[1]. Generally, I don't think you need to wait until after multiple incidents to identify and address potential classes of problems.
While it is good and admirable to stand up for your team, I think that creating a safety net that allows your team to make mistakes is just as important.
I didn't want to add a wall of text for context :) And that was the only time I've said something like that to a client. I was not being confrontational, just telling them how it is.
I suppose my point was that there's a cost associated with increasing reliability, sometimes it's just not worth paying it. And that people will usually appreciate candor rather than vague promises or hand-wavy explanations.
I had a similar situation, but in my case was due to a an upstream outage in a AWS Region.
The final assessment in the Incident Review was that we should have a multi-cloud strategy. Our luck that we had a very reasonable CTO that prevented the team do to that.
He said something along the lines that he would not spend 3/4 of a million plus 40% of our engineering time to cover something that rarely happens.
We've started to note these wont-fixes down as risks and started talking about probability and impact of these. That has resulted in good and realistic discussions with people from other departments or higher up.
Like, sure, people with access to the servers can run <ansible 'all' -m cmd -a 'shutdown now' -b> and worse. And we've had people nuke productive servers, so there is some impact involved in our work style -- though redundancy and gradually ramping up people from non-critial systems to more critical systems mitigates this a lot.
But some people got a bit concerned about the potential impact.
However if you realistically look at the amount of changes people push into the infrastructure on a daily basis, the chance of this occurring seems to very low - and errors mostly happen due to pressure and stress. And our team is already over capacity, so adding more controls on this will slow all of our internal customers down a lot too.
So now it is just a documented and accepted risk that we're able to burn production to the ground in one or two shell commands.
The amount of deliberate damage anyone on my team can do is pretty much catastrophic. But we accept this as risk. It is appropriate for the environment. If we were running a bank, it would be inappropriate, but we're not running a bank.
I pushed back on risk management one time when The New Guy rebuilt our CI system. It was great, all bells and whistles and tests, except now deploying a change took 5 minutes. Same for rolling back a change. I said "Dude, this used to take 20 seconds. If I made a mistake I would know, and fix it in 20 seconds. Now we have all these tests which still allow me to cause total outage, but now it takes 10 minutes to fix it." He did make it faster in the end :)
Good, but I would have preferred a comment about 'process gates' somewhere in there [0]. I.e. rather than say "it's probably nothing let's not do anything" only to avoid the extreme "let's double check everything from now on for all eternity", I would have preferred a "Let's add this temporary process to check if something is actually wrong, but make sure it has a clear review time and a clear path to being removed, so that the double-checking doesn't become eternal without obvious benefit".
When you have zero incidents using the temporary process people will automatically start to assume it’s due to the temporary process, and nobody will want to take responsibility for taking it out.
I agree with the implication, but don't think this applies here. The scenario here is a safety net, i.e. something that visibly "catches" errors, at a cost. If you have zero incidents "caught" during the evaluation period, then the evaluation result is that the cost isn't worth paying.
Obviously if you're planning to implement a vague deterrent-style solution which you have no means (or intent) of evaluating just to check a box, you're better off not doing it.
Yep yep, exactly this. When an incident review reveals a fluke that flew past all the reasonable safeguards, a case that the team may have acknowledged when implementing those safeguards. Sometimes those safeguards are still adequate, as you can’t mitigate 100% of accidents, and it’s not worth it to try!
I’d go further to say that it’s a trap to try, it’s obvious that you can’t get 100% reliability, but people still feel uneasy with doing nothing
> If we see a pattern of mistakes being made then we can talk about taking steps to prevent them.
...but that's not really nothing? You're acknowledging the error, and saying the action is going to be watch for a repeat, and if there is one in a short-ish amount of time, then you'll move to mitigation. From a human standpoint alone, I know if I was the client in the situation, I'd be a lot happier hearing someone say this instead of a blanket 'nothing'.
Don't get me wrong; I agree with your assessment. But don't sell non-technical actions short!
The abbreviated story I told was perhaps more dramatic-sounding than it really played out. I didn't just say "Nothing." mic dropwalk out :)
The client was satisfied after we owned the mistake, explained that we have a number of measures in place for preventing various mistakes, and that making a test for this particular one doesn't make sense. Like, nothing will prevent me from creating a cron job that does "rm -rf * .o". But lights will start flashing and fixing that kind of blunder won't take long.
If you want to go full corporate, and avoid those nervous laughs and frowns from people who can't tell if you're being serious or not, I recommend dressing it up a little.
Corollary is that Risk Management is a specialist field. The least risky thing to do is always to close down the business (can't cause an incident if you have no customers).
Engineers and product folk, in particular, I find struggle to understand Risk Management.
When juniors ask me what technical skill I think they should learn next my answers is always; Risk Management.
(Heavily recommended reading: "Risk, the science and politics of fear")
> Engineers and product folk, in particular, I find struggle to understand Risk Management.
How do you do engineering without risk management? Not the capitalized version, but you’re basically constantly making tradeoffs. I find it really hard to believe that even a junior is unfamiliar with the concept (though the risk they manage tends to be skewed towards risk to their reputation).
Yeah. Policies, procedures, and controls have costs. They can save costs, but they also have their own costs. Some pay for themselves; some don't. The ones that don't, don't create those procedures and controls.
Actually it was the Ati Radeon 9500 non pro that could be modded into a Radeon 9700. Regarding the ATI Radeon 9600, there was a variant called Radeon 9550 that could be overclocked from 250 mhz to 400 mhz.
And my personal favorite, the Radeon 9100 which was actually a Radeon 8500 in PCI format instead of AGP. With a slightly tweaked 8500 Mac Edition bios you would have a very fast GPU for first gen PCI Macs through the Yikes G4. I believe some faster NVidia PCI cards ended up appearing and being made to run on Macs but I had moved from my XPostfacto PCI Macs to an Intel mini by then.
> Actually it was the Ati Radeon 9500 non pro that could be modded into a Radeon 9700.
Sometimes. At least some of those 9500s were binned parts that showed their broken bits when you modded them. I had one. The screen turned into a kaleidoscope when I tried to play a game.
except it's worse, if you manage to get some info out of it, it could all be just hallucinated, you were told a lie and no one is responsible.
it's like the only purpose is to erect a barrier between the company and its clients.
reply