I first encountered Pascal (probably Turbo Pascal) on our Amstrad CPC 464, which being bought as used item came with lots of software floppies including some CPM stuff. Lacking a manual I never really used it though. I do remember it had a really barebones textmode-only editor. :)
It won't be very random though. E.g. Apple keyboards will almost always be on device with Apple's hardware & stack, cheap keyboards will tend to be with cheap computers/monitors, expensive keyboards the opposite.
It'll still be interesting data (and I'll dump as many of my systems in as I can), but it will take a lot more than treating differences as noise to answer those kinds of questions in a meaningful way.
That is indeed an annoyance. Last time I looked at the data the "Apple keyboard" and "Apple computer" submissions overlapped so much I couldn't include them separately in the model.
Similarly, I can't separate the effects of programmable and split keyboards because those two almost perfectly overlap in the data.
I hope getting more submissions will help at least a little bit with this.
It might help to pose the problem as regression analysis with with categorical dependent variables. Perhaps with generalized linear model to account for the case that the predicted variable is positive.
Alternatively, if you have enough data, see if an orthogonal array design is feasible. It will not be very kosher because you would be selecting as opposed to assigning.
My current best attempt is a mixed-effects quantile regression (to capture the influence of the fixed effects on the tenth percentile while accounting for dependence between trials from the same person) but it is so compute hungry with this (apparently relatively large) data set that I'm looking into Bayesian methods for accomplishing similar things.
> No BSP, no kernel source, no vendor documentation — just a DTB extracted from the stock Android firmware and rebuilt from there.
Judging from the build.sh, it looks like this is just using unmodified upstream u-boot and tools from the rockchip-linux repository, so "from scratch" is really just analyzing the DTB to see what drivers need to be loaded?
yes, that is mostly on point. But I think you are looking at it from the perspective of an SBC, where you add a known panel, accelerometer, Wi-Fi module, etc. and already know what components you are integrating.
here the hardware is fixed and undocumented. I didnt modify the tablet, I had to figure out what was inside, what could be supported, where to find missing drivers and how to integrate and debug everything until it actually booted and worked.
I am not claiming to be a C or kernel developer. I am just someone hacking around until the device works. Maybe for others this is trivial, but for me it was a very exciting project.
> The TL-SG108 uses a 4Mbit (512KiB) SPI flash chip from Cfeon, which is too small to contain any assets for a web management interface
The https://github.com/logicog/RTLPlayground alternative firmware for RTL8372/RTL8373 based 2.5GBit Switches does fit into 512KiB, including web management interface.
They need to train an LLM with the windows source code and ask it to write an windows clone.
Apparently copyright law only applies for humans, generative AI gets away with stealing because there is too much monetary interest involved in looking the other way.
I've been mounting my 3.5" hard drives on those "fad" rubber band 5.25" drive bay adapters for decades and have not noticed any increased failure rate at all. Sure, seek time may be worse, but the reduced noise has been worth it for me.
The problem isn't just slower seeks; it's when vibration causes the head to go off-track and write data where it shouldn't, faster than the servo can correct. Track pitch in modern hard drives is only a few dozen nanometers.
Not OP, but I installed a "Balcony solar" 1.4kWp panels 2.4kWh battery system on my parents garage. The only subsidy was the tax free purchase of the components (we did file for an additional tax break with the city, but they had already run out of funds for that because it is so popular). You also save a lot of money on installation costs.
Cost breakdown:
- 400 EUR 2.4kWh 48V battery
- 320 EUR 4x 360W solar panels
- 200 EUR 800W microinverter
- ~200 EUR for helping hands when getting the panels onto the flat roof
- 160 EUR flat roof mounting equipment
- 153 EUR solar cable, connectors and crimping tool
- 115 EUR MPPT charge controller and cables
- 95 EUR electrics (e.g. fuses, dc/dc converter for OpenDTU)
- 50 EUR other assorted costs
So about 1693 EUR in total.
Total yield after 1.3 years: 1715 kWh (including power fed back into the grid)
Of that, discharged from battery: 488 kWh (battery already paid back ~146 EUR)
At the current energy costs, 1715 kWh would be ~514 EUR imported from grid
> you are recommended to get the shingles vaccine instead of the chickenpox vaccine since the way the disease presents and how the body reacts to it changes with age (technically shingles can happen at any age but generally herpes zoster presents as shingles instead of chickenpox the older you get).
If the underlying virus is the same, what is different between the vaccines? How it presents shouldn't matter as much?
The shingles vaccine is a larger/more aggressive dose than the chickenpox vaccine.
And nowadays chickenpox vaccine uses live attenuated viruses (i.e. modified to be non-infectious but still look the same) whereas the shingles vaccine uses recombinant proteins. This allows the shingles vaccine to deliver the higher viral load that they want for inoculating against shingles without putting a bunch of live viruses into the body.
It's also worth noting that the recombinant vaccine is more effective for shingles compared to the equivalent viral load live vaccine by a significant margin. It's something like 90% reduction in incidence vs 50%.
----------
> How it presents shouldn't matter as much?
It's not an all or nothing thing but it's a matter of percentages.
And the big reason why they present differently is that chickenpox kind of attacks every part of the body since it's new. It of course does best at infecting the skin and nerves but it mildly affects every part of the body. But then it goes dormant in the nerves because that's where it's most "compatible" and the body is the worst at fighting it.
So then with shingles your body still has the immunity but the reactivated virus is able to out-compete your immunity in the nerves and it wakes up in whatever specific nerve and spreads along that nerve. This is why shingles generally presents in a band on the body. It's spreading along a specific nerve "line" rather than spreading throughout the whole body, blood, and all.
And so the because the infection can't spread broadly throughout your body it ends up concentrated in that location and presumably the higher viral load combined with focusing on the specific proteins rather than the whole virus increases the body's sensitivity to these flair ups, catching them before they can reach momentum. And then that focused immune training sits on top of the body's existing immunity for the initial "whole body" presentation of the virus.
BTW looking at the 8051 patch bytes, they look like 8051 code to me. 0x02 is the ljmp opcode, so this is a jump table: 0x02, 0x40, 0x58, 0x02, 0x40, 0x4e, 0x02, 0x44, 0x00, 0x02, 0x42, 0x2b, 0x02, 0x41, 0x82
I poked at a vsc73xx-based switch in the past and wrote my own test firmware, but had problems with packet loss since I didn't do all the necessary phy initializations I guess, in case this might be of interest:
https://github.com/ranma/openvsc73xx/blob/master/example/pay...
Also on the device I had the EEPROM was tiny and the code is loaded from EEPROM into RAM, you were pretty much stuck with 8051 assembly that had to fit into the 8KiB of onchip RAM :)
Those addresses all make sense, as 0x4000 - 4fff appears to be where the 8051 has its RAM mapped (all of the peek/poke addresses used for accessing serdes fields are on the high end)
