Hugo Landau writes technical essays on security, cryptography, hardware architecture, reverse engineering and internet history.
HN commenters praise it as a great read with interesting minutiae, citing his PowerPC tagged memory piece and his essay on misused XML.
The imagined use-case for Pushup is the same niche that Rails, Django, and Flask apps occupy, which is a wide range but broadly I would describe as page-oriented, HTML-first, server-side frontends.
I started Pushup because I asked myself, I like programming in Go and think (like you) it's great for web backends - but what is holding it back from being a great full-stack web dev language or environment? net/http is a great building block, and html/template is solid, but I felt more was needed. Like opinionated project directory structure, for one. But also the world has changed since 2006 when Rails and Django debuted.
Obviously, we live in a world in which React and the SPA is seemingly dominant, but projects like htmx have recently shown that you can achieve modern UI/UX in the browser on a server-side app, which less JavaScript. BTW, more and more JavaScript frameworks, like Remix, are (re-)discovering the value of SSR.
I was also motivated to give an old-school mod_php feel of, just add a file and you automatically get a URL route. That's a nice developer experience but also good for long-term project maintenance.
Finally I was struck by this essay[1] about the demise of the "mildly dynamic" site. There is a wide diversity of types of sites and apps, from quick experiments and prototypes, small-to-medium sites of many kinds. But also since it's Go, I think it could scale up on performance to large-scale sites, and as a static binary, be nicely suited to edge apps like…
It would be interesting to throw this URL as far up the internal chain as possible... and see what happens. :P
I'm curious myself, and there are a lot of other people who wouldn't mind knowing too. Fast AND trustworthy turnkey silicon is both a completely untapped hole in tech at the moment and something that's desperately needed in this climate of NDA'd garbage-quality security systems (see https://www.devever.net/~hl/smartcards for one of thousands of examples) and increasingly locked down chipsets.
I'm not sure what else is out there, but I recently learned of RISC-V (http://www.adapteva.com/andreas-blog/why-i-will-be-using-the-risc-v-in-my-next-chip/ ); I'll admit I was impressed to learn a free (open design) CPU has just broken the GHz barrier (http://riscv.org/download.html#tab_rocket_core), but this chip and ISA are still in the early prototyping stages, although the spec seems complete.
On the other hand, x86 is a widely (!) used, well-known ISA with a lot of legacy software running on it, and VIA already have proven CPUs and chipsets and motherboards. I only know about VIA as "the low-power alternative CPU company," so I have no idea what it's position or stance on secure applications is, but it could well net itself some unique contracts by investing in security.
One of the big problems in this space (or at least what's being made into a problem by the major chip vendors) is secure bootstrapping: I can verify the entire boot device (a 128MB boot image could…
Why was POWER9 open? https://www.devever.net/~hl/backstage-cast
> For Intel and AMD, the demarcation point between them and their customer is the CPU, so if they want to keep secrets and maintain a stable interface between them and their customers, they're effectively pushed to do it at the CPU boundary. With IBM, this historically hasn't been the case; traditionally, IBM has only sold servers containing their own CPUs, not the CPUs alone. This means that traditionally, the only customer for IBM CPUs has been IBM — which means there's far less motivation for IBM to lock things down. Moreover, IBM Power servers have traditionally shipped with a proprietary hypervisor (known as PowerVM) built into the firmware. On these servers, all OSes run under this hypervisor, and you can't run an OS directly on the bare metal. This means that the natural interface between IBM and its customers has naturally fallen at the hypervisor—OS interface, not at the CPU..
> When IBM suddenly decided to open up their POWER CPUs for use by third parties, they made available a platform which for its entire lifespan up until that point, hadn't evolved under the same pressures as the existing x86 CPU market, but instead in an environment in which there was really no natural motive for them to lock things down at the CPU level. Which is almost certainly why IBM POWER CPUs seem to so greatly lack any “curtains” — the curtain had always been shipped with the hypervisor, not the CPU.
Why did POWER10…
The thing with cloud and with anything related to it, anything that connects to the internet somehow... is that, unless it's open source and the servers decentralized, you are always trusting SOMEONE. Sure, Apple might make their best to ensure nobody – but them – have access to your data... but Apple controls all the end points. It controls the updates your iPhone receives, it controls the servers where this happens. Like, they are so many opportunities for them to find what you are doing. It reminds me of this article "Web-based cryptography is always snake oil"
https://www.devever.net/~hl/webcrypto
And to be fair, this doesn't apply only to this case. Even the data you have stored locally, Apple could access it if they wanted, they sure have power to do it if they so wish or were ordered by the government. They might have done it already and just didn't told anyone for obvious reasons. So, I would argue the best you could say is that it's private in the sense that only Apples knows/can know what you are doing rather than a larger number of entities .
Which, you could argue it's a win when the alternatives will leak your data to many more parts... But still far away from being this unbreakable cryptography that it's portrayed it to be.
I choose not to engage in proprietary newletter programs, but do read a lot via RSS. Here are some that I consider insightful and/or interesting, above average quality, have limited or no commercialization/monetization, and have a chance of being interesting to someone else:
OldHouseGuy Blog: https://www.oldhouseguy.com/ Has great taste regarding old buildings
Syonyk/Sevarg/Russell Graves: https://www.sevarg.net/ Some combination of /homesteading/off-grid/tech passion/tech skepticism/
The Long Now Blog - makes me think different things
Early Retirement Now - in depth financial writings regarding saving money more than the common person.
Tynan.com - eclectic person
Hugo Landau: https://www.devever.net/~hl/ - Thoughtful insights on tech and adjacent topics.
Casey Handmer - Crazy dreams about space and carbon
scripting.com - Old guy shouting at clouds, old-school Internet guy building stuff. I just read it for variety.
No, the problem with attributes is that people consistently misuse them. So many things about XML break down when you make everything a self closing tag with 50 attributes. So many programmers just seem to say, "oh, it's shorter text so it must be inherently better" or "oh it's one-to-one so I should strictly avoid anything resembling a heirarchy."
Like I think this guy is mostly correct in identifying bad XML: https://www.devever.net/~hl/xml
Though I don't necessarily agree with the "data format" framing. This idea that markup languages are not data formats seems confused.
> They don't. You absolutely don't need a schema. If you declare a schema, it should exist. If not, no problem?
I agree that they should not.
However, I have used many tools that puke when presented with XML fragments or XML with no schema.