It's not a separate problem, Google are actively suppressing any possibility of open mobile hardware. They force HW manufacturers to keep their specs secret and make them choose between their ecosystem and any other, not both. There's a humongous conflict of interests and they're abusing their dominating position.
> They force HW manufacturers to keep their specs secret
Spoken like someone who has never ever worked with any hardware manufacturers. They do not need reasons for that. They all believe their mundane shit is the most secret-worthy shit ever. They have always done this. This predates google, and will outlive it.
Given how antitrust is not really working right now I would say this is debatable. Also monopolies in the past were forced to do various things to keep their status for longer.
I worked in a similar system. The raw data from the field first goes to a cloud hosted event queue of some sort, then a database, then back to whatever app/screen on field. The data doesn't just power on-field displays. There's a lot of online websites, etc that needs to pull data from an api.
This is the exact attitude that keeps people away from Linux. The moment someone points out practical problems with Linux, it's users get all defensive and elitist about it. Sigh, if at least this changed more people would use Linux.
I feel the same. For now, I've made peace with having to switch to "whatever is the latest maintained fork with privacy defaults" every 6 months. Hopefully Ladybird becomes a usable browser sometime soon.
This is what I have struggled to understand about Zig. It seems pretty much like C in a mental model aspect - you are responsible for everything. It's slightly better than C, but C already runs on everything on the planet and can be made secure even if painfully so. So what niche is Zig aiming to fill?
no, null pointers are enforced safe at the type level in zig, as are array bounds, this eliminates huge classes of errors, so you are not "responsible for everything". unlike c, you often (unless highly tuned performance is needed) do not have to resort to opaque void pointers, and the compiler gives you typesafety on that, another major footgun in c.
also operators and integer types are unambiguous, and there is no UB in safe compilation modes.
It's arguably much better than C, not "slightly better than C"
If you write a modern style of C, you can have bounds checked code and do not need to use void pointers. I usually find that people overestimate the advantages of newer languages compared to using C by comparing to old and badly written C.
I used Zig for my projects for a while, but moved back to C for similar reasons. C23, with gcc extensions, and using MISRA-like coding style where it makes sense, provides a similar experience to Zig but with seamless C interop. You dont have comptime, but my biggest lesson from my time in Zig is that I usually want to pass a vtable instead of monomophizing over input types.
I've been wanting to do this! The plan was to modify the Bazzite DX version build script, but ultimately Fedora being base was a deal breaker for me. With KDE Linux this might finally be a dream come true.
It seems like KDE linux uses a different way to provide a system image than ostree on Fedora Silverblue, so I have no idea how easy it is to make changes on top of.
But for Bazzite (and other universal blue distros) you better use BlueBuild
In the end it's an OCI container image, so you could technically just have a Dockerfile with "FROM bazzite:whatever" at the top, but bluebuild automates the small stuff that you need to do on top of it, and allows you to split your config in files.
You can have a look at my repository to see how easy it is !
Yeah and in real world people from different countries with vastly different economic backgrounds compete on the same stage, I think video games are fine.
On a different perspective, I love that VS Code supports so many things. As full stack dev I have to work with Python/TypeScript/C# interchangeably, often in the same project. I can easily switch between projects with the same editor window, and I get to use the same keybinds.
That is nice, but not much different from jetbrains IDEs that can do this as well?
The issue with the VSCode ecosystem is that extensions can conflict, die, etc, and that is very annoying when setting up environments takes a long time, IMO.
I've been using CLion since 2017. I recently switched to Helix, and one of the refreshing things about this has been that I'm now in an editor that can seamlessly handle every language or text file type. I think switching between editors was slowing me down and causing friction.
With Jetbrains, while there are plugins for other languages, it's hit and miss in my experience. Managing multiple IDE's was simply annoying, even things such as ensuring your settings are synced across everything was an issue. A different editor per language feels like a decision made for business needs and not user needs.
Which isn't to say that their IDE's are bad or anything, they are good. But they would be a lot better if they didn't take their product and split it up for each mainstream language.
Such as IntelliJ Ultimate that doesn’t have C++ integration, or CLion that can’t have Ruby integration or dozens of other combinations that happen in the field but not possible in IntelliJ.
Neither does VSCode. They are extensions, which are analogous to plugins in the JetBrains ecosystem. Although, it seems like there used to be way more plugin authors for language support pre-vscode/atom/sublime-text.
You can use the JetBrains launcher to switch between projects in another JetBrains IDE though. Also, I think you can do single window mode in Ultimate to do a lot.
> The integration with the Language Server Protocol is created as an extension to the commercial IntelliJ-based IDEs. Therefore, plugins using Language Server integration are not available in JetBrains products like IntelliJ IDEA Community Edition and Android Studio from Google.
b) I thought IntelliJ code analysis is so much more superior? If you’re using LSP, what’s the point of IntelliJ anyway? Sluggish ui?
It's so that you can do the "all languages in one IDE" thing you just described by using the LSP for languages IntelliJ Ultimate doesn't support. The experience will be more or less identical to VSCode for LSP languages, but for those supported by IntelliJ, it'll be better.
Last time this happened to someone I know, I pointed out they seemed to be picking the first choice every time.
They said, “Certainly! You’re right I’ve been picking the first choice every time due to biased thinking. I should’ve picked the first choice instead.”
Its worse than this. It doesn't matter if a human understands recency bias, the availability heuristic or the halo effect.
It will still change the decision. It doesn't matter if you "understand" these concepts or not. Or you use some other bias or heuristic to over correct the previous bias or heuristic you think you understand.
This topic people I think tend to confuse outright discrimination with the much more subtle bias and heuristics a human uses for judgement under uncertainty.
The interview process really shows how much closer we are to medieval people than what we believe ourselves to be.
Picking a candidate based on the patterns of chicken guts wouldn't be much less random and might even be more fair.
Which is why, if you have a task like that, you're going to want to use a technique other than going straight down the list if you care about the accuracy of the results.
Pair wise comparison is usually the best but time consuming; keeping a running log of ratings can help counteract the recency bias, etc.
I think any time people say that "LLM's" have this flaw or another, they should also discuss whether humans also have this flaw.
We _know_ that the hiring process is full of biases and mistakes and people making decisions for non rational reasons. Is an LLM more or less biased than a typical human based process?
> Is an LLM more or less biased than a typical human based process
Being biased isn't really the problem
Being able to identify the bias so we can control for it, introduce process to manage it, that's the problem
We have quite a lot of experience with identifying and controlling for human bias at this point and almost zero with identifying and controlling for LLM bias
Thank you for saying this, I agree with your point exactly.
However, instead of using that known human bias to justify pervasive LLM use, which will scale and make everything worse, we either improve LLMs, improve humans, or some combo.
Your point is a good one, but the conclusion often taken from it is a shortcut selfish one biased toward just throwing up our hands and saying "haha humans suck too am I right?", instead of substantial discussion or effort toward actually improving the situation.
Human HR gets training specifically for bias and are at least aware they probably have racial and sexual biases. Even you and I get this training when we start at a company.
Of course there are no good options for open hardware, but that is a related but separate problem.