IMO, people generally only want a few things out of work:
- Sufficient money so you don't feel ripped off or left behind compared to others in your social class
- Agency over your day - you can take an afternoon off if you're feeling down, your kids are sick, etc
- Enough free time to relax and have an out of work life
- Lack of obstacle/roadblocks to actually doing good work
Most modern companies get all of this wrong. They pay the bare minimum and raises are small and slow, encouraging job hopping. You have to beg for time off like a child. No clearly defined off hours for most employees. The daily job is filled with bureaucracy and excessive micromanagement that slow you down at every turn.
Being disengaged is the logical response to these conditions.
The entire history of programming languages has been:
- Create a simplistic programming language that looks easy to learn and use but ends up being deceptively complex to apply to real world problems
- Fix those problems with a more rigorous approach that's hard to learn but stands up to real pressure
- Ignore all the lessons learned and create another simplistic programming language that looks easy to learn and use but ends up being deceptively complex to apply to real world problems
If we all agree to stop using Javascript and replace it with something that doesn't have Javascript's baggage I have full confidence that somebody will invent a new "simple" approach on top of that approach that will have all the same oversights Javascript had.
Margaret Hamilton coined the term "software engineering" circa 1965, because she recognised that she and her fellow Apollo programmers were doing engineering, and had to be doing engineering, because otherwise people would die.
Engineering involves requirements analysis, specification, and the mathematical analysis of families of components to demonstrate – according to the known laws of reality – that the proposed solution meets the requirements and won't kill people.
E.W.Dijkstra advocated, repeatedly, from the 1970s onwards (EWD340 – and probably earlier than that also), that software should be formally-analysed and -verified as a matter of course. He called this humility. We call him arrogant, and insane.
Explain to me why you need a language that is pervasively memory unsafe.
And be sure you don't cite reasons why you need unsafe callouts to unsafe capabilities. Nobody denies that.
Explain why you need a language that is pervasively unsafe, unsafe by default. Explain to me what code you are writing that has to routinely access memory outside of arrays. Explain to me what code you are writing that simply must be able to use pointers to access memory in unsafe ways.
In a nutshell, explain what these amazing benefits are to memory-unsafe languages that somehow offset the many and manifold costs we've found over years of usage.
Memory safety in a modern language is not only virtually free, it's a positive benefit. I simple do not see an argument for memory unsafe languages, especially given that every single one of them ship with "unsafe" capabilities available on demand and fully documented.
(Also recall "memory safe" does not imply Rust. Rust is a particularly strong language on that front, sure, but memory safety is basically every currently-used language except C and C++. People advocating for memory safety are not advocating for everything to be moved to Haskell or Rust.)
So why? Why should we keep using memory unsafe languages? It's all cost and no benefit. Who wants that?
(The only practical answer is "I've got a system here written in C/C++", and I concede the engineering pressures that can keep you there. But my personal opinion at this point is that greenfielding a project in C or C++ without adjoining a strong code analysis on day one is rapidly approaching, if not already reaching, professional negligence. And I've got my stink eye on C or C++ with strong code analysis.)
There's a scale of disagreement and responses I see in people.
Discomfort
You can agree, and accept the evidence of something. And yet still say
in good faith that you don't "go along" with that. My favourite idiom
is when French people say "Sure, But that's not my philosophy".
Personal philosophy is considered of equal importance to
"scientific"/observed truth and expressing discomfort is okay. An
example might be "AI being able to write poems as well as people".
Even if a study shows that nobody can tell the machine from the poet,
one can still say "I am not okay with that fact". The discontent makes
no effort to challenge, except maybe personal withdrawal or denial.
Scepticism
This is healthy. Indeed it's part of the scientific method. We should
always tolerate and maybe encourage sceptical thinking. The sceptic
debates and disputes. But the sceptic is still open to being won over
by arguments. The sceptic is expressive of her disagreement.
Cynicism
When we see again and again that a group or an idea is wrong, or
persistently deceptive, the focus shifts from the ideas to the
identity of the group. Nothing said by <psychologists or economists or
politicians> or whatever can be trusted. A cynic can be healed, but
often only by overwhelming new evidence or a deep personal shift in
world view.
Opposition
The opponent has already decided in their mind they cannot or will not
accept some ideas. The good opponent sets up an alternative hypothesis
and engages in research to find new truths that will hopefully
displace the old ones. The negative opponent spends time only on
discrediting others.
Iconoclasm and Vendettas
This is the height of unreason. Being stuck in a black and white
world, split over good and evil in which the opposition must be
completely eradicated. I see this more and more in the world now.
People, like the "internet campaigners" you mention make a career out
of aggressive iconoclasm. They engage in "wars on..." and talk of
"zero tolerance".
---
Not sure I want to attach moral value judgement to any of these
"levels", I'm sure I can be capable of all. Some things are clearly
rotten in the world and people are tepidly accepting of them, whereas
other things absolutely need consigning to history. But there's a lot
of ugliness in the last two categories even if they are morally
justified.
Forgive me for reflexively jumping to one of my favorite critiques of the universe:
Flat design weeds out a myriad of built in affordances of our visual system:
- Color to help us more quickly distinguish between things, what the things are, and their roles.
- Borders, to demark edges of active usable elements, communicate roles, encapsulate closely related things.
- Translucence as a way to combine subtle elements into a single form in a way our visual system can quickly interpret.
- Texture as another means of quickly communicating topic separation and indicating roles. Especially useful for areas containing other elements.
- Shading that our native visual system naturally interprets as rich 3D information. For processing separation, function, including the state of dynamic function.
- Smooth motions to draw attention to, and indicate changes of state.
I am NOT suggesting graphical interfaces should:
- Resemble a rainbow Christmas tree of "look-at-me!" ornaments.
- Organize hierarchical information in n-level nested Mondrian boxes.
- Be performatively stylish: overly glassy, shiny, lickable.
- Have unsubtle textures, or painstakingly recreate leather, felt, marble, or (dear baby Zeus) grass.
- Spray shading and shadows onto everything in an attempt to recreate VR on a flat screen.
- Sparkle, blink, bob and weave, and otherwise snow and distract us with motion.
I am suggesting that it is madness not to sparingly use large dimensions of our visual processing system, to communicate visual information.
These extra dimensions not only provide richer information for our visual fovea, but to our peripheral vision. Our brain is constantly processing peripheral vision to create context.
A classic case of form over function.
A classic case of "simple" as in "less design work, trivial brand language consistency", not "simple" as in "easy to discover, understand and use".
(As with the check/radio/button/selector, I cannot process that Apple fell for flat design. Such corporate amnesia. From design leader to lowest common denominator follower.)
The thing with dieting is that you have to maintain some sort of diet to maintain the weight loss. And that means unless you maintain a diet which requires minimal willpower, so that you're no longer "suffering", you're required to suffer almost every day for the rest of your life.
I think many people are actually good at delaying gratification: suffer unbearably for a few minutes, intensely for a few days, or mildly for a few months. But everyone who suffers long-term eventually burns out, and people who are forced to suffer long-term past burnout (e.g. forced to work intensely to survive, or experiencing chronic unbearable pain) experience so much stress it changes them physically.
Furthermore, food addiction is unique because, unlike drugs, you can't "quit" food entirely. I imagine it becomes easier to avoid smoking or heroin if you haven't done so for years (though maybe I'm wrong on this point), but food is constant, so unless you form "healthy habits" (AKA eat food which both satiates you and maintains your weight) the suffering never goes away. I'm fortunate to not have weight issues myself, but as a long-distance runner, I know hunger, and it's not something you can live your entire life with. I also know that it's not always as easy as "have a cheat day every once in a while", because if you're really lacking nutrients, you'll feel hungry no matter how much you eat, that hunger only goes away after time (and presumably for some people with serious metabolic issues, it never goes away).
The good news with weight-loss is that we've done so much research, we have a lot of tools and techniques so that even people with metabolic issues can be satiated. Not even pills (which are probably only required for a minority which truly have metabolic issues), many people can probably maintain long-term weight loss with diet alone. The key is, these people maintain the weight by sticking to a diet which isn't suffering to them, like one with whole foods (which are known to be more satiating). Even then, you're maintaining constant willpower by not choosing the less-satiating but addictive processed foods, but it's not a willpower which makes you "suffer".
As a dev turned entrepreneur one thing I will do when selling projects is talk to clients about software as a depreciating asset. While there are some limitations to the comparison this framing makes sense to business people in general, especially well with finance or operations departments, and can work with internal stakeholders too.
The sources of the depreciation are tech debt and general turnover/churn in the method and process within an industry/vertical (like if you built a web app in 2002 based on ASP.NET, it's pretty tough for that to be a lively project today).
We know there are systems out there that have been running well and doing their job for 30 years, and there are systems that need to be replaced/rewritten from scratch every couple of years. Which one do you want to buy/fund/budget for?
If the customer or stakeholder only cares about a two year horizon you approach the project one way. If they say they want this thing to be firing on all cylinders 10 years from now then we approach it and price or budget for it differently. When you talk like this it doesn't sound too weird to introduce the idea that we should do an annual tune-up to a system that they don't want to have to replace until 2035. The tune-up is how you get 15 years of life out of your intellectual property instead of 10, this is how you sell time to pay down tech debt. The eventual rebuild is also part of the discussion (not if it will happen, because it will. But when it will happen is something we can influence, so the framing can be, would you rather do an expensive rebuild every 10 years, or do it in 15-20 because you paid for a regular maintenance along the way?).
Boom now in their head this software you're writing is like a car. Everyone understands cars. A car has a lifespan. If you didn't go to the mechanic and do your annual scheduled maintenance and the car breaks down, that's what you get for being cheap. Like I said big ops and finance departments actually really like the idea of a tuneup that prevents the car from breaking down. They're used to thinking about that with lots of physical assets anyway. A marketing department at a startup maybe not so much but their time horizon is usually short anyway.
My trick for this with k8s Secrets, when there's some sort of config file that absolutely must be consumed from disk, is to
1. create a Secret that defines the file as a key
2. mount that Secret into the container (.secret.secretName in the volume definition) under an arbitrary conventional path, e.g. /secrets
3. define an env-var that gives the full path to the file; where the fallback when this env-var isn't defined is to find the file in the working directory with a conventional filename.
If your own code uses the file, it can read the path from this env-var; while if the core of your container is some opaque tool that doesn't know about the env-var but does take the file's path on the command-line, then you can wrap the tool in an entrypoint script that reads the env-var and passes it as a command-line arg to the tool.
IMHO, this approach is flexible but principle-of-least-surprise obeying for both development and production deployment.
Why are people so interested in ‘lengths’ of strings?
The only thing anyone should actually care about is either the number of bytes it takes to store the string, or the number of pixels wide it is when rendered. Both of which are only loosely related to how many ‘characters’ or ‘grapheme clusters’ they contain, and which are themselves only vaguely correlated.
𒈙 (CUNEIFORM SIGN LUGAL OPPOSING LUGAL) is four bytes of UTF8 and as wide as about 9 Latin characters. (an England flag emoji) is about a character wide, but takes 28 bytes to store in UTF8.
The key is that the host is quite constrained in which box he can show you: He must always show you a box with a goat and he can never show you the box you initially picked. So the choice the host makes is less random than your (initial) choice and can give you new information.
In particular, only two different things can happen:
a) You initially picked the car. In that case, the host is free to pick any of the two remaining boxes since both have goats in it and neither were picked by you. In this case, it would be obviously unwise to switch.
b) You initially picked a goat. In that case, the host has no choice at all: They must pick the one box with the second goat, which leaves the last remaining box as the one with the car. So you should absolutely switch here.
If you knew whether you're in situation a) or situation b), you'd already have won the game: You could switch as needed and would always get the car.
Obviously though, you don't know. However you know that a) happens when you initially picked the car and b) when you didn't. You also know, you initially picked the car with 1/3 probability. So you know that with 1/3 probability you're in situation a) and with 2/3 probability you're in situation b).
Therefore, if you're just always pretend you're in situation b) and switch, you'll win the car with 2/3 probability.
> Where data is processed should not affect the care with which it is processed. I can conceive of some verifiable processing package that ensures data can be processed wherever and still meet regulations. Can that be part of the future?
To an extent GDPR already allows this. The fines are only occurring because Facebook is transferring data into a jurisdiction which doesn’t have strong enough data protection laws to satisfy GDPR.
In the U.S. case specifically, it’s issues around laws that allow the U.S. government to force U.S. companies to handover data arbitrarily with very little (if any) due process. If the U.S. modified their draconian laws to ensure that everyone was afforded due process before their data was scooped up by the U.S. government, then there wouldn’t be an issue.
Unfortunately verifiable processes packages don’t solve the fundamental problem that the various three letter U.S. agencies can send a secret order, with effectively zero judicial oversight, to Facebook and compel them to handover data, plus gag Facebook from telling the individuals about the demand.
In the beginning, there was a plan,
And then came the assumptions,
And the assumptions were without form,
And the plan without substance,
And the darkness was upon the face of the workers,
And they spoke among themselves saying,
"It is a crock of shit and it stinks."
And the workers went unto their Supervisors and said,
"It is a pile of dung, and we cannot live with the smell."
And the Supervisors went unto their Managers saying,
"It is a container of excrement, and it is very strong,
Such that none may abide by it."
And the Managers went unto their Directors saying,
"It is a vessel of fertilizer, and none may abide by its strength."
And the Directors spoke among themselves saying to one another,
"It contains that which aids plants growth, and it is very strong."
And the Directors went to the Vice Presidents saying unto them,
"It promotes growth, and it is very powerful."
And the Vice Presidents went to the President, saying unto him,
"This new plan will actively promote the growth and vigor
Of the company With very powerful effects."
And the President looked upon the Plan
And saw that it was good,
And the Plan became Policy.
Yeah it does suck and you’re not wrong. I’ve spent the last 3 years at my company trying to refine our Agile/Scrum process into something that gets out of my engineers way. It basically boils down to the Engineering manager, product manager and project manager or “scrum master” actually putting in a good bit of work to make things run smoothly.
1) keep your stands below 15 minutes. Always. There should also never be more than 15 participants in your stand.
2) The EM/PM/SM or all of the above should be writing high quality tickets that are discrete units of work (they can be tested and have some tangible output). They should never be so large as to take a single developer the entire length of the sprint.
3) Do a single weekly grooming/pointing session. This should take less than 2 hours assuming management did their jobs
4) EM/PM/PM/SM need to actually keep the backlog organized. Don’t make devs sit thru meetings where you slowly drive Jira
5) Do demos, retro and planning in a 3 hour time block with breaks. Balance what went well with what speed bumps you encountered and call out exceptional work done by team members
6) Make judicious use of doing “proof of concepts” to help spec out features/APIs/Integrations before running off to plan larger initiatives
7) Appoint an “Epic Captain” to each epic (group of related tickets). This is dev who is the subject matter expert and has some decision making authority. Defaults to the EM but they should appoint other devs to take proactive ownership over things
8) Proactively track and discuss technical debt and raise it during retrospectives; EM follows through by ticketing it up.
9) Actually do planning when launching major initiatives. A few discussions between devs before leaping into several weeks long project won’t make you waterfall and will actually reduce meetings in the future
For us, the average time per week an engineer spends in meetings is less than 5 hours total, or <1 hour per day on a team of 8. Kinda high but things run smoothly and nobody is out of the loop
Not really a script, but a `.ssh/config` to automatically deploy parts of my local cli environment to every server i connect to (if username and ip/hostname matches my rules).
On first connect to a server, this sync all the dotfiles i want to a remote host and on subsequent connects, it updates the dotfiles.
Idk if this is "special", but I haven't seen anyone else do this really and it beats for example ansible playbooks by being dead simple.
> These domains are strongly associated with fraudulent activities and high-risk investments which take advantage of people who are suffering from economic hardship and growing global wealth inequality. Few to no legitimate use-cases for this technology have been found; instead it is mostly used for fraudulent “get rich quick” schemes and to facilitate criminal activity, such as ransomware, illicit trade, and sanctions evasion. These projects often encourage large-scale energy waste and electronics waste, which contributes to the declining health of Earth’s environment. The presence of these projects on SourceHut exposes new victims to these scams and is harmful to the reputation of SourceHut and its community.
I'm going to send this to everyone who I know is involved in crypto/blockchain.
I love nix, I've been using it for the last 2 years, I have a very stable setup from these 2 years of effort [0], and I just can't recommend Nix for Linux beginners, why?
It's not because of the nix language, It's not because of the CLI, it's because everything is scattered, you have to consult many places to find out how to do things with Nix, here is an example:
Usually, when I need a new complex program, like Steam, I first check the system-wide configuration [1], the wiki [2] and the package list [3], if I just want it on my user, I need to check if Home Manager has an option [4], if it doesn't, I can try using the "home.packages" option. Now, if I need to override something on the package, I need to remember how to do it with [5] [6] (while checking the source code for the package in parallel to find the options).
And then sometimes, on very rare occasions, I need to fine tune something with the nix language, so I need to check the builtins/lib docs [7], but some builtins are not there, so I need to either use nix-doc [8] or find the docs inside the code-bases [9] [10] (they are split between both repos)
For me, this is one of the main pain points of using Nix / NixOS that needs to be solved.
Sit on my lap youngling, and I will tell you tales of i18n horror... and I'm from an English-speaking country!
A realistic scenario is an Australian writing French poetry while on holidays in Turkey. Now you have an OS GUI with en-GB as the language, licensing and date/number formatting as per the AU region, French spelling dictionary, a US-101 keyboard layout, Turkey as the location, and GMT+3 as the time zone.
It's a rare piece of software that can handle this. Few vendors have staff that have even heard of such exotic places.
There are still people... many people... that deny the existence of places outside of the United States of America. Such filthy, heathen locations are surely a thing of myth, or legend!
Places where dates are formatted with the days before the month, followed by the year in some sort of weird, unnatural order.
Nations that have fallen into the trap of some sort of mass hallucination, or shared dream of common measurement units. Some sort of... metric, for space, time, and matter. Maybe they've been watching too much Star Trek!
Multicultural countries where strange unions of races are commonplace, and couples may want to watch Netflix in one language, but have subtitles in a different language. Neither of which are English for the hearing-impaired! Surely, nobody but the deaf are unable to comprehend the universal English language! Not to mention that such taboo couplings are, thankfully, still banned on this stream of holy virtue and shall not be permitted by the data scientists that have declared: "Your union is a statistically negligible!"
Rewriting something like OpenSSL isn't exactly trivial for many of the same reasons rewriting a large, widely used software library (especially one written in C) isn't trivial. Except in this case you need cryptography experts that are familiar in Rust (or whatever language) to review the code.
As a developer you should use prefer libraries written in safer languages (Rust, Go, etc.). But that's not always possible given business/environment/etc constraints.
From the article:
> These rules may sound complicated, but really, they are about understanding the fundamentals of how a computer works.
... and from the post that the article links to:
> Understanding String vs &str implies an understanding of the ownership system, which implies an understanding of the lifetime system. That probably means that you’ve been exposed to pointers, references and perhaps even aliasing. There’s usually a discussion about mutability intertwined here. Gaining an intuition of data types that represent text benefits from understanding encodings, which benefit from understanding how CPUs operate.
> I’ve yet to find a way through this for complete beginners. Learners with that already know another systems programming language have a distinct advantage here.
This, IMO, is the key to understanding why Rust is hard to learn: it was written as a systems programming language, and we now expect it to be more than that. I nodded my head in agreement as I read the intro to Rust until I reached the explicit use of lifetimes. To me that was where the abstraction got leaky. If your core abstraction of borrowing needed to expose the fact that the compiler uses lifetimes and needs a hint from time to time, you're saying explicitly that your audience are system programmers and they get that no abstraction is clean.
Take that up a few levels of abstraction and application development with Rust is hard. Maybe the rust community should just say: "Yes, its hard in the beginning, but its worth it if you stick with it. Welcome"
PS: I personally found it hard to learn Rust when I was looking for a static single binary generating language for my side project, and went back to C (please don't judge, its just familiarity). But I see what Rust can do.
> It seems like they're using "secure cryptography" kind of narrowly, as AFAIK a one-time pad could still be secure without any kind of one-way function.
The security of OTP is much more restricted than most cryptography books admit.
OTP's security can be proved in the following cases:
* the set of secrets (plaintexts) is finite,
* the set of secrets (plaintexts) is the uncountable sets of streams, say, N -> {0,1}.
What one is interested in for cryptography is if the set of secrets is a countable domain, say the a set of strings (e.g. {0,1}^*).
Bad news:
"[N]o perfect private-key encryption schemes, over the set of all strings, exist. Stated informally, this means that there is no way to perfectly encrypt all strings without revealing information about their length."
I blame the internet. Back in the days before it, we had to learn to live with those around us, now you can just go out and find someone as equally stupid as yourself.
I call it the toaster fucker problem. Man wakes up in 1980, tells his friends "I want to fuck a toaster"
Friends quite rightly berate and laugh at him, guy deals with it, maybe gets some therapy and goes on a bit better adjusted.
Guy in 2021 tells his friends that he wants to fuck a toaster, gets laughed at, immediately jumps on facebook and finds "Toaster Fucker Support group" where he reads that he's actually oppressed and he needs to cut out everyone around him and should only listen to his fellow toaster fuckers.
Apply this analogy to literally any insular bubble, it applies as equally to /r/thedonald as it does to the emaciated Che Guevara larpers that cry thinking about ringing their favourite pizza place.
TL;DR it's important to have the ability to launch nukes even if the President is insane, that's why it goes through a chain of command rather than from POTUS directly to the button pusher. I just have a lot to say, sorry for putting my soapbox here. This starts on topic and goes off the rails at the end.
This is a tough call. I agree with the premise that it's quite important to make sure that an insane president can't launch nukes. At the same time, this is a fundamental issue in the military -- when they say he lacked the qualities of "leadership" what they really meant was "followership", which is a concept not really taught to us in school. Everyone in that organization has a role to play, and if they don't play that role then they are not welcome. This isn't an organization where you join to really be a leader in the "trailblazer" sense, but a leader in the "set a good a example by demonstrating how to follow the rules properly" sense.
Does that mean an officer in the military is absolved from making moral choices? Of course not. They have the free will to say no, to not do what they're told, and to abandon their role. Of course there are consequences for that, but that's not really the issue. Doing the right thing isn't supposed to be easy and consequence free. In fact it's usually quite the opposite, which is why courage is a virtue. But the point is the choice to not press the button always exists.
Also, it's worth pointing out that truly insane people are not subtle about it. I don't know how many people here have talked to genuinely insane people. but from my experience they can't go very long without revealing they are abjectly and certifiably crazy. Someone in that state of mind would have been acting crazy for quite a while (it takes time to go from a sound mind to "NUKE THE WORLD"), and everyone around him would be keenly aware of his behavior. It's destructive by its nature, and does not go around quietly.
Diseases of the mind are quite loud and they are also infectious, if people aren't aware. Not that I mean you can become literally insane in the presence of insanity, but that insanity ramps up your anxiousness, because of how unpredictable and... well insane they are behaving, which in turn degrades your decision making capabilities -- "Well, I could do this completely sane and rational thing, but that would upset the insane person I'm with for illogical reasons. But I'd rather not upset them because that's upsetting to me, therefore I will act irrationally and that's somehow the most rational thing to do". See how twisted it gets? That kind of logic is unsustainable for a rational mind for long, so if you're forced to endure those mental gymnastics, all critical thinking shuts down and you just become a reactive nervous mess. Insane people leave a wake of chaos behind them at all turns. It's not subtle.
Notably General Mark Milley recognized this in Trump at the end of 2020, and assured his chain of command that any nuclear strike order would be issued from the President to Gen. Milley and then he would transfer that order down the chain. What Milley meant to convey with this statement was that any order for a nuke would be lawful, because he would only have advanced it if he deemed it lawful. Not the President. Right, because who determines whether a strike is lawful? Not a court. Not the congress. Maybe after the fact they would have a role but not in the heat of things. The President can issue a strike but his issuance does not make it necessarily lawful; nuking California because they voted against you in an election for example would be an unlawful order on its face. So really the lawfulness of a nuclear strike order is determined in situ by the individual members of the armed services as they pass the order down the chain of command. An unlawful order can still make its way through the chain under these circumstances, but at least it's something. Because what's the alternative? Anything else would slow the process down to a point where the nukes would be completely useless as a deterrent; you have to have the ability to launch them in a timely matter. Because if your opponent knows it takes you 3 months to get an authorization to launch a nuke while you wait on the result of the President's mental health assessment and subsequent lawsuit and court appeals, then MAD completely breaks down.
The President doesn't go directly to the button pusher with an order to push the button. There are channels and even if there isn't apparently a "two man" rule for nuclear strikes, it still originates at the President and goes through a number of personnel. Any one of them has the agency to say no and refuse the order as unlawful. Now, the further down the chain you go, the less weight a refusal carries. That's because each link in the chain acts as a sort of authentication, so you don't have to trust the President is sane, you just have to trust that your direct superior is sane. What Mark Milley was telegraphing at the end of 2020, was that he himself was in fact sane, and any order subordinates might receive would have be effectively laundered by his sanity, even if the President were insane.
And come to think of it, how would that play out?
Insane President: Launch the Nukes
JCS: No.
Insane President: Okay then I will fire you.
JCS: No you wont.
Insane President: And why is that, I have absolute authority.
JCS: If you do then we're going to tell everyone that you fired us because we refused to carry out your nuke order. And then we will reveal that we had been planning a preemptive nuke, which will cause our enemy to preemptively nuke us.
Insane President: Well why would you do that?! You would be nuked too!
JCS: You're right that would be bad. So then don't fire us.
Insane President: But then how would I nuke them?
JCS: .... you don't....
Right? How would the nuke order go anywhere if the JCS doesn't endorse it. So in that sense there is a kind of two man rule but it's at the top end.
Because what if the President were insane but we also really needed to launch a nuclear missile for a good reason. Well that might need to happen immediately and we can't have random people in the chain of command refusing orders because they have some negative perception about someone far removed from them in the chain. That opens up a whole other world of problems.
So that's why I think an insane President is not likely to be able to launch a Nuke.
--
Now, the issue is a little bit different in Russia. Putin is not insane, he's a narcissistic psychopath -- the worst kind of psychopath. He has been on a huge power trip the last 6 years, and his ego has been inflated to the size of the universe. What's happened in Ukraine has popped his bloated head. It's caused him the gravest narcissistic injury, which I won't describe here, but I'll leave it to the professionals: https://medium.com/@Elamika/hell-hath-no-fury-like-a-narciss...
Narcissistic rage is one of the darkest and deadliest forces known to mankind. Before it erupts, it usually simmers and percolates for a long time, fueled by resentment, envy and entitlement, the latter always aggrieved as the narcissist’s need for adulation and glory is insatiable and he can see the world populated by the undeserving, inferior people who nevertheless dare to be happier and/or more successful than he is. It thus creates enemies out of the innocent and often weak who become vessels for the narcissist’s hateful and envious projections.
This article is written with respect to Trump, but Putin and Trump are both narcissistic psychopaths of the highest order so it applies to both of them equally (and no one has to wonder anymore why just last week Trump was calling Putin a savvy genius for what he's doing in Ukraine). But Putin being a narcissistic psychopath means that he absolutely can and will give the order to launch a nuke, and I don't enough about the Russian system to say anything more. Other than the fact that Putin's character disorder means that this conflict ends in 1 of three ways:
1. Putin kills himself Hitler style (also a narcissistic psychopath), as his war effort and country crumble around him.
2. Putin's citizens find him and string him up at the gas station Mussolini (ditto) style, or they find him in a hole in the ground Saddam style (yet another one, seeing pattern?).
3. Putin is murdered or deposed by his generals as he goes off the deep end.
That's it. This is going to keep on going until Putin is gone. Everyone trying to offer him an "exit ramp" or trying to give him an "out" so he can "save face" just does not understand the interplay between Putin's narcissism and his inability to let this go. Narcissistic rage doesn't go away because the target of your rage assuaged you. That is just your target signaling their weakness and vulnerability, and really giving you permission to strike. That's the mind Putin has. There are a lot of "pundits" right now who are out on the internet completely perplexed as to Putin's motives. They say "He can't hold Ukraine, he can't install a puppet government there, what does he want? For the life of me I can't say so he must be inane and completely irrational." I mean, yes and yes he is, but only from our perspective. Within his framework his decisions are completely rational. And his framework is this (it's from the article).
1. I am great.
2. People unfairly malign me.
3. I will show them (they will pay).
We're at stage 3 right now. "They will pay" doe not go away until they have actually paid in the eyes of the narcissist. You can't give the narcissist a "way out" because they don't want out. Their motive is nothing beyond revenge. It's not like Putin bit off more than he can chew and he's desperately looking for a way to get out. No, he bit off more than he can chew, but he wants to shove it down his throat and choke on it because at least maybe he would get his revenge in doing so. He's willing to sacrifice all of Russia or even the entire world for this revenge, and I think people are still unwilling to fathom that. He wants to kill Ukrainians. He wants mass murder on purpose. The phrase "If I'm going down I'm taking you with me" comes to mind.
A 'character' meaning what? The first code point? The first non-combining code point? The first non-combining code point along with all associated combining code points? The first non-combining code point along with all associated combining code points modified to look like it would look in conjunction with surrounding non-combining code points along with their associated combining code points? The first displayable component of a code point? What are the following?
the second character of sœur (o or the ligature?)
the second character of حبيبي (the canonical form ب or the contextual form ﺒ ?)
the third character of есть (Cyrillic t with or without soft sign, which is always a separate code point and always displayed to the right but changes the sound?)
the first character of 실례합니다 (Korean phoneme or syllabic grapheme?)
the first character of ﷺ or ﷽ ?
The main issue isn't programming language support, it's ambiguity in the concept of "character" and conventions about how languages treat them. Imagine how the letter i would be treated if Unicode were invented by a Turk. The fundamental issue here is that human communication is deeply nuanced in a way that does not lend itself well to systematic encoding or fast/naive algorithms on that encoding. Even in the plain ASCII range it's impossible to know how to render a word like "ANSCHLUSS" in lower case (or how many 'characters' such a word would have) without knowledge of the language, country of origin, and time period in which the word was written.
> "one code point in unicode does not necessarily map to one character on the screen."
Also, importantly, some characters are not represented at all. For example, there is no codepoint or combination of characters that distinguishes a capital Turkish dotless I from its identical looking but conceptually different sibling the Latin capital I. Similarly for capital Turkish dotted İ.
I find it extremely weird that two codepoints couldn't have been spared, yet we have gradations of skin tone in emoji. One can use composition to deal with the round-trip from i -> İ -> i (within a closed ecosystem), but even that fails when it comes to ı -> I -> ı.
A case in point are the product pages for my friend's book on Amazon. Compare "Sınır Ötesi" to "Sinir Ötesi". The former means "beyond borders" whereas the latter means "exceedingly irritating".
Yet, because there is no unambiguous representation of the Turkish I's, the rendering makes an assumption on the basis of the domain. Note that all other non-US ASCII letters involved are rendered correctly.
\c[PERSON FROWNING, ZERO WIDTH JOINER, PROGRAMMER]
Technical debt is something that 'business users' don't need to or want to care about.
If you're having conversations about technical debt, you've messed up, and you will continue to have unsatisfactory outcomes until you stop doing so.
You can't tell people; here is a dial, you can pick 'fast and you're screwed later' or 'slow and careful now'. You're setting yourself up for failure; they cannot pick 'slow and careful', because that's not their job; their job is to quickly deliver value/outcomes/whatever.
Almost no one has a job of 'go do this really slowly and carefully'.
They will always pick fast, and it's your problem later.
So... don't do that. Instead, say: this is how long it will take to do.
Not "if we rush we could probably do it in..."; no, if you say that, then why are you not rushing now? Do you not care what the business wants? Do you not have 'skin in the game'?
Say: This is how long it will take, we estimate. If you want it faster, we can cut some features.
Then, do enough of a good job so you can continue to deliver value in the future.
That's literally your job.
Doing a rubbish job as quickly as you can is not your job. Not ever.
You cannot abrogate responsibility for doing your job properly by saying "but I was told to do this", if you literally gave them the choice of A or B, where one of those options was "you have to pick this one, and it lets me get away with doing a rubbish job of it".
That's YOU choosing to do a rubbish job.
...and to be fair, yeah, there are situations where someone will come and tell you "no, do it now", and that's what you have to do... but you also have to come and clean up afterwards. Not because you're told to, explicitly, because... it's your job.
If the trim runs away far enough (which it clearly can, more easily because MCAS was also activating the stick shaker which is INCREDIBLY DISTRACTING) it can become impossible for a pilot to physically turn the manual trim wheels to get back into trim.
So the procedure for runaway trim (turn off electric trim, use hand wheels) doesn't work. You have to instead use electric trim first to get back into normal trim, then turn off the electric trim, and never turn it back on for that flight.
- Sufficient money so you don't feel ripped off or left behind compared to others in your social class
- Agency over your day - you can take an afternoon off if you're feeling down, your kids are sick, etc
- Enough free time to relax and have an out of work life
- Lack of obstacle/roadblocks to actually doing good work
Most modern companies get all of this wrong. They pay the bare minimum and raises are small and slow, encouraging job hopping. You have to beg for time off like a child. No clearly defined off hours for most employees. The daily job is filled with bureaucracy and excessive micromanagement that slow you down at every turn.
Being disengaged is the logical response to these conditions.