I had an opportunity to write Go for 8 months, it was such an exciting experience. Being a java developer, I felt that I was closer to the hardware while writing Go, no abstractions, no syntactic sugar, just basic code
I sort of like Golang, but the problem is the code executable is so large bloated, a shame. But Golang seems easier to understand than RUST or C++. I'm just so use to C.
I respect Linus. But instead of talking that kinda stuff, why he's not out here helping RISC-V to not repeat those "mistakes" he didn't even explain? Makes him look like the Linux version of Steve Ballmer to an extent tbh.
We have that problem solved in ϕSystem. We don't insert tabs into text files. Three or more repeated characters are compressed into a two-byte sequence.
“Lay not up for yourselves treasures upon earth, where moth and rust doth corrupt, and where thieves break through and steal: but lay up for yourselves treasures in heaven, where neither moth nor rust doth corrupt, and where thieves do not break through nor steal: for where your treasure is, there will your heart be also.” Matthew 6:19-21 KJV
Hopefully developing in the open documents why some fixes are made so it's easier to go back and understand the implications and limitations in the future instead of leaving things because we don't know why and when there's a fundamental rework we can not repeat the mistakes for that architecture.
This year, I had to switch to AMD because updating to certain kernel version would break the Nvidia driver. After several weeks, Nvidia comes with the patch. The drivers are ok for most of the time, but Nvidia is slow to deliver patches even for critical bugs :(
Human nature will cause AI to be used and relied upon in a multitude of situations that are bad. Do I actually engage my brain in this government office, and fact check, or do I just accept what the computer says because it has been a long day and it is just before quitting time. You can bet China is using AI in a massively negative way. Same with other countries. Look, i just input your name in our government computer system and it says you are a criminal. You will be arrested immediately. Fact checking be damned. A handy tool for totalitarian oppressive purposes.
The major advantage of C over Rust is that you can look at the C code and pretty much know what the CPU will be doing since the C code is so close to the machine code that the C compiler generates. The same cannot be said for Rust code.
IMO the biggest mistake many CPU architectures make is that they focus too much on the CPU and too little on how to build a whole platform/system around it. A big part of the reason why x86 is so successful is that the PC is, for the most part, a standard platform, with standardized buses that can be probed to discover what hardware exists on the system, standardized firmware, etc. Yes you might need specific drivers for various things, but there is a standard way for the OS to discover what hardware exists on the system, what drivers to load, etc. It all just works automagically. You install Windows or Linux (or other OS) on a x86 PC and, as long as you have the drivers you need, it all just works. It autodetects what hardware you have and how to configure the drivers. Not so with Arm and RISC-V. Everyone makes their own bespoke devices and their own hacky forks of the Linux kernel to support them. If you are lucky, support for a specific board/device makes it upstream into the mainline kernel, but the process is often very difficult, because every one of them requires different hacks, workarounds, etc. You need a Device Tree file for each specific product, to tell the kernel what the hardware is and what drivers it needs, because it cannot autodetect that. It's horrible. Yeah, ACPI and EFI are awful ... but honestly needing bespoke device tree files for every product because Arm/riscv don't have any standards for how to build a whole computer around them, is much worse. This recently started improving largely thanks to 1) Microsoft's Windows on Arm efforts, 2) Arm servers. But I kinda hate the fact that the "solution" they came up with is to just adopt UEFI and port over a lot of the x86 legacy. I'd have liked to see a better (simpler, less bloated, more streamlined, less buggy) firmware standard. I guess they just wanted to make it easier to port existing OSs (Windows) to Arm. We need something like the "IBM PC-compatible" (everything in the x86 world is, to this day, an evolution/derivative of the same computer platform that started in the 1980s), but for Arm and RISC-V. Some kind of standard for how all the basic foundations of a full computer system should work. So that different manufacturers can just make computers, and people can just install a standard OS on them and it all just works out of the box. Manufacturers can still have the freedom to differentiate their products and make different chips and boards with different user-facing features, but they should be built on standard low-level foundational tech (buses, firmware, etc) to ensure software compatibility.
Bascially today LLM is the junior dev who writes a lot of code and you're the senior dev that makes engineering decison, archtecture decisions, and does code review to make sure everything works. Some cases like SQL and regex where llms are likely much better than any human. I think a lot of dashboard, lo-code people are going to be in a lot of trouble.
Torvalds is and has always been a clown. He did something relevant 40 years ago and he's been farming clout for the rest of his life without doing anything but imposing his eccentric ideals on others. He won't name any of the so called "mistakes" because he's just a professional hater, he's doing the same shit he did with Rust except that time the community, which are the people actually doing the work, said no to him. Absolute AAA tier irrelevant clown boomer.
Rust developer of PopOS! Jeremy Soller's recent comments regarding his relationship with the Linux kernel developers is of extreme concern with the future of Linux.
4:31 - It’s crucial to remember that the current state of LLMs is the worst they’ll ever be. They’re continually improving, though I suspect we’ll eventually hit a point of diminishing returns.
@@Insideoutcest I actually just received my first offer doing R&D for a software development company. I specifically specialize in AI product software development (writing code) . The statement I made is 100% factual, the current capabilities of models are the worst they will ever be…. They will only improve, now how much remains to be seen. Could be just 2% could be 20%. I personally believe there is room for considerable improvement before we hit the frontier of diminishing returns. Edit: you know nothing about me, why tell me I don’t program? As if that would certify my previously stated opinion on the improvement of the technology….
The main problem is that RISC-V is a real RISC-architecture in the sense of the early RISC-CPUs. It has a minimized instruction set and misses a lot of instructions which are naturally for nearly any current contender. F.e. a conditional move is just a extension-proposal. And there's no DWCAS-operation which is necessary for fast userspace memory-management.
My take on RISC-V is that, despite being open-source, it might not see widespread success due to its licensing model. We can draw parallels to software like FreeBSD, which is a fantastic Unix-like operating system. Many companies use it, modify it, and incorporate it into their products, but hardware and driver support remain poor. This is largely because companies aren't obligated to contribute their changes back to the main project. As a result, FreeBSD doesn't thrive, but rather crawls along, kept alive by commercial interest. In contrast, the Linux kernel's GPLv2 licensing strikes a balance. It ensures that any changes made to the kernel must be open-sourced, encouraging companies to share improvements without having to release their entire codebase. This setup creates opportunities for contributions to be pulled into the main repository. On the other hand, GPLv3, used by most GNU tools, is more restrictive, requiring all code in a project to be open and free. This makes it tough for companies to include proprietary code alongside GPLv3 software, often forcing them to maintain separate repositories and install proprietary components separately. RISC-V seems to be more in the FreeBSD camp when it comes to licensing, which could hinder its growth and lead to fragmentation. For RISC-V to truly flourish, it would need a licensing model more like the Linux kernel's, which incentivizes contributions and collaboration. Otherwise, much of the innovation will remain siloed, and the ecosystem will struggle to advance.
It's easy - really. 1. One tab can mean more than one space - so it takes less disk space which matters on devices with limited space like electronics or when you need that extra network request speed. 2. Besides tab has semantic meaning - intendation while space is universal so parsing space without context is a little slower Both doesn't matter much in modern times with strong hardware we have today. So do as you please
@@meninoesperto2773 Just C, sure, try to use compound literal in C++, you noob. And its not a "more stuff", its fucking mess like requires(requires(...)) explicit(explicit(...)) constexpr(constexpr(....)) noexcept(noexcept(...)) -> decltype(bullshit)
ARM still has made big mistakes. They're still dependent on devicetrees cause there's no way for OS's to detect everything. Every OS needs to be customized for each ARM hardware platform and it's ridiculous. I hope RISCV doesnt have this problem, but I doubt it.
I can't see that a problem since most devices powered by ARM are SoC's anyways. ARM is just the ISA part-- everything else is going to be different anyways.
RISC-V mainly excites me because of its use in pedagogy. people who are new to the hardware design community will likely understand it better because they can practice on an open, highly developed architecture like RISC-V. that said, I don't actually believe RISC-V is a better designed architecture than its predecessors, nor is it *supposed* to be. it's just supposed to be *an* architecture, that does all the same things as its predecessors because they work, but is open-source. in many ways, RISC-V's rising stardom can be attributed to geopolitical reasons; there's a huge push in China to pivot away from the American-owned x86_64 and British-owned ARM, to the Chinese-owned LoongArch, region-agnostic RISC-V, etc.. that said, I think that RISC-V will still be a net benefit worldwide, rather than just for China; and I think that unless you're an investor or some kind of nationalist, you really should be cheering for RISC-V too.
