PaX

joined 2 years ago
[–] PaX@hexbear.net 12 points 1 month ago* (last edited 1 month ago)

1915 Lemmy lib: "God the German propaganda on .ml is intense"

The propaganda: Peace pls yes-honey-left

Any info I encounter contrary to the interests of my preferred empire must be the work of the dastardly Foreigner. If the other side wanted peace they should simply unconditionally surrender imaginator (skull can barely contain brain of this size)

And if they won't, ~~we~~ Ukrainians must be willing to give up their lives in a total war until victory (which is going well and good and can be expected to end in that outcome)

Russia's terms have been quite clear since the beginning of the war: a neutral, non-West-aligned Ukraine and the official ceding of Crimea and the breakaway republics. Even regardless of how you feel about those issues, how does it benefit you or the average Ukrainian to keep fighting over this? It is such a pointless, devastating loss of life over shit that obviously represents larger geopolitical issues for the West and Russia while Ukraine is turned into a literal wasteland (omg and the Ukrainian side has been financed by massive Western loans doomer, even if Ukraine "wins" they are gonna be fucked when the creditors come for their repayments after the war which is intentional ofc, will probably result in even more IMF austerity plans and poverty)

Idk, maybe the Ukrainian side could get better terms (they def could have earlier) but they have just refused to actually negotiate (beyond telling the world how "open" they to are it lol) and have taken your total victory position. Ofc there is so much more to say but yeh

[–] PaX@hexbear.net 7 points 6 months ago (1 children)

chomsky-yes-honey A better timeline?

Windows UI design peaked with Windows 98 and Unix UI design peaked with IRIX imo

[–] PaX@hexbear.net 5 points 6 months ago

I am so tired haha

[–] PaX@hexbear.net 8 points 6 months ago (2 children)

Okay but it was less doomjak, relatively bloomer to now

[–] PaX@hexbear.net 32 points 9 months ago (2 children)
[–] PaX@hexbear.net 1 points 10 months ago* (last edited 10 months ago)

You can check to see what drivers were compiled as modules or into your kernel by reading the kernel configuration at /proc/config.gz or /boot/*config*

There might also be out-of-tree (not included with the kernel) drivers installed as packages on your system but this is very rare outside of like... having an NVIDIA card and running the closed-source vendor driver

[–] PaX@hexbear.net 7 points 10 months ago* (last edited 10 months ago)

The vast majority of drivers are included with the Linux kernel now (in tree) so the difference usually comes down to kernel version (newer kernels have more drivers, of course) or kernel configuration set at compile-time (this can be anything from including or not including drivers, to turning driver features on and off, or more fundamental changes beyond drivers)

You can get kernel version info from uname -a and a lot of the time, probably most of the time (this is also down to configuration), you can get kernel configuration info from /proc/config.gz (use gzip -d to decompress) or something like /boot/config

Then you can run diff on configurations of 2 different distro kernels you're interested in to see how the 2 distribution's kernels were set up differently

This could also be caused by different setups of userspace tools or UI that interact with these drivers in different, sometimes worse ways but this is usually much less likely in my experience (most Linux distros do things like this the same way these days tbh)

Oh, also, there are a lot of drivers that require vendor-supplied firmware or binary blobs to function and most of the time distros don't bake these into the kernel (although it is possible) and different distros might have more or less of these blobs available or installed by default or they might be packaged differently. The kernel should print an error message if it can't find blobs it needs though

I guess there's kinda a lot to consider lol. Sorry if all of this is obvious

What hardware are you talking about specifically?

[–] PaX@hexbear.net 3 points 10 months ago* (last edited 10 months ago)

Ohh that's true, I didn't think about that. It would be difficult to route anything through it unless you were connected directly to it with nothing in-between because no other router would forward packets destined for somewhere else to my machine (except maybe in the extremely unlikely case of source routing?). It seems obvious now lol, thank you!

I'll write some firewall rules just in case

 

can someone else use my machine as a router to forward traffic to anywhere else on the internet?

I'm not entirely sure what the security implications of that would even be if true but probably nothing good

I don't have any other routes in my routing table other than my "default" route and this machine is reachable via a globally routable IPv4 address. Also I think there are probably other machines on the same subnet (cloud VPS)

[–] PaX@hexbear.net 2 points 10 months ago* (last edited 10 months ago) (1 children)

I see. Our motherboards have different chipsets (I have an X570 in mine). It probably has nothing to do with my issue...

Hoping those kernel parameters fix it. I wish I could help further. PCs are just a bottomless, mostly undocumented rabbithole :(

 

cross-posted from: https://hexbear.net/post/1747735

CPU-posting on main

MTI = MIPS Technologies (company that made MIPS (Microprocessor without Interlocked Pipeline Stages) processors, they make RISC-V processors now lmao)

At the time when the MIPS R10000, known as the "T5" while in development, was being designed, MTI had made a name for themselves as designers of high-performance computer microprocessors along the lines of the then-new philosophy of reduced instruction set computing (RISC). Actually, their R2000 design was the first commercially-available RISC microprocessor. By the time the T5 was being designed, they were no longer alone in the RISC microprocessor market. Several companies, including IBM and Motorola (joined together in the AIM alliance which produced PowerPC), DEC (who designed the Alpha line of RISC microprocessors after MTI owned them in the 80s when their radically simpler chips were performing better than VAXen), and Sun Microsystems (who were making the SPARC line of microprocessors) were now marketing RISC microprocessors. Not just even marketing but beating MTI in the market they had created. After trying and failing to develop their own complete computer systems alongside their chips, they were having financial difficulties until Silicon Graphics acquired MTI to secure availability of MIPS microprocessors for their famous ("it's a Unix system, I know this!") MIPS-based workstations and servers. Although their new (in 1993) R4000 and R4400 designs performed well compared to their contemporaries, they were quickly being made obsolete by MTI's competitor's new offerings and they were left with a problem:

The MIPS R4000 and the R4400, which is essentially an R4000 with bigger on-die caches, were more or less just an architectural evolution from the R2000. The R4000 made its performance in much the same way as the R2000 did, the classic RISC design process mantra: "let's make it simpler" and thus be able to run it faster. In particular, what this means for the R4000, and what is a key difference from its predecessors and its contemporaries, is a technique called superpipelining. In an instruction pipeline, the maximum speed at which your processor can issue instructions is set by the pipeline stage which takes the longest to complete. Superpipelining is one way of addressing this problem: you can subdivide each pipeline stage into 2 simpler pipeline stages that individually complete faster and thus be able to clock your chip faster without problems. However, this has its limits. Eventually, it becomes impossible to further "deepen" the pipeline like this or clock the processor faster in general without other problems. This is why MTI's competitors opted for the analogous superscalar approach: you can duplicate functional units of your processor and have multiple instructions "in flight" at the same time and usually this also involves multiple pipelines. At the time MTI thought this approach would result in more consistently higher performance (not to mention save die space) but were quickly proven wrong when their competitor's superscalar (and often with other architectural tricks) chips were outperforming the R4000 in spite of MTI's fabrication partners constantly improving their process and releasing chips that ran at higher and higher speeds.

Enter the MIPS R8000 (die not pictured here) in 1994, a weird and expensive 6-chip 4-way superscalar design meant for the high-end microprocessor market while the next-generation T5 (which would become the MIPS R10000, as mentioned earlier) was under development. It didn't sell well because of its high price and the fact that its integer performance, important for general-purpose computing applications, was lacking compared to the 200-MHz R4400 that was being sold by then. It did, however, have impressive floating-point performance, which landed many R8000-based systems in the TOP500 supercomputer list for a time. But this design could never be the high-performance and general-purpose processor MTI needed to compete with their competitor's offerings...

Introduced in 1996, the MIPS R10000 (die IS pictured here) was a significant departure from the architecture of the R4000 (which more or less was directly derived from the first research done at Stanford University where MIPS was initially created over a decade earlier). Dropping the superpipeline approach, the R10000 is a 4-way superscalar processor even capable of executing instructions out of order! Another big change is that it has a branch predictor and speculatively executes instructions after a branch as opposed to the R4000, which used the classic MIPS "branch delay slot" technique to schedule one more instruction in the pipeline after a branch and then stall lol (they should have added even more delay slots, caring about binary compatibility is liberalism). It's hard to find benchmarks for something this old but this design performed at least several times faster than an R4400 at about the same clock speed!

If you like my CPU posting and want me to post more in the future let me know

Also ask me any questions if you want too and I'll try to answer

view more: next ›