I can't shake the feeling that since its dealing with a huge amount of network traffic and it also strips SSL from every connection before passing it onto origins, they are a very juicy target for a certain three letter agency to place a tap.
The bit I'm less bothered about is the centralising effect it has on the internet.
They're still decrypting on their nodes, and then re-encrypting before sending to the origin. There's no getting around the fact they can see the traffic as plain text.
Full Strict just means that CF verifies your origin cert against actual CAs (or the private CA they issue you a cert for). "Full" means they don't verify the certificate authority of your origin, which technically is _a lot worse_ because that means you could be getting silently MITMd by some middlebox, since Cloudflare will accept whatever self-signed certificate your origin presents.
For almost all of Cloudflare's features. CDN, WAF, and all the compute features require seeing, storing, and caching content in plaintext. CF doesn't have much of a value proposition if all they're doing is handling Layer 3/4 DDOS prevention (most DDOS hits even back in 2015 were done on the protocol layer, or at least most DDOSes that actually showed up or impacted the underlying service).
They would have had to make an even larger section of the OLED translucent and traded internal space for an IR dot projector and a second camera beside the main one.
It would have made an even larger splotch of the screen look odd.
I think some of the Youtube thumbnail stuff is lazy-loaded, so depending on the speed of your browser and connection it can just hang there doing nothing for a while.
Honestly, there's never been a better time to be writing games for those platforms. The SDK's are much improved from the proprietary stuff available at the time and the hardware is very well understood. People have been pulling off some utter witchcraft on the N64.
The N64 is never going to get any faster, and emulators can run on just about any potato these days. People have realistic expectations of what the platform can do, so there's no need to spend insane effort making the graphics look better. It's always going to look kinda crappy, and that is Just Fine.
This lets game developers focus on the actual gameplay itself. No "Generic Shooter vol. 26 - now with slightly prettier water!", but innovative stuff focusing on the narrative and on novel gameplay elements.
Kaze and James Lambert are amazing. Kaze's new Mario game looks better than a first party Nintendo title, and James's engines pushes the console to its absolute limits.
I've been thinking about giving it a go myself. It's such a fun and nostalgic console, and the limitations are fun constraints.
The code archeology is really cool too. Seeing Rare's Dinosaur Planet boot up and play after being a lost title. Decompiling all the original titles. Building sequels to Ocarina of Time and Majora's Mask. It's such a fun scene.
Then there's Analogue 3D and ModRetro too, which make it fun to play as physical hardware.
It was last night, after seeing Linux on the Atari Jaguar, I was just pondering over that whole scene.
Then I decided to throw on Metal Slug X, a classic of the Neo Geo. Then it struck me, "Could I attempt porting this to Jaguar?!".
It would be a great start project to familurise myself with this older stuff again. They both have a 12MHz 68k, it is just that the graphics and audio cores are different. Would probably have to base it off the CD version so that the memory addressing is already handled (it loaded all assets into 1MB RAM - twice the jaguars storage).
It doesn't sound impossible. But the Jags RISC chips were notorious for being a little slow due to limited cache space, so it might not be so straight forward.
I was actually a bit curious how much HN uses, since it's probably the lightest site that I frequent.
According to Brave's dev tools, looks like just shy of about 90kb on this comment page as of the time of this writing.
Obviously some of that is going to be CSS rules, a small amount of JS (I think for the upvotes and the comment-collapse), but I don't think anyone here called HN "bloated". Even that one page wouldn't fit on Voyager.
Our comments don't really contradict each other. The page size without any linked documents like an external style sheet grew to 140KB after your comment. But just the text is 30KB.
HN used to work fine on an Nokia classic phone until last year. Sadly it doesn't any more, since they switched the CA to something that is not in the OS root trust. If HN wouldn't enforce HTTPS, it would still work fine.
Nice. Do you just use your 5 as a stationary iPod, or do you dual-carry with a modern device as well? Curious on if you also use it to wi-fi the web on your local LAN periodically too, of it that was just a periodic test to check if HN worked.
I use it around the house to Airplay music to various devices.
A number of things don't work, or work in unexpected ways, mostly because Apple doesn't allow me to log in to iCloud with such an old phone.
I can't control lights with the Home app. But Airplay works fine. The phone doesn't know what a HomePod is, but it shows up with a regular generic speaker icon, like the AirMac I have hooked up to my stereo.
Sometimes I have a few minutes to kill, and I pick it up to look at HN. The New York Times web site starts to work, but the login page doesn't load at all. WSJ blocks me at a "verifying the device" screen. WaPo half works. eBay works some, but no pictures. Ditto for Wikipedia.
There's a lot of things you take for granted on a new phone that you only realize when you're using an old phone. Like you didn't used to be able to quickly scroll an entire web page it's only a screen at a time in iOS 10. You can't grab the scroll bar on the side and move it, either.
And 99.9999% of people don't realize the genius of the camera island. It makes it so much easier to pick up the phone if one end is elevated a bit. With a completely flat phone, you end up dragging/scraping it along the table in order to grip it, which scuffs the surface. And if the table is really smooth, it's surprisingly difficult to lift the phone straight up.
Why can't you log into iCloud? unless somethings changed in the past year or something broke between ios 6 and 10, it should work. I'm still signed into my iPad 2 running iOS 6 (granted, iirc the root cert expired a bit ago so you need to update that). the 2fa is also a bit weird, you have to input the code after your password (eg: if your password is password123 and the code is 789 you'd submit password123789)
I think that might be a thing with apples Advanced Data Protection if you have it enabled, which is understandable since the software needs to know how to un-encrypt the data. If you don't have that enabled, then ignore this and assume apple decided to kill a whole lot of devices (particularly their macs, I know a surprising amount of people still on 10.15)
There is more information in a typical, single page of comments here than there is on the average webpage. And I'd say a far higher signal to noise ratio (though depending on the topic discussed some will disagree).
A low refresh rate probably still requires the same display-side framebuffer as PSR.
With conventional PSR, I think the goal is to power off the link between the system framebuffer and the display controller and potentially power down the system framebuffer and GPU too. This may not be beneficial unless it can be left off long enough, and there may be substantial latency to fire it all back up. You do it around sleep modes where you are expecting a good long pause.
Targeting 1 Hz sounds like actually planning to clock down the link and the system framebuffer so they can run sustain low bandwidth in a more steady state fashion. Presumably you also want to clock down any app and GPU work to not waste time rendering screens nobody will see. This seems just as challenging, i.e. having a "sync to vblank" that can adapt all the way down to 1 Hz?
But why 1hz? Can’t the panel just leave the pixels on the screen for an arbitrary length of time until something triggers refresh? Only a small amount of my screen changes as I’m typing.
When PSR or adaptive refresh rate systems suspend or re-clock the link, this requires reengineering of the link and its controls. All of this evolved out of earlier display links, which evolved out of earlier display DACs for CRTs, which continuously scanned the system framebuffer to serialize pixel data into output signals. This scanning was synchronized to the current display mode and only changed timings when the display mode was set, often which a disruptive glitch and resynchronization period. Much of this design cruft is still there, including the whole idea of "sync to vblank".
When you have display persistence, you can imagine a very different architecture where you address screen regions and send update packets all the way to the screen. The screen in effect becomes a compositor. But then you may also want transactional boundaries, so do you end up wanting the screen's embedded buffers to also support double or triple buffering and a buffer-swap command? Or do you just want a sufficiently fast and coordinated "blank and refill" command that can send a whole screen update as a fast burst, and require the full buffer to be composited upstream of the display link?
This persistence and selective addressing is actually a special feature of the MIP screens embedded in watches etc. They have a link mode to address and update a small rectangular area of the framebuffer embedded in the screen. It sends a smaller packet of pixel data over the link, rather than sending the whole screen worth of pixels again. This requires different application and graphics driver structure to really support properly and with power efficiency benefits. I.e. you don't want to just set a smaller viewport and have the app continue to render into off-screen areas. You want it to focus on only rendering the smaller updated pixel area.
> This seems just as challenging, i.e. having a "sync to vblank" that can adapt all the way down to 1 Hz?
I was under the impression that modern compositors operated on a callback basis where they send explicit requests for new frames only when they are needed.
There are multiple problems here, coming from opposite needs.
A compositor could request new frames when it needs them to composite, in order to reduce its own buffering. But how does it know it is needed? Only in a case like window management where you decided to "reveal" a previously hidden application output area. This is a like older "damage" signals to tell an X application to draw its content again.
But for power-saving, display-persistence scenarios, an application would be the one that knows it needs to update screen content. It isn't because of a compositor event demanding pixels, it is because something in the domain logic of the app decided its display area (or a small portion of it) needs to change.
In the middle, naive apps that were written assuming isochronous input/process/output event loops are never going to be power efficient in this regard. They keep re-drawing into a buffer whether the compositor needs it or not, and they keep re-drawing whether their display area is actually different or not. They are not structured around diffs between screen updates.
It takes a completely different app architecture and mindset to try to exploit the extreme efficiency realms here. Ideally, the app should be completely idle until an async event wakes it, causes it to change its internal state, and it determines that a very small screen output change should be conveyed back out to the display-side compositor. Ironically, it is the oldest display pipelines that worked this way with immediate-mode text or graphics drawing primitives, with some kind of targeted addressing mode to apply mutations to a persistent screen state model.
Think of a graphics desktop that only updates the seconds digits of an embedded clock every second, and the minutes digits every minute. And an open text messaging app only adds newly typed characters to the screen, rather than constantly re-rendering an entire text display canvas. But, if it re-flows the text and has to move existing characters around, it addresses a larger screen region to do so. All those other screen areas are not just showing static imagery, but actually having a lack of application CPU, GPU, framebuffer, and display link activities burning energy to maintain that static state.
I mean sure, you raise an interesting point that at low enough refresh rates application architectures and display protocols begin needing to explicitly account for that fact in order for the system as a whole to make use of the feature.
But the other side of things - the driver and compositor and etc supporting arbitrarily low frequencies - seems like it's already (largely?) solved in the real world. To your responsiveness point, I guess you wouldn't want to use such a scheme without a variable refresh rate. But that seems to be a standard feature in ~all new consumer electronics at this point. Redrawing the entire panel when you could have gotten away with only a small patch is unfortunate but certainly not the end of the world.
I'm glad someone else said this because I was right about to.
One of the things I love about Rama 1 is how it squashes the idea of a human centric universe where everything has to occur for reasons knowable by us. Rama is truly alien, inscrutable and fulfilling a purpose we don't get to understand. As soon as it enters our solar system, its gone for good, leaving a lot unanswered.
Its a steep premium to not have zucc peering through your headset cameras.
reply