I find it funnysad that python people coined the phrase duck typing and then ended up designing what they have now. Meanwhile TS manages to embody duck typing far better even though coming from very different background.
It's all of the above, integrated with a maximum latency for each tier level. Not a new protocol, but adopting the best of the best, like QUIC over UDP: https://en.wikipedia.org/wiki/QUIC#Client_support
Apple is a vertically integrated company, so the idea is that a mobile carrier/ISP could help ensure the middle trunk from server to client arrive in a timely fashion. Often that involves good QoS and limiting streaming to 720p. But there are a lot of other things that can be done to limit slow page loading. For example, I tried loading Reuters on a slow data connection, and it took much longer than BBC. https://idlewords.com/talks/website_obesity.htm
I still don't get it. I came here to make much the same comment as you are replying to.
Unless you mean that your parallel internet is just the regular internet but with the protocols you personally like? So its more of a web thing where you promote sites that aren't bloated?
> so the idea is that a mobile carrier/ISP could help ensure the middle trunk from server to client arrive in a timely fashion.
I don't know that demanding someone like Hurricane Electric to use QoS is going to have a desirable outcome. Is this more a government thing? Forcing T1s to use QoS? My gut tells me that ignoring QoS markers saves them an appreciable amount of CPU, and also lets them act more neutrally.
How do I as a carrier service your "Thinnernet". How "Parallel" is the infrastructure? Do I have to buy capacity or can we peer? Do I have to maintain a separate routing table? Do you use BGP or something else? Are you planning to buy L2 international capacity to "Replace" T1's? What do you do if a carrier starts sending everything as EF? Is there a PoC node or network operating anywhere?
I just don't see anything in here except for broad references to undersea cables and UX.
the references are metaphorical. App developers like Facebook have Lite versions of their Messenger. No actualy physical sectoring or allocation needs to take place. What it's emphazing is that App developers have a liteweight mode. Google got rid of their HTML page version when checking GMail on the web in 2024. Their app still works relatively fast, but on a 128KBps connection, loading a single page on the Javascript only desktop browser version is really, really slow. Like 5-10 minutes slow. I wrote more in another response here:
https://news.ycombinator.com/item?id=48453653
The Symbian phones from Nokia and Sony were ultra-efficient. Not everyone remembers that era, but they were real time operating systems that ensured tasks got completed in a certain time, including user-prompted inputs. It's not a technical limitation of a company or service, but a lot of their revenue might depend on a minimum number of ads or cookies and web analytic trackers being visible on a page. Often in the numbers of 30 or 100+. With all those elements removed from a site, the service might not bring in much revenue. So it's not really an issue of technical capability, but a business model.
Personal blogs don't typically have this issue, as they can be hosted on a small home server, or a remote server, and aren't concerned as much with ads. I can't suggest how the internet should be run, and the article does acknowledge the benefits of a decentralized web. But predictability of content delivery ETA from internet speeds is not an impossible thing to optimize towards, even if uptime isn't above 99%. What is somewhat novel in this proposal is standardizing a subset of typical website activities, like checking news, weather and mail, and getting a more predictable completion time for certain tasks, but factoring in known latencies from wireless providers (as pings will not be as low as a wired connection), and lowering the average latency for the round trip.
On a much larger scale of interactions- but again the web is so wide and varied, that most of those things cannot be standardized, nor should. But kind of like measuring the commute time of an expressway in a city, or subway trips to a grocery. Things that people need and won't optimize more with an Uber. Hence measuring static over HTML is an easy test, and more sophisticated web services can and do have those kinds of benchmarks. But integrating the device, ISP, and server in a way where certain activities can get slightly preferential treatment like ordering and picking up a prescription at a pharmacy, setting appointments with a doctor, would not get deprioritized bandwidth compared to someone streaming something in 4k, and maybe temporarily limiting that other user's bandwidth to 1440p for maybe a few minutes.
So I do think a tiny bit of QoS or speed throttling is needed only in exceptional cases, but for the most part, the typical user wouldn't notice or necessarily need that level of speed adjustment. Most of the optimization would take place at the software, website, and OS level.
I agree most of the issue is on the "web" and not the physical infrastructure, although there is an internet outside the "world wide web" too:
https://yesterweb.org/zine/issue-05/08/
"The internet and the web are not one and the same. The web is simply one protocol of the internet. You see the "https://" at the beginning of the url bar? That's the Hypertext Transfer Protocol, or as it's more commonly known, The World Wide Web."
I sometimes mention the two because multiple protocols are part of the Transport layer. But then again, relying on one too much may be part of the problem, hence the emphasis on examining all the layers and protocols, like UDP.
But you don't really examine the other layers, just talk about them. You aren't proposing alternatives.
Honestly if you cut through everything that's brought up and left dangling, whats left is Website and App efficiency, and a very sizable percentage of apps are just wrapped websites.
I just did a ctrl+f on the page and couldn't find a reference to UDP.
Edit: One thing I didn't include in the article was file sharing protocols, because of security vulunerabilities. I recall IPFS had some known issues, but others have tried to use similar protocols:
Do they work faster than the regular web? Well, torrents can download faster. But I do not know how much the web depends on it or needs it. I know Microsoft and Steam servers allow downloading games and updates from other PCs, including ones outside a local network. Why they offer it (for Windows system files), is beyond me. Maybe some areas (public networks) share an unsecure wifi network more often and do not own a separate router for trusted internet access. I guess the files are encrypted enough that there is a checksum that can determine if the files are not tampered?
>I must admit I am still having a hard time following you.
You're not the first. A "sister" project I started in 2020 is hardware focused, and later on, I determined that a lightweight suite for internet would complement the offline stack: https://ei2030.github.io/FemtoTX/#about
One could say it's a "solution in search of a problem", but game development also is an incubator:
There are other Jobs inspired R&D groups out there- a notable one is Ink & Switch: https://www.youtube.com/watch?v=9s8OA08ggbM They use an aircraft carrier vs. bicycle comparison, as Steve Jobs preferred the bike metaphor as an extension of user capabilities.
>Why should a household or office download windows update files more than once? Seems like a great idea.
I agree with you on that. I also use it to share files and updates on my own network, often when transferring Steam games from one PC to another. I meant for non private networks (like internet cafes) is where I thought there might be a security issue.
https://www.tomsguide.com/computing/windows-is-using-your-in... I do not really know whether it's secure enough, but I'm going to leave that to the experts.
HTTP isn't the WWW. Back when browsers supported FTP and Gopher, you could deliver the exact same HTML, for the exact same experience, over either protocol.
My intent was to simplify the shapes of state borders as much as possible while retaining the topological (?) relationship between states. But there is no fancy math behind my map, it's just hand-drawn mess.
I reckon that OP did the work and that the map is correct. The CA/NV border seems weird. Under Mercator, you're insisting that the angles are correct in the projection. It just looks a little strange - with all those straight lines that you'd expect to see on a plane, but not on a sphere. The conservation of angles threw me off.
Everything that doesn't have a discrete GPU has unified memory these days. If you're asking for something closer to the RTX Spark or Apple Silicon then look at AMD's Strix Halo systems.
Also, if you'd like to know of an earlier example, the very first Raspberry Pi has fully unified memory. Released 2012, SoC from 2011. It's not exposed in the usual APIs which is why you have a configurable RAM allocation for the GPU, so you need to write special code targeting the GPU cores. You can pass a pointer from the CPU and have the GPU read data directly. Results are written back to RAM which can be read by the CPU.
The M1 isnt particularly good at inference, so pretty much every major current competitor with a 256+ bit unified memory system is better: AMD Strix Halo, NVIDIA DGX Spark, possibly Intel Panther Lake
Even in Apple land M1 isn't the first with unified memory - pretty much all intel on-chip GPU (Sandy Bridge and newer) count - it was even a reason for driver issues early in intel's new dedicated GPU lineup, as the drivers expected unified memory - but M1 is essentially modification of an iPad chip, and you can see "unified memory" there going all the way back to first chip Apple bought from Samsung to power iPhone 2G
You were likely only using Intel systems then. AMD systems have had iGPUs capable of light gaming for a very long time. It took Intel a long time to get to that level, after M1 (2020).
You are missing a major detail: integrated GPUs are crap. They win on efficiency but not on raw compute. Before AI (and crypto too, I guess) people bought GPUs to render graphics and that was their main consumer. People built more and more demanding games that required increasingly powerful GPUs to render well. Gaming systems always had a discrete GPU so there was no reason to scale up integrated GPUs because they wouldn't sell, or they would be a waste of die space.
I don't think the M1 specifically focused on inference. Their goal was to replace Intel/AMD/Nvidia with their own chips, and since the previous Macs shipped discrete GPUs, they had to match or beat those so they don't ship something slower.
or you could use 3-digit octal (so 000-777) for a 512 color palette, which arguably would be even more simple. as a bonus you can use it to color file permissions :)
> Plus the fact you can "record" them from a real-world physical environment without ever having to "model" it opens up a lot of utility too.
This is the big thing imho. Sure, you can do traditional photogrammetry to capture meshes and textures but getting the shaders exactly right is afaik non-trivial etc, and if you want real-time rendering then you likely need some further post-processing of the assets. With 3dgs you can pretty much bypass all that complexity and the whole pipeline from photos to rendered frame is much more straightforward.
reply