The marketing culture for announcing hardware exploits is so strange to me. The norm seems to be getting a custom domain, logos, demos, an FAQ... why do all this instead of just reporting the exploit and releasing a paper?
Only academics read exploit papers. I don't see anything wrong with releasing the information is a more digestible way if it is something that affects the general populace. I only knew about heartbleed because of the website. https://heartbleed.com/
Heartbleed et al. demonstrated conclusively that recognition matters; I don't begrudge researchers any technique that increases the relative visibility of their work.
It’s happening in other parts of the research world too: a couple colleagues of mine were talking recently about a paper we found at a conference last year that had a web page to go along with it with a domain and fancy graphics and such. For a boring programming languages paper. We concluded this is the modern way to try to jack your citations by getting noticed for everything but the technical content of the work, which is a bit off putting.
Getting funding and good job offers is mostly about marketing. Even worse, lots of people controlling the purse strings aren't domain experts. In a way, it's no different from getting published in specific high-profile publications or attending specific universities.
It's a recent trend basically since Heartbleed had a cool name and lots of press. Why would you not want your exploit to be well known and to get lots of credit for it? If anything it's surprising it didn't happen earlier.
The custom domains can be a little silly, but for all the rest, why not? Logos (and the associated fancy name) are a lot more memorable than CVE-2025-XXXX. Demos are and were always appreciated. FAQs are a lot more digestible for the average reader than a paper.
I know it's kind of goofy, but I don't really see the downside to it.
Blame society. Businesses won't value security unless the fear of getting attacked is sufficiently strong and the losses significant. Otherwise why invest in it at all?
Definitely not just hardware exploits though. Look at heartbleed for example. It's been going on a long time. Hardware exploits are just so much more widely applicable hence the interest to researchers.
It also feels like that people who are highly determined to build high quality, secure software are not valued that much.
It is difficult to prove their effort. One security-related bug removes everything, even if it happened only once in 10 years in 1 million line code base.
I love RSS. I use RSS daily. I use link-aggregation websites like HN to find interesting authors and subscribe to any RSS feeds that they have. Highlights from my reader sync automatically into my Obsidian vault. It's great.
But I know I, and everyone else posting in this thread, are in the minority. It's clear that most people prefer algorithmic drip in a walled garden. There's a reason everyone flocks to those platforms when RSS superseded them. I don't think I need to re-hash why those platforms are bad for the health of the internet and society as a whole.
So what can be done at a structural level to fight this? What can be done to incentivize people to leave these algorithmic drip feeds to reverse this trend?
Build tools to make it easy for people to assemble their own chronological feeds that have quality UI / UX. IMHO the algorithmic feed's principle benefit is how easy it is for a user to curate something close to both what they want, and what they didn't know they want. We too often view things in terms of technical implementations and such, and lose focus on the core problems the user is actually having. Algorithmic feeds are great, because:
- User installs app, opens it
- User begins scrolling
- Within a few minutes they have an endless feed of mostly interesting content
That is REALLY hard to do without an algorithmic feed, and there are a lot of problems when they subscribe. Not insurmountable, just easily underestimated. The motto I keep repeating to myself when I fall into a doomerism about the inevitability of the algorithm, I just say "Its time to build" and hope I can find something on the other side, if I keep digging. The principle weapon against the algorithm is, I think, not needing an infinite pool of profit. I.e. Facebook could build great apps that weren't algorithmic, but it is highly likely they would make much less money. So not only won't they, they literally _aren't realistically allowed to do it_. Its a crazy thing to think through.
I don't think that's something that RSS (or any other alternative) can fix. I don't think RSS is as toxic as algorithmic feeds, but they are still cut from the same hyper-connected cloth. If you want to fight the algorithmic drip, promote people to connect with others in their community on a small scale.
Even if you have to use the internet to do it, making time to talk (with your vocal cords) to a friend on a regular basis can be much better than mindlessly scrolling or reading endless news feeds.
What might be even better are various other social activities away from a computer. It doesn't have to be highly social either. Just being in a park or library with other people silently reading or feeding ducks can be a highly positive semi-social experience. Just silently enjoying a common experience draws way more connection than the various "social" media apps out there.
I would argue for Twitter over a spotty collection of RSS feeds just because there's ironically more of a democratic aspect -- anyone can start tweeting about whatever. They can go viral and disappear, they can gradually build an audience, etc. They can interact with followers or reply guys or stay aloof; they can recommend content and become a mini content aggregator in their own right. People can be anonymous or they can use their real world cachet to build a following.
Accomplishing the same thing via publishing an RSS feed is a daunting task -- you need to build an RSS feed somewhere, you can't interact with others or be easily boosted by bigger accounts to start to gain a following.
The "walled" aspect of this is basically the limitations of what the platform will allow, which especially under the Musk regime is a good balance of only very light touches of moderation.
People talk about the feed and the algorithm, but no two people have the same feed; the accounts you choose to follow will determine what your feed looks like, together with some generally popular content.
My only response to this is that I don't like the even-more-pay-to-play aspects of RSS. To even up an RSS feed requires a commitment that is an effective bar for 99% of individuals that would be interested in participating in public discourse.
The "for you" feed is less transparent in its nature than the "following" feed, but is still extremely customized. I do see content from accounts that I don't follow, but the vast majority is from accounts that I do follow (or that I can reasonably believe were liked by accounts I follow, though that interaction is more hidden now).
I do wish there was a simpler way of "unliking" or "downprioritizing" a post or an account short of blocking/muting. You can do the "see less of this content" but it feels too subtle; I don't know what the actual effect of this is.
1. Mandate that all platforms must have a reverse chronological feed as the default. Alternative "algorithmic" feeds must be explicitly opted in to (preferably with age verification).
2. Regulate out of existence the business model where time spent on site converts to revenue, and force people to directly pay for stuff. Levels of indirection in "payment" for services turn the free market into (even more of) a joke (Noam Chomsky already highlighted this when advertising was cohort based in print- and TV media long before the targeted advertising of today).
Would immediately increase the signal-to-noise ratio by many orders of magnitude.
Make it easier, probably. Even in the glory days of RSS I just never put in the effort to make it work for me. (sort of like how Twitter fans always told me I had to "curate" my feed better to make it less of a cesspool, but I actually just didn't care about randos yeeting random junk into the void).
Curating your feed requires a LOT of upfront investment, and then a nonzero amount of maintenance.
Readwise Reader. Yes, as another commenter stated it costs money, but it has many other features that I find useful such as good text-to-speech, integrations with other apps like Obsidian, and a good export feature if I want to switch to another feed app.
- i tried it, and it’s okay… however personally i much prefer a more private rss reader, where i don’t share all my personal data with yet another commercial company.
Also, it’s quite expensive.
I primarily write code in a DSL which has no good FOSS LSP implementation. If I’m writing this code on my personal computer I’m out of luck. My employer pays for a language server that requires a license.
There are a non-negligible number of my coworkers who don’t use the licensed LSP implementation and they write all their code in vim – or worse, gvim through a VNC. It’s very easy to tell that their code quality is worse.
> It's too easy to defeat the purpose of these things if you're even slightly driven.
Things like the OP and LeechBlock are tools for people who have already mostly conquered their addiction, to help keep them from relapsing. On their own, they're not sufficient to turn an addict into a non-addict.
Because I am not always driven to type 128 random characters or even use my phone camera, so it does successfully stop me from procrastinating much of the time.
That’s the ideal but it’s not what I’ve observed in practice. In my org, people send reactions and reply all emails like this. It’s just more distraction.
Not OP but I use this and like it. It gives a slight scratchy feel when I write on my iPad with the apple pencil and it removes all of the glare for when I'm reading. It's magnetic so you can remove it whenever you want to, but I never take it off.
I do really think that PG often glosses over what he really means when he says "success." From a critical view, you could interpret the word to mean solely financial/economic success. Given his occupation, I would imagine that's his intention with the term.
But if you replace that term with something like "virtue" or "eudaimonia" and read from that perspective, there can sometimes be some truths to glean from his writing. Nothing really novel, but interesting to read nonetheless.
> But if you replace that term with something like "virtue" or "eudaimonia"
These are generally ego-centric qualities that don't clearly benefit the people around us outside of our not being a liability to others under most moral frameworks. Greek philosophy is quite a poor fit for modern relations between individual and society.
Thank you for making this post. I always love chatting with people.
Alias: artisanspam
Interests: Philosophy pertaining to both political theory and how to live “the good life,” cycling, violin, piano, jazz, PC gaming, design of the built environment (city design, interior design, landscaping) and how it shapes you, meditation, Buddhism (from a secular perspective)
Language(s): English
Link to something you think is cool: Pertaining to built-environment design, I find this YouTube channel interesting: https://youtube.com/@nevertoosmall
> The easiest way to improve this would be to capture as much of the architecture as possible in formats that are easy to read and manipulate. In particular, instruction encodings and control/status registers are easily described by simple JSON/YAML/XML/… formats.
This has been something I wish was available for ARM pseudocode. It’d be ideal to just generate an equivalent Python, SystemVerilog, etc. library from the ARM ARM instead of having to reimplement a subset of it yourself.
This has been available for arm for some years. Here is a blog post I wrote at around the time it was released. The easiest bits to use would be the instruction formats and the register fields
I am a DV engineer, and I'm going to give some candid feedback: CI tooling is not what I spend most of my non-coding or verification-planning time on, so I wouldn't find much use out of this tool. Now that wasn't always true – I used to work somewhere that had horrible CI tooling. But that's just because the company didn't invest in someone to maintain that infrastructure. Given that, I don't think they'd pay an external vendor for a tool and require someone to maintain that tool as well.
However, I do have some problems that you may want to consider pivoting to or adding in the future:
1. A wrapper that works with all of the tools that EDA vendors offer as a back-end. Basically, CMake for SystemVerilog where I can just run `make` and compile, elab, and sim run in order. Every company I've worked for has made their own wrapper program which essentially re-creates this process and I've had to relearn it several times. If you had this wrapper, then you could easily just use other CI/CD pipeline which calls this tool. Bonus points if you can integrate it with VUnit or SVUnit unit testing frameworks.
2. SystemVerilog code generation. Something smarter than just "I wrote a Python script that prints SystemVerilog code to a file based on some config file and then you run your build with the file the Python just printed."
I'm sure there are others that I am not thinking of. But overall, I don't find a lack of CI to be the problem. It's the lack of tools that a CI pipe uses that's the problem.
ETA: Also, was it intentional to launch right on the tail of DVCon? If so, clever planning.
CI is a core component of our product, but it's also a building block that we're building lots of DV-specific features on top of. In fact, one of those features is a build wrapper sort of like Make/Bazel for compiling stimuli, feeding them into simulators, and doing post-processing. Essentially what you describe in point 1 but for verification. We'll likely open-source this so other CI platforms can use it too.
For the other problems you mentioned: we're currently just handling the verification piece of the puzzle for right now, we want to do one thing really well first. We feel your pain on the SystemVerilog code generation front, we've had to interact with similarly primitive code generation mechanisms. You can only go so far with the preprocessor and what gets generated during elaboration.
