Alessandro 'kLeZ' Accardo – posts in English

The sitemap that reports itself

kLeZ — Thu, 17 Sep 2026 10:20:00 +0200

On Saturday 12 September, after dinner, I opened my inbox and found an email that had arrived at 22:39. Subject Medium Risk: Sensitive Paths Disclosed via Sitemap on https://klez.me, sender “White Hat 66” (hsafe240@gmail.com). Inside was a security report about my blog, complete with severity, bug name, PoC URL, impact and suggested fix, and at the bottom a request for a reward. My first reaction was a defiant grin, and the urge to track the guy down and give him a piece of my mind.

The bug does not exist

According to the report, my sitemap.xml contains URLs for areas that appear to be administrative, internal or otherwise not meant for the public. That appear is the most honest word in the whole email. Which areas, the email doesn’t say. There isn’t a single path in the report, and the proof offered is a link to the sitemap itself.

I built the blog myself, with Jekyll, a static site generator: pages are generated once and GitHub Pages serves them as they are, with no application code running and no login of any kind. There is no admin panel, and nowhere for one to live. The sitemap lists the posts, /about/, /cv/, /contatti/, /privacy/ and a few course slides under /lf/, which is to say public pages listed on purpose so that search engines can find them, which is the reason a sitemap exists (protocol on sitemaps.org).

The impact section claims the file “directly points attackers to non-public or sensitive areas”. Put that next to the total absence of paths and you can see how the report was born. Someone, or more likely something, found klez.me/sitemap.xml and logged the file’s existence as a vulnerability, without reading it. A tool that treats the mere existence of a sitemap as a bug is a mediocre tool, and whoever uses it to ask for money didn’t even reread what it spat out. Opening the source of the home page would have been enough, since it says <meta name="generator" content="Jekyll v3.9.3" /> in plain text.

The prose reads as if it came out of a language model, every field in its place and not one detail that actually concerns my site. The signature, White Hat 66, has all the gravitas of a gamertag. At the end, under “White Hat Note”, comes the request:

We would appreciate hearing about reward or acknowledgment you may offer.

White Hat 66

Beg bounty, not bug bounty

Troy Hunt calls it a beg bounty. You take any old configuration detail, in his examples a missing DMARC record or an absent security header, wrap it in the language of a vulnerability disclosure and send it to someone who has no bug bounty programme, hoping they’ll pay to make it go away. According to NWS Digital the people doing this target small organisations, where there is often nobody able to tell a vulnerability from a public file.

It is attempted fraud. Article 640 of the Italian Criminal Code:

Whoever, by artifice or deception, leading someone into error, procures an unjust profit for themselves or others to another’s detriment is punished with imprisonment from six months to three years and a fine from 51 to 1,032 euros.

Italian Criminal Code, art. 640(1), translated

And article 56:

Whoever performs acts that are suitable and unequivocally directed at committing an offence is liable for an attempted offence, if the action is not completed or the result does not occur.

Italian Criminal Code, art. 56(1), translated

The invented report is the artifice, the reward for a vulnerability that doesn’t exist is the unjust profit. It didn’t work on me, and that is exactly why the fraud stays attempted.

I didn’t pay and I didn’t reply. A reply, even just to say no, would have confirmed that someone reads that address, which makes it an address worth trying again.

The infrastructure behind the address

That night, without a hoodie, I sat down to read the headers.

SPF, DKIM and DMARC all check out for gmail.com, so the message really was sent from an authenticated Gmail account and it isn’t spoofing. The Message-Id is <6aa5b897.e862d496.39e5c9.6c94@mx.google.com>, the submission to smtp.gmail.com happened at 20:39:51 UTC (22:39 in Italy) and ProtonMail received the email seven seconds later.

The first of the three Received headers, the one at the bottom, shows the address of the client that authenticated with Gmail:

Received: from [192.168.100.57] ([153.117.18.172])
        by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb33ea4fsm15029442f8f.21.2026.09.12.13.39.50
        for <klez@pm.me>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sat, 12 Sep 2026 13:39:51 -0700 (PDT)

192.168.100.57 is the machine’s private address, behind a NAT; 153.117.18.172 is the public address it went out on. The APNIC registry assigns that block to Cyber Internet Services Pvt Ltd, a Pakistani provider known as Cybernet, and the 153.117.18.0/24 prefix is announced by AS9541. According to ip-api.com the address doesn’t belong to a VPN, a proxy or a hosting service, and geolocation puts it in Karachi (with all the precision geolocation usually has).

At the time I checked, the IP wasn’t listed on Spamhaus ZEN, SpamCop or Barracuda, but that says little. Those lists are fed largely by what incoming mail servers see, and this email reached the destination servers from Google’s IPs.

I stopped there, at IP, provider and autonomous system.

What I did

During the night the plan I liked best was a different one: open a few throwaway inboxes on Guerrilla Mail and rough him up a bit (he’s a criminal, so it seemed like a very good idea, and I still don’t hate it). Then I went to bed, and the next morning I settled on this post and two reports.

The first went to Cybernet’s abuse desk, noc-abuse@cyber.net.pk, the address APNIC lists for that block, with the date and time of sending, the Message-Id, the Received line above and an offer to forward the full message. The second went to Google through the Gmail abuse reporting form, because the account is theirs. I don’t know whether anyone will read them.

If you get a similar email, these are the signs:

Subject:  "<Severity> Risk: Sensitive Paths Disclosed via Sitemap on <domain>"
Claim:    sitemap.xml exposes administrative or internal areas
PoC:      the URL of sitemap.xml, without a single sensitive path named
Ask:      "reward or acknowledgment" in the closing note

The same script at the W3C

The W3C’s public mailing list archives hold a thread from December 2024 with the same structure. In October a Gmail sender had filed a “Vulnerability Report” about email spoofing on w3.org, with the usual advice on DMARC and SPF, and in December came back asking for confirmation “about the reported vulnerability and its bounty reward”. A different vulnerability and a different name in the signature, but the same request, and a DMARC record to fix is one of Troy Hunt’s own examples.

Hackers, crackers and hats

In 1983 WarGames comes out, with a teenager who reaches a military system from the computer in his bedroom, and in the same year a group of Milwaukee teenagers, the 414s, makes the news for breaking into several systems, including the one at Memorial Sloan Kettering in New York. One of them ends up on the cover of Newsweek. For much of the American public it is the first time they hear about hackers, and the word arrives already carrying the meaning it still has on the evening news, where in the meantime the kid has put his hood up.

Inside the scene, hacker meant something else. RFC 1392 from 1993, a glossary for Internet users, defines a hacker as “a person who delights in having an intimate understanding of the internal workings of a system”, someone who enjoys understanding how a machine works from the inside. Around the mid-1980s, to defend themselves against the way the press used the word, hackers had coined cracker, a word specifically for people who break into other people’s systems without permission, and that one made it into the glossary too.

Cracker never caught on. Outside the scene nobody uses it, and in Italian the word lands on the crackers you eat with cheese long before it lands on someone breaking into your server. A word that smells of snack food doesn’t work in headlines.

A different image won, taken from westerns, where the good guy wears a white hat and the bad guy a black one. White hat and black hat entered the vocabulary of people who work in security, and later grey hat was added for those who break in without permission but without criminal intent, and often tell you afterwards. Today, outside the industry, the word for a “good hacker” is white hat, and everyone understands it.

The white hat also served to give a job a presentable name. A company is reluctant to let a hacker in the door, but it will put a white hat on contract. Bug bounties predate the hats: in 1983 Hunter & Ready promised a Volkswagen Beetle to anyone who found a bug in its VRTX operating system (“Get a bug if you find a bug”), and on 10 October 1995 Netscape started paying people who found security holes in the Navigator 2.0 beta. Today’s bug bounty programmes grew out of that, with platforms acting as intermediaries between companies and researchers, and written rules.

Anyone who puts on that hat accepts those rules. You look for vulnerabilities where someone has given you permission to look, within a written scope, you rate what you find by severity and you report it through coordinated disclosure. If there is a programme you get paid on its terms, usually only for valid findings nobody else has reported first. If there is no programme you can still report, but you don’t ask for money.

The hat on White Hat 66

Asking for money over a sitemap is petty fraud, the windscreen washer at the traffic lights who cleans your glass unasked and then holds out a hand. What makes me far angrier is the signature.

White Hat 66 has put on a lifeguard’s uniform to walk among the beach towels lifting wallets. The name he pins on himself is the one that got a whole profession out of the crime pages, and he breaks precisely the rule that separates a white hat from a fraudster: nobody asked him for anything, he found no vulnerability, and he wants to be paid all the same.

He took the shape of a bug bounty programme, removed the programme and kept the invoice.

To a small-time fraudster one name is as good as another, I know. Except that it took decades to make that name respectable, and every email like this one devalues it a little, because white hat and bounty become counterfeit currency in the hands of someone spending them to get paid for a sitemap.

The part that hurts

I don’t care about the sitemap, it’s an XML file a script generates for me. What I’m defending is the word, and what sits underneath it. In 2010 I was compiling a distro from scratch with LFS to understand what happens when you press the power button, and in February I went back to it, when LFS stopped documenting System V. Take things apart to understand them, and leave what you build open to being taken apart: everything else follows from there, free licences included.

On that ground, a bloke with a Gmail account is the least of the problems. The same words get taken by companies with a legal department and a communications budget, and they hollow them out at their leisure. Open source has become a phase of the commercial life cycle: Elastic moved from Apache 2.0 to SSPL and the Elastic License in January 2021, HashiCorp from MPL to the Business Source License in August 2023, Redis from BSD to RSALv2 and SSPL in March 2024. The stated reason is always the same, cloud providers reselling other people’s work without giving anything back, and it isn’t made up. The outcome is always the same as well: the community redoes the work from outside, with OpenSearch, OpenTofu and Valkey.

Redis, to its credit, wrote it plainly:

First, we openly acknowledge that this change means Redis is no longer open source under the OSI definition.

Redis, 20 March 2024

Software freedom has become a parameter you adjust when revenue requires it. Hacker, meanwhile, has ended up in job titles: growth hacker, a term Sean Ellis coined in 2010 for someone whose true north is signup growth. Same root, meaning flipped, and nobody bats an eyelid.

What gets lost along the way is the philosophical part, which was the engine of the whole thing: the idea that understanding how something works is a right, and that software should open the way a car bonnet opens. Hollow that out and what’s left is a services market with a few vintage words kept on for the marketing.

An email like White Hat 66’s is funny for ten minutes, then it’s infuriating, and in the end it hurts, because it’s the cut-price version of a theft somebody else is carrying out wholesale, with paid lawyers and press releases.

White Hat 66, if you’re reading: the hat was never your size. But other people had already had it altered, long before you came along.

Sources

Sitemaps.org, the sitemap XML protocol
Troy Hunt, Beg Bounties, 8 November 2021
NWS Digital, Is that Scary Website Security Warning Email Legit?, 29 December 2021
Italian Criminal Code, art. 640 and art. 56, text on Brocardi
APNIC, RDAP for 153.117.18.172, and RIPE Stat, prefix overview for the same address
W3C, public thread from December 2024
Alex Orlando, The Story of the 414s, Discover Magazine, 10 October 2020
RFC 1392, Internet Users’ Glossary, January 1993, and Wikipedia, Security hacker, quoting the Jargon File entry for “cracker”
Cadre, Winning Bug Wars: From Volkswagen Beetles to Million Dollar Bug Bounties, 27 August 2020, and Esben Friis-Jensen, The History of Bug Bounty Programs, Cobalt, 11 April 2014
Shay Banon, Doubling down on open, Part II, Elastic, 14 January 2021
HashiCorp, HashiCorp adopts Business Source License, 10 August 2023
Redis, Redis Adopts Dual Source-Available Licensing, 20 March 2024
Sean Ellis, Find a Growth Hacker for Your Startup, 26 July 2010

Slop, trust, and a three-line patch

kLeZ — Sun, 28 Jun 2026 02:46:01 +0200

A maintainer closed my patch with one sentence: “Sorry, but this sounds like AI slop.” The patch was three lines of Go. It fixed a real authentication bug, it shipped with a debug log that pinned the cause, and a week later a stranger running a different account setup cloned my fork, built it, and reported back that it worked. None of that counted. What counted was the smell.

Now the dull context, which is the whole point. I back ProtonMail’s mail through a small open-source bridge called hydroxide, because I don’t pay for Proton’s own bridge and hydroxide is what I have. Accounts with two-factor authentication can’t finish logging in: the password step and the TOTP step both succeed, and then the very next call, the one that fetches the key salts, comes back 401. Proton invalidates the access token once you clear the second factor and hands you a fresh scope, and the client keeps presenting the old token. I found this by turning on the debug log and reading the request trace. I confirmed it against the behaviour of Proton’s own web client. The fix is to ask for a new token after the second factor and use it for the rest of the login. Three lines, gated so single-factor users never touch the new path.

I’ll be precise about how I worked, because the precision is what the rejection got wrong. I used a language model to read the codebase faster: it was someone else’s Go, I had never seen it, and I wanted a map before I started digging. Read-only. The notes it produced never reached a commit; I deleted them once I understood the code. I wrote the fix by hand. Then, because I was out of time and patience, I described my own change to a model and had it draft the issue and the pull request text. The code was mine; the prose was not. I disclosed nothing about this in the description, which, as I’ll get to, is the part everyone has decided to fight about.

The part where I concede everything

Slop is real. I want to say that before I say anything else, because the people sounding the alarm are not imagining the fire.

The clearest case on record is curl. Through 2025 Daniel Stenberg watched AI-generated vulnerability reports flood the project’s bug bounty until roughly one in five submissions was slop and the rate of reports describing a real vulnerability fell below one in twenty. Seven people on the security team, three or four of them needed to read each report, thirty minutes to three hours apiece to conclude it was nothing. One submission described an HTTP/3 exploit complete with debugger sessions and register dumps, all of it referencing a function that does not exist in curl. Stenberg called it DDoSing open source and shut the bounty down.

What that describes is a resource attack, and it has a name older than the chatbots. Alberto Brandolini’s bullshit asymmetry principle says the effort to refute nonsense is an order of magnitude larger than the effort to produce it. Language models industrialise the cheap side of that asymmetry and leave the expensive side exactly where it was: on a human who has to read, reproduce, and decide. A maintainer facing that inflow is not paranoid. He is doing triage in a building that is genuinely on fire, and a wall is a reasonable thing to want.

The worry behind my rejection is legitimate. It was aimed at the wrong layer.

The wrong axis

Read Stenberg carefully and the complaint is never really about who or what wrote the report. He says outright that it makes no difference whether a submission came from a human or a machine if it carries no real finding and only burns reviewer time. He runs three AI review bots on his own pull requests, at two in the morning when no human is awake. When the models improved in early 2026 curl reopened the bounty, because the slop had thinned out even as the volume kept climbing. His axis is verification. Does the thing check out, and what does it cost me to find out.

“This sounds like AI slop” is a different axis. It is authorship, detected by smell. And smell is cheap, which is exactly why it tempts you when you are tired. You stop reading for whether the claim is true and start reading for whether the prose feels synthetic. The trouble is that the two axes come apart in precisely the case that matters. The smell test fires on the contributor who used a model for the boring half and did the real work by hand, and it fires hardest on people whose English is a second language and who reach for a model to sound fluent. In my case the classifier worked perfectly and was useless: it correctly detected that the prose was machine-drafted, and from that it convicted the code, which was mine and which was correct. The signal it caught was real; the inference it drew was garbage.

The double bind

There is a trap inside this that almost nobody names, and it is worth sitting with.

The same projects that fear slop ask contributors to disclose AI use. hydroxide’s contributing guide is explicit: if a model helped, say so, add an Assisted-by line. Honesty is the rule. Then read James Bach, who has written one of the sharper arguments against AI in writing, and who tells you to do the opposite. Never admit you used a model, Bach says, because the moment you do he will treat your work as slop or spam, and so will every serious professional. In his frame disclosure is a confession of laziness; he compares letting a model draft your prose to taking a helicopter to the summit and claiming you climbed.

Hold both at once. One norm orders you to disclose. The other promises to punish you for disclosing. The honest contributor, code by hand and prose by machine and forthright about which is which, loses under both. No disclosure satisfies the rule-followers and the rule-skeptics together, so the incentive the system actually teaches is to hide: write the prose yourself, badly, or launder the model’s prose through enough edits that nobody can tell. A rule that punishes honest disclosure destroys the very signal it was built to collect. That is not a stable place to stand.

The market for lemons

George Akerlof won a Nobel for describing what happens next, in a 1970 paper about used cars. When a buyer cannot tell a good car from a bad one, he will only pay the price of an average car. Owners of genuinely good cars cannot get a fair price, so they leave. Average quality drops, the price drops with it, and the market can keep unravelling until mostly lemons remain. Information asymmetry does more than annoy buyers. It selects against the honest sellers and degrades the whole pool.

Open-source contribution is now a lemon market. A maintainer who cannot cheaply tell a real patch from a plausible one rationally applies a blanket discount: assume slop, close on sight. The cost of that discount lands on the contributors who did real work, because they are the ones with something to lose. They get treated as the average, the average is assumed to be junk, and so they leave. I will not be sending hydroxide another patch. The bug is still open. Multiply that by every competent person waved off with a one-line smell verdict, and the blanket discount manufactures the exact future it was meant to prevent: a contribution pool with the good actors filtered out. Each rejection is individually rational. The sum is a project pricing itself toward lemons.

Scale is the whole argument

Here is where I have to be fair to curl and hard on the imitation of curl.

curl earns its walls. Hundreds of millions of installations, a seven-person volunteer team, real money on the table that drew people brute-forcing the bounty with chatbots. At that scale the expected value of a random unsolicited submission really is near zero, verifying it really is expensive, and a high prior of slop is correct Bayesian reasoning, not panic. Stenberg is rationing the only finite resource he has, which is attention; his wife has started asking him about his hours.

hydroxide is not curl. By its own maintainer’s account it is casually maintained, kept alive mostly so he can send kernel patches, sitting on a few dozen open issues with no bounty and no crowd. The population of people who install a niche ProtonMail bridge, hit a two-factor bug, read Go they have never seen, isolate the cause, and write a fix is small and heavily self-selected. The base rate of slop in that population is low. Verifying three gated lines costs minutes. Importing curl’s prior into that situation is a base-rate error wearing the costume of prudence: you have adopted the threat model of a project a thousand times your size and applied it to a contributor who, by the sheer cost of getting that far, was almost certainly not your problem.

The maintainer is within his rights. I am questioning the judgment, not the right to make the call. It is his project, his time, and he owes me nothing; I said as much to him, in those words. Rights were never what I was arguing about.

Trust is not a one-way audit

The word everyone reached for in the thread was trust, and they used it as though it ran one way: the contributor earns the maintainer’s trust, the maintainer adjudicates. But trust in a commons is something both sides spend. I spent mine. I installed it, used it, found the bug, read the trace, read a stranger’s code until I understood it, opened an issue that pointed at the exact fault, wrote the patch, and signed it off, all in time I do not have, toward a project I wanted to keep working. A reviewer who closes on a smell spends none of that and discards all of mine.

The repair was cheap. The whole thing was avoidable for the price of one sentence: did you understand this code, and is the description AI-written? The honest answer rebuilds in one line the thing the smell test set on fire. Asking would have cost less than the closing did.

I did not make that easy, and I should own it. When I told the maintainer he “deserved” the broken project and that I would wait for him to fix the bug himself, I handed him the edge he needed to slide the conversation off the code and onto my attitude, which is a more comfortable place for a rejection to live. The structural point survives my bad manners. Closing a reproduced fix on authorship-smell, at a project where verification costs minutes, spends trust that a volunteer commons cannot easily refill.

What it actually costs

I want to keep the stakes the right size. This is not the end of anything; it is a small bridge and a small patch.

But notice who is not harmed by any of it. The closed and the corporate scale fine. They have headcount, process, and money; a slop flood is a line item, and so is review. The thing that runs on nothing but trust between strangers is the small, weird, volunteered long tail: the niche bridge, the one-maintainer tool, the patch from someone you have never met. That is exactly where the blanket-slop posture does the most damage relative to the real threat. The towers protect the projects that least need protecting and price out the collaboration that has nothing else holding it together.

Slop is a tax on attention. The paranoia is a tax on trust. The first is the louder problem and the more obvious one, and it is real. The second is quieter and worse, because attention can be bought back with tooling and money, and the curl story is partly the story of that recovery. Trust between strangers does not recover on that schedule. Once a community’s default reading of a good-faith contribution is “probably a machine, probably junk,” you do not get the default back by upgrading a model. You get it back, if at all, the slow way, one honest exchange at a time, which is the same way it was built and the same way it is now being spent.

The bug, by the way, is still open. The fix still works. Somebody will merge it eventually, by hand, written by a person, the way it was the first time.

Sources

hydroxide pull request and the linked issue: PR #346, issue #345
The contributing policy referenced in the thread: emersion/.github CONTRIBUTING.md
James Bach, Public Service Announcement: Don’t Say You Use AI for Writing: satisfice.com
Daniel Stenberg on AI slop and curl’s bug bounty (primary): daniel.haxx.se/blog; secondary coverage with the figures cited here: The New Stack
George A. Akerlof, “The Market for Lemons: Quality Uncertainty and the Market Mechanism”, Quarterly Journal of Economics 84, no. 3 (1970)
Alberto Brandolini, the bullshit asymmetry principle (Brandolini’s law), 2013

Using The Eisenhower Matrix In Emacs Org-Mode

kLeZ — Tue, 22 Oct 2019 16:18:35 +0200

Riporto integralmente l’articolo di Tom Purl che parla dell’integrazione della matrice di Eisenhower in Emacs Org-Mode.

Purtroppo Tom ha rimosso l’articolo dal suo sito ma sono riuscito comunque a trovarlo tramite la Wayback Machine.

Di seguito (in inglese) l’articolo integrale. Forse (forse) porterò una traduzione di questo articolo nel blog, a imperitura memoria, soprattutto per chi non mastica granché l’inglese.

I just finished reading the The Procrastination Matrix article on the Wait But Why blog and it really spoke to me. I’m a big fan of using Org-Mode in Emacs to organize all of my tasks, and I wondered if I could make both of these systems work together. Naturally, Org-Mode makes it really easy, and here’s how I did it.

Easy Tagging

First, I need to be able to categorize my TODO’s as being urgent, important, or both. The easiest way to do this in Org-Mode is to use tags that looks something like this:

** TODO Pay bills                                                    :urgent:

You can easily add tags using the C-c C-c command, but I like to make things even easier by using the org-tag-alist variable:

(setq org-tag-alist '(("important" . ?i)
                    ("urgent"    . ?u)))

Now when I tag a TODO item, I simply need to type i or u to tag it as important and/or urgent.

Canned Searches

Now that my TODO’s are tagged I would like to be able to look at all 4 quadrants quickly and easily. I can do this in Org-Mode by setting the value of the org-agenda-custom-commands variable. Here’s what I have:

(setq org-agenda-custom-commands
   '(("1" "Q1" tags-todo "+important+urgent")
     ("2" "Q2" tags-todo "+important-urgent")
     ("3" "Q3" tags-todo "-important+urgent")
     ("4" "Q4" tags-todo "-important-urgent")))

Q1 stands for “quadrant 1” and contains all TODO’s that are tagged as both important and urgent. Q2 contains all of the TODO’s that are tagged as important but not urgent. And the rest should be pretty self explanatory.

Now when I press C-c a I see my usual agenda search dialog with the following lines at the bottom:

  Q1        : +important+urgent
  Q2        : +important-urgent
  Q3        : -important+urgent
  Q4        : -important-urgent

I can then see all of the tasks for a given quadrant by pressing the corresponding number.

That’s It!

Once again Org-Mode has proven itself to be very easy to customize. It literally does everything for me but complete my tasks and show the Instant Gratification Monkey who’s boss.

Free Software Day

kLeZ — Thu, 14 Feb 2019 12:48:55 +0100

Today it’s free software day! Let’s celebrate!

A nightmare to remember -- not the Dream Theater's song -- [BTRFS vs. me - pt1]

kLeZ — Thu, 01 Aug 2013 18:42:35 +0200

Today I want to say a few words about BTRFS. Firstly I want to say that this filesystem is awesome for functionalities, I will use it as my filesystem again as soon as it will become stable. But, It is not yet stable, I tried and I fallen in front of his horrible performances.

Actually there are some problems on this filesystem that developers know in fact but, they are much more complicated to solve because most of them are normal behaviors of other functionalities. As an example in order to understand much better and quickly: there is a known issue of (obviously) horrible performances that I experimented by myself, it makes performance decrease whenever you use it because he want to write down all the data in the same time, he want also manage all the metadata at the same time, only because those data are in the same transaction (!!), and you cannot do anything to fix that behavior because it is not customizable AND this is the normal behavior of work for btrfs. Result: you have an awesome filesystem that decreases its performances more quickly than Windows, so it is hardly unusable, especially if you use it for the root partition.

A system cannot be so slow in 2013 so I ended up in a solution: I have to migrate my filesystem. I’m not a fan of passing data from a disk to another, I make a few bckups sometimes but not always, in fact this is a bad attitude, but that’s me. SO.

In order to migrate the root filesystem (yes I had BTRFS for the root – and home – filesystem, I used to be a bad guy, huh) I used a slooooow but simple universal and powerful solution. The situation was aggravated by the fact that my laptop has secure boot and then the boot partition was very touchy. I used the well known live distro (any live distro could do this work, I used the openSuSE recovery system for that purpose) and so I logged in a shell. The rest are some commands, a cp, some other commands.

Anyway, here is what I typed:

I had to make a new partition of the same size or even better, so I resized the btrfs home partition of -200G in order to keep root filesystem very large.

btrfs filesystem resize -200G /dev/sda4

Then I created the new filesystem and after that I mounted old (as read only) and new root filesystems.

So I ran this command: __

cp -bfrdvx –preserve=all –suffix=~-bak-newfs -t /newfs/ /old/{bin,boot,etc,lib,lib64,media,mnt,opt,root,run,sbin,selinux,srv,tmp,usr,var}

It took a few to complete but as it finished I had all my old root copied in the new one. I omitted copy the home folder because I have a separate partition for that, but I copied boot because even if I have a partition for that some files needs to be copied in any case.

Explination:

-b: means backup, cp makes a backup if it has to overwrite a file, as described in the man “it works better with -f [force] and -r [recurse]”

-f & -r: means recurse and force overwriting if you find the same file on destination

-d: this is the combination of two other switches, it means that cp cannot ever follow any link in the source and it should preserve the link attribute on the new filesystem, it is useful in our case because we want to keep everything even links to system libraries, kernels configurations and so on. We have a user friendly distro, not slackware, so we want to preserve the configurations made by the packagers of our precompiled software.

-v: verbose, no words.

-x: stay on this filesystem but, as described by man “mount points are not worth” [read that as if you were David Letterman].

–preserve=all: means preserve all attributes, other than links (remember -d__ switch?)

–suffix=~-bak-newfs: I chose only a suffix that I can remember of, later.

-t /newfs/: oh well, I’m explaining cp, but you should know of the -t option, it sets the destination folder.

/old/{bin,boot,etc,lib,lib64,media,mnt,opt,root,run,sbin,selinux,srv,tmp,usr,var}: the filesystem, without volatile folders. This a bash expansion, so it is not fully trusted to use it on a different shell.

Ended now?! No! You should go across other commands in order to recover your poor system. As it i now your new root don’t knows how to start itself, it knows only how to start the old root. There are some files you have to edit in order to let the new root know about itself.

/etc/fstab

You have to edit the /etc/fstab of the new root because you have to change the mount device for / (root) mount point.

I assume you know how to modify fstab.

Then for the rest of configuration you have to chroot into the new root, so I bounded volatile filesystems (dev sys proc) and chrooted into the new root.

You have to fix two main things that are broken because of their reference to the old filesystem: bootloader and kernel, you mind that if you do not do that part, the system will not boot up.

In order to fix grub2 (I have grub2-efi so I make a guide on that, do not try to ask of lilo grub legacy or other BLs) I had to fire the command below:

grub2-mkconfig -o /boot/grub2/grub.cfg

So easy? Yes! Grub2 is composed of a bunch of useful scripts that detect automagically all the systems installed in the mounted partitions, and writes all the data into the grub.cfg. It’s handy isn’t it?

For kernel you have to pray all goes smooth as it did for me, in othre cases, I saw errors that you humans will never see in your lives.

This is the command: mkinitrd, if it works, good, anyway pray god it will autofix itself.

Once fstab, init ramdisk, and grub2 are all fixed you can try to exit the chroot and reboot your machine, optionally you can also delete the old root partition.

If it ended up smooth you should see grub2 loading, kernel loading and launching init, and the rest of the system run as normal, but with greater performance.

I hope they will fix those errors and make btrfs ready for the prime time as soon as possible, anyway I have btrfs for the home partition yet, so I have chances to try it out more and more.

SecureBoot [The last Microsoft weapon to keep its users locked on Windows... 8]

kLeZ — Tue, 30 Jul 2013 03:05:47 +0200

Tonight let’s talk a little about SecureBoot.

Secure Boot is IMHO the worst thing that Microsoft did in the last 15 years, and we’re talking about an era of Windows 98 [Epic Crash!], Windows Millennium [BUUgs] and Windows Vista [SLOOwness], and the first Service Pack of Windows XP, that introduced more bugs than that ones it has corrected. So it is IMHO a horrible thing that will never protect them against malware: done the law, found the trick. BUT! As Microsoft does every time a new component is introduced, every hardware producer install a copy of it in its UEFI firmwares, this leads to problems for most of the users in the dreamland of linux.

Thanks to Red Hat, Novell and Canonical (Fedora, OpenSuSE and Ubuntu), we stolen (making noise with money) a key from Microsoft and we can now successfully install in a GPLv3 way our preferred OS: GNU/Linux [I’m sorry RMS, I was going to write only Linux, don’t flash me with a lightning].

I installed successfully openSuSE 12.3 on my Asus K55V with UEFI and SecureBoot, but tonight it stopped working after a reboot (!!). As I’m actually writing this blog post, you can deduce that I have solved my issue. Yes. I solved my issue. I’m fine thanks, my granny is greeting you.

What happened was that SecureBoot has forgotten all the non Microsoft keys [I always thought Microsoft could put a naughty joke in one of its core components, Bad Microsoft BAD] and the only way I found to repair was to enter in the repair system of the openSuSE DVD and to use efibootmgr to solve the things.

Before to do that I have to clear [it is not like a charm, some times, it won’t clear anything, even after reboot] all the keys in the key store of the UEFI settings. I’m lucky to have this menu, others could be not-so-lucky as I was.

Then entering the repair mode I had to fire this command: efibootmgr -c -L openSuSE -d /dev/sda -p 1 -l \EFI\opensuse\shim.efi.

Explain: -c : means that efibootmgr has to create a new boot entry -L : it is the name of the boot entry in the UEFI menu -d : takes the block device in which the efi things and the OS resides -p : could mean partition to someone, that are my guys! -l : it keeps the loader with all the path, DOS-like [because this shit was written by Microsoft], starting from the root of the partition containing the efi code, in my case efi has its own partition, the first

Now if it happens to you, and you are not a Microsoft lover, you can repair (almost) easily the (UN)SecureBoot.

Oh well, I was going to forget, to see if you have SecureBoot enabled, on a running Linux system, run this command below, 1 as enabled, 0 otherwise:

od -An -t u1 /sys/firmware/efi/vars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c/data.

I hope you will never need this page.

Nerditure of a tech-nerd: Prologue [How to use ADB on a working Android phone to send sms through a PC]

kLeZ — Mon, 29 Jul 2013 18:38:37 +0200

Hey all, this is the very first post of my blog and I want to thank myself for having decided, finally.

Today I needed to send a text message (S[hort]M[essage]S[ervice]) to my girlfriend, in order to instruct her on how to go somewhere in Rome (Italy) and grab a little thing for me. There were a lot of informations to aggregate and I used EMACS, as I usually do, to keep them together. Grepped all the data from the Internet, placed on an EMACS new buffer, and cleaned some bytes here and there and the file is ready to be sent to her.

Now I have to copy all the text by hand on the phone and send the text… No wait! I’m a smart tech-nerd so I have to find a better way to do so. Well, Unix fan, a bash under my fingers, an android phone connected to my laptop…. “Can I send an SMS through an Android Intent by hitting some adb shell commands?” I thought and I replied instantly “YES!”.

Long story short: At the bottom of this page you can find a link to my github.com repo where I put the code I used to send the text message. Note that this could not work for you, and that will not be my fault, even if it brokes up your device. It worked for me, not guaranteed it can work for you.

SO.

I searched the Internet, thanks Holy Google, and found out that I can launch an Intent via shell on android with _am start _, a useful answer is on this stackoverflow question: [http://stackoverflow.com/questions/6613889/how-to-start-an-android-application-from-the-command-line](http://stackoverflow.com/questions/6613889/how-to-start-an-android-application-from-the-command-line). Hm, interesting. Then I searched the sendto intent in the Android documentation: here's a link [http://developer.android.com/training/basics/intents/filters.html](http://developer.android.com/training/basics/intents/filters.html). Guessed other details [here](http://stackoverflow.com/questions/4043490/how-do-i-send-an-sms-from-a-shell) and [there](http://stackoverflow.com/questions/6980090/bash-read-from-file-or-stdin). The final script can be found in my git repo, below.

Here’s the link for you: https://github.com/kLeZ/lin-utils/blob/master/adb-sms-send.sh

Enjoy!