HN user
I'm looking for a cheap ARM MCU with I2S support and one that I found was a Chinese part from GigaDevices which is $0.50.
On the other hand, lots of software is written for STM devices so spending a couple of bucks more for their parts will save you development costs and time.
True that. Their political system is extremely dangerous if it depends on the mental disposition of one man.
If Xi has a bad day he could start a nuclear confrontation with no one able to reign him in.
I heard U.S. officials say that it's definitely a spy-balloon. They refused to say how they know this, but I assume they have their sources.
But a balloon has to intrude in someone's airspace. Doing so could trip off an international incident, like it has now.
I'm very surprised that China would take the risk of fueling a political firestorm when these balloons are only marginally more effective than the satellites they already have.
These intrusions are clearly a violation of our airspace and could even be considered an act of war.
What the hell was Xi thinking? Is he trying to communicate that China can do whatever it wants with impunity? Did he even authorize this flight or was this someone else's decision?
Isn't Montana sparsely populated? If the Air Force can't shoot it down there good luck trying to do so over New England.
The markets have been wishing / predicting a decline in the rise of interest rates, which clearly isn't going to happen.
I've been using Firefox for twenty odd years now. It's performance is comparable to that of other browsers.
But the pilfering of Mozilla by its management (giving themselves million dollar bonuses and pretending they're managing a billion dollar corporation) and their illogical and fickle decisions has reduced IMHO the need for an independent open-source browser.
The only rationale for having a browser like Firefox now is to push back against megacorps like Google adding extensions to prop up their agenda (like preventing ad-blockers from working).
Mozilla had its day in the sun. I still use it but if it were to go away I wouldn't lose too much sleep over it.
here are abundant reasons why Google would want a non-Linux operating system internally.
You may be in the right, but I personally don't see no reason for it. Linux is the best supported operating system in the world and Google always has the option to alter the OS if need be.
I do believe Fuchsia is vastly more secure and stabler than Linux, which could be a benefit, but Google isn't exactly being pilfered by miscreants on a daily basis, so that benefit is in doubt.
I don't see why this would make the experience better. Java has been a huge part of Android's success allowing for backwards compatibility in a smooth manner. Java should also be given credit for Android's stability, due to its lack of memory safety errors.
IMHO Google shouldn't pull-back from using Java (or Kotlin). Rust could be an option but that would certainly degrade Android's developer experience.
I see Fuchsia's benefit mostly in security and stability. Linux is one big blob with potentially huge security holes in it, many of which simply haven't yet been discovered (except maybe by intelligence agencies).
Fuchsia's architecture is extremely resilient and secure by design and there's very little change culprits will be able to breach its security.
Fuchsia is one of Google's most interesting products, so these layoffs put out a huge question mark.
The company will soon have to decide how to move forward since replacing Linux will require a sizeable investment in manpower. My suggestion would be to focus on only replacing the Linux kernel whilst keeping other parts of the Android stack intact as much as feasible.
They should be able to do this in relatively short order, say two years.
Logical bugs are out of scope for any programming language.
But then you'd need to entice Tor users to turn on Javascript since it's turned off by default.
I doubt the Tor user was identified on the Tor network.
Most likely his Bitcoin donations gave him away, since Bitcoin is far from anonymous. He might also have left other clues such as an email address which he accessed from clearnet.
Anyway, it's pretty obvious LEA cannot identify Tor users en-masse. There have been several CP websites taken down which had hundreds of thousands of users, yet they only managed to arrest the website administrators. Only a handful of users were arrested, and mostly because of dumb mistakes.
Do you really need to know? All that matters is that the GC will eventually clean up the used memory. When you're interested in that sort of info you're using the wrong language or asking the wrong kind of questions.
I'm speaking from my own experience here. I've tested a couple of Rust programs which were developed in relatively short order yet were quite complex (a Minecraft type game being one) and there wasn't even the slightest hint of instability.
Some of my own Rust code is moderately complex but never showed any signs of instability during development. I often have crashes now and again with my C++ programs. Sure, I fix those afterwards but getting it flawless every time the first time is (for me at least) unheard of.
It may slow them down during their initial development when they're new to Rust, but I'm convinced that it will be much cheaper during the entire Application Lifecycle (ALM), not to mention customer satisfaction.
I believe Rust will ALWAYS be beneficial compared to MMM languages because it will save time in the long run.
Programs with Rust will always be rock-stable, unlike many C/C++ programs which are more like a house-of-cards.
I disagree. It depends on the type of project you're working on. If you're writing a public facing high-performance application it MAY be more beneficial to use deterministic memory management.
Most tools, even very technical tools like assemblers, debuggers and compilers, don't need deterministic memory management. Only operating systems, device drivers and some time-critical applications (like video/audio encoding/decoding) need deterministic memory management.
"Rust has made the decision that safety is more important than developer productivity. This is the right tradeoff to make in many situations — like building code in an OS kernel, or for memory-constrained embedded systems — but I don’t think it’s the right tradeoff in all cases, especially not in startups where velocity is crucial."
I completely disagree with this statement. If a Rust developer takes longer to code some feature this time will eventually be saved fixing memory bugs later on. And don't forget the immaterial cost of losing customer confidence if the product crashes or glitches because of memory instability.
And then I'm even glossing over the enormous benefit of Rust when writing correct multi-threaded code, which is almost always a minefield in C/C++. Code that looks and seems to work OK might in production suddenly crash after a year or so. A complete nightmare!
Memory safety is ALWAYS a good thing to have.
Memory bugs! I mean mean memory bugs.
Every project should have exactly zero (0) memory bugs. That's nigh impossible to achieve with large codebases written in C/C++ or some other unsafe language.
Chromium and FireFox are still busily fixing memory bugs twenty years after the code was written. It's a God-awful mess!
You don't know that. Life might be possible with simpler chemistry too.
Chemistry was sufficient 100 million years ago for intelligent life to evolve, so some other solar system could've easily have had intelligent life for that long or even longer if they were lucky.
Our lives have changed beyond recognition in the last 500 years. Imagine a civilization that's thousands, tens of thousands or even hundreds of thousands of years ahead of us.
Mind you that only a handful of developers worked on LadyBird and it has Javascript and CSS working.
LadyBird only needs video and WebRTC to be fully functional for day-to-day use by non-power users.
WebSockets and WebGL would be nice too, but that will take some time. Most other API's are cruft, such as WebUSB (a Google contraption that more or less ignores security).
The management team should've been fired along time ago. But they essentially hijacked Mozilla. All the trademarks and copyrights belong to the Mozilla Corporation, not the Foundation.
Management are filthy crooks, scum and carpetbaggers.
Right now they don't have a unique selling point (USP). Rust could've been that selling point but they instead focused on making divisive UI changes and adding subscriptions.
Also their crusade against taking money from Google is ill-conceived. There's simply no other source of revenue for a web browser (unless they start their own search engine, but that would be suicide since Google would immediately cut off their funding).
They should focus on building the best and most secure browser and then their market share will almost certainly improve.
I believe you're 100% wrong. There are probably hundreds if not thousands of bugs in the old code. Just because they haven't been found yet doesn't mean they're not there.
If a handful of developers at SerenityOS can write a web browser (including Javascript and CSS support) from scratch in a year or so why can't Mozilla rewrite the FireFox engine in Rust?
It also shows the poor management Mozilla has since they effectually cut-loose the Rust team and aren't investing too much in rewriting parts of FireFox in Rust.
Rust would've been a great USP for FireFox. They squandered it and now the competition is running with it. Both Google and Microsoft are all-in with Rust.
I believe Google is putting too much effort into bringing interop between C++ and Rust. Why not simply rewrite the core of Chromium in Rust?
I mean, if a handful guys at SerenityOS can write a web browser from scratch in just a few years surely Google can muster enough manpower to rewrite Chromium in Rust in a couple of years?
Interop is wasteful since there's a large discrepancy between C++ and Rust code. Trying to plug the holes will lead to an inferior product at great cost.
So there could've been civilizations that are literally BILLIONS of years ahead of us? Imagine what these people know about the universe!
This reminds me of the Star Wars lead-in: "A long long time ago in a galaxy far far away." It really could've happened you know!
Microservices are merely just another hype in the IT world.
Everyone ran with it and now we're stuck with thousands of fragile and unmaintainable systems which will ruin companies in the coming decades.