It should be the opposite, I am a bit confused about LineageOS' statement here. The Quarterly releases represent solid milestones towards the final Android number milestone.
GrapheneOS claims that this made their rebasing much more efficient: instead of receiving a massive dump of all Android 15 at the end, developers receive incremental changes (the QPRs) to help them anticipate major changes in the code.
The OP makes an interesting point but it doesn't point out the main problem with high level hardware languages: these kind of languages don't allow you to describe the hardware you want exactly, they only allow you to describe their functionality and then they generate a hardware for said functionality. The problem is that you will end up with a hardware that is less optimized than if you were to design it in Verilog.
I work at a very big semiconductor company and we did some trials with implementing the exact same hardware we had in Verilog but on an high level HDL and while development could be faster, we ended up with worse PPA (Power, Performance and Area). If you try to improve this PPA, you just end up bypassing the advantages of high level HDLs.
On top of that, it raises a lot of questions on verification: are you going to do verification (testbenches) in the Chisel code or in the generated Verilog code from Chisel? If you do it in Chisel, how do you prove that Chisel didn't introduce bugs in the generated Verilog code (which is what you will end up shipping to the foundry for tape out after synthesis and place & route)? If you do it in the generated Verilog code, how do you trace the bugs back to the Chisel code?
I do think that we need a new language but not for design. Verilog/System Verilog is fine for hardware design, we don't need to reinvent the wheel here. We will always end up in Verilog in our synthesis and quite frankly, we don't spend that much time writing Verilog for hardware design. Hardware design is 5 lines of code and that's it. The real cost of hardware development is the other side of the coin, which is hardware verification.
If hardware design is 5 lines of code, hardware verification is 500 lines. Writing testbenches and developing hardware verification environments and flows is essentially normal programming and we are stuck in System Verilog for that, which is a very bad programming language. Using System Verilog as a programming language is so prone to unintended bugs in your testbenches and bad programming constructs.
This is what we should try to improve, verification not design. We spend far too much time in hardware verification and a lot of that time is spent dealing with pitfalls from System Verilog as a programming language.
I wish people would be investing more thinking here rather than trying to make hardware design friendlier for programmers.
I wouldn't call it the "hot blooded Spaniards stereotype", it's more like the general snarkiness and arrogance that emanates from this type of social networks.
If you feel the need to escalate your view to Twitter and turn it into a one-sided view, then maybe there is a chance you are missing something out.
It reveals that there are things that marcan is glossing over and forcefully pushing for his way of doing things. No wonder why the conversation with the maintainer is not going forward.
He is talking as if these are private conversations and forgetting that this is completely public.
I admire his efforts in bringing up Linux on Apple Silicon platforms but this attitude of making a tantrum on Twitter is just sad and not very professional. And I bet a lot of junior developers use him as a role model, which is even sadder as this kind of attitude and snarkiness just keeps propagating.
The Portuguese implementation of this is quite poor and widely unused. They started to improve it recently but nothing beats the implementation of BankID in Sweden, it is definitely a killer feature.
I agree that HN goes overboard with Google Reader but I can also share the sentiment.
You are right when you say that there are many alternatives to Google Reader, even better ones you could say. I am fond not just of Google Reader but also I am fond of the times of better news consumption of back then.
When Google Reader disappeared, it left some sort of hole in news consumption that got filled up with Google+, Twitter and Facebook. The media outlets became obsessed about sharing news articles in social media, fighting for "likes", "+1s" and "retweets".
Google Reader provided a simple of way of having your news centralized on a snappy service, with good UI, without any ads or "smart suggestions" and without all of your social graph embedded in there. It was the way of consuming news for people that actually wanted to be informed.
And the best part, you could actually subscribe to other's people favorite feeds. It was kind of hidden, there was no dedicated "find friends" button or anything like that, you had to go out of your way and ask to someone "Can I have the link to you RSS feed for your saved items?" in order to "add them" to Google Read. And you could actually comment on their saved items.
I miss these times, I was actually a news junky back then because of Google Reader. I was shown what I wanted to be shown with no social crap or "hot articles" thrown to my face. I slowly lost interest in consuming news after that.
I have this experience more with HN rather then Reddit. Granted that the popular subreddits are quite overloaded with "normies" but I still visit lesser know communities that still keep their spirit and a solid user base.
HN on the other hand suffers from having just "one subreddit" and it became quite bad over the past years.
While Element.io still has some UX points to improve upon, I wish people would be a bit more honest about the state of Matrix clients and less fatalist.
There are other alternative Matrix clients that implement an experience closer to Whatsapp than Element, like Fluffychat.
I have been running my own Matrix instance with federation on my 20 dollar/month Linode VPS for 5 years already.
I use between some friends and family and I'm also connected to massive channels like the official "Element Android" and "Element Web/Desktop".
And it runs... just fine. The server can be a bit performance hungry but I also host plenty of other services on my VPS (email, HTTP server, Seafile, VPN, etc) and I never noticed any degradation in performance in any of them.
They have been making a lot of progress in improving the performance of the Synapse server and it is very usable now. And it is not difficult to configure at all, it's easier than configuring Prosody.
I would say that the bottleneck now is more about improving the UX and the Voip capabilities of the clients.
If you are going to post that specific email, then you should also post the mail in which Matthew Hodgson from Matrix addresses and clarifies some of the concerns there:
I don't feel negative towards Prosody, Prosody is an awesome project.
My criticism is about XMPP in general and its ecosystem.
I stopped my XMPP server a few years ago, Dino was still in its infancy. It's good to see that the client is reaching some maturity but then, looking at the supported XEPs I can see that MAM is not supported for group chats:
XMPP is featherweight compared to Matrix because it does less things than Matrix.
Having a gigantic group chat with hundreads of people, with encryption, history and media synchronized between everyone without relying on a centralized server is something that XMPP doesn't even try to solve. Matrix does.
Prosody is a great project, I used to run my own Prosody server before moving on to Matrix. But people shouldn't lose perspective of the state of the protocol.
XMPP is okay if you plan to chat with a few people individually that are willing to spend time choising the right client with the right plugins and if you don't care about modern features but anything beyond than that and it becomes a huge headache.
That statement doesn't reflect the sad state of XMPP clients available nowadays.
I used to run my own XMPP server for years before moving on to Matrix and the reality was that the only good client was Conversations for Android. There wasn't a single one for Linux desktop that felt modern and up to speed with the latest XEPs.
And let's not even mention trying to get multiple clients supporting the same history with encryption enabled, that was super chaotic.
I'm really glad I abandoned my XMPP server in favor of Matrix. Matrix is modern and it just works and setting up a Synpase server is way easier than setting up a Prosody server.
It's sad to see how far the HN community has fallen, to the point in which people don't seem to understand how computers work anymore.
No, this is not a brand new CPU ISA without custom instructions, it's Arm based. And yes, compatibility will be kept with other Arm based CPUs including Apple Silicon.
I know very well who marcan is and I also have quite some experience in this area. I know how challenging these kind of things are and I just didn't expand on my argument because it is a very ambitious project.
GrapheneOS claims that this made their rebasing much more efficient: instead of receiving a massive dump of all Android 15 at the end, developers receive incremental changes (the QPRs) to help them anticipate major changes in the code.