RVA23 is pretty nice. This is the first RISC-V profile that’s really viable for desktop class CPUs. (But I still wouldn’t buy a RISC-V chip expecting to run Linux on it until they have proper support for UEFI, ACPI, etc. and “unified discover” is specified, which won’t be for probably 3-5 years.)
Yeah he’s dead wrong here. Even clang-format - easily the worst autoformatter I’ve used - is an order of magnitude more tolerable than no auto-formatting.
Sure it might not always be as good as what a perfectionist human would produce, but it’s sure as hell better than what the average human produces, and it means you don’t have to waste time ranting like this.
Not on RISC-V. The registers don’t really have an endianness. They’re just bit vectors - you can’t address within them.
When you access memory the current endianness setting determines the mapping between the register value and the bytes in memory. It’s the access that has endianness; not the register.
Unlikely, you’d do packet processing in hardware, either through some kind of peripheral or if you’re using RISC-V you could add custom instructions.
He’s right. I think it was really a mistake for RISC-V to support it at all, and any RISC-V CPU that implements it is badly designed.
This is the kind of silly stuff that just makes RISC-V look bad.
Couldn’t agree more. RISC-V even allows configurable endianness (bi-endian). You can have Machine mode little endian, supervisor mode big endian, and user mode little endian, and you can change that at any time. Software can flip its endianness on the fly. And don’t forget that instruction fetch ignores this and is always little endian.
Btw the ISA manual did originally have a justification for having big endian but it seem to have been removed:
We originally chose little-endian byte ordering for the RISC-V memory system because little-endian systems are currently dominant commercially (all x86 systems; iOS, Android, and Windows for ARM). A minor point is that we have also found little-endian memory systems to be more natural for hardware designers. However, certain application areas, such as IP networking, operate on big-endian data structures, and certain legacy code bases have been built assuming big-endian processors, so we have defined big-endian and bi-endian variants of RISC-V.
This is a really bad justification. The cost of defining an optional big/bi-endian mode is not zero, even if nobody ever implements it (as far as I know they haven’t). It’s extra work in the specification (how does this interact with big endian?) in verification (does your model support big endian?) etc.
Linux should absolutely not implement this.
They certainly tried (see Poetry, Pyenv, Conda, etc.). But that was mostly done by Python developers in Python, which is frankly the entire problem.
I hope this encourages the remaining Ruby devs to move to languages that aren’t quite so awful to work with. Even Python is significantly better at this point, now that uv has mostly solved the tooling disaster.
Tell me one time when GNU coreutils being GPL has had any effect whatsoever.
Wow are there still SystemD naysayers? Mind boggling.
Kind of hard to tell without seeing the actual mod decisions. But usually these things are super opaque and the official discussions are super vague so it pretty much is he said she said.
That said, this is definitely waaay better than the vaguebooking that the Rust mod team did when they quit.
I have. It just goes nowhere. The number of people you need to sign off what is essentially a donation is just too high. You always hit someone who says “why do we need to do this?” and the answer is “we don’t”.
You need some actual benefit before most companies will actually pay money. It doesn’t have to be huge though. Sometimes support is enough (as long as you don’t also offer free support e.g. via GitHub issues). Phabricator did that and it seemed to work.
Open core also definitely works. My company pays for GitHub premium because we need the features - primarily merge trains.
They’re very rarely going to donate out of the goodness of their hearts, and if you expect them to do that because you think they are morally obliged to then you’re going to be disappointed.
Yes but why will it take market share away from Google? I can’t see why anyone would use it. It’s going to be slower, less well supported and not even any more secure.
Servo at least has potential upsides: better security and performance. But another C++ engine is never going to have either of those.
Does it need another C++ browser engine though? I don’t see what advantage this will possibly offer over just using Blink or WebKit.
Removed by mod
Windows 11 IoT LTSC is very good. I don’t know about the normal consumer version.
Not exactly. It is pretty similar though, true.
Yeah it’s obviously an improvement but I guess you can’t really sell a distro on “it has a more logical filesystem layout which may cause some issues, and it’s super super niche which will definitely cause some issues”.
Probably a lost cause. I imagine Flatpak will actually work properly before the Unix filesystem hierarchy is made sane.
Ha-Ha -exactly
I agree, KDE is actually pretty amazing these days. Bizarre that the Linux ecosystem is focused around Gnome when there’s another option available that so much better.