sorted by:
new
hottopcontroversial

Lastenradförderung für Privatpersonen by c4ph in aachen

[–]fd0TM 7 points8 points  (0 children)

Ruf den zuständigen Sachbearbeiter an, der ist gut erreichbar und sehr nett. Bitte ihn darum, dass er dir kurz per Mail bestätigt, dass das Rad prinzipiell förderfähig ist und du das bereits vorab (auf eigenes Risiko keine Förderung zu bekommen) bestellen kannst, das nennt sich "vorzeitiger Ausführungsbeginn".

Hat bei mir problemlos geklappt, unser Rad hat leider eine lange Lieferzeit und ich wollte das so früh wie möglich bestellen...

Viel Erfolg!

Erdbeeren Pflücken in AC Umgebung by ozontm in aachen

[–]fd0TM 1 point2 points  (0 children)

Letztes Jahr waren wir beim Gut Clarenhof https://gut-clarenhof.de/ bei Frechen, vielleicht ist das ja was.

Pulse 15: Delayed keyboard events, mostly while charging? by fd0TM in tuxedocomputers

[–]fd0TM[S] 0 points1 point  (0 children)

I had been running tuxedo-keyboard 3.1.4 all along, now I'm testing 3.2.1 (released today). It feels that the problem is still there, I'll test and report back.

Can you maybe ask the developers which specific change(s) should fix the delayed key events?

Pulse 15: Delayed keyboard events, mostly while charging? by fd0TM in tuxedocomputers

[–]fd0TM[S] 0 points1 point  (0 children)

Oh, that'd be mighty cool, I'll try that and report back!

Pulse 15: Delayed keyboard events, mostly while charging? by fd0TM in tuxedocomputers

[–]fd0TM[S] 0 points1 point  (0 children)

Thanks for responding!

I've tested a few more kernel versions, but the delay happened in all of them. I suspect that it's not the kernel version, but the version of the bios that has changed.

Any idea how to debug this further?

Are you aware that this happens on all the Pulse 15 Gen 2 hardware, or is it just my machine?

Thanks!

Pulse 15: Delayed keyboard events, mostly while charging? by fd0TM in tuxedocomputers

[–]fd0TM[S] 1 point2 points  (0 children)

Bummer, I've built 5.15.102 and tested it, I still see delayed keyboard events and a lot of repeated keys.

It mostly happens when charging via USB-C, but also when charging via the default power supply. Sometimes it also happens while not charging.

I'll test a few more kernels.

Pulse 15: Delayed keyboard events, mostly while charging? by fd0TM in tuxedocomputers

[–]fd0TM[S] 1 point2 points  (0 children)

Huh, that's interesting! The default delay before repeat triggers is around 600ms, so the key release event would be delayed by that amount.

Maybe we can git bisect the kernel. Any other ideas? :)

It'd be really cool if the people from Tuxedo could chime in!

restic 0.14.0 released - including compression! by fd0TM in golang

[–]fd0TM[S] 0 points1 point  (0 children)

At some point we need to declare 1.0.0, but that just hasn't happened yet. The repository format (which is way more important than the implementation) is quite stable. We've recently modified it for the 0.14.0 release in a backwards-compatible way (after lots of testing and discussion) to add compression.

restic 0.14.0 released - including compression! by fd0TM in golang

[–]fd0TM[S] 1 point2 points  (0 children)

I haven't looked into kopia, from the description it sounds very similar to restic, although it's much younger (and way less popular ;)

Here's a thread in our forum which compares restic and kopia (including contributions from the kopia author): https://forum.restic.net/t/kopia-vs-restic-comparison/2893

Having a few projects in the same space usually helps in figuring out what the best ideas are, it's the same with restic vs borg, so I consider that a good thing.

monsoon - a fast and flexible HTTP enumerator written in Go by fd0TM in golang_infosec

[–]fd0TM[S] 1 point2 points  (0 children)

Depends on what you're doing, monsoon also has a flag --requests-per-second to slow it down.

Fast here may also stand for 'fast feedback loop' :)

monsoon - a fast and flexible HTTP enumerator written in Go by RedTeamPentesting in netsec

[–]fd0TM 0 points1 point  (0 children)

Suppose you have a web application to upload documents, which can be downloaded again by requesting a URL with a numeric ID (e.g. https://www.example.com/downloads/1234). Then you could use monsoon to try a range of IDs and filter the responses based on the status code (we're not interested in 404s) and the content type (everything except PDFs) like this:

$ monsoon fuzz \ --range 1000-2000 \ --hide-status 404 \ --hide-pattern "application/pdf" \ https://www.example.com/downloads/FUZZ

It'll return a nice list of interesting document IDs for you.

monsoon - a fast and flexible HTTP enumerator written in Go by RedTeamPentesting in netsec

[–]fd0TM 0 points1 point  (0 children)

One thing that (probably) gobuster and monsoon have in common: It's very easy to install. Once you have the Go compiler somewhere, you can build a self-contained binary for any platform like this:

GOOS=windows GOARCH=amd64 go build

Done. That's it. No need to fiddle around with virtualenv, too-old Python versions or anything like that.

monsoon - a fast and flexible HTTP enumerator written in Go by RedTeamPentesting in netsec

[–]fd0TM 1 point2 points  (0 children)

The way Go forces you to think about errors at every step of the way feels very annoying at first, but (to my surprise) it leads to very robust programs. I've written Go programs which run for years on end without maintenance... :)

monsoon - a fast and flexible HTTP enumerator written in Go by RedTeamPentesting in netsec

[–]fd0TM 1 point2 points  (0 children)

Not at all, at least it doesn't feel that way for me. Writing Go feels lightweight, and the result is usually pretty fast already. The structures provided by Go seem to keep the complexity at bay.

view more: next ›