This is a much better introduction to circuits than most. You actually get a bit of depth rather than a cookbook of "do this to get that" sort of prose.
I'm not sure who exactly this book is for, but it's certainly not for absolute beginners. There is a huge delta between the target audience and the level of understanding and experience someone not knowing a first thing about electronics would typically have.
I can clearly remember sitting there reading about component parasitics, without even having a clear idea how an ideal component behaves, and so on. I was just lacking buckets of context, and it was a painful read with lots of assumptions about the reader's background.
On the other hand, I still think it is a great book, like pretty much everything else from NoStarch. I just disagree on it being suitable as a first book in electronics.
That said, I'm looking forward to the day when I will be on an adequate enough level to read it again -- this time, in its entirety.
That’s also what I really like about “Practical Electronics for Inventors”, the authors explains the underlying physics for each component. Though the theory chapter can be heavy if you want to follow everything. “Secrets Life of Circuits” seems to be a bit more approachable
I'm hoping you're right. I enthusiastically bought PEFI but found it to be way over my head. I'm eager to get SLOC because I'm hoping it can be sort of a bridge between my "MAKE: Electronics" book and PEFI.
PEFI/PE4I as a technical reference when you need details about a specific topic, SLOC as an overall introduction to give a good intuition, and M:E for more practical project tutorials, if that’s what we (hobbyists without any formal training) end up with that would be awesome :)
AlphaPhoenix YouTube channel is also a great source of information to clarify theoretical topics. I find it very helpful to just see how he think about electricity in his various projects: https://youtu.be/X_crwFuPht4. And his enthusiasm is contagious!
One personal note: as someone coming from software I find learning electronics pretty hard as it requires a completely different mental model and way to approach systems. Took me years of various failed attempts to finally internalize I have to stop relying on metaphors and shortcuts, and instead understand the actual physics at play to develop an intuition that makes sense. That looks daunting and I thought I would hate that part but in fact after pushing through the first weeks it becomes really satisfying! Accept things take time and that you will be uncomfortable for a while, and move at your own pace. And here LLMs are actually really helpful to clarify topics you’re not sure you understand fully, once you start to learn the terminology (I use instructions that makes it clear they shouldn’t solve things for me and instead evaluate my understanding)
Also as a person who came to Embedded/Electronics from the Software side, i found the following incredibly useful to bridge the software-hardware gap using MCUs;
This has more of a hardware interfacing slant than most books on embedded systems which is what a software person needs. Every topic is first introduced in a general way with lots of illustrations and then its application in MSP430 is shown. Hence we can easily transfer our understanding to any other MCU family. A really good textbook for serious students of embedded electronics.
To me, transistors are the best example of how hard EE can be. I heard "transistor is a switch" or "transistor is an amplifier". So I bought some MOSFETs and tried to use them. No go. Well, I had to learn (through random web pages and some books) that microcontrollers struggle to switch mosfets. Fine. I'll get a gate driver. Then I have to very carefully pick a bunch of resistor values that make my system behave. Eventually, I learn that transistors aren't switches at all, but can be coerced into sort of behaving like switches, but in reality, there is always leakage and a hundred other variables you have to understasnd and control for. You can see one of my threads here: https://www.reddit.com/r/AskElectronics/comments/1omqn4d/con...
> as someone coming from software I find learning electronics pretty hard as it requires a completely different mental model and way to approach systems
I went from electronics to software and one thing that has puzzled me is how much people dislike reading docs as in reference manuals. People can get by with sloppy code full of hidden bugs and when those bugs arise they’re like deers frozen by headlights.
Imagine building a circuit without any ideas how it operates. I’ve encountered web devs that don’t understand how http works.
I like Elicia White’s Making Embedded Systems because it covers a lot of practical stuff like how to read a datasheet. It’s a good book for existing programmers.
A lot of electronic books struggle to find balance between super easy projects, very specific cookbook recipes or a laundry list of components.
From the article: With the LLMs every time there’s a mistake, I don’t learn. I can spot the mistake because I have some experience (lucky enough to have been born 34 years ago), I can pinpoint the mistake and let the LLM fix it.
This is something I realized when I became a manager of programmers rather than doing the work myself. When I write code I do it from a position of having a deep understanding of what all the moving pieces are, when someone working for me writes code I just have to trust they had that level of understanding[1].
But being a manger, the thrill of solving the puzzle was replaced by the thrill of helping some new engineer get better at the craft of writing code. They took pride in their growing skill set and I took pride in helping them grow.
Managing consultants however was very transactional. Did they deliver what was asked of them? Did they fix the flaws I pointed out? Do I still want to pay them?[2] And I could of course fire them easily and try new ones that had a reputation for being "better" at the tasks I needed done.
If history is any judge, there have been many companies over the years where some founder/leader has a "great idea" and just needed someone technical to make it real. And the typical arc for those companies was they get founded, they spend a ton of money on consultants to build their technology, something changes (fashion, systems, something) and their product is no longer a good fit for the market so they try to hire consultants to fix it, which now costs more than 2x because first the consultants had to understand what the previous consultants did, then they have to change it in a way that leadership wants. The result is a product that got more and more brittle until there wasn't enough money to or enough consultants to anneal the product back into something people would pay enough for to support the salaries of the visionary leaders who never had any idea at all of how the product they sold actually worked.
It feels like we're going to speed run that. In the LLM era.
[1] And of course that level of trust is not always warranted but that's a different comment :-)
[2] With consultants there is a velocity vs organizational expertise equation that always needs to be balanced. Dropping people into a legacy code base they've never seen is just as hard for them as dropping them into a consultant's work product that they hadn't previously seen.
Both are fine, but I also prefer 'furnish', as in put in the main parts of your CV. In a way, 'burnish' is more like 'polish', suggesting an extra layer on top, rather than the fundamental parts.
I wonder if LLMs can tell when you're taking the mickey out of them. Has anybody tried imitating its mannerisms and had it react? There's a new benchmark for you: SelfAwareness!
It was really depressing when I realized that people will buy a sketchy product which is hurting the community and makers of non-sketchy products because "its cheaper and its not like my purchase is gonna change things one way or another."
It is selfish and short sighted, and it leaves their future impoverished, but in the moment they "got a good deal."
It's not worth engaging in the debate. People have complained that Prusa printers are expensive since forever, even when the MK3 was objectively superior to the alternative models. They would rather buy a $200 Ender and spend a lifetime tinkering with it.
I think it's a bit iffy to argue that the bootloader code is covered by the GPLv3. In programs for standard computers running a big OS, the distinction lies in whether you are linking a library into your program. If the GPL code isn't a library but an external program, it isn't linking, and OK by the GPL. Now on to the bootloader code: in order to flash your device you have to put everything into a single image file. I guess the claim is that this process constitutes linking. But I don't think that is how most people think. Some possible arguments:
When linking, symbols pointing to addresses are involved. The main program calls functions in the library, and you end up with a whole program. On the other hand, a bootloader just does its thing and then jumps to a fixed address in the main program. The main program doesn't call anything in the bootloader. (Note, the Linux kernel has a special clause that explicitly allows the userland to programmatically interface with the kernel.)
I realize this sort of depends on the microcontroller toolchain. I'm familiar with a few, but not much with STM32 stuff. If the toolchain is dumb and implements the bootloader in a way that resembles linking, i.e. making it possible to resolve all the symbols in the bootloader from the main program then it could very well make the bootloader subject to the GPL.
Even as far as linking goes... If you're not actually deriving from the code in a copyright sense then the GPL is limited in what it can demand. The advice from the FSF on linking is not exactly unbiased. The part about the intimacy of the communication between pieces of code seems a lot more solidly based in copyright law.
> This allegedly violates the GPLv3 clause that requires the release of the source code for the entire work if they are combined to form a larger program in or on a storage or distribution medium, such as the flash memory of the STM32F407 micro-controller on the board, and more recently in the update images Prusa supplies
This makes 0 sense as presented here. The GPL explicitly distinguishes mere aggregation from combining in a way that makes it a larger program. Putting both the proprietary bootloader and the GPL OS on the same disk / in the same system makes 0 difference to whether the bootloader is covered by the GPL or not.
If this were true, then any phone, any PS5, any Linux laptop, and almost all consumer hardware would be in violation of the GPL (note that the wording quoted there is also part of the GPLv2, it's not GPLv3 specific).
Unfortunately this comment entirely misses the mark.
The reason this is such a big deal is precisely because it's not a sketchy product. For people who are using their FDM printers for more than just minifigs from thingiverse there's no proper alternative to Bambu. Their hardware and software is significantly ahead of the competition.
If you want to print engineering-grade plastics reliably and accurately you are going to need a Bambu device, or drop 5 figures on a commercial machine. Those are the alternatives. Very few other firms offer consistent, accurate, high temperature printing - and the few that do, don't have the software to manage vibrations, flow control and thousands of other parameters well enough to get consistent hiqh quality results.
Some examples: Prusa have the One+, and good software management. But the "heated chamber" is actually just a fan attached to the underside of the bed, which means that the chamber temperature is not consistent across the volume, leading to poor quality products. There's a few niche devices from people like Qidi, but they don't have the build and software quality to get reliable, repeatable results.
Overall if you're trying to solve actual problems with your FDM device, rather than messing around as a hobby you need a tool that just works, and that can handle materials like PA12, PET and PC. Bambu are really the only sensible choice for this. Yes, I'd be far far happier if the software was really FOSS (the encrypted non-user-readable logs enrage me!), but overall it's a tool not a hobby. I don't have a sensible alternative.
I appreciate where you're coming from, but I think you may have unintentionally made my point.
Try this: Change the context "Acme's Sunscreen which is made from killing an endangered fish, is significantly better than any other sunscreen out there, and because it is already on fish we know it doesn't hurt the ocean!" except the production of Acme Sunscreen is leading to the extinction of said fish in the future. Short term profits, long term loss, and perhaps a bet that at some point what ever it is about the fish that makes great sunscreen will be figured out.
Using FOSS requires (by license) that you give back your changes, which, when functional prevents a vendor from exploiting the work of a bunch of people they didn't pay, to make a product where they pay a few people to push it way past what the community offers. Whereas if they had been publishing their changes, then their product wouldn't be "significantly ahead" because everyone using the same slicer base code would be able to also use Bambu's improvements. But Bambu doesn't do that because why let the competitors take advantage of the work of people who they didn't compensate for that work. Hmmm?
Except that the software part of the "significantly ahead" is in the device firmware, not the slicer. And it's only the slicer that's at issue in this debate. If it were the slicer that provided all this advantage over the competition it'd have been copied years ago, so this is really nothing to do with my point at all.
Again, I'd be far happier if they followed the terms of the AGPL and provided source for their custom slicing extensions, but it wouldn't really move the needle very much for the competition.
You realize that the slicer has to talk to the firmware, and it is documenting the commands their firmware implements which makes the combination of slicer + firmware print right? The whole point of the AGPL on the slicer was to prevent people from having special sauce printer firmware, get all the work of the slicer for "free" and then make their combination better than everyone else's. So you publish the code the slicer uses to talk to your device and that lets someone else implement the same codes (if they choose too).
I think it's reached commodity status instead of community... 3D printing I mean. At that point only thing that matters is ease of use, price, and quality of the result. People who are not _in_ the community but use the tool.
This is exactly what people engaged in surveillance capitalism is trying to achieve. Sell hardware/software at a loss, push out the competition that does things legitimately and then continue there engagement in profiling everyone for profit.
I did a presentation[0] on this about a month back. If we want these situations to stop we need to work to inform the public and work towards getting people that care in positions of power.
You can't really spit in the hobby 3d printing world without hitting the community. I have coworkers who talk about their printers, filament choice, what they've printed recently, etc etc. I've been around hackerspaces with that behavior for over a decade, but it spontaneously showed up at work from a shared interest.
That community is where open source tech tends to come from.
I know the community well, I was challenging the assertion this hurts the community. On the contrary, better and cheaper printers help the community way more than the worries over software licensing. The average person doesn't care, they want a printer that works and doesn't cost much.
Its not only a licensing issue, but they abuse this closed source binary to lock away major features from other slicers (DRM, signature checks), hinder development, include anti-debugging, telemetry, encrypt logs and configs, etc.
And the stock plugin ships an unaligned atomic that triggers the kernel's split_lock detector on every modern Intel CPU. Startup stalls for 25-60 seconds while the kernel walks each trap; every Device-tab click hits it again. The workaround (sysctl kernel.split_lock_mitigate=0) degrades system-wide performance and still misbehaves in LAN-only mode. Reported to Bambu over a year ago and still open: bambulab/BambuStudio#8605.
Again, the average person does not care about any of that. They will use the Bambu slicer (if even, I bet many only print from their phones with the app). They aren't aware of, nor do they care about, anti-debugging, telemetry, encrypted logs, or anything of that nature. Most who do use the slicer will probably be on Windows, not Linux, and on an x86_64 machine. Why is any of this a surprise? It's an appliance, not something to hack on. It would be one thing if it was presented that way, like the Prusas, but it is explicitly sold as a turnkey machine. If you don't like that, you can buy a printer from one of their many competitors, or build a printer yourself, Bambu is not stopping you.
Is the product sketchy or just their practices from your point of view?
I think a valid view (not saying it's right) of this is: "some dorks in a country I don't inhabit gave away valuable code. I'm going to use it and I don't particularly care about what they think about it"
How much do you care about Chinese law? does that make you sketchy?
Inevitably the situation is the "sketch" here is that the vendor avoids a cost by creatively interpreting the requirements. It became famously difficult to buy a reliable PC power supply at one point because PSU vendors were all trying to cut costs and undercut each other. When there isn't a lot of market differentiation features, people differentiate on price. At NetApp we got more and more prescriptive in our contracts with motherboard OEMs because they would do silly things like "leave off 1/2 the bypass capacitors" which would then cause the filer to fail in some environments. And I get that "its just business"
It's an easy thing to avoid the costs associated with complying with FOSS licenses because they FOSS people don't come after you. So instead of having a person on staff who is making sure the company is compliant and updating the web site with source as it changes etc etc. You just don't do any of that and not only do you save money not paying that person you don't have to bother the web site people every time you do a software update. So from a manufacturer's perspective it's a win.
That said, Chinese vendors selling to Chinese customers following Chinese law. All good. Chinese vendors selling to US customers and not following US law, that's bad. I don't see how Chinese law would be part of that discussion.
Yes openly breaking Chinese law in a manner that is in breach of international convention or otherwise has wider consequences (breaking rules about keeping information from the party doesn't count unless I'm there: our privacy laws override) would make us sketchy. Can you name a company that has done that, or are you pulling an idea out of your hat because your argument otherwise lacks supporting facts/evidence?
What makes them particularly sketchy is the hypocracy: they fully understand the concept of IP and they are using/abusing it to try defend their semi-walled garden.
I think the Bambu case is a good one to litigate the AGPL but perhaps should start in the Court of International Trade. That court has the power to block imports as part of a TRO which would shut down a lot of their revenue from the US at least. Doing something similar in Europe would also help apply pressure. Takes lawyers and money though, of which there is certainly not enough of the latter.
Not to be too glib here, but its one of the paradoxes of "free software" which is there isn't any money generated by the licenses that keep it free. Where as "licensed" software has a revenue stream that is used to enforce the license against people who fail to honor it. The FSF can only do so much with their budget here.
The article says the SFC had a fundraiser and raised over $250,000 to hire a lawyer.
There's a confusing part of the article where he says that what he believes is a violation is something that a judge isn't going to care about. I don't know if he's implying that the judges aren't capable of interpreting the AGPL properly, or if he's admitting that the legal argument isn't as solid as they thought it was when they started. It's a confusing thing to say next to the broad claims about violations.
For background, I participated in a "small" action that Sun took against someone who was violating the Java license. The legal fees (in the late 90's) were 8.2 million dollars. $250K is nothing to sneeze at, its a solid 6 weeks of a single lawyer's time, maybe a couple of weeks for a small team. Against a company doing nearly a billion dollars a year in revenue[1] and owning 29% of the printer market? Add in a couple of expert witnesses which are essential to that sort of a case and you'll see that $250K isn't even table stakes. Sad, I know, but it is the way things are these days.
And the saddest thing is that Bambu knows this. They know that people who give away software are not a serious threat to them. And it is especially galling that the value they have extracted out of that software will pay the lawyers that keep you from preventing them from continuing to extract that value and keep it for themselves.
Lawyers fees for a case like that also include expenses, and this would be on the high side.
Court fees, fees for accessing case law, experts, paralegals, etc.
You pay the lawyer and a big portion of that goes towards his costs for additional labour and everything else. A lawyer grossing $2m/year isn't bringing home anything close to that.
That said $250k for a single lawyer for 6 weeks seems high.
Outrageous cartel then. For such amounts there would be plenty who would have intellectual chops to do the job, driving the price down. Legal costs are nowhere close to this outside the US.
This just means that there's pent up demand for litigation that is currently left unfulfilled because it's too expensive. Or, equivalently, many people think that they have been wronged and must simply take it, due to litigation being the only option to enforce that issue while litigation is too expensive to be affordable to them, or more expensive than the cost of the dispute (so, in effect, scamming people out of small dollar amounts is legal since the cost of enforcing one's legal rights may be in excess of the cost of the dispute).
Imagine what would happen if we made it cheaper, as happens very frequently when some other good or service becomes cheaper? Usually the provision/manufacture has some advancements that make it much more scalable, and often less involved, resulting in a lower cost, and sometimes but not always lower quality. So, for litigation? We'd get lower cost, via some more efficient¹ system², maybe lower quality depending on how we make that system more efficient and this may or may not matter in any particular case, and then those people who think that they've been wronged suddenly have an avenue to address it. Overall, this seems like a strong positive to me.
Now, what if people start enforcing frivolous legal rights? Repeal or reform the law that creates the right if it' s so bad. What about people dragging others into court in bad faith? Well, we just streamlined the bureaucracy and took a buzz-saw to the costs, so is it hard to defend against? Perhaps not. Making that perhaps a certain reality would be a good goal of such reform methods. We already allow people with more money and systemic literacy to bully people in this way, and this is a large part of litigiousness in our society now, so this strategy becoming ineffective may reduce it substantially and thus ironically make litigiousness less intense in at least some cases.
1: one proposal off the top of my head (so it may be terrible): sending written documents to a judge with LLMs helping lay people write and refine them, or a cheaper-than-a-litigation-lawyer expert human review service, perhaps, then the judge rules on their own schedule asynchronously for civil disputes without any heavy procedure to deal with.
2: another proposal is to remove law school/JD requirements to obtain a law license, but keeping a rigorous test in place and maybe some less-intense character/background checks, to lower the pay of lawyers
That is not meaningfully different to my estimation, since it is not test-only. Instead, you need to get accepted to an internship/apprenticeship, and then do that for a number of years, prior to having the law license. For gatekeeping purposes, this is functionally the same as requiring getting accepted into a law school and then doing that for a number of years prior to having the law license.
I've only had to hire a lawyer once, and it was $2,500 to have them file a couple papers and speak to the judge once.
You're paying for their experience, just like an engineer - only it's often much higher stakes than a piece of software or product: your livelihood or freedom.
The reason engineers don't cost this much is that lawyers are lawyer brained smooth talking networking types who hold together tightly and have a quid pro quo system and you have to pay protection money to their mafia. Law is based on rubbing elbows in the right places, playing tennis and golf with the right people and in case of jury trials, on acting convincingly and exuding a certain image to manipulate their emotions. Engineers are too autistic to hold together end rent seek this much.
But some engineers do make that much. I say this as a fellow software engineer: why do so many of my colleagues think every other profession is worthless bullshit? BTW, statistically, SEs and Lawyers earn about the same...
The top of top frontier AI research talent maybe makes 2M and I'd guess you have at most a few hundred such people globally but maybe just a few dozen.
Non "FAANG" (or whatever the new term is) software engineers often make sub-100k even in the US. And regular sw engineers won't break above 500k unless they are managers heading some large team or branch. Getting over 1M is almost superstar level as a sw engineer. If you think it's common, you must be in a tiny SV bubble.
I said some, and pointed out that on average SE’s and lawyers get paid about the same. This conversation started on IP litigators, who generally have a BS degree in a related field and often times experience in the industry they practice, so yes they are amongst the best compensated.
Aside, but IP is a propaganda term. These laws are not property rights, their purposes are varied and usually have the wider public as the beneficiary in their reasoning for existing, it's not like ensuring right to actual property.
That confused me as well. I interpreted as judges not having (much) precedent and potentially unable/unwilling to interpret along lines of the license intent. But that’s what courts in this process are there for IMO. If a well written license and a good case, then you need to start somewhere to set precedent.
He is saying a judge will not care that they are technically a separate download. They only care if the end result is complying with the spirit of the license.
This would be a vindication of the SFC's position, which holds that what people commonly call "TiVoization" was in fact already not allowed by the GPLv2, and that the GPLv3 makes a slightly more complicated requirement.
Specifically, the SFC generally claims that the GPLv2 doesn't allow you to distribute hardware running GPLv2 software on it and then refuse to allow customers to modify or update this software themselves*.
Instead, they claim that what TiVo actually did that necessitated the creation of the GPLv3 is more complicated: you were perfectly well allowed to modify the Linux system on your TiVo box, BUT the proprietary TiVo software would thereafter refuse to run. Basically, you could either use the TiVo with only official TiVo software, OR you could use it as your own Linux PC, but NOT both.
According to the SFC, this is the only difference between GPLv2 and GPLv3 in this area - if the functionality of the product you received is allowed to be degraded intentionally because of modifications you make under your GPL rights. Linux with its GPLv2 license allows this, but much of the GNU utils, with the GPLv3 license, don't at this time.
* unless the hardware itself is incapable of loading modified software, of course, such as the case where the software is burned into a ROM and no one can update it.
I would expect this to forcibly unlock the bootloaders of every Android phone sold in Germany (because the Linux kernel, used on all such phones, is GPLv2, and to replace it the bootloader must be unlocked, and tivoization means restriction of the right to replace it), yet as far as I know this is not the case.
So, what am I missing? Which specific German cases are you thinking about?
Steck vs AVM. But the bootloader on your phone is still locked because companies don't have to comply with the law until you sue them. If you live in Germany, you should sue them.
I can't find the source right now, but I believe punitive damages are excluded. So all you could collect would be actual damages. What are the actual damages Bambu owners have suffered?
My assumption was that a settlement would be part of the “cost of doing business in the USA” so they’d pay up to keep importing their products legally rather than lose the market - but you know what they say about assumptions…
The article mentions reverse engineering the code.
But is there anything to stop reverse engineering the physical printer itself, improving on it by 10mm build volume in each direction, and releasing that?
It won't be a copy of the Bambu printer AND it can run the same software, truly freely.
Do you mean physically modifying a printer you bought from Bambu, and selling that on? Potentially as a service, where you buy in bulk and re-sell with this modification? If so, I don't see how that would change anything about the software you're allowed to run on it.
Or do you mean manufacturing your own printer that is a copy of theirs with 10mm extra build volume in each direction, and with your own software? That may be illegal if they have any patents, but otherwise should probably be ok, and would of course not have anything to do with their software - but you still couldn't take the software from one of their printers and running it on yours, most likely.
Some context on the US/WTO conflict. It started under Obama, blocking reappointment of two judges. Trump in term 1 went all in, stopping all appointments. When Biden was elected he fully maintained and supported the policy of blocking judges. So it has been more of a bipartisan policy than "Trump gutted".
I think 'least regard' belongs to Oracle. For some reason I thought DuckDB was one of Gabe's ideas over at DuckDuckGo :-).
That said, the acquisition by Amazon is interesting in that it seems to overlap with their existing DB offerings? Which makes me wonder what exactly it is that they are getting out of this.
Java could be in better hands. Maybe will be, one day, when Oracle finally ends up fighting the organisational fire that has started in their debt pile.
I mean this more generally, beyond that team. Oracle have used their ownership of Java as a thumping great cudgel before, and my own feeling is that the Google lawsuit basically ended Java’s appeal as a language on which others would risk any kind of innovation. A more nuanced approach might have preserved its relevance.
A few years ago, I was itching to either brush up on Java (which I hadn't used since around v1.8) or learn a new one. (eg Golang, Rust, etc) In light of Oracle owning Java, I suspected it would face a long, slow decline and would eventually fade into Perl-like obscurity and decided to spend my time elsewhere. Also, I didn't want their nagging runtime updater on my system anymore.
Haven't regretted that decision at all and it seems to be playing out about how I expected. (Except LLMs make rewrites into other languages more tractable so the slow decline of Java may accelerate)
Its a fun radio, the Si4844-A10 is another one and it can tune AM as well. I built one for my house that was connected to an STM32 that was connected to the Internet and would let me stream AM radio to my phone. That way I could listen to sports when I was on the road with the "home" announcers :-).
Yeah, so was 8051 and it sucked too :-). I appreciated having this rant all in one place. Ranting against bad architecture is always cathartic and absolutely useless since the people who built and now champion the bad architecture are invested so one's rant simply irritates them. And like the parent comment here, I too find RISC-V "useful" in that it has sufficient tooling to make most everything foundational 'out of the box' rather than me having to build it.
Perhaps the most interesting thing is that RISC-V shows just how ISA agnostic people are, as long as you have cross compilation with the gcc suite and an open source way to program and debug things. Before RISC-V, working on a bespoke ISA and computer architecture was never going to "go" anywhere except perhaps into a paper or conference talk. Now there is evidence of a non-zero chance of it going mainstream. :-)
> Perhaps the most interesting thing is that RISC-V shows just how ISA agnostic people are
Of course! Most people in the computing world work way higher up the ladder of abstraction. I suspect a small minority of working software engineers know what an ISA even is.
I did some contract work in web development for a time. It is staggering how few people understand how the javascript they write gets executed on the machine. People don't understand pointers, or virtual machines, or in many cases how JS bundlers work, despite using them daily.
In some ways, this is a sign that our abstraction layers have been a great success! People can program for the virtual javascript machine, without needing to understand how the actual machine works, or how it emulates javascript. Is this the future we wanted? I'm not sure. But it's here.
Definitely. I’m a weird software guy that got a hardware degree in college so that I could understand all the low level stuff. I remember there was a joint project with the hardware (ECE) and software (CS) students to build a simple computer with bit slice and microcode and program it to do something (I forget what). I remember the software students being bewildered that there was no division instruction in these systems (because who needs that when you have shifts and add/subtract). Nowadays, with so much stuff running in browsers, the average software engineer has no clue what the hardware is doing.
> Perhaps the most interesting thing is that RISC-V shows just how ISA agnostic people are
To the extent that Raspberry Pi shipped a microcontroller that can literally be either RISC-V or ARM (indeed, one of each at the same time I think?)
RISC-V, it seems to me, lives in that cognitive space occupied by things like: open source, open weights, C, HTML, ethernet, Greggs sausage rolls and VHS.
Far from optimal, obviously flawed, and could change human society for the better. Ubiquity is inevitable.
What’s far from optimal about open source? Open source seems like a window into another universe, which is just lightly better than ours: people just working on problems and sharing solutions, because humans are basically good social creatures that enjoy solving problems. To the extent to which there are issues like the difficulty of funding open source projects: our society is wrong, not open source.
Nobody wants to cross compile a full linux OS though just for their project. I assume most are using debian multiarch (as they do for arm), and that does mandate a common RISC-V ISA subset. So presumably this will drive further standardization
Which sort of affirms the mantra, "If you can't prove causation, try to prove correlation." This because you can market correlation to unsophisticated readers and imply causation.
> Which sort of affirms the mantra, "If you can't prove causation, try to prove correlation."
There’s already tons of correlation published for semaglutide lowering rates of dementia. This study is an effort at helping find the mechanism beyond the generally also known correlation that losing weight lowers rates of dementia.
reply