Depends on what you mean by active. The kernel has the code in the binary, but on boot it goes through device discovery and initialization, so it doesn't initialize or run drivers for things that aren't present.
There are also architecture specific builds, so the aarch64 build won't include driver code at all for devices that are specific to x86.
What's the size difference between the AFM needle and the area of stored magnetic flux on a hard drive platter? If you used an AFM as a sort of record player, scanning along lines of little pits, what sort of theoretical information density could be achieved over the whole surface of the disk?
It's not mine; just a project I've toyed with a few times in my search for GUI toolkits over the years. Issues and/or PRs can be filed on the github page though.
Seems some of the listed advantages for Janet would also apply for tcl (small/simple, easy to learn, embeddable, usable as a shell, great for domain specific languages). It would be interesting, to me at least, to see a fan of Janet compare the two.
As long as you're taking suggestions, since many of the books are quite old, adding a publication date or date range to the search functionality might be nice. I personally would find it very useful since I have a tendency to look for things that are older than year _x_ when researching various things.
I don't understand this perspective. How can one accept the objectively more user hostile option because the less hostile one gets money from the other. If one objects to using products funded by google, why is there not also an objection to using products from google?
For as long as the funding for Firefox continues, it remains a viable option. And despite all their bad decisions of late, they still give users the ability to configure or disable user hostile components.
Their funding model is a risk, but I've been using Firefox and librewolf forever and I'd argue it's a much better option than chrome or edge, especially with a handful of plugins. A risk is still better than the actual realization of the risk.
I suspect that timing might help Intel here, with so much of the better established foundries near fully allocated for the next two years, it may be more a question of availability than brand name risk. And for whatever problems Intel has, it's pretty unlikely they'd go completely under and disolve in less than a year. Good non completion clauses in the contracts can mitigate a good chunk of the remaining risk.
Not to mention potential customers who would prefer a US based foundry regardless. My guess is that there's a pretty large part of the market that would be perfectly fine with using Intel.
Ones that might be of interest to you are Umka, tcl, and berry.
There's also a lot of others listed that range from someone's experimental side project to professional grade and well supported languages. Kinda fun to see different people's approaches to things, and no matter what your preferred programming style, there's probably a few in there that will mesh pretty well.
At the risk of stating the obvious, the drone shouldn't be flying anywhere near the crane. It's an active construction zone with a structure that moves and swings about in unpredictable ways with people and equipment moving about below. It shouldn't be delivering to the construction zone, and if it can't figure out how to stay out of the area, it doesn't belong in the sky.
There are some FAA requirements about cranes/temporary structures that would give pilots an appropriate NOTAM, but I don't know if all cranes require this. That said, I'd argue that if it isn't tall enough to require notifying the FAA, the drone is flying too low.
> it also requires GIGABYTES of crap you need to download on windows
I was surprised by this since all I need on Linux is llvm and clang, but looking at the official getting started page, it does indeed say "MSVC compiler and windows SDK" are required. Is that really the only way to run it on windows, or is that just the path most familiar to a typical windows developer?
I personally disagree with saying it requires IDE support. I want to write a ctags parser for it, but that's all I would ever use; as a die-hard vim user, I never liked all the language server stuff people are so reliant on these days. But if that's what people want to use, it's available for Odin as well: https://odin-lang.org/showcase/ols/ -or- https://github.com/DanielGavin/ols
I thought the funding section was a little odd; I was under the impression that Bill was being paid by JangaFX to develop/maintain the language? But I think the corporate sponsorship of language development should be the norm. If existing languages are not sufficient to solve a business need, then they should pay for the development of a new one (or directly support one they rely on). But making a language "popular" and widely used is directly opposed to making it paid. There are plenty of closed languages out there, but they're only used by the corporations that developed them, and are probably kept closed to make sure the language doesn't stray from their business needs, and/or to maintain a competitive advantage.
Otherwise, I'm generally a fan of Odin, but I do find it quite irritating that only place to ask questions and participate in the "community" is locked behind discord. I even gritted my teeth and tried to make an account for discord just for this, but discord wouldn't accept my (apparently mandatory) phone number. Community questions and answers need to be readable and searchable without yet another login. If I'm learning a language and can't find an answer to a question that was almost certainly asked already, that's just another stumbling block that will prevent me from using said language.
> voice interface that can reliably understand commands for temperature changes.
Unless...
- The radio is playing.
- The windows are open.
- You're driving in heavy wind/rain/hail pelting the car or other driving conditions making an awful racket.
- You don't drive a super expensive car, but one designed by marketing, bean counters, and summer interns.
- Other people in the car are talking/conversing.
- Other people in the car are sleeping (long road trips aren't uncommon for many).
- You have an accent.
- You don't speak a language supported by the car maker.
- You have a speech impediment.
- You have a physical disability preventing clear or any speech.
- A software update breaks the system.
So what exactly is the benefit of moving to touch screens / voice control? I'm pretty sure physical buttons and dials don't suffer from any of those problems except for maybe physical disabilities, but at least with physical buttons/switches/dials, you or a third party could modify and/or tie into them to suit the specific needs of the disabled driver. Good luck getting the auto makers to let you modify their software for a similar purpose. I just don't see the point in moving from something that works well in the vast majority of scenarios to something that works measurably less well, with virtual no real benefit. Fine if voice control is in addition to physical, tactile interfaces, but the trend toward replacement doesn't fill me joy.
There are also architecture specific builds, so the aarch64 build won't include driver code at all for devices that are specific to x86.