An interface can have many ipv4 addresses as well. It's just not that common, so many people believe they'd need vlans to achieve that.
HN user
bewo001
well.. openflow is pretty much dead, too inflexible, too slow. The whole control/user plane split is an attempt of the classical router vendors to keep their proprietary boxes. It adds complexity as it requires to synchronize the state of some controller with some data plane box.
P4 was a great idea, but there's not much hardware that supports it.
fd.io / vpp is an impressive stack for software-only routing. Like all SW-only solutions, it suffers from high power consumption and packet rate variability. At today's packet rates, you always have to ask 'how many CPU instructions / cycles are required to perform this or that function per packet'.
Hm, some things compilers do during optimization would have been labelled AI during the last AI bubble.
It's much simpler. In the EU, truckers have to do mandatory 45 min breaks after 4 1/2 hours of driving. With the latest truck generation, this is enough time to recharge to get through the rest of the shift. 400 kW charging is sufficient in this scenario. No wasteful expensive H2 or fancy battery swapping technology required.
IQ tests are a bit absurd if one looks at the changing definitions of intelligence over the past century.
Someone in the 1920s/30s would call the ability to solve equations or play chess well as signs of high intelligence. Not so long ago, translation of natural languages was considered a task requiring a good level of intelligence.
Each progress in AI changes the definition of intelligence as we realize that a machine finally able to do task X is not really as intelligent as we thought it had to be.
And today the AI/robotics industry struggles to build a machine that can perform the job of a room cleaner. Beating grand masters at chess was far easier.
I did once fly as a guest with a winch start, and yes it is something. The ascend is pretty steep and the acceleration is powerful. The pilot did not find good lift and we had to land shortly after. My stomach did not like his curving around looking for lift, so I wasn't too unhappy about the short flight.
My late father was a maintenance technician for those things. He hated it when programmers did smart instruction placement to optimize drum timing. When the drum speed was a little off, they called him to calibrate it so their programs would run fast again.
forth would come to mind, some people have build surprising stuff with it though I find it too low-level.
yes, IBM's CUA wasn't that bad. 'F1' for help is one remnant of this.
Actually, every browser supporting webrtc datachannel supports SCTP over UDP.
I don't understand the difference to TCP here. If the path is not congested but the receiving endpoint is, the receiver can control the bandwidth by reducing the window size. Ultimately, it is always the sender that has to react to congestion by reducing the amount of traffic sent.
RPC is something of a red flag as well. RPCs will never behave like local procedure calls, so the abstraction will always leak (the pendulum of popularity keeps swinging back and forth between RPC and special purpose protocols every few years, though).
AFAIK, an ebpf function can only access memory it got handed as an argument or as result from a very limited number of kernel functions. Your function will not load if you don't have boundary checks. Fighting the ebpf validator is a bit like fighting Rust's borrow checker; annoying, at times it's too conservative and rejects perfectly correct code, but it will protect you from panics. Loops will only be accepted if the validator can prove they'll end in time; this means it can be a pain to make the validator to accept a loop. Also, ebpf is a processor-independent byte code, so vectorizing code is not possible (unless the byte code interpreter itself does it).
Given all its restrictions, I doubt something complex like a graphics driver would be possible. But then, I know nothing about graphics driver programming.
"Schematics work really well for capturing information that's independent of time, .." This spells out what always irked me about graphical software.
The fun really starts if you have a CPU using big endian and a bus using little endian..
Back in the late 1990s, we moved from Motorola 68k / sbus to Power/PCI. To make the transition easy, we kept using big endian for the CPU. However, all available networking chips only supported PCI / little endian at this point. For DMA descriptor addresses and chip registers, one had to remember to use little endian.
For high-speed networking, exokernel concepts are now being used in the form of DPDK (user space) and eBPF/XDP (user code dynamically verified and loaded into kernel space). Exokernels aimed to move kernel functionalities not into a bunch of separate processes like microkernels, but into libraries. In the late 1990s, I worked on such a system which unfortunately fell victim to the dotcom crash.
done (https://github.com/Netflix/bpftop/issues/17). Seems to be some futex issue, the kind of bugs that tend to be hard to replicate.
I might have mis-interpreted this statement: "Certain types and traits that exist in the standard library are known to the Rust compiler." (https://doc.rust-lang.org/reference/special-types-and-traits...")
I was thinking of things like Box, Rc, Arc, Cell, Refcell. Then there is also the macro language, which integrates Scheme concepts. Like C++, it is a huge language, with extra wrinkles for every new corner case. Again, maybe this all is unavoidable if one wants to have zero cost abstractions. Hopefully, language designers will learn from Rust and come up with something more elegant.
No disagreement about Perl's ugliness..
Nice! But I got it to freeze under higher load. Removing the load does not help.
lifetimes, async, the myriads of pointer types, that poor-person's monad '?' for a single type.. Sure, you need to give the compiler a lot of hints to achieve what Rust is doing, but it does not look pretty or elegant.
From my VoIP experience, there is no 'typical' in NAT. There have been attempts to classify NATs (https://www.rfc-editor.org/rfc/rfc3489, Section 5), but they have been abandoned after seeing how NATs sometimes change their behaviour dependent on their load, the number of connections, the phase of the moon etc (https://www.rfc-editor.org/rfc/rfc4787, Section 3). So, yes, application-level keepalives are your best bet.
By this they mean expulsion of all people -including citizens- who don't "look German" and people who support them. If this is not fascist, I don't know what is.
E1 (2Mbit/s) lines were used to connect data centers in the early 1990's.. Man, to think what you could at home with such bandwidth. Maybe even video!
Actually, it was envisioned that you'd use the D channel for packet switched data traffic (not IP, more like X.25). Why would a private person use more than 16 kbit/s for a home computer? Much more important to have two high-quality voice lines! And we are busily working on ATM-based Broadband-ISDN to even make high quality video calls and TV available! Just you wait!
I worked at an ISDN adapter company in the late 1990s. Apparently, one customer a couple of years earlier did use ISDN as their LAN technology. Each PC with an adaptor (to the joy of my employer, this customer was not small), using the PBX as network switch. I have no idea what software they used. Probably some CAPI-based file transfer. The extended version of that, using ATM-based BISDN, was the telcos' vision of networking.
also https://www.sharedrop.io/ it uses webrtc for local communication
I understand that there were good reasons why it was done. But out-of-band control is so much nicer to work with. One channel for control, one for data.
No parsing of text. No escaping of '+++' to avoid that a '+++ATH' in the data stream closes the connection (I wonder how the download time of a file containing only '+' differs from a file with other characters).
And with increasing mobile network speeds, you really want something like DMA instead of reading individual bytes from a serial interface.
This use of AT commands in 4g modems was really something that made me laugh out loud when I started dabbling with those devices. The muscle memory still worked. The lack of dialing and modem sound was a bit of let-down, though.
It is astounding that the 3g/4g modem industry did not come up with a better way to talk to their devices. Even ISDN had a widely implemented proper API.
Got it, I'll use JCL for the next project.
More seriously, this is a very good comparison. IBM always dreamed to be something like AWS is today.
I once worked in a project where the plan was to have 3 switches in a box, ethernet, ATM, and TDM. The 622 Mbps ATM switch chip was much more expensive than a 1 Gig-Ethernet chip. So ATM was dropped pretty quickly from the concept.
ATM-based DSL was a compromise of the different factions inside telcos. The 'net heads' got a fast Internet access technology. The 'Bell heads' got ATM into every home in preparation of all the glorious ATM applications that would be available any moment now.