I am a full stack software engineer that is always interested in learning new technologies and is good in navigating through complexity (for a public example of this, I am a commiter in Nix/NixOS repository and did numerous PRs in multiple open-source projects).
But N64 was a more expensive design, and also came almost 2 years later, and from an architectural standpoint it also had significant issues (e.g.: the texture cache size that someone said above).
This is why I said considering the constraints, I find the first PlayStation to be impressive.
> you'll see that the design of a 3D-capable console in the 90s was a significant challenge for every company.
While this is true, I still think that the PlayStation had the most interesting and forwarding looking design of its generation, especially considering the constraints. The design is significantly cheaper than both Saturn and Nintendo 64, it was fully 3D (compared to Saturn for example), using CD as media was spot-on and also having the MJPEG decoder (that allowed PlayStation to have not only significantly higher video quality than its rivals, but also allowed video to be used for backgrounds for much better quality graphics, see for example Resident Evil or Final Fantasy series).
I really wanted to see a design inspired in the first PlayStation with more memory (since the low memory compared to its rivals was an issue it seemed, especially in e.g.: 2D fighting games where the amount of animations had to be cut a lot compared to Saturn) and maybe some more hardware accelators to help fix some of the issues that plagued the platform.
> There's technically no reason OpenSSHd can't also be used in this context.
For initrd you generally prefer static binaries. Not saying that OpenSSHd doesn't build statically, but having less code and dependencies makes it easier to statically compile.
But yes, technically there is no reason to not use OpenSSHd, but in practice having a smaller and more self contained binary helps considering that you would want the bare minimum during initrd.
I am fine with this behavior as long as I can disable it. Yes, I also use NixOS and don't like when things download random binaries, but I can understand there is demand for things that just work TM.
> As such, an FGPA emulator isn't necessarily any closer to the original hardware behaviour than a software emulator. I guess the main advantage of FGPA is better performance on lower cost hardware.
The price of the majority of FPGA chips are really expensive compared even against cheap (yet still way more powerful) SoCs (like really cheap ARM CPUs that are used in sub $100 handheld emulators). Also, technically a FPGA based emulator could be more efficient compared emulating everything in software, but AFAIK even Analog Pocket is not really that better in battery life compared to say a Miyoo Mini + (maybe because a ARM SoC have better energy management, but I don't know).
I think really the main hype of FPGA is lower input latency, that is really difficult to archive with software emulation. There are still some tricks you can do in software that reduces the input latency significantly, but they generally are expensive to compute [1], so it wouldn't be feasible to be done in a cheap handheld device (at least yet).
Since my Chromebook is not really powerful, yes, Firefox feels like a second class citizen. But I imagine in a better Chromebook it should work better.
This is a welcome addition for Chromebooks, because now you can install latest Firefox (not ESR) in Crostini without using Flatpak.
Sadly Mozilla still doesn't offer `aarch64-linux` builds for Firefox in their official channels, so for those that have a ARM64 Chromebook will still need to use something else to get Firefox running (I use Nix, but it needs some complicated setup to work with hardware acceleration, for example, using nixGL).
The title is bad, this only affects Firefox mobile that AFAIK has a really low amount of users (BTW, I am one of them).
Not saying that they shouldn't have detected this (i.e.: where is the automated testing for those things?), but I don't think this is Google screwing up Firefox on purpose.
And if Google really wanted to screw up Firefox, they would probably do a better job than User-Agent sniffing. Firefox already has an internal list where it applies fixes for websites (e.g.: setting a custom User-Agent), and the bug report actually comes from it. You can see it by going to `about:compat` page in Firefox.
> Most Linux installers already had a good GUI installer on the Live CD at that point.
Yes, I think between the end of Windows XP and start of Windows Vista era is interesting because it is by that era when Linux installers got really good (they're full graphical and would be really easy, most times just pressing Next->Next->Finish) while Windows still had its ugly TUI installer.
Also, Windows at that time didn't ship with as many drivers as today, and also we didn't have as fast internet and Windows Update still did a poor job for installing drivers from random devices, so most of time after installing Windows you had a pretty poor installation with broken internet/audio/graphics and also possibly weirdly slow (because missing chipset drivers would make the system slow depending on the hardware). While Linux if you had reasonably supported hardware it would just work.
Not that this really matters. Installation of a new OS is something that was and still is mostly done by knowledge people, and generally those people can install either Windows or Linux regardless.
Maybe an issue with patents? All the formats there are open source with the exception of MP3, that from what I remember had its patents expired a few years ago.
Interesting that in Mac with Apple chips (M1 Pro) it seems both Chrome and Firefox report them as Intel:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Edit: even Safari itself:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.1.2 Safari/605.1.15
I concur, the amount of times I had to Google dozens of minutes for issues happening in my work-issued Macbook Pro, and never finding answers because things are supposed to "just work" is maddening.
For one example on top of my head, sometimes I can't adjust the brightness of the monitor in the Macbook using the Notification Center (it is grayed out), but if I open the "Settings -> Displays" I can do it. Never found a solution for it after searching for a while, so I just gave up.
Or the fact that I can't enable retina or font smoothing in my 1440p monitor, so the fonts looks ugly (I got used eventually, but they still looks worse than Windows or Linux in the same monitor). I used a workaround in the past using "Better Display" to create a 4k framebuffer that was downscaled to 1440p, but this was so slow and also prone of other issues so eventually I just got used to the ugly fonts.
Another one: I have a TouchBar Macbook (again, this is a work-issued laptop), but I just want it to work as a normal keyboard: show the Function keys, if I press Fn show the shortcuts. Yep, doesn't work: while you can do this, pressing Fn while pressing some of the shortcuts in the TouchBar doesn't work. This is especially infuriating because one of the shortcuts that doesn't work is the brightness one. Go back to the first issue and you can see why this drive me mad sometimes.
Sure, doesn't make this any less inconvenient though. I would much prefer to finish whatever I want to finish today (even if I spend a few hours trying to fix an issue) than wait whatever amount of days waiting until my hardware is fixed.
Exactly, and this is one of the main reasons why Apple is unmatched in performance in the smartphone space: they can afford much larger transistor budget than other companies since they're vertically integrated.
Remote: Remote/Hybrid preferred
Willing to relocate: No
Technologies: Java, Kotlin, Clojure, Python, Nix, AWS, Kubernetes. Willing to learn new programming languages as needed
Resumé/CV: https://drive.google.com/file/d/1_21FxImnXxGBz1-FCCOu5AvENFT...
Email: thiagokokada AT gmail DOT com
GitHub: https://github.com/thiagokokada/
---
I am a full stack software engineer that is always interested in learning new technologies and is good in navigating through complexity (for a public example of this, I am a commiter in Nix/NixOS repository and did numerous PRs in multiple open-source projects).