sweden

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.

His Twitter thread with a user called Peter Geist is quite an interesting read: https://twitter.com/marcan42/status/1587122439561318400

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.

It's also not pretty how marcan is just making fun of the kernel maintainer in other tweets: https://twitter.com/marcan42/status/1587023643380682759

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.

That's not how Matrix works. Please don't spread FUD.

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.

Which file are you talking about? The homeserver.yaml?

Mine only has around 100 lines without comments.

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:

- https://mailarchive.ietf.org/arch/msg/tools-discuss/G4-c-2P9...

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:

- https://github.com/dino/dino/wiki/Supported-XEPs

Fortunately Matrix and the respective clients have been evolving quite well, so I don't see the need of going back to XMPP.

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.

Agreed. It took me a while to realize that this was just about compiling Linux drivers for a network card connected through PCIe.

That's not how licensing Arm technology works.

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.

If you are just planning to hack something to show some basic and buggy 2D rendering, 5 years might be realistic.

It has been longer than that and 3D support is still a bit shaky. And this is based on known hardware.

Btw, I hate twitter for this. Why isn't someone as technical as Marcan posting this on a blog?

The world went mad.

Keep in mind that something as fundamental as the GPU driver wouldn't be available even they managed to get Linux up and running.

And the M1 GPU is Apple's full custom GPU. Even if someone tried to reverse engineer a driver, it would take decades.

That's because we might be just seeing the low-end version of the M1 and we might see the high-end version of these chips next year or so. :)

Thank goodness the title mentions it is Softbank backed, otherwise I would have missed some good Softbank bashing.

So I can buy the tool without the support contract?

Probably not but it's not something you would like to. Cutting corners is a really bad idea when it comes to hardware development because once it is out there, there is not going back.

Having access to a professional engineering work force that knows how the tool works and know it will ready and interpret the Verilog and process it can make a difference between a 5 minutes delay and 2 week delay in the project.

So it's automatically a wash? Why bother trying to improve things if there will always be bugs, right?

You are distorting my words. I'm not saying that we should be complacent and just accept incompetence.

This is a very well formulated question, well asked.

People are already doing every step you mentioned but there are three problems:

- Processors nowadays are so advanced and complex that you can't simply approach them as if it was one single block. You need to divide the processor into smaller blocks, develop those smaller blocks and put them together by the end of the development. Like in any engineering problem. The main problem is that it takes a lot of time for all sub blocks to be mature and stable enough for top level integration.

- Once you have all your blocks ready, you can start integration and bring up the system with FPGAs. But now you face the problem that FPGAs are really slow and are not really usable as a normal system. You can run some preliminary tests, the short ones but it would take months to properly execute a normal benchmark.

- You could create and tape out test chips but then you would also need to create all the infrastructure needed for the processor to work like the memory system, memory RAM, communication buses, firmware and etc.

Those are some very empty counter arguments but I will try to answer them anyway.

EDA tools are expensive, yes. But you are not just paying for the tools, you are paying for all the engineering support being those tools. Bugs and problems happen in any development tool and those companies are ready to pick up the phone at any time of the day to help you with anything you might face, whether it is a problem with their tool or a problem with their setup, to the point that they can deploy a new version of their software on the spot just for you.

And they have actual engineers on the other end of the line who know the product like the palm of their hand.

While this might sound superficial, it is extremely important when you are racing towards a $100M dollar deadline for your project.

I don't think that is the point of the article. Even a state machine that is very well written can be wrong if it's fed with the wrong input. And this is the core of the problem with hardware development.

You want to make sure that the hardware you are designing never ends up in a situation that you didn't foresee. So you want to make sure that during hardware verification you go through every single possible combination of inputs and you want to make sure you exercise every single possible outcome.

The quality of the hardware is not about the language you write your hardware in. It's about the tools, the methodology and the infrastructure you use to exhaustively test your hardware.

And this is the point of the article, current processors are so complex and do so many things that the hardware verification suffers from an explosion of states to exercise.

As a hardware designer (well, mostly a hardware verification engineer), I feel that this kind of comment is a pure misconception from software people that gets echoed time after time in HN.

I generally see a lot of more effort and good quality tools in hardware verification than in software validation. The hardware design and verification industry is not really 30 years behind the curve compared to software development.

Hardware and software are two very different problems with their own set of constraints. It's actually more often that you see software barely tested being deployed in the wild to millions of users rather than hardware. Hardware bugs tend to get more attention because you can't really deploy a patch to fix the issue.