I don't really get why people keep repeating the "C++ is too big" complaint together with the implication that you need to remember the entirety of the standard library. In comparison Java has networking, GUI framework and even MIDI in its standard libraries. Is it because C++ is more closely related to C which library is so small that it barely contains anything useful? I much prefer code that uses a library feature rather than yet another poorly implemented and not documented hand rolled version of it.
Networking, GUI frameworks, and MIDI are presumably all self-contained and you would not need to be familiar with them except when working on networking, GUIs, or MIDI files, respectively. This is a general-purpose thing that could show up in any c++ code.
>do something insane like a giant bundle of everything, or static linking
But isn't this exactly what shipping on Windows looks like? I've just checked my Windows partition and there are 43 instances of sqlite dll and 16 instances of Qt5Core.dll because every program that uses those libs needs to include them in their "giant bundle of everything".
The issue on Linux is that the distro's package manager decides which versions of shared libraries exist system wide, and this works well when you install everything through the package manager. Windows SxS is specifically designed to allow multiple incompatible versions of the same shared component to coexist without forcing the entire Windows install to use it.
But okay, I accept your point. However I'd like to point out that "the OS allows you do something in multiple ways" is different from "this is the only way to do it"
> The issue on Linux is that the distro's package manager decides which versions of shared libraries exist system wide, and this works well when you install everything through the package manager.
Linux takes the lead: make code that depends directly on `kernel32.dll` exposed interfaces and you're in a world of hurt.
The problem pointed out is a distro, library compatiblity, packaging, or sand-boxing problem, not a Linux problem.
> Windows SxS
Now that's one very good Windows idea.
Nothing should prevent your favourite packaging/sandbox tool to present a facade that the file system has some specific files (your specific version of libraries) over some more generic files (say, Flatpak: freedesktop SDK, Steam Pressure Vessel: Steam Runtime) over some even more generic files (your actual distro libraries).
On the other hand, almost _nobody_ and _nothing_ should be touching "libraries" or "utilities" or whatever on my base system!
>The problem pointed out is a distro, library compatiblity, packaging, or sand-boxing problem, not a Linux problem.
Are you suggesting Windows users switch to Linux and not use a popular distro that can provide software they need? Otherwise, its simply a pedantic argument.
>Nothing should prevent your favourite packaging/sandbox tool to present a facade that the file system has some specific files (your specific version of libraries) over some more generic files (say, Flatpak: freedesktop SDK, Steam Pressure Vessel: Steam Runtime) over some even more generic files (your actual distro libraries).
If you introduce a new library in facade 2.0, its not going to work in facade 1.0. You can backport, but how many versions are you realistically going to support indefinitely? Its a good idea, but it doesn't solve the full problem.
> Are you suggesting Windows users switch to Linux and not use a popular distro that can provide software they need? Otherwise, its simply a pedantic argument.
If you use a distro that can provide the software they need, why not?
Or, thinking in a orthogonal way, using a distro that doesn't impose draconian library management requirements, and allows simultaneous use of ABI incompatible versions of a library? Why not? Nixos is out there and has more packages that most other distributions already.
> but how many versions are you realistically going to support indefinitely.
No versions. No indefinite support. And intentionally so. The previous layers just stay there.
The point is to intentionally provide a stable platform - with known bugs and security vulnerabilities frozen forever - something people can build their things upon. And rely on the things the things they have built upon to not be rugpulled from under them at random.
Every now and then, someone might fix a egregious security vulnerability in the platform; someone might fix a egregious usability problem in the platform; someone might implement modern features on a older platform; someone might implement compatibility tweaks - but that should not be considered a given.
I fully expect at minimum to run legacy software on a sandboxed "compatibility mode", if one values the overall safety of the rest of the system. And if you are not legacy software, someone recompiles the software every now and then to the newer platform.
No, they don't support it. Instead, you need to run it inside a compatibility mode, that probably sandbox or VMs the facade. But your software keeps running.
The current problem is that your software no longer runs. That's a 100% denial of service problem.
> I want to run a modern OS with modern features and still run any software that I already paid for 5, 10, 20 years ago.
I already have a bunch of software that I paid for more that 20 years ago and I can't use most of it outside of full VMs. Microsoft didn't ask me if I didn't use them anymore before removing Win16 support.
> Out of curiosity, have you asked customers to run your software in a VM? How did that conversation go?
Customers never got a choice "where to run your software" when all software I develop ends up hidden inside a SaaS service or being delivered via representational state transfer code on demand. They either run it on a browser sandbox or it doesn't run.
>I've just checked my Windows partition and there are 43 instances of sqlite dll and 16 instances of Qt5Core.dll because every program that uses those libs needs to include them in their "giant bundle of everything".
Oouch, I just got temporary headache just trying to read and comprehend the Windows mess that you mentioned here.
It kind of is their fault because of Google Play Integrity APIs. They are effectively developing tools that are designed to make their product mandatory. There wouldn't be a backlash that big if we could just unlock our bootloaders and run a patched version of Android.
What do you mean? The webchat client is linked right there in the second paragraph, doesn't require you to install anything and let's you connect and list channels as a guest without registering. It took me like 30 seconds to find out that there is indeed an astronomy channel.
Uhh, I'm not seeing any system requirements, am I blind? It just warns against using the /list command if you have a very slow internet connection since it produces rather voluminous output. If you scroll down a bit further they also link to a third-party website that has a searchable index of all publicly visible channels.
Sure, replacing the car with a plane for your grocery shopping would be probably more dangerous, but do you have any data at what distances do the risks flip?
When I see those statistics I think about flights like Austria to Finland and I imagine that is indeed safer by plane.
I went from a passively cooled RPi5 to a N100. The RPi idled at around 50°C and throttled under load. The N100 keeps 56°C under light load (the heaviest things are rtl_433, grafana, nextcloud). To keep it from throttling in heavy load I zip tied a small Noctua NF-A4x20 to the side of the case over the passive heatsink and adjusted the fan curve to only run at above 60°C. This works super well, the N100 doesn't get hotter than about 62°C under full load and the fan spins slow enough that I can't hear it at all even if I put my ear directly next to it.
> To keep it from throttling in heavy load I zip tied a small Noctua NF-A4x20 to the side of the case over the passive heatsink and adjusted the fan curve to only run at above 60°C.
I applaud your creativity but surely this is an indication of the limitations of the architecture!
Nice solution, but with the case I linked, my Pi idles around 37, and reaches 50-ish (both degrees C) at most (if I load it hard), since the case is sucking heat from all chips and bottom of the PCB.
How does it handle electrostatic discharge when touching it in that case? I used a case that was really more of an oversized heatsink[1] than a case and it was really sensitive. Managed to crash the rpi a couple of times when I touched it without touching ground first a couple of times.
edit: I replaced the thermal sticker for thermal paste, not sure if that could have affected it, the paste wasn't the conductive kind.
Thats somewhat surprising. I have an old 14nm Celeron I use as a home server and under typical usage it is a few degrees above ambient. Checking now it is 26C. There is no fan, and it just has whatever tiny stock heatsink it came with.
I tried some hl2 maps and the need for speed most wanted map. I'm really impressed by how close the rendering is to the original games. Not only did they get the lighting and shading right, there are also details like the NPCs being present, or even animated falling leaves particles in the most wanted map.
I'm at a loss how they managed to convert/managed so many different formats — the textures, level data, sprites, etc. Rare games on the N64 made extensive use of "vertex shading" like techniques, and these have all been carried over to a higher degree than I would've expected...
Off topic, but you're the guy who made the HN User Tag script! I recognise you since I have you tagged as "tag-legend". Still waiting for you to post your creation as a Show HN! ;)
Many of the contributions are others reversing and implementing a new game on top of the existing API, so the really labor-intensive per-game work is still spread out reasonably well.
A lot of games use similar or derived map formats (for instance, most Valve games). There’s a fair bit of game-specific tinkering to do, but you sometimes don’t have to reverse-engineer a new binary format from scratch…
They are definitely ripped from the game. More significantly, there's a lot of work on the rendering engine side of things to make all these different types of games with their different rendering techniques work on the browser.
On the projects page (https://suricrasia.online/projects/) it says "Make glitchy beats with randomly generated Opus protocol packets." So I guess it's random data fed into the opus decoder.
author here: this is correct. the opus protocol is so efficient, you can fill a packet with random data and it will still decompress into a sensible sound. this is where all the sounds come from
