The $15 minimum wage may yet pass as part of the pandemic relief bill; who knows. The Democrats in the House, admirably, intend to go right ahead and pass the relief bill with the minimum-wage increase included in it, in effect daring anybody in the Senate to be the one who'll sign their name to having stripped it out. But this, exactly this kind of dithering and capitulating, is why the Democratic party is always so much less popular than incredibly well-liked ideas -- Medicare For All, gun control, COVID-19 relief checks, minimum-wage increase, a federal government that does more to help people directly, etc. -- whose only support in government comes from its own members. Given the rare opportunity to flex some power, and a clear and obvious moral mandate to do so, they're throwing their hands up at non-binding parliamentary procedures and well actually-ing their own supporters over what exactly the phrase "$2,000 checks" means.

Bigots and billionaires and culture warriors can at least count on the Republican party to gleefully immiserate the classes of vulnerable people they despise, whenever it's entrusted with the power to do so. The only thing you can count on the Democratic party to do is to develop a sudden paralyzing case of situational Budget Concern or Norms Respect, whenever it can cripple or stall or dilute the fulfillment of a pledge to make common people's lives better, to materially address any of the myriad ways American society has been warped into incoherent brutality by capitalism and white supremacy.

Previously, previously, previously.

TL;DR: There should be an option, taproot=lockintrue, which allows users to set lockin-on-timeout to true. It should not be the default, though.

As stated in my previous post, we need actual consensus, not simply the appearance of consensus. I’m pretty sure we have that for taproot, but I would like a template we can use in future without endless debate each time.

• Giving every group a chance to openly signal for (or against!) gives us the most robust assurance that we actually have consensus. Being able to signal opposition is vital, since everyone can lie anyway; making opposition difficult just reduces the reliability of the signal.
• Developers should not activate. They’ve tried to assure themselves that there’s broad approval of the change, but that’s not really a transferable proof. We should be concerned about about future corruption, insanity, or groupthink. Moreover, even the perception that developers can set the rules will lead to attempts to influence them as Bitcoin becomes more important. As a (non-Bitcoin-core) developer I can’t think of a worse hell myself, nor do we want to attract developers who want to be influenced!
• Miner activation is actually brilliant. It’s easy for everyone to count, and majority miner enforcement is sufficient to rely on the new rules. But its real genius is that miners are most directly vulnerable to the economic majority of users: in a fork they have to pick sides continuously knowing that if they are wrong, they will immediately suffer economically through missed opportunity cost.
• Of course, economic users are ultimately in control. Any system which doesn’t explicitly encode that is fragile; nobody would argue that fair elections are unnecessary because if people were really dissatisfied they could always overthrow the government themselves! We should make it as easy for them to exercise this power as possible: this means not requiring them to run unvetted or home-brew modifications which will place them at more risk, so developers need to supply this option (setting it should also change the default User-Agent string, for signalling purposes). It shouldn’t be an upgrade either (which inevitably comes with other changes). Such a default-off option provides both a simple method, and a Schelling point for the lockinontimeout parameters. It also means much less chance of this power being required: “Si vis pacem, para bellum“.

This triumverate model may seem familiar, being widely used in various different governance systems. It seems the most robust to me, and is very close to what we have evolved into already. Formalizing it reduces uncertainty for any future changes, as well.

*Germany convicts former Assad regime agent in historic Syria torture verdict.*

*Woman awarded $7,700 for five years of housework in China divorce ruling.*

It is a long-standing feminist complaint about social practices that women tend to do the chores, and their work is undervalued because it is unpaid. It seems that China takes this argument seriously.

Frequent forest fires reduce the forest's carbon capture.

This is another positive feedback that will push us towards disaster.

Protests have put an end to the plan to build a giant gas power plant in England.

The UK should build batteries or other energy storage units instead.

*Israeli checkpoint killing of Palestinian was an execution, report claims.*

*Corporate Lawyers Line Up for Justice Department Top Slots.*

* Decline in system underpinning Gulf Stream could lead to more extreme weather in Europe and higher sea levels on US east coast.*

*Covid and the climate crisis show why we need a new social contract between old and young.*

Let's resist supposing that the question is whether to blame the baby boomers in general or generation z in general, because maybe it's neither. Plutocrats often play divide and rule. Setting the old and the young against each other is just their sort of thing.

The argument that we need to retire later, and thus keep working longer, makes perfect sense, but how can that be reconciled with the fact that lots of people in their 50s are already terminally out of work?

Meanwhile, the lifestyles of Americans are terribly inefficient. Surely we can do something to move to greater efficiency in our consumption.

The Environmental Poisoning Agency engaged in the most blatant stupidity to overlook evidence that Telone is carcinogenic.

Many Yazidis cannot go home to Shinjar, and continue to live in dismal refugee camps. With Covid-19 on top of that, some young people are committing suicide.

If the wrecker had continued the campaign to eradicate PISSI, perhaps more of the Yazidis could go home.

I am surprised by the statement that some Yazidis remain prisoners of PISSI. PISSI no longer controls territory; where can it hold its prisoners. The statement is so brief and sketchy that it is hard to make sense of. The reference given does not seem to say anything about this.

Len Kusov:

PSA: if you or someone nearby are being brutalized by a police Spot robot and can get a hand or something underneath, grab this handle and yank it forward. This releases the battery, instantly disabling the robot.

Keep your hands away from joints, Spot WILL crush your fingers.

If you are a bystander and can get BEHIND spot, don't hit the power button, hit the OTHER button - it physically disconnects the motors.

Spot can also be countered with booby traps easily.

If you're armed, shoot center-of-mass as normal. The lithium pack is huge and not armored

Spot is also purely optical, meaning paint, dust, a sheet or blanket, sticky tape, etc can severely impair it.

Original stereo cameras on the face. 360 camera, pan/tilt/zoom cam, and LIDAR rangefinders on accessory rails.

If you're feeling creative, and can prepare beforehand, Spot is literally just controlled with an Android tablet. In manual (as in, non-autonomous) mode, Spot is literally just communicating over Wifi.

A WiFi jammer based on an ESP2866 is $40 on Amazon, just sayin.

Ostensibly, Spot was never meant to see combat - at least the current iteration of it.

There are, of course, military versions in the works that probably get rid of most of these vulnerabilities but police departments are buying the civilian ones just cause they can.

Previously, previously, previously, previously, previously, previously, previously.

There is no safe way to have in-person classrooms without massive vaccine deployment, no matter how much you want a babysitter.

This is not rocket surgery.

Previously, previously, previously, previously, previously.

If like me you're wondering, "But why tho?", you might dig up this article: mostly a history of other times that people have moved houses, and including only this by way of explanation:

The move of 807 Franklin St. is being done by a private owner looking to restore two empty Victorian-era buildings while making way for a new eight-story, 48-unit rental property.

...leaving me still wondering, "But why tho?"

Previously, previously, previously, previously, previously.

Today we learned that an art group is planning a spectacle to draw attention to a provocative use of our [military] robot, Spot. To be clear, we condemn the portrayal of our [military] technology in any way that promotes violence, harm, or intimidation. [...]

In addition, all buyers [except the military] must agree to our Terms and Conditions of Sale, which state that our products must be used in compliance with the law, and cannot be used to harm or intimidate people or animals.

The "and" in that last sentence is doing a lot of heavy lifting: armies, are they legal?

Anyway, it was very nice of Boston Dynamics, The Robot War Dog Company,™ to put out a press release drawing attention to this art project, but they seem to have mistakenly left out the link to the art project itself! What an embarrassing oversight! It's here:

Spot's Rampage by MSCHF:

We've put a Spot in an art gallery, mounted it with a .68cal paintball gun, and given the internet the ability to control it. We're livestreaming Spot as it frolics and destroys the gallery around it. Spot's Rampage is piloted by YOU! Spot is remote-controlled over the internet, and we will select random viewers to take the wheel.

WILL THERE BE A "WINNER"?

We're all winners in our hearts.

WILL THERE BE A LOSER?

The human race, when remote-operated dogs of war become commonplace. As these war dogs become fixtures of militaries and militarized police we will all learn a new meaning of fear: an oppressor who can pull the trigger without even needing to be physically present.

MANIFESTO

See Spot Run. It tops out at a blistering 3mph.

See Spot Roll Over. Spot is an empathy missile, shaped like man's best friend and targeted straight at our fight or flight instinct. When killer robots come to America they will be wrapped in fur, carrying a ball. Spot is Rob Rhinehart's ideal pet: it never shits.

Good Boy, Spot! Everyone in this world takes one look at cute little Spot and knows: this thing will definitely be used by police and the military to murder people. And what do police departments have? Strong unions! Spot is employee of the month. You never need to union bust a robot - but a robot can union bust you.

See Spot KILL!! Spot is an empathy building tool, because: Cute and approachable! We talked with Boston Dynamics and they HATED this idea. They said they would give us another TWO Spots for FREE if we took the gun off. That just made us want to do this even more and if our Spot stops working just know they have a backdoor override built into each and every one of these little robots.

See Spot Fall Over And Freak Out. Quite an experience to live in fear, isn't it? That's what it is to be a slave. Our saving grace: Spot is evil but not very good at its job.

Previously, previously, previously, previously, previously, previously.

"This is fine."

jackdanger:

As the price goes up it's worth it for miners to spend more to mine a coin. Even if it costs them enormously in energy costs.

Will they? Guaranteed.

As long as someone who wants to better their finances can make a fortune destroying a common good at least one psychopath will do that.

[...]

What can we do? Treat Bitcoin like we (should) treat the heroin trade. Folks want it, suppliers are getting foolishly rich off it, and it does absolutely no good.

Stop adding it as a checkout option like it's not a planet-killer.

And for godsakes stop letting anyone refer to the future promise of blockchain as a beard for BTC. If there were any other use besides burning Earth to a crisp we would have found it by now.

But this analogy may unfairly malign heroin, which for all its downsides, has probably brought the world more joy than Bitcoin ever has.

Previously, previously, previously, previously, previously.

These changes greatly reduce the amount of code running in the "critical" section: the part of the code where a crash would cause the screen to unlock. That critical section is now only around 1,800 lines of code, a reduction of roughly 87%.

My approach with XScreenSaver, as I've written about extensively, has always been to minimize the amount of code in the critical section: to link with as few libraries as possible, and to sandbox as much of the rest as possible in separate processes. This approach has worked out very well; XScreenSaver has had an excellent security track record over these last three decades. Not perfect, but pretty damned good. Especially as compared to its putative "competition".

But, it still contains quite a lot of code, and keeping up with new operating system features like hot-swapping of monitors, new ways of detecting user activity and so on, has caused more and more code to creep into it. Remember that XScreenSaver predates not only HDMI, but USB! I wrote the first version on a 1-bit monochrome display.

So I stepped back and took a fresh look at the whole thing from the perspective of, "what needs to be here?" In addition, dropping support for X11 systems more than fifteen years old -- an eminently reasonable thing to do -- allowed me to simplify the flow of control a lot.

The new design looks like this:

• xscreensaver
  • The daemon. Links with Xlib and nothing else.
  • Requires the XInput2 extension, standard since X11R7 in 2005.
  • Handles grabs, idle detection, and client messages.
  • Maps no windows.
• xscreensaver-gfx
  • Launched by xscreensaver to blank the screen.
  • Launches the screenhacks as sub-processes.
  • Handles monitor reconfiguration, fading, visuals, etc.
  • If it crashes, the desktop will momentarily be visible, but the keyboard and mouse will remain grabbed and the screen will remain locked.
• xscreensaver-auth
  • Launched by xscreensaver to authenticate the user.
  • Draws the unlock dialog, and talks to PAM.
  • Exit code indicates success or failure, so if it crashes, that has the same behavior as "incorrect password".

The old XScreenSaver daemon contained 14.5k lines of code in a single executable. The new one contains 12.5k lines across three different executables -- a 14% reduction overall. But as I said earlier, the critical section -- the process whose crash will result in an unlock -- now contains only 1.8k lines -- an 87% reduction. This is great not just because it reduces the attack surface, but also because it's easier to understand and audit.

Since this is a very large change, I would like to get a lot of testing on this before calling it ready for release. Please beat on it, eyeball it, throw whatever you can at it, and see if you can make it crash. Particularly, see if can make it crash and unlock.

Let me know if any of these things don't work by default:

• There should be no compilation errors that "configure" didn't warn you of first.
• Locking should work, specifically unlocking.
• The "xscreensaver-systemd" program should be running in the background.
• Fonts and font sizes in the unlock dialog should look sensible.
• Custom fonts should have been installed and used (e.g. "memscroller" should be using an OCR font).
• Fading and un-fading should be smooth on all screens.

Things that it would be nice to have some testing on, if you have the means:

• Non-English locales.
• Passwords containing non-Latin1 characters.
• Unixen that are not Linux.
• Linuxen that are not Debian or Fedora.
• Hot-swapping monitors willy-nilly.
• Laptops with flaky power management.
• HiDPI monitors.
• PBP monitors ("two HDMI one cup").
• Kerberos.
• Exotic PAM authentication methods, such as USB or bluetooth fobs, or fingerprint readers.
• Any PAM setup that prompts for more than one input.
• Does XScreenSaver interact sanely with remote desktop clients or games that grab the mouse for long periods?
• Exotic input devices: do you have a controller that does not present as key-press or mouse-motion, and does XScreenSaver recognize it as user activity?

Launch it as "xscreensaver -log log.txt" and if anything goes wrong, send me the entire log file, and as many other details as you can about your system and what was going on at the time.

If there were any compilation problems, send me the entire output from "configure" and "make", as well as the "config.log" file.

Please note, this is a BETA release. Do not download this unless you are willingly participating in the testing of software that is probably flaky! And above all, do not distribute this version to other users.

Do send me email and let me know what systems you've tried it on and how that went.

Thanks!