kevinday

https://www.php.net/archive/2026.php#2026-10-20-1

One example is Musk Thistle. It grows extremely rapidly, reproduces at a rate that's unbelievable, and is very difficult to kill. In this heavily farmed region, a few of them growing in a roadside ditch can turn into tens/hundreds of thousands of them within a year. Not only do they outcompete just about any other plant including crops, but they have incredibly sharp barbs that injure livestock.

In publicly owned spaces or abandoned fields/lots, the county has people that searches for them and sprays them with a herbicide. If they're spotted on your private land, usually they'll notify you that you have X days to cut them down (before they flower and seed) or they'll come do it whether you want them to or not. Some counties will send a bill for this, some fund it from property taxes.

If you haven't lived in an area where they vigorously grow it sounds like a huge overreaction, but left uncontrolled because one neighbor isn't taking care of it, it can become impossible to keep it out of your yard. According to wikipedia, a single plant can produce 10,000 seeds that disperse through the wind and remain viable for decades in the soil. Even the desire to not have a painful rapidly reproducing weed in your yard aside, they can do incredible damage to cropland.

It's a shame though, it's a kinda pretty flower. Imagine a vivid pink sunflower.

https://en.wikipedia.org/wiki/Carduus_nutans

This is an in-browser ARM PC emulator, running an ARM port of MS-DOS 4 with full accurate PC hardware (VGA graphics, Sound Blaster, IDE, etc) and a ton of software ported to a very DOS-like ABI running ARM instructions. Off-the shelf games and applications like Doom, Quake, the GEM desktop and more were ported and recompiled for ARM-DOS.

Clones of many DOS applications were created, like a full Turbo C style IDE (with TinyCC as a compiler) or a pretty extensive QuickBasic like IDE are there.

You can launch TERM (a ProComm like terminal emulator) and dial a BBS, that runs as an entire second ARM-DOS PC in your browser and upload/download things and play door games. There's a second early AOL-like dialup service that lets you access real Wikipedia and Hacker News over the authentic speed modem - and even view images full screen and watch the re-encoded GIFs slowly download.

There's also a full Rosetta-like JIT converter. You can take most stock X86 DOS applications and just run them.

This is part an exploration of 80's PC nostalgia, and part a tech demo of what an IBM ARM PC could have been. Then trying to see how over the top this idea could be taken within the confines of a browser.

https://kevin.day/armdos/ to play with this https://kevin.day/armdos/docs/ for manuals and more info

But on any modern CPU there should be essentially no penalty for doing that now. Testing the full register is basically free as long as you aren't doing a partial write followed by a full read (write AH then read AX), and I don't think there's any case where this could stall on anything newer than a Core 2 era processor. But just replacing that with a "jnc" or whatever you're exactly trying to test for would be less instructions at least. I'd love to see benchmarks though if someone has dug deeper into this than I have.

I kept telling it to debug the problem, and that I had confirmed that database file was not the problem. It kept trying to rm the file after it noticed the code would recreate it (although with no data, just an empty db). I thought we got past this debate until I wasn't paying enough attention and it added an "rm db.sqlite" line into the Makefile and ran it, since I gave it permission to run "make" and didn't even consider it would edit the Makefile to get around my instructions.

for more background. The short story is that when doing CNAME based validation, they were supposed to put an underscore at the start of the random string for you to add to your DNS records. They still generated sufficiently random strings but didn't include a _ before it which is in violation of the RFC. The rationale is that some sites might do something like give you control of yourusername.example.com and they don't want to make it possible for random users to register the random string and be able to manipulate it. If you don't allow users to generate anything that causes a hostname to appear with a leading underscore, they can't pass the domain validation.

This is a slightly better and more detailed version of this story.

Renew your affected certificates and install them immediately to ensure that your services continue to be available.

If you need support for the renewal, please comment here on the ACME Community where our staff and Community members will be able to assist.

We apologize for any inconvenience this may cause.

Buypass as

I appreciate the sentiment, but new devices being sold that still don’t support WPA3 means the adoption of 6GHz is going to be a very slow process.

More info here since this is surprising to many: https://www.extremenetworks.com/resources/blogs/wireless-sec...

OpenBSD uses pdksh, Busybox/NetBSD/Minix use ash, there are some linux distros that use zsh, OpenSolaris is ksh, etc.

This was later improved with things like chunked encoding and caching the compressed output on the server side, but they came later and weren't always supported or desirable.

https://twitter.com/eromang/status/1183422784082530304/photo...

You can try yourself by going to one of the IOS Safe Browsing test pages on your phone, and when the warning pops up click "Show Details". It'll either say Google or Tencent on the warning message, which should let you know which one got chosen for you.

https://testsafebrowsing.appspot.com

I just tried it, and it says Google for me in the US.

https://pastebin.com/vmgSU6nj

  # cat >sleepy.c
  #include <unistd.h>
  int main(void) {
    sleep(999);
    return 0;
  }
  # cc -o sleepy sleepy.c
  # ./sleepy &

  # cp /bin/date sleepy
  cp: sleepy: Text file busy

  # install /bin/date sleepy
  # ./sleepy

  # touch a
  # stat -f %i a
  686974
  # cp /etc/motd a
  # stat -f %i a
  686974

  # stat -f %i a
  686974
  # install /etc/motd a
  # stat -f %i a
  687076

  46785 install  CALL  unlink(0x7fffffffed52)
  46785 install  NAMI  "a"
  46785 install  RET   unlink 0

  46785 install  CALL  openat(AT_FDCWD,0x7fffffffed52,0x602<O_RDWR|O_CREAT|O_TRUNC>,0600<S_IRUSR|S_IWUSR>)
  46785 install  NAMI  "a"
  46785 install  RET   openat 4

It sounds like they distributed a tool that goes through your Chrome saved passwords database and if the installer thinks you're a pirate, it sends credentials from that database back to the author. The author is now saying they used credentials they learned from this to break into a private website to learn more about how their DRM was being bypassed.

This seems so incredibly illegal, I can't believe they admitted that this is what they're doing.

https://www.facebook.com/help/125384024209252?helpref=faq_co...

#1 Weak default key in config_auth()

If you're only doing local timekeeping, and not using authentication (you'd know if you were) this doesn't apply. Basically the automatically generated key used for authentication (if you didn't specify one) was only 31 bits long and easily guessable.

#2 non-cryptographic random number generator with weak seed used by ntp-keygen to generate symmetric keys

Same as the above. If you're not using keyed sessions with remote hosts, this doesn't apply to you. Even if you are, the worst you're losing here is that someone could potentially mess with your clock.

#3 Buffer overflow in crypto_recv()

If you are using crypto (i.e. your ntp.conf file contains a line starting with "crypto pw"), you are potentially remotely exploitable to remote code execution. You probably do not have that configuration line set unless you know you put it there.

#4 Buffer overflow in ctl_putdata()

From the sound of the post on ntp.org, this is the scary one. "A remote attacker can send a carefully crafted packet that can overflow a stack buffer and potentially allow malicious code to be executed with the privilege level of the ntpd process." This makes it sound like everyone is exploitable. However, Redhat says "the ctl_putdata() flaw, by default, can only be exploited via local attackers". This makes me believe if you have your ntp.conf locked down using the 'restrict' lines you might not be vulnerable.

#5 Buffer overflow in configure()

This is the same as #4, ntp.org's advisory is vague enough that it sounds like everyone is vulnerable. Redhat is saying "the configure() flaw requires additional authentication to exploit." I do not know what this means.

#6 receive(): missing return on error

From their description, it's technically possible (but they haven't done it) to get ntpd into a weird state that is unlikely to be exploitable.

TL;DR: You're possibly vulnerable to #4 and #5 on a stock configuration. Redhat says no, ntp.org's advisory is vague enough that I'm not sure.

https://www.youtube.com/watch?v=IEp6ca9Ppks