> This is the special thing about OpenSCAD design is they figured out how to build an abstract syntax tree that could either be sent to OpenCSG, CGAL (old engine), Manifold (new engine), or even the bare bones 'ThrownTogether' renderer (ancient engine on machines with no gpu that just draws 'negatives' as green blobs iirc).
Mostly.
I've still had several instances when drawing curved solids that the OpenCSG renderer worked well with (visually) but when it came to render-time, there was something wrong. It is very hard to debug things, or at least I found it so, when it goes wrong like that.
I don't know enough about supply chains to recognise whether what most of what you're saying is true or not, but "Mediatek has caught up to them on the SoC side of thing" is so laughably false that I seriously doubt the rest of what you say. The best MediaTek CPU is about 3/4 the speed of the best Apple one.
"I personally went back to Android this generation when my iPhone 13 became unusable." - perhaps you're letting your situation affect your bias...
3/4 the speed is actually very very good, given how fast iPhones are! 3/4 the speed together with much better battery and cameras is clearly better, especially since you cannot run iPhones in Desktop Mode. 3/4 the speed of the best iPhone is way more speed than 99.9% of users need.
No offense but you could have checked before accusing me of bias. Here is a summary of the benchmarks. [1]
The Dimensity 9500 scores above the A19 Pro in AnTuTu 10 and Multicore GeekBench 6. A19 Pro has better Single Core Geekbench 6 results but that only around 10%. The Dimensity 9500 GPU scores are also better but that was already the case for the previous generation.
Apple used to have a significant lead on the SoC side of things. That's over. Both Mediatek and Qualcomm are competitive nowadays.
And before people come back explaining to me that it hardly matters because the A19 Pro is more power efficient, my current Chinese phone battery is 1.5 times larger than the one in the Iphone 19 Pro Max and I have more than two full days of use between charges, which are obviously significantly faster than on the iPhone.
Yep. Spent Tesla-level cash on a Kia EV6 GT Line S AWD recently. Took my time deciding which car to buy, test drove a few cars and read lots of reviews, whenever Tesla was mentioned by the sales rep “That’s not happening”, and whenever a review had the Tesla car ranked, my eyes just went to the next one.
The number of times I might want to write something in C and have it less likely to crash absolutely dwarfs the number of times I care about that code being cross-platform.
Sure, cross-platform is desirable, if there's no cost involved, and mandatory if you actually need it, but it's a "nice to have" most of the time, not a "needs this".
As for mutex overheads, yep, that's annoying, but really, how annoying ? Modern CPUs are fast. Very very fast. Personally I'm far more likely to use an os_unfair_lock_t than a pthread_mutex_t (see the previous point) which minimizes the locking to a memory barrier, but even if locking were slow, I think I'd prefer safe.
Rust is, I'm sure, great. It's not something I'm personally interested in getting involved with, but it's not necessary for C (or even this extra header) to do everything that Rust can do, for it to be an improvement on what is available.
There's simply too much out there written in C to say "just use Rust, or Swift, or ..." - too many libraries, too many resources, too many tutorials, etc. You pays your money and takes your choice.
> As for mutex overheads, yep, that's annoying, but really, how annoying ?
For this use-case, you might not notice. ISTR, when examing the pthreads source code for some platform, that mutexes only do a context switch as a fallback, if the lock cannot be acquired.
So, for most use-cases of this header, you should not see any performance impact. You'll see some bloat, to be sure.
> There's simply too much out there written in C to say "just use Rust, or Swift, or ..." - too many libraries, too many resources, too many tutorials, etc.
There really isn't. Speaking as someone who works in JVM-land, you really can avoid C all the time if you're willing to actually try.
shrug horses for courses. I’m at that wonderful stage of life where I only code what I want to, I don’t have people telling me what to do. I’m not going to throw away decades of code investment for some principle that I don’t really care about - if I did care more, I’d probably be more invested in rust after all.
Plus, a lot of what I do is on microcontrollers with tens of kilobytes of RAM, not big-iron massively parallel servers where Java is commonly used. The vendor platform libraries are universally provided in C, so unless you want to reimplement the SPI or USB handler code, and probably write the darn rust implementation/Java virtual machine, and somehow squeeze it all in, then no, you can’t really avoid C.
Or assembler for that matter, interrupt routines often need assembly language to get latency down, and memory management (use this RAM address range because it’s “TCM” 1-clock latency, otherwise it’s 5 or 6 clocks and everything breaks…)
Yeah, there are two batteries, the one in the earbuds and the one in the container. There's no way in BLE to transmit both values - and choosing either one is lying to the user about something.
It's not uncommon (at least for me) to have a low earbud battery level (because I've just binged Slow Horses) or a low container battery (because I've just charged the earbuds from the container for the third time and drained the container). There's a suggestion above that you should "just choose the lowest one because 99% of the time that's what you're interested in", except that's not true in the second case.
I'm fairly sure that if you could report both, then Apple would report both using this hypothetical standard method, but since you can't, and there's no easy way to just "choose one" without misleading the user about something, they choose to do it properly, even though that means it's an Apple-only thing.
See my other replies in this thread — it’s totally possible to do with standard Bluetooth, yet Apple doesn’t do it. So your “fairly sure” assumption that Apple would make use of this feature if it existed seems to be wrong.
There are a surprising number of right-wing people on HN, or bots - impossible to tell from just downvotes. If anything is even remotely critical of Cheeto Benito[1], it is automatically [flagged] as well. This site is a part of the trumposphere…
1: I love the fact that autocorrect capitalises that for me!
As someone who reads the discussions for hours each day, whenever this trope "anything even remotely critical of [blah] is flagged" it seems always to actually be an example of the opposite of what it's purporting to prove.
These kinds of comments get flagged because (a) flamebait and political/ideological battle is against the guidelines and longtime users know that very well, and (b) those sentiments about particular figures have been expressed so often for so long that they're now considered completely uninteresting.
The purpose of HN is curious conversation about interesting topics, in which we hope to learn something new. Saying the same critical things about the same people year after year is antithetical to that, and is not the kind of thing people value HN for, even if they've agreed with the sentiment for years. People who are comfortable with their views about the world don't need to say – or read – the same things over and over.
Calling a spade a spade, while quite repetitive, is pertinent. The business and social environment needed to work in the field and more importantly start or maintain businesses in the field is inherently political. Politics ebbs and flows or a long time scale and the current trends really suck for most groups.
People who are comfortable with their views could and often are full of shit. Reality happens independent of one’s viewpoint.
The purpose of HN is to increase the gloss on Y Combinator, increase the allure of startups and get some more business heading their way. Any altruism is merely the price they pay for marketing.
The purpose of HN is to be interesting, and to gratify intellectual curiosity.
That's it. There's no need for any secret corporate or political agenda. HN is most valuable and useful to YC if it just attracts an audience of people who are intellectually curious, because those are the kinds of people who are interested in learning about new things, including new technologies and companies.
Given that, the most counterproductive thing we could do is alienate more than half our potential audience by promoting/tolerating views that they find abhorrent.
It also means our audience isn't easily deceived, because the most intellectually curious people are hard to bullshit, pretty much by definition. And this is the thing you learn quickly as a moderator here: even if you ever wanted to get away with any kind of deception of the audience, you soon find you wouldn't be able to, because people are so quick to notice and point it out if anything seems a bit off.
My greatest hope for HN is that if we could somehow keep raising the bar of intellectual curiosity, maybe we could yield new ideas that might help to break the world out of the stupid politics that seems to prevail these days. Hopelessly idealistic perhaps, but we all need something to dream about.
Repetition of the same old rhetoric, day after day, year after year, doesn't get us anywhere, other than making this place boring and miserable. By all means, criticise powerful figures and institutions. Sure, let's talk about the ways "current trends really suck for most groups" – we talk about that a lot here. But an argument only really belongs on HN if it gives us something new to think about.
Atari 8-bit basic used something pretty similar to this [1], except it did have normalization. It only had 10 BCD digits (5 bytes) and 2 digits (1 byte) for exponent, so more of a DEC48 but still… That was a loooong time ago…
It was slightly more logical to use BCD on the 6502 because it had a BCD maths mode [2], so primitive machine opcodes (ADC, SBC) could understand BCD and preserve carry, zero etc flags
Those figures seem rather low for one of the larger platforms on the planet.
reply