While we're at it, let's change 404 from "file not found" to "nothing here." The stream thrown back at you in response to an HTTP request is often not really a file.
It kinda has been advancing, but the advancement has been happening on the SIMD/SSE/AVX side of things (up to 512 now).
Regarding the non-SIMD side of x86, what are good driving needs to process 128-bit values among the normal instruction stream?
- 128 bits is 16 bytes, and that's a decent maximum length for many textual identifiers. These can be loaded, compared, and processed with single instructions now and possibly be processed without intermediate memory accesses.
- It would be super convenient to load a GUID/UUID or IPv6 in a single register/instruction I guess. Would Intel get an `RDUUIDV4` instruction and be able to generate them natively?
- A bigger space for `mmap()` could have interesting possibilities.
- 64 bits of additional randomization available for memory paging could make security techniques like ASLR a bit better.
Data-level parallel processing (or SIMD vector width) is a different thing to address space width. If you want to see some _really_ wide units, look at GPUs.
For UUIDs, 16-byte short strings and IPv6, there's no real reason the SIMD units couldn't do the work there. (Granted the existing vector units may be a bit short on features for working "across" lanes - I'm not sure how capable they are at dealing with null-terminated C strings for example).
In principle at least (and allowing for some snags around memory alignment), C++ std::strings with the short string optimisation (which stores the string's data on the local stack, if it's less than a certain number of bytes) can already be loaded into vector registers and indeed never materialised as memory at all. How much this happens in pratise I wouldn't like to say, but it's not that hard to roll your own stringid_16 or whatever with conversion operators.
To configure Linux to do software switching, you need bridge interfaces and NICs to be made part of the bridge with the appropriate `ip` commands (or `brctl` if you're still using that).
This is common with small home routers - the WLAN and wired LAN ports (all typically appearing as one NIC) will be made part of a bridge `br0`. The four LAN ports aren't typically exposed as separate NICs so there is hardware switching going on there (some devices do let you split them out because they are VLANed internally though).
If `ip link show type bridges` doesn't show any bridges then you aren't software switching unless your drivers are lying to you.
> They’re not physically, emotionally, a psychologically damaging you.
I contest this claim. Ads create envy, which create overconsumption, which leads to environmental degradation. Furthermore ads which try not to look like ads tend to take advantage of people who are not smart. Also, things that are given away for free, but ad-supported, have been shown to create market distortions where "you are the product", and also facilitate loss of privacy through ad-driven surveillance and shady data-broker deals.
Expansion chips aren't ROMs; they need to be emulated as well.
The situation was IMHO a bit worse with the SNESs precedessor, the NES.
There were quite a few expansion chips--called mappers--even though their general function was expanding the NES's memory space instead of adding additional processors or capabiliies - and they were in most games because without them the NES is limited to 32KB of PRG ROM and I think 4KB or 8KB of CHR (graphic) ROM. Most games after the year the NES came out had them.
These all had to be reverse engineered along with the console itself - fortunately much simpler than reverse engineering an add-on CPU or accelerator though. Some are common and in many games (MMC1, MMC3) and others are pretty much for a specific game only (MMC2 is for Punch-Out only).
> I prefer to use VirtualBox because I am unable to make QEMU/KVM work, since I am not a rocket scientist.
What this translates to is "I did not want to read the large and comprehensive QEMU/KVM documentation, go through each option one by one, take notes, and specify the ones I wanted."
Which is ... totally fine. `qemu` has a lot of options. But that's why they make frontends. You want a scary, difficult command to work with? Try `tc`. I would NEVER touch raw `tc` commands when configuring QoS - FireQoS all the way.
When I experimented with `qemu` to make a Debian-based headless hypervisor, I did have to put some time in it. I had to make some scripts to convert some easier-to-make "config" files into `qemu` commands (in addition to making the `tap` network interfaces for virtual networking). Got it working and it did its thing. It was cool that it could be done - launch VMs from a script with no need for a GUI.
No, we're not doing NAT, but the devices aren't really accessible from the wide web either. In this case "NAT" is just an implementation detail and getting rid of it didn't bring any of the benefits IPv6 promised.
that or it was an inevitable and powerful scaling technology that enables a double-digit billion number of devices to communicate using only 3B addresses
Yes, here we are, spending many, many thousands of dollars unnecessary:
> I work for a Native American tribe in the PNW. We scrambled to get the reservation reliable internet in the later part of 2019. We managed to cover most of the reservation with wi-max and wifi with a fiber back haul configuration. We are now slowly getting more stable and reliable fiber to the home(FttH) service installed to as many homes as we can, but it is slow process covering the mostly rural landscape doing all the work in house.
> Our tribal network started out IPv6, but soon learned we had to somehow support IPv4 only traffic. It took almost 11 months in order to get a small amount of IPv4 addresses allocated for this use. In fact there were only enough addresses to cover maybe 1% of population. So we were forced to create a very expensive proxy/translation server in order to support this traffic.
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
> The world probably has never been as peaceful as in the last 50 years or so.
True, but we are not talking about the last 50 years, we are talking about the future, for example, the next 5 years. People don't commit suicide if they think their future will be OK.
> Same goes for access to drinkable water, food, decent shelter, gender equality, freedoms, technology, etc.
- Item 2 and 3 ignore recent rises in food prices and housing prices.
- For the U.S., item 4 and 5 have been reduced in many places by various recent laws and judicial decisions (unless you are super rich), and this will probably continue for the near future.
- The last item - 6 - technology. I think for a non-tech-person standpoint, it really appears like technology primarily has ...
A) ... stagnated. Phones--the tech most people use daily--haven't done anything new and exciting for some time. The Internet hasn't given the non-tech public-at-large the next big thing after social media, either.
B) ... primarily become interested in putting monthy fees, ads and tracking on everything one does, and
reply