fl42v

joined 1 year ago
[–] fl42v@lemmy.ml 5 points 17 hours ago (1 children)

TeXurger, LaTeXurger, XeLaTexurger...

[–] fl42v@lemmy.ml 3 points 1 day ago* (last edited 1 day ago)

I'm wondering if syncthing in gplay can show some kind of warning that the app is discontinued pointing to use the fork version on f-droid, or, if that's prohibited by play's EUFOA (end-user fuckover agreement), discussion on the forums mentioning the existence of said fork... [addit: So, kinda like what termux folks did, but less covertly]

[–] fl42v@lemmy.ml 2 points 1 day ago

Ooo, pretty, thanks!

[–] fl42v@lemmy.ml 9 points 1 day ago* (last edited 1 day ago)

I'm not sure you can classify this as a failure, as explicitly prohibiting interfacing with non-agpl stuff would greatly limit the amount of stuff you can license under it, perhaps up to the point of making it generally unusable. As for "not like that"... Well, yeah. But you can't deny it's misleading, right? Free software kinda implies you can modify it whatever you want, and if it's a free ui relying on a source-available middleware... Turns out, not so much.

Although, a posdible solution would be require explicitly mentioning if you're basically a front-end for something; but I'm not sure if it can be legally distinguished from the rest of use-cases.

[–] fl42v@lemmy.ml 12 points 1 day ago* (last edited 1 day ago) (2 children)

Is there a similar list of ~~good stuff~~ [sry, ofc I mean notorious criminals stealing what little money a licensor needs to buy a new yacht] but for music?

[–] fl42v@lemmy.ml 31 points 1 day ago (2 children)

I doubt it. What'll probably happen is them moving more and more of the logic into the SDK (or adding the back-end of new features there), and leaving the original app to be more or less an agpl-licensed ui, while the actual logic becomes source-available. Soo, somewhat red-hat-esque vibes: no-no, we don't violate no stupid licenses, we just completely go against their spirit.

[–] fl42v@lemmy.ml 4 points 1 day ago

I mean, I see a usecase for that, given you make a separate community for that, and not, say, spam c/technology with everything posted on XDA. So, kinda like RSS with comments. I personally follow hackaday both here and via RSS.

Alternatively, one can mirror someone who publishes rarely and only cool stuff. I remember mr.d0x being such a guy (now I don't really follow security-related things much, so mb it's changed, but I doubt it)

[–] fl42v@lemmy.ml 46 points 1 day ago (5 children)

Thanks for sharing your concerns here. We have been progressing use of our SDK in more use cases for our clients. However, our goal is to make sure that the SDK is used in a way that maintains GPL compatibility.

  • the SDK and the client are two separate programs
  • code for each program is in separate repositories
  • the fact that the two programs communicate using standard protocols does not mean they are one program for purposes of GPLv3

Being able to build the app as you are trying to do here is an issue we plan to resolve and is merely a bug.

I.e. "fuck you and your foss"

[–] fl42v@lemmy.ml 7 points 1 day ago (4 children)

Well, there's also "punk goes pop" stuff, like the good old https://youtube.com/watch?v=gbMbCbEp5cA

[–] fl42v@lemmy.ml 13 points 1 day ago

Nope, it didn't when I last checked (mb ½year ago). Also, it has analytics and stuff.

I personally ended up cloning mercury and adding a few of those patches myself, which is quite easy since you don't need to add toggles (you always use what you use, and can skip adding what you don't use)

[–] fl42v@lemmy.ml 5 points 2 days ago

Wait, you can compile coreboot without google's vboot support. If it's the only problem, why drop motherboards?

[–] fl42v@lemmy.ml 2 points 2 days ago* (last edited 1 day ago)

So, the "[edit: ~~last~~] previous update" was built from ac41318, since then there were exactly 2 commits:

Both do not immediately look malicious. So, either the release is poisoned (in which case you can build it from source and see if still detected), or the repo was poisoned before, and the payload didn't activate until those changes, or AVs decided to crackdown on random shit running their code in other law-abiding processes' address space 🤣

 

So, yet another "if you're in the middle of nowhere and can't/don't_want_to wait for proper tools to arrive" kind of post.

Firstly, there's pico-serprog with quite good instructions from the libreboot project. Unfortunately, it didn't want to detect the chip at all in my case (in hind sight, likely due to the board pinouts being different between my board and a regular pico and them providing pico pins and not gpio numbers)

What worked, albeit rather slowly, was pico-dirtyjtag. If using this one, the connections are as follows:

  • cs - gp19
  • miso - gp17
  • mosi - gp16
  • clk - gp18
  • gnd - gnd
  • 3v3 - 3v3

The chip pinouts can be sourced from the libreboot guide/a laptop schematic/ic datasheet. Flashing with sudo flashprog -p dirtyjtag_spi -w rom.rom (or flashrom instead of flashprog). It may complain that there are multiple definitions matching the chip, in which case you manually choose one of the mentioned with -c (in my case -c W25Q32FV and -c W25Q64BV/W25Q64CV/W25Q64FV for top and bottom chips respectively).

Also applicable to stm boards with the main dirtyjtag repo.

 

So, I've dug up my corebooted t440p and decided to check if it'll work with the battery from my t480, and it did! Well, sort of.

Since coreboot also replaces the embedded controller firmware (mb sometimes they keep blobs of it, idk, but certainly not in case of t440p), we won't get those nasty "battery not supported, pay me" messages even if they've changed the verification since then.

However, I suspect some batteries may be unprepared for the power draw of earlier models. I've tested it on 2 batteries, one was a 22wh → 72wh conversion with BMS built on top of a cheap controller with rather unpleasant feedback from battery repair people; the other one was a more trustworthy 72wh clone powered by bq8050. The latter one worked ootb, while the former somewhat worked: fine in uefi, fine in grub, drop voltage to 0 as soon as the os starts loading → poweroff. If the power supply is plugged in during boot, the battery works fine (may drop voltage again under load, haven't tested it myself).

Soo, basically the use case is that you can try to retrofit the guts of a newer battery into older thinkpads if those run core/libreboot.

 

I've replaced cells in my fake battery a few days ago, and while recalibrating the bms I noticed what looked like it trying to overcharge the cells -- the voltage went up to above 12.6v and stabilized at around 12.9 (which amounts to ~4.3v per cell and is 0.1v above what cell manufacturers generally recommend). Idk if that's the intended behavior or clone manufacturers trying to shorten the lifetime of said batteries, so if the owners with genuine batteries can provide that info, I'd really appreciate it.

On linux, you can check this with cat /sys/class/power_supply/BAT*/voltage_now (as your usual user, those files are world-readable); not sure about windows, tho.

 

Out of curiosity, I've been watching a few restorations of those spectrums, and I've noticed the keyboards having a rather peculiar construction, judging by today's standards. They have 2 springs, the small one, as far as I understand, presses the membrane layers together, and the larger one returns the key into neutral position once the key is released.

I personally haven't used any spectrums, yet I've encountered the very same construction on a keyboard of a Russian clone of said machines (namely, zx atas), and to this day I haven't touched anything worse... The only way I can describe it is like trying to type on a piece of raw meat.

So, if anyone here had a chance to type on the original spectrums, was it this bad? I suspect otherwise since I haven't heard of crowds of people requesting PTSD treatment, but the whole thing still somewhat bothers me 😅

 

Just thought I'd share. Probably nothing new or fancy, but may help some of you find a way to repurpose devices that aren't worth repairing into home servers or something: e.g. op5 I've used has better CPU compared to raspberry pi 4, can run linux (postmarketos, albeit with some caveats), and costs less if bought with broken display (or nothing if you have one lying around)

 

Decided to share an older "project" of mine - ms sculpt wireless to wired conversion (also, it runs qmk, so we get all its features). A sensible person would order a custom pcb (such projects exist on the web, take a look if you're interested), but I went with removing all the components except from the ribbon cable connector, sending the PCB smooth, gluing a piece of discount card to isolate the traces, gluing a Chinese rp2040 on top, and wiring all the necessary traces to it. No, it wasn't fun. Yes, it works.

Bonus: when I disassembled it now I found out the type-c wasn't soldered well and decided to separate from the board:

ResizedImage_2024-04-08_18-20-32_2

So, here we go: using phone as a poor man's microscope (note: also, still works)

ResizedImage_2024-04-08_18-20-32_1

The end result kinda doesn't give it out, so whatever (insert your frontend -- backend jokes here)

ResizedImage_2024-04-08_18-36-32_1

75
submitted 6 months ago* (last edited 6 months ago) by fl42v@lemmy.ml to c/lemmyshitpost@lemmy.world
 
 
 
 
view more: next ›