285 karma · joined November 3, 2022
And for many generations now, x86 machines are basically RISC processors with a CISC frontend.
Empirically it seems that CISC has 'failed' as a way to design processors, and it's better to let the compiler do that job when you're building a general purpose computer.
Maybe, if that were the case, though even the opacity of the messaging is also a problem. Not 'your browser doesn't support the XYZ API, which is required for this feature, try Chrome', or even 'your browser is unsupported, but if you want to try anyway, click here', but 'use a supported browser for this or fuck off <links to Chrome>'.
From what I've looked into on this in particular though, Google sends different code to Firefox, and does pretty aggressive browser detection to do so (spoofing UA is not sufficient to get the Chrome code), but if you can get it to run the Chrome code, it actually works fine. There may be some performance issues on Firefox that the Meet team doesn't like, but rather than doing an overrideable runtime performance check or exposing anything at all to the user, they just ban Firefox users from the feature. This is, if you ask me, totally against the principle of the web, which is meant to be based on open standards and running the same code everywhere, not deciding if you like the browser the user is using and giving them a degraded view.
We've seen where this leads before when we have a dominant browser vendor that wants to entrench that position, and now that vendor operates important web services too, which they can leverage to further cement that dominance. I don't think it is a good place to be.
There is a Bugzilla on it that suggests Google disabled it on Firefox due to performance issues that the Mozilla team is working on, though it seems a bit dubious to me that it's not just an effort to push people to Chrome, since they're doing aggressive browser detection too.
It is also pretty annoying and sad to see the Web heading back to the siloed features and browser incompatibilities/lock-in of the 90s.
'App Store', 'Multi-Touch', 'FaceID', and others that Apple claims though are definitely questionable IMO. When you have to jump through linguistic hoops to describe your product because someone's trademarked the obvious descriptive language, there's a problem. I don't know either. I guess, considering how the legal system generally works in the US, that someone would have to legally challenge their validity, and nobody wants to go against Apple in court.
To be fair I'd say most of the trademarks they claim are pretty reasonable, though: https://www.apple.com/legal/intellectual-property/trademark/...
Edit: Did a bit of looking into the App Store trademark and it looks like both Amazon and Microsoft did challenge this, but both settled out of court with unknown terms, and the trademark stands as a result.
I'm not too sure how this is handled on other platforms, but pre-PA the in-app volume control would often modify the global mixer, rather than implement an in-app mixer/attenuator, which is definitely not what you usually want. In most Linux apps these days, those controls manipulate and are synchronized with the PA mixer, so there's still only one actual mixer, they are the same control. I assume that other OSes also do per-stream mixing in a similar manner, and just choose not to expose the mixer for whatever reason.
As much as people complain about PulseAudio it's always worked well for me, and from what I've seen of Windows and macOS alternatives, it's more featureful and usable out of the box.
I've never been hang gliding, but I get the sense from the article there there's another factor at play here that may be less applicable to powered pilots that should have a good understanding of the risks from their required training and pre-flight planning. An important element in the essay seems to be that hang glider pilots don't have a good understanding of the risks - due to the way crashes are perceived in the community - and that is a prerequisite for doing a competent risk analysis and formulating a safe plan in the first place. They're blind to the risks they're taking, and consider the sport safe, even when they are frequently crashing.
The teaching point of the essay to me, is more that if something can be 'safely' accomplished 99% of the time, but 1% of the time it is deadly, it is extremely unsafe, but due to confirmation bias from 'always' being successful, won't be seen as risky, and in those situations we humans need to be very deliberate about our decision making.
I would say this is one, and by far the most important case, where Apple's incentives aggressively oppose those of the end users'.
Whether this is enough to tip the balance of which company is 'worse' is a value judgment, but I cannot fathom how people argue in good faith for this blatantly anti-consumer and anti-fundamental-freedom vertical monopoly that is enforced with strong crypto. Crypto should be working for the user, not against them to secure Apple's ability to rent seek on all economic activity that passes through the user's device. And no, the two are not fundamentally coupled, as Apple will have you believe.
I would say that carrier locked phones are undeniably anti-consumer though, and they are banned in many jurisdictions. Their sole purpose is to add friction and give the customer less choice, and due to 'collusion' between the few carriers that exist, impossible to avoid, even if you did choose to purchase the phone outright; it's practically the definition of anti-consumer. The phone purchase should be a separate contract, with a defined monthly payment against the retail price of the phone. Offering this is a profitable enterprise for BestBuy etc. on other electronics, so why not phones? The user should be free to switch carriers with little friction, to maintain as competitive a market as possible in a market that is a natural monopoly.
It reminds me a lot of the equipment monopoly in the Bell System until the early '80s.
The issue with framerate mismatch is a fundamentally different one, in that it's not a synchronization problem. It's the result of a non-integral ratio between display frames and playback frames, and exists regardless of clock source. So it's the harder of the two to deal with, and is worse in magnitude too at several slipped frames per minute with e.g. 29.976fps vs. 30fps. In the classical approach, this simply results in frames getting doubled or skipped, since it's not tracking the video rate at all, it just asks for the display to be updated at its frame-time, and the display system will either get a chance to show it or not. The slightly more refined approach is to play back at the closest integral ratio (e.g. play 29.976fps video at 30fps on a 60fps display), and resample the audio to match this new rate, but again this is computationally expensive and complicated.
mpv team has a good writeup: https://github.com/mpv-player/mpv/wiki/Display-synchronizati...
More recently (2011) RFC6177 took a more pragmatic / softened approach, but it does say:
- it should be easy for an end site to obtain address space to
number multiple subnets (i.e., a block larger than a single /64)
and to support reasonable growth projections over long time
periods (e.g., a decade or more).
My point was more "The tools they provide for IPv4 are crap, so wouldn't you expect the tools for IPv6 to be crap too?" with a side helping of "Just because they don't show you any (good) UI doesn't mean it doesn't exist". I agree that ISP-provided routers suck for both IPv4 and IPv6 configurability, maybe a bit worse for IPv6, but in my experience I've never seen one that both enables IPv6 by default and allows inbound traffic.
There was a bug that caused the AOA DISAGREE alert on the EICAS not to be displayed, because at some point someone misunderstood the requirement that the AOA indicator should be hidden if they didn't pay for the upgrade, but this was just an indication and wouldn't have affected control at all (though likely would have hinted the pilots to a more appropriate cause of action).
One could also consider the lack of cross-checking between the two flight computers and associated AOA sensors to be a bug, but that was how the system was intentionally designed, because AOA wasn't considered a flight-critical measurement in the system's safety assessment, so they didn't consider this required. A holistic safety analysis was never really done inclusive of MCAS though, and this requirement probably just followed on from 737NG and wasn't really considered (at least thoughtfully...) in MCAS' design.
This is one thing that's actually been vastly improved in IPv6 (IMO), though I guess it is somewhat more complicated, it is standardized.
In the IPv4 model, your hosts get 'internal' addresses and some gateway device translates these addresses to/from the associated 'public' addresses as necessary. Behaviour when multiple addresses are assigned is undefined, and there are plenty of weird corner cases with internal hosts trying to hit the public addresses of forwarded services and such.
In the typical IPv6 model, your hosts (if they need to talk to the Internet) get a (or several) Globally Unique Address (GUA), which is routeable on the Internet. Optionally, hosts can also have a Unique Local Address (ULA) which is analogous to an RFC1918 address in IPv4. Because it's codified in the standard, hosts will choose the correct source address depending on the destination they want to talk to; a ULA address if the server is also ULA, and a GUA source will be chosen for talking to GUA addresses.
In a typical corporate network, you'd give hosts both classes of address, and your internal services run on ULA addressing. But in most residential or hosting environments, you'd just use GUA as there is no benefit to segregating things this way.
I think the most reasonable explanation is probably because they thought ::1 being loopback (otherwise it would have to go above 255.255.255.255) was more important (since it would exist as long as IPv6 does) than the transition encoding that presumably would die off over time.
Most/all such boxes, especially those deployed by ISPs, have a stateful firewall with an allow-out deny-in policy in place by default. I've never seen otherwise, but I guess it's possible?
Back in the day, cable modems didn't include a 'router' and lots of users plugged their Windows XP PCs into them and got compromised. Most weren't really blaming the ISP for this; go buy a router they said. And some providers will still just give you a public IP with full access by default when you plug into their demarc equipment; indeed many users want this because that's what Internet access should be. Security is on the end user. I don't see this situation as any different, though your ISP should know better than shipping insecure-by-default, this isn't really a problem with the protocol.
More reasonable to look at announcements per AS, where it's currently about half of IPv4, but trending upwards at a faster pace.
v6: https://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata... v4: https://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata...
This is perfectly viable, and is how many mobile networks handle IPv4 (ie. there is no native IPv4 on the handset at all), and how many cloud providers are handling it these days too. You have to do NAT at the border anyway, why not NAT to/from an IPv6 address?
The adoption problem doesn't have that much to do with the technology, it's simply that it provides little value to most individual entities participating in the network, even if the benefit in aggregate is clear, so it's difficult to achieve the critical mass to make it valuable. It's the same thing behind climate change and so many other societal issues.
It sounds like this test payload was part of a larger CubeSet built by NASA, but the actual datacom components seem pretty much off the shelf (besides the optics). 100Gbps transceivers, an optical mux, and an EDFA - all common in terrestrial telecom - and some IR optics to collimate the beam.
To the credit of systems engineers, I can't think of a recent high profile fatal accident that could be reasonably blamed primarily on software, but that's not so much because software is infallible, but because systems are designed to fail safe.
IP is concrete, not abstract. Whatever the form the network takes, when you make a request, your ISP is going to have a make a decision on how to route it over their physical assets to get it to the desired destination. Unless you are talking about your ISP provisioning a physical circuit directly between you and Amazon, with no multiplexing and no equipment on it, you are going to have those hops whether you use IP to choose the route or not. That is not really negotiable, or you're not describing a network (or something even remotely viable) at all. Maybe that path is invisible to you, but it exists.
And in fact, in many or even most carrier networks, this is abstracted in much the way that you describe within that particular network using MPLS. But this approach doesn't scale to the scope of the Internet, requires all edge devices have complete knowledge of every necessary path in the network, and makes inter-networking more difficult because every endpoint and its end-to-end path to every other needs to be shared and synchronized. This is actually more complex, and much more brittle, than the current implementation. And for what? I still have yet to understand what advantage you think would be gained here. Right now, if you want to talk to s3, you send a packet to s3, and your ISP does all the 'complex and byzantine' work. What do you care how they do it?
Ignoring the long tail is also silly. FAANG might represent a majority of traffic on the Internet, but the long tail is huge, and you can't just hand-wave it away like that. Enabling it is what makes the Internet what it is, and if your proposal doesn't account for it, it's dead in the water.
> And in general the more important part is within AWS' (or Microsoft's or enterprise X's) network why waste time on IP when the network owner knows exactly which host every compute process is running on?
Knowing that is the easy part. You still need to figure out a path and actually route the packets along it. You still need to deal with path selection, load balancing, fault tolerance, and synchronizing any necessary state. You still need devices along the path to know what to do with a packet they receive, somehow. It turns out that hop-by-hop routing is an efficient and viable way to accomplish this.
> Instead of thinking of an enterprise network as a set of autonomous hosts that need to figure out a path between each other think of it as a set of processes running on the same OS (the virtual infrastructure). Linux doesn't need to do BGP to figure out how to connect two processes so why does your network?
Because the 'network' you describe is not a network? It's processes running on the same machine? This is not analogous at all to a large distributed network like the Internet.
> AWS knows exactly which physical hosts my processes are running on and could at a control plane level connect them directly. And I, as someone running a business, could focus on the higher level problem of 'service X is allowed to connect to service Y' rather than figuring out how to send IP packets across subnets/TGWs and where to configure which ports in NACLs and security groups to allow the connection.
You shouldn't be? Doesn't AWS number your machines for you automatically and give you a unique ID you can use with DNS to reach it? And also provide a variety of 'ingress' services to abstract load balancing and security as well? I'm not a consumer of AWS services in my dayjob, but isn't this their entire raison d'etre? Otherwise you may as well just run much cheaper VMs elsewhere.
> Similarly my ISP knows exactly where Amazon and CloudFlare's nearest front doors are so instead of 15 hops and DNS resolutions my laptop could just make a request to Service X on AWS. My ISP could drop the message in AWS' nearest front door and AWS could figure out how to drop the message on the right host however they want to.
Uhm, aside from handwaving away how your ISP is going to give you a direct, no-hops connection to AWS, this is pretty much exactly what your ISP is doing. Hell, in some cases, your ISP has abstracted the underlying backbone hops too using something like MPLS, and this is completely invisible to you as an end user. You or your laptop don't have to think about the network part of things at all. You ask to connect to s3, your laptop looks up the service's IP address (unique ID) in DNS, sends some packets, and your ISP routes them to CloudFlare's nearest front doors.
There are some good arguments to be made for a message-passing focused rather than connection focused protocol model, but that doesn't seem to be what you're talking about. What you seem to be talking about is doing away with routing altogether, and even in a relatively centralized internet, that just makes zero sense. We will continue to need the aggregation layer, we will continue to have multiple routes to a resource through multiple hops that need to be resolved into a path, and we'll continue to need a way to uniquely identify a service endpoint.