Após as atuações de gala de Mbappé, Messi e Haaland por suas seleções, com dois gols do francês contra Senegal, um hat-trick do argentino diante da Argélia e dois gols do norueguês contra o Iraque, resolvi fazer algumas ponderações futebolístico-filosóficas, ao estilo do futebol filosófico do Monty Python.
Messi, Mbappé e Haaland encarnam a exemplaridade atlética máxima em suas seleções. Na visão de Sloterdijk, que propõe uma ordem antropotécnica, eles seriam os “aristocratas do esforço” no topo da acrópole competitiva global. Mas acho que o treino e o esforço explicam nossa admiração em apenas uma dimensão.
O Messi do hat-trick de ontem, por exemplo, já não depende tanto do vigor físico; ele é como uma entidade incorporada ao campo, dotada de uma percepção das possibilidades que excede a dos demais, exibindo uma graça que escapa à pura força e agilidade do Haaland ou Mbappé.
Tenho a teoria de que o futebol cativa tantas pessoas porque indivíduos assim convertem a superação humana numa plasticidade sublime, uma potência que comove, arrebata e causa espanto. Isso se manifesta nos gritos de espanto da torcidaa, com um sonoro “– OOoooooohhh” coletivo, quando esses craques atravessam as linhas de defesa ou quando um Messi encontra um passe invisível para os demais, produzindo uma ruptura momentânea nos limites do que julgavam possível.
Os espectadores na arquibancada experimentam algo próximo do espanto filosófico: “como isso foi possível?” E Sócrates, segundo Platão, já nos lembrava que a filosofia nasce justamente da nossa capacidade de se espantar (thauma).
Do you have a new/new-to-you/used Windows device that needs a fresh start? Here's the process I've refined for myself over the years to get the best, most usable device possible. Start with zero added crap like McAfee or manufacturer sales programs.
You'll need a couple of USB flash drives for this process. Grab one that's at least 16 GB (install media) and one that's at least 32 GB (data backup). If you're going to be doing this often, you can replace the install media flash drive with an IODD device. I've got one with a 1TB SSD with a bunch of Windows and Linux ISOs, a separate folder for drivers, and a little 1 GB FAT32 partition specifically for holding BIOS updates.
Step 0: BACK UP YOUR DATA. On a separate, external device like the 32 GB or larger flash drive. Copy your user profile(s) and set it aside. You can just copy C:\Users and get 99% of things you'll care about. Get one that's visually distinct, label it, and put it somewhere else so you don't overwrite it. Do this even if you have multiple drives in the system. Don't count on your ability to keep internal storage devices straight. You can skip this step if you're pulling the device straight out of the box.
Step 1: Prepare Media. This requires a working computer.
Microsoft provides clean (for Microsoft) Windows 11 ISOs directly on their website: https://www.microsoft.com/en-us/software-download/windows11 Download the ISO directly from Microsoft. Don't download the ISO from any third-party sites. You can also use the Microsoft “Create Windows 11 Installation Media” program which will automate a lot of the process.
With the Windows 11 ISO, you can use Rufus to create your Win11 install flash drive. Rufus can do some fun things like kill the Microsoft Account requirement.
MAKE SURE YOUR INSTALL USB DEVICE ISN'T YOUR BACKUPS USB DEVICE
You can also just dump multiple ISOs on your IODD. I keep older versions of Win11 install ISOs around specifically so I can just use the bypassnro trick to create a local account, but there will probably always be some option to get around the online account requirements.
Step 2: In addition to Windows, there are a couple of other things you want to grab.
Check to make sure you have the latest UEFI (AKA/FKA BIOS) version for your device. Get this from the vendor with their name on the box directly from their website. Download the version specific to your model/serial number.
Also grab the latest system/platform, graphics, and network/wifi drivers from the manufacturer's website. 90% of these “executables” will be zip files that you can extract and point Windows at the folders later.
After you create your install USB, you can copy the BIOS update, drivers, and miscellaneous programs to it.
Step 3: Update UEFI/BIOS. Specifics are going to depend on your device and its process. Make sure you're on the most recent version, especially because of the Secure Boot certificate expirations.
Step 4: Boot Windows 11 Installer. Start fresh, blow away everything on the existing internal drive. The default manufacturer programs are almost never worth saving. The restore partitions are going to have old crap that will be replaced almost immediately when you start updating.
Modern devices won't have a Windows license sticker; the key is baked into the UEFI. Sometimes the Windows installer will pick up the right edition (home/pro/enterprise), sometimes you have to select it yourself. Either way, you can install Win11 without needing to provide a license key at this step. See also the MAS further down.
Step 5: Install drivers for devices Windows didn't handle during installation. The old Device Manager still exists. Right-click on the Start button/Windows logo, and select “Computer Management”. There you can see devices, including ones that don't have working drivers. Either run the executables you downloaded earlier, or right-click on the problem device and “Update Driver”, pointing it at the folders you unpacked.
Step 6: Kill the annoying semi-setup bullshit Windows pulls after updates. Settings app –> System –> Notifications –> Additional Settings –> Uncheck “Suggest ways to get the most out of Windows and finish setting up this device” and “Get tips and suggestions when using Windows”. These are the terrible interruptions Microsoft has started imposing after some updates that will do the absolute bullshit like tricking you into using Onedrive or switching your browser back to Edge. They're gross and terrible and if we had working antitrust enforcement they'd get another deserved crotch-kicking over it.
Step 7: Run the RemoveWindowsAI script. Kill it all, roll back to “classic” Paint/Notepad/Snipping Tool. Uninstall a bunch of MS garbage like Onedrive, Teams, the Office stub, and whatever else you don't need.
Step 8: Install PowerShell7/Terminal/PowerToys, configure to taste. You can install MS Office here too, if you need it. If you don't, we'll install LibreOffice later.
Step 9: Update Windows. Settings –> Windows Updates –> Check for Updates and Advanced Options –> Optional Updates. Just grab everything, get to the latest version. Check “Receive updates for other Microsoft products” too. This covers MS Office and PowerShell. This will take a while, and make sure the bullshit in step 6 didn't get re-enabled.
Step 10: Run the RemoveWindowsAI script again, because “no” isn't a term Microsoft understands.
Step 11: Install Vivaldi, set as default browser, configure as desired. For me that's a dark mode theme, crank the built-in ad-blocker to max, make Settings a tab instead of its own window, setting the search engines to DuckDuckGo, and install the extensions for 1Password, PrivacyBadger, and uBlock Origin.
Step 12: Install/run Privacy.Sexy and WinAeroTweaker.
Privacy.Sexy can break things, so I normally just use the “Standard” setting. I've had good luck with its revert options when it DID break things, but your mileage will vary.
WinAeroTweaker will restore some older Windows defaults to their better options. Once you find settings you like you can save and load those settings to a simple file.
Step 13: Verify Windows activation. Settings –> System –> About –> Product Key and Activation. The system has probably already activated itself in the background. If not, do it now. Or not. I'm not the software police. You can also use the MassGrave Activation Scripts, at your own risk.
USE AT YOUR OWN RISK: Massgrave.dev has published the “Microsoft Activation Scripts (MAS)” on MassGravel GitHub: https://github.com/massgravel/Microsoft-Activation-Scripts These can be used to activate Windows and Office through a couple different methods.
Step 14: Everything else. I've used Ninite for decades to bootstrap a bare computer into usability. Check the boxes, get an executable that will download and install the apps with the best defaults. Only criticism is the free version dumps a bunch of icons on your desktop.
My personal absolute minimum app list is this:
Vivaldi
Firefox
WinDirStat
7-Zip
VLC
Notepad++
For utility, I'll add these:
Paint.NET
IrfanView
LibreOffice
FileZilla
You can keep the Ninite executable around and rerun it later to update existing installs. The EXE isn't locked to a specific machine, so if you're doing several machines you can just dump it on the install flash drive and run it directly.
Manufacturer utilities like Dell's SupportAssist can be okay, but you've got to keep a close eye on them to make sure they don't do something dumb like install McAfee for “free”.
Step 15: Restore your documents/pictures/music/miscellaneous backed-up data. Now's a good time to make sure you have a comprehensive and tested backup scheme for your data too.
Now you should have a usable, fast Windows 11 device with the minimum Microsoft bullshit hanging around.
This is the second entry in a series. If you haven't read the previous one, now might be a good time. If you're all caught up, then let's get into it.
Viable systems exist within an environment. They adapt to the environment, but they may also change the environment as they adapt and grow. Beavers evolved to build dams, and in doing so they changed the ecosystems in which they evolved. A successful company will change the market. A successful non-profit will change their domain. But even a stable company is only one entity within the environment. Other companies, NGOs, consumers, and the public sector all exist within this same environment. Regulations, technological advancement, and customer tastes all shift the environment.
Within this dynamic environment, what are you doing to track changes that impact your viability? How are you connecting environmental changes, such as regulation, to internal constraints, such as those that drive compliance enforcement and verification?
A security program will need to focus on a specific subset of this question. How do you monitor threat actors? The evolution of threat actors and their attack profiles must inform your risk model and prioritization. As defenses evolve, threat actors adapt and their attack patterns change. How do you collect data? How do you process it into intelligence that's actionable by people on your team?
Similarly, a security program will need a mechanism to track external changes to its attack surface in the form of supply chain risk management. What mechanisms do you have in place to track vulnerabilities in third party libraries, applications, and appliances that you use? How do you make sure that information (and specifically that information, not a flood of false positives) gets to people who can act on it?
We will come back to threat actors and vulnerability management in other articles.
Keeping track of you constraints as they evolve is only half of the constraint management equation. The other half is algedonic signaling. How do you know when constraints are violated?
In the body, an algedonic signal is a basic “pleasure or pain” signal, like those we started with. When your body is hungry, you feel it. When you get hungry enough, it hurts. The signal isn't detailed. It doesn't provide much information. It's simple and generally easy to investigate. Many signals, such as hunger, are intuitive. We learn to understand them immediately and without investigation.
All constraints should be tied to “algedonic” signals that trigger when they violated. But are they? If you've recorded your constants (as described in the previous article) then you can perform a gap analysis.
For each constraint you have identified, write down the signals that fire when those constraints are violated. For any gaps you identify, and figure out a plan to close them. Are there constraints you have listed that you would feel comfortable not being alerted of in case they are violated? Those are not really constraints (at least not at your level) and they should be removed from your constraint list.
Anyone who has worked in tech long enough has seen some variation of alarm fatigue. Perhaps it has even been you who has had an email filtering rule that dumps alerts into a folder that is periodically cleared without any messages ever being read. Many security engineers will have had the experience of pointing to a vulnerability found by some automated scanner or other, a vulnerability which has since been then verified by a security engineer, and asking, “why was this been marked as a false positive?” Perhaps you've observed to someone frantically clicking through a series of dire warnings, recognizing that the warnings intended to stop them have simply trained them to click fast without thinking. Too many signals can overwhelm a system. Notice that I'm not specifying spurious signals. Accuracy is also a problem, but sheer volume of accurate signals can be enough.
Then what is the mechanism by which signals are reduced? Common frameworks can address common vulnerabilities. Many security programs will look for security violations: insecure software being used, vulnerabilities in software being developed, and so on. There are infinitely many ways to implement software insecurely. There may well be as many ways to implement software securely. Sorting between these sets requires tremendous knowledge and has a high probability of failure. By restricting the definition of “secure” as complying with a specific set of vetted patterns, software, hardware, configurations, and the like, the verification work is reduced.
Security Engineering can work on identifying common problems, addressing them with vetted patterns, and ensuring deployed patterns are updated as needed. This internal optimization work helps make the external signals around supply chain risk into something manageable. These restrictions are enforced not by complete refusal to use software, hardware, or configurations not explicitly allowed, but by adding friction, in terms of additional auditing or monitoring requirements, for teams trying to use them. Critical deviations will still be possible, at a cost, and most users will choose the path of least resistance.
Compliance work may revolve around understanding what regulations apply to software, what assets regulatory bodies need, and making sure those assets can be delivered. But it can be easy to miss that compliance can reduce regulatory risk through early intervention. By providing guidance that allows software to be designed in a way that avoids falling under regulation, or by concentrating regulatory risk in a smaller set of components, complexity, and the risk of signal overwhelm, can be reduced.
While cybernetics foregrounds the importance of complexity management, encapsulated as Ashby's Law of Requisite Variety, security program leadership can struggle to see the forest for the trees. In the frantic struggle to fight all the fires, it can be difficult to even notice the larger patterns. This is exactly where cybernetics can help us most.
The VSM defines a set of metasystemic subsystems that manage any system. In the first article we talked about the system itself as an entity surviving within and adapting to an environment. We connected that to the Identity subsystem, and how invariants inform constraints through identity.
In this article, thus far, we have talked more about that dynamic environment and how we need an Awareness subsystem to track environmental changes. We've also talked about managing complexity through synergy using an Optimization subsystem. This leaves two more metasystemic components to cover: Internal Audit and Learning, and Harmonization. Before we talk about those, let's jump down the stack one more time. What are these subsystems learning about, auditing, and harmonizing? All of these metasystemic functions exist to support the Operational Units. Operational Units “do all the work that keeps the system alive.” In the body these are the muscles and organs that breath air, find food, digest food, and remove waste.
While the brain, the metasystem, directs the activity, it is the rest of the body that realizes that activity. It is important to keep this fact in mind as we try to understand the role of security in an organization. With this in mind, let's return to where we were.
The Optimization subsystem can passively coordinate optimization opportunities that are identified by subsystems, but it can also look actively collect data. Internal Audit and Learning is a subsystem of optimization that performs audits and looks for anomalies. Security folks may well be taking notice, recognizing some of our own work in this subsystem. But it's a little more complex than that. Let's talk about the Harmonization subsystem.
The function of the Harmonization subsystem is, essentially, to keep operating units from interfering with each other. If Operational Units are sharing compute resources, for example, Harmonization would include things like permissions and quotas. The VSM says that operational units should have maximal autonomy, but each Operational Unit must be prevented from threatening the viability of the system itself.
Now we, security, can really see ourselves in our familiar role with our familiar problem. Each operational unit may be trying to create a product, ship software or hardware, or to provide a service, but in doing so they can increase the attack surface. Promotion driven development may push team leads to compete to get software out faster and cheaper, incentivizing them to cut corners wherever they can. They ask if they can reduce the scope of a review, or push now and fix later. They may even push features that change the threat model but are, somehow, also “too minor for a security review.”
They each individually peruse their own objectives, and in doing so threaten the security of the organization as a whole. But when vulnerabilities are found, and perhaps even exploited, within a team's code the company as a whole bears the burden. Isn't it interesting that security tends to behave similarly to police, when, in actuality, our job is that of commons management.
Customer trust and internal funds are parts of the internal commons threatened by through a company's collective attack surface. The job of security is to coordinate teams across the company to ensure attack surface is minimized. Security works to protect customer trust from reputational threats, and funds from regulatory action and illegitimate compute usage.
Companies mature enough to understand that “policy enforcement” needs to have teeth, often become too big for that same enforcement role to maintain visibility. Companies that haven't reached that level of maturity simply don't give “policy enforcement” the tools to actually “enforce” anything. “Policy enforcement” creates an adversarial relationship between security and operational units that makes everyone's job harder. By recognizing security as a support role, rather than an authority that demands obedience, we can focus on building the relationships we need to protect the organization that we all share.
The economist Elinor Ostrom worked extensively on commons management, but the rules she developed are outside the scope of this work. That said, we will briefly touch on five rules for commons management will help simplify our work:
Commons must have clearly defined boundaries.
Commons must be monitored.
Those who abuse the commons must be sanctioned.
Commons management must have authority.
Commons management works better when the specific commons exists within a larger commons framework.
We have already touched on both the “authority” and “abuse” elements, though we'll need to come back to those later. In the next section we'll align all of these into a process that's driven by a new threat modeling methodology. This new methodology will pull from the information we established in the first section, and the program we build around it will revisit many of the concepts we've introduced in this section.
If you are unable to get yourself food or water for a long enough period, you will die. We all know this. Our bodies tell us this with hunger and thirst. After a while we start to hurt, a headache or aching stomach. We will be compelled to do something about it, perhaps anything, to survive. You may even feel a bit of anxiety now even just thinking about it.
Some people override these signals consciously. They fast for religious reasons. They go on hunger strikes to resist oppression in the only way they can, or raise awareness about a problem that isn't getting attention. What self-control, one might say, imagining Kafka's Hunger Artist sitting stoically in his cage as he wastes away. (I mean, no one would say that, but I'm not going to miss such a good opportunity to throw in a Kafka reference.)
Control, including both the signals the body sends to the mind and the ability of the mind to override them and dictate the body, is precisely the subject of the study of cybernetics. But cybernetics, of course, isn't specific to biological system. It abstracts concepts into models that can be applied to plants, animals, machines, social systems, and many other things. One such model is the Viable System Model (VSM).
The VSM describes the abstract control components that a system needs in order to “remain viable.” The “viable” part of that is defined by a specific set of invariants. For biological things that means “have enough water,” “have the right nutrients,” “have enough food,” etc, while for businesses that generally means something like “have employees” and “remain solvent.”
All viable systems exist within environments and viability can only be described within the context of these environments. Their existence within an environment necessarily changes that environment, and changes to the environment may influence their viability.
The VSM, as a model, helps us think about the mechanisms which must exist, and the ways in which they must exist, within a system in order to maintain viability. Positively it tells us how to make a system viable or check that a system is viable. But that necessarily means it also happens to be useful for modeling.
So let's take these concepts and begin to think about how we can leverage the power of cybernetics to design or improve a cybersecurity program.
We need to start at the heart of the matter: viability. Whatever you're trying to protect either is a system that must remain viable, or exists within a system that must remain viable. Things that threaten that viability are called “threats,” where a “security threat” is a subset of those threats such that the threat may be intentionally realized by an actor. Now, by “remain viable,” we mean “must maintain a set of invariants.”
A company, as we have discussed, needs (at least) employees to work and money to pay them (if no others). These are the minimal viability invariants of a company. A department within a company may have constraints, perhaps based on metric targets or goals: must maintain 10% customer growth, must achieve positive cash flow for product sales by the end of the year, etc. Subsystems, teams, subteams, individuals, software, will all derive their own constraints (explicitly or implicitly) from these root invariants.
A system's invariants are enforced by the parent system (directly or through inheritance, say, from the laws of physics). Constraints are derived by the system or parent system in order to protect the system against violating the invariant within a specific environmental configuration. As the environment changes, constraints will also need to change; invariants must remain true as a property of the system across all possible environments.
So then, what are those invariants for the highest level system for which you are responsible? List them.
A system does specific things, generally in a specific way, in order to avoid violating these invariants. This defines the system identity. A store sells things within a specific market niche. A manufacturer makes stuff, from specific materials, with specific tools, for a specific market niche. I am a security engineer. I am writing about security. I may be able to pivot between security engineering work and technical writing, but if I try to be a baker tomorrow, and a landscaper next Tuesday, and a carpenter the following Friday, I will quite likely threaten my income. Without income, I will struggle to maintain the housing and food I need to maintain the constraints of temperature and caloric intake that keep me viable. As difficult as it would be for me, as an individual, to rapidly pivot, all the more-so for the shoe store to become a butcher or the cabinet factory to pivot to pharmaceuticals.
Identity informs constraints. What then is the identity of the system for which you are responsible? Are you responsible for a subsystem, such as a department or team, where your identity is derived from a parent system? If yes, how so? Write these things down.
What are the constraints that keep you from violating these invariants? List them.
These constraints may be things like “service and labor spend must be lower than customer provided income,” “services must comply with all applicable regulations to avoid fines,” or “the business must operate in a way consistent with the ethical framework of the community in order to retain employees and reduce retaliatory risk.”
Constraints will be derived from invariants, through various levels of system identity. If you are mapping constraints for a subsystem, you should be able to contextualize these constraints at least within the context of the next level of parent system above yours. A team should understand the department it's working it, a shop should understand regional goals.
You have been asked to record other peaces of information, such as invariants, identity, and derived constraints. This specific information will be useful in the future. But while invariants won't change, and Identity should rarely or never change, constraints are a product of invariants interfacing with a dynamic environment through identity.
This introduces us to the highest level cybernetic metasystemic function, and the dynamic environment within which a viable system must exist. This will set us up to talk in the next essay about the remaining metasystemic functions that allow our system to adapt to this dynamic environment, internally regulate, and manage complexity. In the third essay, we will revisit what you have written down here and use it to think differently about threat modeling.
For many organizations today, threat modeling lies somewhere between theater and magical thinking. Design remains uninformed by threat models, and threat models become dead documents that are written once and thrown away. Assets that should be related to threat models, such as incident response plans, remain disconnected. What should be a tightly-knit living web of knowledge about the risk lifecycle of software becomes an archipelago of dead and disconnected data.
This dead chaos breeds complexity, complexity that can be absorbed by a living knowledge system and a process that builds and leverages that knowledge. By putting the “cyber” back in cybersecurity, we will be able to build a security program that is actually able to consume the complexity we are experiencing today, and not choke. Keep your notes from this section. You will need them for the section on threat modeling.
জানালার কাচে তখনো বৃষ্টির শেষ ফোঁটাগুলো আলতো করে টোকা দিয়ে যাচ্ছে। কিছুক্ষণ আগেও প্রকৃতির বুকে যে উন্মাতাল তাণ্ডব চলল, তাকে একরকম রূপকথা বলেই ভ্রম হয়। দমকা ঝড়ো বাতাস, মেঘের গুরুগুরু গগনবিদারী গর্জন, আর সাথে বুক কাঁপানো দুই-একটি বজ্রপাত -সব মিলিয়ে প্রকৃতি যেন তার সমস্ত ক্ষোভ উগরে দিল এই আধঘণ্টায়।
তারপর হঠাৎ করেই শান্ত। আকাশ তার রাগ ঝেড়ে এখন হালকা, শান্ত। ঘরের কোণে জমে উঠেছে একটা শিরশিরে ঠান্ডা হাওয়া, যা গায়ে লাগলেই কেমন যেন একটা আলসেমি জড়িয়ে ধরে। মন বলে, এই চমৎকার ঠান্ডা আবহে কম্বলটা গায়ে টেনে দিয়ে একটা লম্বা, নিটোল ঘুম দেওয়া যাক। কিন্তু চোখ বুজলেই কি আর ঘুম আসে? কিছু কিছু আবহাওয়া আসলে ঘুমের চেয়ে বেশি জাগিয়ে তোলে ভেতরের মানুষকে, খুঁচিয়ে খুঁচিয়ে স্মৃতির ধুলোবালি ঝেড়ে ফেলে তাকে তুলে ধরে মনের দৃষ্টিতে।
যেমন আজ এই বৃষ্টির শেষলগ্নে এসে বুকটা কেমন যেন হুঁ হুঁ করে উঠল। খুব মনে পড়ছে আম্মাকে।
আসলে ‘ইদানীং মনে পড়ছে’ বলাটা ভুল হবে। আম্মা চলে যাওয়ার পর থেকে জীবনের এমন কোনো মুহূর্ত নেই, যেখানে তার ছায়া আমি খুঁজে না। এখন প্রতিটা ছোটোখাটো কাজেই আম্মা অবধারিতভাবে চলে আসেন। কোনো একটা কাজ করতে গিয়ে থমকে দাঁড়িয়ে ভাবি, ‘আচ্ছা, আম্মা থাকলে তো কাজটা এভাবে করতেন না, তিনি হয়তো অন্য কোনো সহজ উপায়ে করে দিতেন!’ কিংবা কোনো জিনিস অগোছালো দেখলে কানের কাছে যেন মায়ের সেই চিরচেনা কণ্ঠস্বর ভেসে ওঠে, ‘এটা এখানে রাখছিস কেন? ঐখানে রাখ।’ অথবা কোনো কাজে আটকে গেলে মনে হয়, আম্মা থাকলে ঠিকই এই সমস্যার কোনো সমাধান বলে দিতেন। এই রকম হাজারো হাবিজাবি, টুকরো টুকরো ভাবনা এখন আমার একাকিত্বের সঙ্গী।
তবে আজকের এই ঝড়-বৃষ্টির রাতটা যেন আম্মার স্মৃতিকে বড্ড বেশি জীবন্ত করে তুলেছে। আম্মাকে আমাদের চেনা-পরিচিত সবাই খুব সাহসী এক নারী হিসেবেই জানত। যে কোনো বড়ো বিপদ বা কঠিন পরিস্থিতি তিনি এত ঠান্ডা মাথায় সামাল দিতেন যে, অবাক হতে হতো। দেখে মনে হতো, তার কোনো উদ্বেগ নেই, কোনো তাড়াহুড়ো নেই। যেন এক অদ্ভুত জাদুবলে সবটা ঠিক হয়ে যাচ্ছে, কিংবা অদৃশ্য কেউ একজন এসে তার হয়ে সব গুছিয়ে দিয়ে যাচ্ছে।
কিন্তু আমার কেন যেন মনে হতো, এই পাহাড়সম সাহসী মানুষটারও একটা দুর্বল জায়গা ছিল। ঝড়-বৃষ্টির সময় আম্মাকে আমার বড্ড ভীতু মনে হতো। যদিও তিনি মুখে কখনো ভয়ের কথা স্বীকার করতেন না, চোখে-মুখেও ভয়ের কোনো রেখা ফুটতে দিতেন না, তাও একজন সন্তানের চোখ তো! মায়ের ভেতরের চাপা অস্থিরতাটুকু আমি ঠিকই টের পেতাম।
সেই দিনগুলোর কথা মনে হলে আজও ঠোঁটের কোণে মৃদু হাসি ফোটে, আবার পরক্ষণেই চোখটা ভিজে আসে। বজ্রপাত শুরু হওয়া মাত্রই নিয়ম করে এলাকার বিদ্যুৎ চলে যেত। চারদিক ঘুটঘুটে অন্ধকার হওয়ার আগেই আম্মা তড়িঘড়ি করে এসে বসতেন আমাদের ড্রয়িংরুমে, যেটাকে আমরা বলতাম ‘সোফার রুম’। সোফার রুমে বসেই উচ্চকণ্ঠে বাড়ির সবাইকে ডাকতেন, ‘কই রে তোরা, সব এখানে আয়!’
আম্মার ডাক শোনামাত্রই আমরা যে যেখানে থাকতাম সবাই মিলে টর্চ, চার্জার লাইট কিংবা মোবাইলের ফ্ল্যাশ জ্বালিয়ে সেই সোফার রুমে গিয়ে জড়ো হতাম। মুহূর্তের মধ্যেই সেই অন্ধকার ঘরটা আলো আর মানুষের কলকাকলিতে মুখর হয়ে উঠতো। এরপর শুরু হতো এক তুমুল আড্ডা। বাচ্চারা আলো-আধারেই নিজেদের মতো খেলা শুরু করে দিতো, চিৎকার করত, ঝগড়া করতো আবার খুনসুটিতে মেতে উঠত।
আম্মা কখনো কখনো সোফায় কিংবা মেঝেতে বসতেন। বাকিরা যে যার সুবিধা মতো জায়গা করে বসতো। তারপর আম্মা ধীরে ধীরে বলতে শুরু করতেন। কত গল্প বলতেন, কত মানুষকে নিয়ে বলতেন, কত-কত সময়কে নিয়ে বলতেন। কী ছিলো না তার সেই টুকরো টুকরো কথায়! আমি সাধারণত সেসব আড্ডায় খুব একটা কথা বলতাম না, নিজের মতো এক কোণে বসে আম্মার গল্প শুনতাম, বাচ্চাদের আনন্দ দেখতাম, মোবাইল স্ক্রিনে দৃষ্টি নিবন্ধ করে রাখতাম, আর মাঝে মাঝে চোখ তুলে আম্মাকে একটু দেখতাম। অন্ধকারের মাঝেও আম্মার হাসিমুখটা দেখতে বড্ড ভালো লাগত।
আম্মা শুধু আমাদের নিয়েই ব্যস্ত থাকতেন এমন না, বরং ঝড়ের মাঝেই মোবাইলে কাছের-দূরের আত্মীয়, পরিচিত সব মানুষকে ফোন করে খোঁজ-খবর নিতেন। কে কেমন আছে, কার বাড়ির চাল উড়ে গেল কি না, কোথাও কোনো ক্ষয়ক্ষতি হলো কি না -এমন সব খোঁজ-খবর নেয়া চলতো। পুরো ঘরটা তখন এক অদ্ভুত ওমে, ভালোবাসার চাদরে ঢাকা পড়ে থাকত। বাইরের ঝড়-বৃষ্টির হুংকার তখন আর আমাদের ছুঁতে পারত না।
আজ আম্মা নেই, দেখতে দেখতে একটা বছর পার হয়ে গেল। প্রকৃতিতে আজও ঝড় আসে, বৃষ্টি নামে, আকাশ ভেঙে বজ্রপাত হয়। বিদ্যুৎ চলে গেলে চারদিক আগের মতোই অন্ধকার হয়ে যায়। কিন্তু আমাদের আর সেই সোফার রুমে একত্রে বসা হয় না। সত্যি বলতে, এখন আর ওভাবে বসতে ইচ্ছেও করে না। যে মানুষটাকে কেন্দ্র করে আমাদের সেই অন্ধকারের উৎসব জমে উঠত, সেই মানুষটাই যখন নেই, তখন সোফার রুমের ওই শূন্যতাটুকু বড্ড বেশি কামড়ে ধরে। সবার হৃদয়ে আলো জ্বালানোর মানুষটাই আজ অন্ধকার ঘরে একাকী নিদ্রা যাপন করছে।
মাঝে মাঝে এই রকম দমকা হাওয়া আর বৃষ্টির রাতে বুকের ভেতরটা বড্ড বেশি হাহাকার করে ওঠে। তীব্র ইচ্ছে জাগে, সব ফেলে এই ঝড়-বৃষ্টির মাঝেই ছুটে যাই আম্মার কবরের পাশে। সেখানে গিয়ে চুপচাপ বসে থাকি, যেভাবে একসময় সোফার রুমে এক কোণে বসতাম। আম্মার মাটির বিছানার পাশে বসে বলি, ‘আম্মা, ডরাইয়েন না। এই বৃষ্টি একটু পরেই থাইমা যাইবো।’
কিন্তু সময় আর নিষ্ঠুর বাস্তবতার বেড়াজালে আটকে সেই ইচ্ছেটা আর পূরণ হয় না। জানালা দিয়ে আসা ঠান্ডা বাতাসটা গায়ে লাগে, আর আমি একা ঘরের বিছানায় শুয়ে স্মৃতির কম্বল মুড়ি দিয়ে আম্মাকে খুঁজি।
আম্মা ভালো থাকুক তার এই দীর্ঘ নিদ্রায়। পৃথিবীর কোনো ঝড়, কোনো মেঘের গর্জন কিংবা কোনো বজ্রপাত আর কখনোই যেন তাকে বিচলিত না করতে পারে। অনন্তকাল পরম শান্তিতে তিনি ঘুমিয়ে থাকুক নিশ্চিন্তে।
A train has derailed near a populated area. Multiple people are reporting eye and throat irritation. One person, an elderly man working near the site, has been hospitalized with respiratory complications. What do you do?
Table-top exercises (TTX) are common in public disaster response. They help management teams check their plans. They verify that inter-agency communication and coordination works as expected. They teach team leaders to ask the right questions, and to respond dynamically under pressure. Like practicing forms in martial arts, they train a sort of muscle memory that takes over when it matters.
Disasters will happen. That's a simple fact of reality. While systems should be built to prevent them, it is also critical to prepare to respond to them. By training, organizations decrease response time. Decreasing response time saves lives.
Perhaps some of this sounds familiar. I remember log4shell. I was called into a room with other security leaders. People brainstormed, identified gaps, took tasks, and got to work. Commercial scanners lagged behind, so we designed and built our own. We ran it, manually checked things flagged as “false positives,” and drove every instance into the ground. There were a lot of late nights, a lot of grumpy engineers paged in to patch their systems. It was hard work, stressful at the beginning, but, in the end, it was good. We quickly developed a flow and coordinated closely as an ad-hoc team. We found the bugs, fixed them, and came out the other side with better tools and better procedures.
Large scale security events like log4shell, text4shell, spring4shell, and others are unlikely to become less common. LLMs allow code to be generated more quickly and with less knowledge. Meanwhile, these same LLMs either miss vulnerabilities or are prohibitively expensive to run on incoming code. Core open source infrastructure has been inundated with pull requests, while closed source software is infeasible to use for many projects with no way of knowing if quality is better.
LLMs themselves have been integrated into all sorts of projects. Meanwhile, it remains ultimately impossible to secure LLMs. Our attack surface continues to multiply, while tools for managing this complexity are still evolving. The ever-relevant Gramsci quote haunts us. Indeed, “now is the time of monsters.”
If you use software in 2026, especially if that software is Internet facing, you need to be ready to respond to a large scale event. But CVSS 10 0-day events are uncommon. How do you prepare for something that requires such a high level of coordination and precision, that demands a rapid response, and that doesn't happen very often? More importantly, how do you prepare to respond outside of the crucible of the actual event? Take a page from disaster response: practice.
Our response to log4shell was solid and quick. The room was full of the best engineers and managers, people with a lot of institutional knowledge and a lot of talent. Leaders followed everything closely and always asked the right questions. But we were still inventing things, figuring stuff out, sometimes stepping on each other's toes. After log4shell, we wrote a runbook for such large scale events. Then we tested it, several times, with table-top exercises, until we were confident it could be executed successfully.
Every disaster preparedness exercise starts with a runbook. You can't really test a plan unless you have a plan, can you? Do you have a runbook? Let's talk briefly about what that looks like.
A large scale security event runbook needs to answer several questions:
How do you know there's an event?
Do you have a vendor who will alert you? Do you subscribe to a newsletter? Is there an intelligence team? What are you doing to make sure you're on top of security news?
How do you know the event is an emergency for you?
Do you have a feed of already-vetted intelligence? Does your security team verify news? How will they do that?
Who do you call in?
This should be a list of roles, but those roles should be associated with pagers or phone numbers. Phone numbers should have back-up phone numbers. Do you have the right people? You will need to have people in the room who can answer more questions, or can find the right people to answer those questions.
How do you stop making the problem worse?
You are going to keep making code, or at least using it. How do you make sure you aren't deploying vulnerable stuff right now. If you can't stop pushing out more vulnerable code, then you're digging in sand: any progress you do manage to make will only be eaten away as you push more stuff out.
How do you find out what is vulnerable now?
Do you have a commercial scanner? Does it have updated signatures? Can you wait for them? Can you shut potentially vulnerable services down while you wait, or are they critical? Do you need to write your own scanner? Do you have the skills in-house to do that? Do you have a vendor you can call?
How do you find out what has been compromised?
If you patch fast enough, you may be able to avoid being hit before adversaries can scramble their resources. But don't count on that. Who do you call to figure out what the signatures of a compromise might look like? Do you have an incident response team? Do you have a vendor you work with?
What do you do when you find a vulnerable system? What do you do when you find a compromised system?
Some of these questions can fall off to other runbooks. Your vulnerability management team should already have a generic runbook for dealing with vulnerable systems. Your incident response team should have incident response runbooks. Do they work? You can test them while you're testing this one.
How do you inform customers?
Do you have a media team? Do you have an existing template for large scale events? What is important to tell customers? What regulatory requirements do you have for disclosure based on your business?
How do you know when you're done?
Fires will come and go. You can't stay in emergency mode all the time, or you'll burn yourself and your people out. But if you go home too early you might miss something critical. What is the indicator that it's time to transition to everything back to normal operation? When can normal runbooks take over from large scale event runbooks? Does someone decide? Is there a specific threshold?
The runbook doesn't need to be perfect. It won't be. It will never be. It should not be expected to be. That's the whole point of this exercise.
After reading all of this you may not be ready to go to the next step. That's fine. You've already learned something about your capacity to respond, and that's what's important. Record those lessons, turn them into action items, drive each one to closure. Even if you are ready, this will become a pattern. Each time you test, you learn something. You come out with information that you need to turn into action items. You need to make sure those items get closed. Each cycle will repeat this same pattern.
Do you have a good start? Great. Let's test it.
You'll need to choose a facilitator. In the table-top RPG world, the facilitator who leads the scenario is called a “Game Master” or “GM.” Your GM is going to come up with a scenario, keep track of progress against the scenario, and generally run the exercise. There's a mix of procedure and creativity involved in both gaming and these types of exercises, so we're going to stick with the terminology of “GM” for our facilitator. We're also going to use the terms “player” and “game” to describe team members and the exercise.
The GM will be tasked with coming up with a scenario. This should draw from past experiences, if you have them, or external accounts of incident response. If you have an organizational threat model, you will want to include this in crafting the scenario. What kind of event would most impact your business? What kinds of disruptions would be the most harmful? What subsystems are the most critical?
It may be tempting to use LLMs to help generate scenarios, and this may well work. But the research that goes into generating scenarios also helps build knowledge. That knowledge can be useful in developing a more robust runbook, and in responding more dynamically to disruption.
Fortunately, there are also other resources. CISA has a set of tabletop exercise packages focused on specific industries. Some vendors may create tabletop exercises on request, or may have already existing packages they can support you with. The Backdoors and Breaches card deck can also provide help provide inspiration.
Once you have a scenario, schedule a game day. You can make it as realistic as you want. Getting important people in a room to talk through everything will give you a high level check. But the more realistic the exercise, the more that can go wrong, and the more opportunities you have to learn from that. The scenario will include information about how people find out. Did someone read the vulnerability on HackerNews? How long does it take to from contacting the security help desk to having security leadership in a room?
Once the GM has gathered together the appropriate security roles, as designated by the runbook, the GM will then provide appropriate information. Security will ask questions to get as much information as possible, and execute on the runbook from there.
The game is turn based. Each round starts with the GM giving some information about the current situation and relevant situational changes. Depending on the flow of the scenario, the GM may not reveal all relevant information unless specific actions are carried out. For example, a GM may choose to designate a system as “compromised” during a turn but would only reveal that information after incident response starts looking for signatures.
The GM may play as all external actors. This includes adversaries, security vendors, and external researchers. Alternatively, a “Red Team” may be designated to play as the adversaries against the defending “Blue Team.” When played this way, the exercise begins to look more like a military tabletop exercise. Military models can also prove useful here.
The OODA Loop is a decision-making model developed by Air Force Colonel John Boyd to help fighter pilots make clear decisions under extreme stress. We can also use this model to help train quick and clear decision-making. Since this article focuses on TTX for security, we're only going to briefly touch on the subject here.
During each phase, players can talk through each step of the OODA Loop:
Observe
What data do we have? How are we getting our data? Is our data already refined into intelligence, or do we still need to refine it? Keep track of what information is missing so you can collect that later.
Orient
What does this data tell us? What do we know, or think we know? How does this new data challenge or confirm that? What does this data mean for us, in the context of this situation? Is anything we're observing now the result of a previous action we've taken, or is it the result of external actors? What does the runbook say? Does any of the information we have trigger a runbook action, or do we need to figure things out? Is anything actionable, or do we need to learn more before we can choose other actions?
Decide
Choose an action from the set of actions. If the data doesn't simply trigger the next runbook step, does your next action help you understand the situation more? What belief does your next action imply? How will you know if that action was correct or incorrect? Can you form a hypothesis? What observations would challenge your hypothesis? What observations would confirm it? Are those mutually exclusive, or are there additional observations or actions you must make to clarify things?
Act
Finish your turn by choosing your action or actions (individually or collectively). Perhaps take a moment to write down notes, like what your observations, your hypothesis, and if you think your previous hypothesis was confirmed or refuted. You can review these all later to refine your thinking.
End your session after you've either reached the terminal point of your runbook or you've reached a problem with your runbook so bad you had to stop. (Don't worry, this doesn't mean you've done a bad job. It means you've learned something important before it was a problem.)
When you're done, the GM can reveal any hidden information not yet revealed. Plan a retrospective to identify areas of improvement. Turn these notes into action items, and plan to re-run after you've completed those items.
Run this game multiple times until you're confident in the results. You may still learn things each time. You may still come out with action items. But there comes a point where the cost of practice outweighs the value of the lessons you will learn. Where this price point lies depends on your business and the risk tolerance of your industry.
You can get a bit more value out of repeated exercises by making them more realistic (as described earlier), or by adding in a “chaos monkey” element. The “chaos monkey” may remove a person (simulating, for example, a personal emergency), or report that tooling has been broken. In this variant, an incident responder may find expected logs missing, or a critical employee may be unavailable. In the same way that the tool helps you build more a resilient architecture, so does this element help your team become more resilient in the face of challenges.
Large scale runbooks can be tested quarterly, yearly, or every two years, depending on staff turnover and technology changes. Runbooks and skills both begin to rot the moment they are not used.
But why should we stop at large scale events?
Every engineering team should know what to do if their software is compromised. They should know where to look for logs to help incident responders. They should know which regulatory agencies they need to contact, and the time limits for legal compliance. These timelines may be surprising. Companies running in India, for example, have 72 hours to report a breach before risking penalties.
Scaled down versions of these table-top exercises can be run to verify team
runbooks. And the GM's role scales well. One GM can facilitate multiple sessions
at the same time, with different learning from the exercise together, learning from each other's good ideas and failures. Shared retrospectives can provide opportunities to foster innovation by cross-pollinating between teams.
Rare events can be chaotic, and time can be lost in that chaos. Lost time can be lost data, and lost data can be both lost revenue and fines. By training for rare and unexpected events, it becomes possible to minimize their impact. While a data breach and lose customer trust, a competent response to an unexpected event can also build trust.
How prepared are you for the unexpected? Are you ready to find out?
লাভ বুঝি না লোকসান বুঝি না
ভালো বুঝি না মন্দ বুঝি না
কিংবা তাদের মিসেল বুঝি না
হাসি বুঝি না কান্না বুঝি না
কাছের মানুষ হারাবার আগে
তাদের চোখের ভাষাটা বুঝি না
আমরা আসলে কিছুই বুঝিনা
গ্রাম ভেঙে শহর করার আগে
গ্রাম্য জীবনের সরলতা বুঝি না
নদী ভরাট জমি করার আগে
নিরালা বাতাসের শীতলতা বুঝি না
মাটির ঘর পাঁকা করার আগে
আপন নিবাসের ঠিকানা বুঝি না
আমরা আসলে কিছুই বুঝিনা
ধুলো মাখা পথে পিচ ঢালার আগে
খালি পায়ে হাঁটার সুখটা বুঝি না
ল্যাম্পপোস্টের আলো জ্বালাবার আগে
আঁধারে বসার শান্তি বুঝি না
জোনাকি দল হারাবার আগে
অন্ধকারের ভাষাটা বুঝি না
আমরা আসলে কিছুই বুঝিনা
উজ্জ্বল এলইডিতে হারাবার আগে
কুপির বাতির নাচন বুঝি না
স্ক্রিনের আড্ডায় হারাবার আগে
উঠোনে গল্পের আসর বুঝি না
গোছানো ফ্ল্যাটে হারাবার আগে
মুক্তপ্রাঙ্গণের বিস্তার বুঝি না
আমরা আসলে কিছুই বুঝিনা
হাঁসে ভরা বিল হারানোর আগে
মন জুড়ানো বিকাল বুঝি না
ধান ক্ষেতের দোল হারানোর আগে
সবুজের মোহ মাত্রা বুঝি না
বরই-পেয়ারা গাছ হারানোর আগে
লংকা-লবণের স্বাদ বুঝি না
আমরা আসলে কিছুই বুঝিনা
ডাঙ্গুলির শৈশব হারানোর আগে
মায়ের বকুনির মমতা বুঝি না
কৈশোরের দুরন্ত হারানোর আগে
নিস্বার্থের বন্ধুর মায়াটা বুঝি না
সুতো ছেঁড়া ঘুড়ি হারানোর আগে
মুক্তো আকাশের বিশালতা বুঝি না
আমরা আসলে কিছুই বুঝিনা
যান্ত্রিক চাকায় শান্তি হারাবার আগে
ধীর জীবনের ছন্দ বুঝি না
নগর বিনিদ্রায় হারাবার আগে
নিশি গ্রামের নিদ বুঝি না
শ্রুতিকটু অ্যালার্মে ভোর হারাবার আগে
পাখির ডাকে ঘুম ভাঙা বুঝি না
আমরা আসলে কিছুই বুঝিনা
শহুরে ভিড়ে হারাবার আগে
চেনা মুখের মায়া বুঝি না
জেব্রাক্রসিং এ হারাবার আগে
আঁকা বাঁকা পথের জাদু বুঝি না
শহুরে জঞ্জালে হারাবার আগে
সরল গ্রামের বিপুলতা বুঝি না
আমরা আসলে কিছুই বুঝিনা…
⠀⠀
বহুকাল আমি নিজেকে একজন ভুল মানুষ ভেবে এসেছি। আমার পৃথিবীটা ছিল কুয়াশায় ঢাকা, যেখানে স্পষ্ট বলতে কিছুই ছিল না। আমার ভেতরে নিজেকে প্রকাশ করার এক তীব্র আকাঙ্ক্ষা ছিল, কিন্তু যতবারই আমি মুখ খুলতে চেয়েছি, ততবারই মনে হয়েছে যেন কেউ একজন আমার কথাগুলো বন্দি করতে ছুটে আসছে। ভয় ছিল আমার ছায়াসঙ্গী। তাই আলো থেকে পালিয়ে বারবার আমি ফিরে এসেছি আমার পরিচিত অন্ধকারে, আর সেই অন্ধকারই হয়ে উঠেছিল আমার একমাত্র পরিচয়। আমি মেনেই নিয়েছিলাম- আমি আদি থেকে অন্ত পর্যন্ত ভুলে ভরা এক মানুষ, যার জন্মই হয়েছে ভুল করার জন্য।
কিন্তু একদিন সবকিছু বদলে গেল, যেদিন আমার ভাবনার সাগর নিজের গতিপথ বদলে গিয়ে পড়ল ছোট্ট একটি বীজের উপর।
মাটির গভীরে, নিশ্ছিদ্র অন্ধকারে একটি বীজ পড়ে থাকে। তাকে যদি কেউ জিজ্ঞেস করে, “কেন তুমি এই অন্ধকারে? বাইরে এসো, আলোর পৃথিবী তোমাকে ডাকছে,” সে হয়তো কোনো উত্তরই দেবে না। কারণ সে জানে, ঐ অন্ধকার তার শত্রু নয়, বরং তার আশ্রয়। ঐ মাটি, ঐ চাপ, আর ঐ একাকিত্ব.. এগুলো ছাড়া তার শেকড় গজাবেই না। আলোতে মাথা তোলার আগে, ঐ অন্ধকারকে তার আপন করে নিতে হয়, মাটির প্রতিটি কণার সাথে বন্ধুত্ব পাতাতে হয়।
সেই বিকেলে আমার হঠাৎ মনে হলো, আমি তো সেই বীজটার মতোই। আমার ভয়, আমার অস্পষ্টতা, আমার ভুলগুলো… ওগুলো আসলে আমার শত্রু ছিল না, ওগুলোই ছিল আমার মাটি। যতবার আমি নিজেকে গুটিয়ে নিয়েছি, ততবার আমি আসলে নিজের শেকড়কে আরও গভীরে চালনা করেছি।
এই ভাবনাটা আমাকে পৃথিবীর দিকে নতুন করে তাকাতে শেখালো। আমি দেখলাম, লিওনার্দো দ্য ভিঞ্চির মতো শিল্পীও তাঁর সেরা কাজগুলো অসম্পূর্ণ রেখে গেছেন, কিন্তু তাতে তাঁর মহত্ত্ব কমেনি। আমি বুঝলাম, পূর্ণিমার চাঁদের চেয়েও অমাবস্যার রাতের প্রয়োজন বেশি, কারণ সেই অন্ধকারই আমাদের আকাশের আসল রূপ চেনায়, কোটি কোটি তারার জগৎ চোখের সামনে মেলে ধরে। প্রকৃতির সবচেয়ে সুন্দর মুহূর্তগুলো এই যেমন আমাদের চিরচেনা ক্ষণস্থায়ী সূর্যাস্ত বা পাহাড় থেকে নেমে আসা ঝরনা -কোনোটিই চিরস্থায়ী বা নিখুঁত নয়, কিন্তু তাদের সৌন্দর্য অসীম।
আর ঠিক তখনই, আমার নিজের পরিচয়টা আমার কাছে পরিষ্কার হয়ে গেল। আমি “অন্ধকারের মানুষ” নই। আমি সেই মানুষ, যে অন্ধকারকে চেনে। যে অন্ধকারের অতল গভীরতাকে ভয় পায় না, বরং তাকে আলিঙ্গন করে নিতে শিখেছে। আমার ভুলগুলো আমার ব্যর্থতার ইতিহাস নয়, বরং আমার পথচলার চিহ্ন। আমার ভেতরের দ্বিধাগুলো আমার দুর্বলতা নয়, সেগুলো আমার চিন্তাশীল মনের প্রমাণ।
সেদিন আমি বুঝতে পারলাম, আমি ভুলে ভরা এক মানুষ নই, বরং আমি অভিজ্ঞতায় ভরা এক জীবন্ত সত্তা।
⠀⠀
⠀⠀
এখন আর আমি আলো খোঁজার জন্য দৌড়াই না। ভয় এলে তাকে তাড়িয়ে দিই না, বরং তার কথা শুনি। ভুল করলে নিজেকে দোষারোপ করি না, বরং হাসি মুখে ভাবি, “বেশ, এখান থেকে নতুন কী শিখলাম?” আমার সেই অন্ধকার ঘরটা এখন আর ভয়ের জায়গা নয়, ওটা আমার শক্তির উৎস -আমার শেকড়ের মাটি।
আলোর দিকে দৌড়ানোর প্রয়োজনটাই হয়তো ফুরিয়ে গেছে। কারণ যখন একজন মানুষ নিজের অন্ধকারকে আপন করে নিতে পারে, তখন সে নিজেই নিজের আলো হয়ে ওঠে।
⠀⠀
⠀⠀
⠀⠀
⠀⠀
⠀⠀
For over a year, with small periods of inactivity here and there, I had some paid work, writing and reviewing other people's writings, mostly the latter. This was the only thing I found I could do at my own pace, with no fixed schedule, whenever my lack of health allowed it. Although I didn't make a ton of money monthly, it allowed me to pay my medication, basic expenses, and the weed or weed derivative I used to keep the pain low enough so I could keep working for more than an hour a day. And, for a while, I had enough pain relief that I could almost feel a glimpse of normalcy, as long as I reduced my physical effort to a minimum.
At some point, this made me think the good times would keep up, and I was no longer feeling like dead weight to everyone around me. Reality is a bitch, though, and doesn't care about anyone. Eventually, the work began to dry up. Every month, the amount of work decreased to the point I am today, with barely any paid work in the last three months.
We have a saying here: “no money, no vices”. I had gotten used to a manageable level of pain (keep in mind that what I consider manageable is still a crazy amount of pain), and I had forgotten how bad it gets. I didn't forget this shit is awful, but I had forgotten exactly how painful it can get.
Let me give you a fresh example: last Monday, at dinner, my fingers were hurting so much I could barely cut my own food.
Now, I'm back to literally burning my back just to get a small relief. I'm not joking or exaggerating. Almost a week later, I still have blisters from putting a hot water bag directly on my back a few times per day. If I don't brute force the pain signals with other stuff, like the burning feeling, I can't get pain relief. This is what I suspect happens with the weed: the increase in serotonin production forces the brain to allocate more resources to it, leaving less for the pain signals.
I'm currently trying to find another work option, but it's not an easy thing to do when you have these constraints.
Mostly note to self:
Summer 2025 a crypto mining scam setup was made.
dlmining.com, dlmining.net and dldefi.com
Probably advertised through a kind of affiliate network.
This network apparently paid websites for promoting the scam.
Many apparently legal websites.
The setup seems to have disappeared around early march 2026.
dldefi.com seems to have used a chat support at 3nf3vi.com.
Which now can be found at 34.49.197.197 (googleusercontent.com) together with a buttload of “6 chars” domains.
Have not checked further so I don't know if this are domains used solely for scams or they are domains used by a “legitimate” support .services
মানুষ ঠিক ততটুকুই সম্মানেই সবচেয়ে মানবিক থাকে, যতটুকু তার প্রাপ্য। এর বেশি দিলেই বিপদ। এটি কোনো দার্শনিক অনুমান নয়, এটি জীবনের ঘটনাপ্রবাহকে নিবিড় পর্যবেক্ষণ করে পাওয়া একটি অকাট্য সত্য।
অতিরিক্ত সম্মান মানুষের মস্তিষ্কে এক বিচিত্র রাসায়নিক বিক্রিয়া ঘটায়। প্রথমে সে এই অযাচিত সম্মান পেয়ে একটু অবাক হয়, তারপর তাতে অভ্যস্ত হয়ে উঠে, এবং তারপর- এটাই সবচেয়ে বিপজ্জনক ধাপ; সে ধরেই নেয় যে এটাই তার ন্যায্য প্রাপ্য ছিল!!
এই উপলব্ধির পর থেকে সে হঠাৎ আবিষ্কার করে যে তার মতামত অমোঘ, তার রুচি অতুলনীয়, এবং পৃথিবীর বাকি সবাই মূলত তার জ্ঞানের অপেক্ষায় ক্ষুদ্র, তুচ্ছ, অতিনগণ্য। এরপর থেকে সে আর মানুষের মতো আচরণ করে না; সে আচরণ করে একজন রাজকীয় ছাগলের মতো। যেদিকে খুশি যায়, যা খুশি বলে, যা খুশি করে, যা খুশি তাতে মুখ লাগায়, যা খুশি তাই খায়, আর কেউ সামান্য বাধা দিলে উলটো শিং নাড়িয়ে তেড়ে আসে।
এখন স্বাভাবিক প্রশ্ন হলো, এই অবস্থা থেকে পরিত্রাণের উপায় কী?
একটাই উপায় তার, তা হলো 'সম্মান প্রত্যাহার'।
কিন্তু সেটি ধীরে ধীরে করলে কাজ হয় না, কারণ মানুষ নিজের সম্মান হারানোর ব্যাপারে অত্যন্ত সৃজনশীল(!)। প্রতিটি ধাপে সে নতুন ব্যাখ্যা দাঁড় করায়। সে ভাবে এবং বলে- “ওরা আসলে আমাকে বোঝে না”, “ওরা হিংসুটে, আমাকে হিংসা করে”, “ওরা আমার কদর বুঝলো না”, “আমি যে ওদের জন্য কী করেছি তা ওরা বুঝলো না”, কিংবা “এই যুগ/লোকগুলো আমার উপযুক্ত নয়”। এমনকি প্রয়োজনে সে ইতিহাসের দুই-একজন মহামানবের সাথে নিজের তুলনাও টেনে বসে, কারণ তারাও নাকি জীবদ্দশায় স্বীকৃতি পাননি। এই জাতীয় দার্শনিক সান্ত্বনা সে নিজেই নিজেকে অবিরাম দিতে থাকে, এবং ছাগলামি নির্বিঘ্নে অব্যাহত রাখে।
সম্মান পুরোপুরি শূন্য না হওয়া পর্যন্ত এই প্রক্রিয়া থামে না। শূন্যের কোঠায় এসে সে কিছুটা থমকায়, চারদিকে তাকায়, এবং ধীরে ধীরে আবার মানুষ হওয়ার চেষ্টা শুরু করে। তখন অবশ্য অনেক দেরি হয়ে যায়, এবং দর্শকরাও ততদিনে তাকে ছেড়ে চলে গিয়ে থাকে।
তাই কাউকে সত্যিকার অর্থে শ্রদ্ধা করলে, তাকে যতটুকু প্রাপ্য ঠিক ততটুকুই সম্মান দিন, তার বিন্দু বেশি নয়।
কারণ অতিরিক্ত সম্মান আসলে সম্মান নয়, এটি একটি ধীরগতির বিষ, একটি দীর্ঘমেয়াদি অভিশাপ। এই অভিশাপ মানুষকে নিজের অজান্তেই, ধীরে ধীরে, অত্যন্ত নিপুণভাবে অন্য একটি প্রাণীতে রূপান্তরিত করে।
এবং সেই প্রাণীটির নাম ইতোমধ্যে উল্লেখ করা হয়েছে।
Após as atuações de gala de Mbappé, Messi e Haaland por suas seleções, com dois gols do francês contra Senegal, um hat-trick do argentino diante da Argélia e dois gols do norueguês contra o Iraque, resolvi fazer algumas ponderações futebolístico-filosóficas, ao estilo do futebol filosófico do Monty Python.
⠀⠀
বহুকাল আমি নিজেকে একজন ভুল মানুষ ভেবে এসেছি। আমার পৃথিবীটা ছিল কুয়াশায় ঢাকা, যেখানে স্পষ্ট বলতে কিছুই ছিল না। আমার ভেতরে নিজেকে প্রকাশ করার এক তীব্র আকাঙ্ক্ষা ছিল, কিন্তু যতবারই আমি মুখ খুলতে চেয়েছি, ততবারই মনে হয়েছে যেন কেউ একজন আমার কথাগুলো বন্দি করতে ছুটে আসছে। ভয় ছিল আমার ছায়াসঙ্গী। তাই আলো থেকে পালিয়ে বারবার আমি ফিরে এসেছি আমার পরিচিত অন্ধকারে, আর সেই অন্ধকারই হয়ে উঠেছিল আমার একমাত্র পরিচয়। আমি মেনেই নিয়েছিলাম- আমি আদি থেকে অন্ত পর্যন্ত ভুলে ভরা এক মানুষ, যার জন্মই হয়েছে ভুল করার জন্য।
