Even if it was still a thing (and it really isn’t, imo), libimobiledevice does a decent job already, and given a little funding it shouldn’t be super hard to close the gaps and build a nice UI on top of it. But that’s not happening because very few people care about it at all.
Now, AirDrop support is a completely different beast. But it requires hardware support (promiscuous mode, iirc) that many common chipsets simply lack.
The only integrations that matter to me are Messages and notifications for phone calls, neither of which are even available on Windows AFAIK, and could just as usefully be implemented as a Web app as a native Windows app if Apple chose to do so.
Oh, and USB tethering, but in my recent experience that's harder to get working on Windows 11 than on Linux (had to find the correct driver manually on catalog.update.microsoft.com as neither Windows Update nor any of the Apple Windows apps installed it, only to have some update or other remove it without my knowledge or consent a few weeks later).
Your response and the parent sounds like the comments on DropBox thread. It is detached from reality of consumers and fails to contribute direction that can actually move the needle.
I read your comment. This doesn't expand on how dated your claim is whatsoever. Acting pissy and mysterious about your claim doesn't help either.
You literally claimed these are exclusive to Windows if not a Mac. Not only do very close to zero Mac users do this on their Mac -- do you understand we can copy and share photos and files right on the iPhone? -- on Windows the dominate way people do this is a web browser. You know, exactly the same web browser that works on basically any computer.
As a longtime iPhone user with Macs and Windows, I was legitimately confused by your weird claim of a dependency on Windows. The more comments you've made, the more certain I am that you actually have no idea what you're talking about.
It is pretty clear that you have no idea about the level of seamless integration between iPhone and Windows via iTunes, from Music to Photos and file sharing.
I have no idea how being able to share something right on the iPhone or via browser on Windows has to do with this.
Good news for you! 1.5 is in O(50) since they’re both constants! (It’s 1.50 because the author has the 58€-a-month flat rate ticket for all local and regional services in the entire country. If you buy a regular ticket, you get back 25% of the ticket price for delays over an hour and 50% for delays over two hours)
There is no implicit conversion (except to bool, but that tells you whether the optional contains a value), and operator* / operator-> throw std::bad_optional_access if it’s empty. See https://en.cppreference.com/w/cpp/utility/optional
No problem, if I caused you to fix a bug before it happened that's great. Yes, I find that reading sources I'm about to cite is often eye-opening. Our memories are not as good as we think they are, and our condensed understanding of a complex situation may have ignored something which is now crucial.
Once in a while I go down a rabbit hole, but hey, it's not as though HN isn't a rabbit hole anyway.
They were really in a pickle here. It’s easy to be snarky, but both options (no pun intended) have downsides. In short, do you choose consistency by default, or safety by default?
This feels like an easy choice in isolation, but at the time this was being developed (and arguably even now), there’s no definitive plan to holistically move C++ code to being safe by default. So whenever that happens, a ton of things will need to be dealt with, and there’s always the possibility that being an odd API here makes that overall move harder not easier. And C++ is regularly criticized for being inconsistent. Do you deepen those criticisms just so that one tiny corner of an API is better?
If I’m honest with myself, I probably would have made the same choices they did in this situation.
> If I’m honest with myself, I probably would have made the same choices they did in this situation.
Some of the more modern proposals (std::optional is quite old) actually make an explicit appeal to WG21 not to choose consistency at the price of safety because it just needlessly makes the language worse. "But we made the language worse before" is more like a plea for help than an excuse.
Barry Revzin did this in his "do expressions" which are an attempt to kludge compound expressions into C++ which really wants them to be compound statements instead. For consistency, all the obvious mistakes you'll make in do expressions could introduce UB like they would in equivalent C++ core features, but Barry argues they should be Ill-Formed instead - resulting in your mistakes not compiling rather than having undefined behaviour.
This is not the norm, as the employment modalities in that thread are super strange. If you’re employed by a German entity and your salary is 91.1k€, your take-home income would be around 53.8k€. Put another way - the $100k / 91.1k€ are the Arbeitgeberbrutto, they correspond to 75.5k€ Arbeitnehmerbrutto (the number you’d normally see on your contract). The difference exists because there are employer deductions and employee deductions, but the employer deductions don’t show up on the pay slip. Only in this constellation the employee has to pay both. It’s very much the exception, not the norm.
> If you’re employed by a German entity and your salary is 91.1k€, your take-home income would be around 53.8k€.
> Put another way - the $100k / 91.1k€ are the Arbeitgeberbrutto, they correspond to 75.5k€ Arbeitnehmerbrutto
I fully disagree. I'm talking about the Arbeitgeberbrutto as it does not make any difference for the employer if he sends the money to you or to the state/health insurance/.... He is already paying it so he would be willing to also pay it to you if he would not have to pay it to the state/health insurance/... So in my opinion it is part of the salary and I think the split into employer deductions and employee deductions just exists to make the contributions appear to be smaller than they actually are.
The post I linked just made it clear to me that salaries aren't that bad in germany compared to other states it is just that we have to pay most of it to the state/health insurance/...
As an employee, the Arbeitgeberbrutto is a number you never see. You’re not saying that employing people isn’t worth it, you’re saying that working in Germany isn’t worth it. Then you have to take the employee’s perspective, not the employer’s. Nobody advertises the true cost to the employer in other countries either. How much do all those benefits to US employees cost? Do you include that when you list US salaries, or do those get magically excluded because health insurance isn’t mandatory?
> you’re saying that working in Germany isn’t worth it.
Yes, that's my first sentence in my first comment.
My comment was not about reasoning if it is worth to employ people in germany but to state why people may prefer to work less.
> How much do all those benefits to US employees cost? Do you include that when you list US salaries, or do those get magically excluded because health insurance isn’t mandatory?
Yes, if the employer pays it it is part of the loan and should be considered if you compare the loans between different countries.
> Your premise just seems fundamentally flawed.
Okay, to be honest I just don't see how it is flawed. Also I don't have anything left to say. I just don't see why I shouldn't consider it as part of the salary as it would not make a difference to the employer to pay it to the employee instead if the employee deductions wouldn't exist.
-------
Edit:
I can't answer anymore. So I'm editing this post.
> Making an argument about how people may want to work less based on a number most have never seen [...] is a flawed argument no matter how you approach it.
Yes, that makes sense. Most employees likely won't think about how much of the Arbeitgeberbrutto is taken away.
Still I think if you know it then it reduces ones motivation and
it also has the indirect effect of reducing the Arbeitnehmerbrutto an employer is willing to pay and therefore employees may be less motivated due to a low salary.
Making an argument about how people may want to work less based on a number most have never seen or care about is a flawed argument no matter how you approach it.
Your information is quite a few years out of date. The solar learning curve has continued in the meantime, reducing the cost every year. Especially in sunny places like California, unsubsidised solar pays for itself surprisingly quickly (I don’t have the numbers for CA, but I wouldn’t be surprised if the number was 10 years).
If you enjoyed XOR filters, you might also like ribbon filters, something that I had the pleasure of working on last year. They share the basic idea of using a system of linear equations, but instead of considering 3 random positions per key, the positions to probe are narrowly concentrated along a ribbon with a typical width of 64. This makes them far more cache-efficient to construct and query.
By purposefully overloading the data structure by a few per cent and bumping those items that cannot be inserted as a result of this overloading to the next layer (making this a recursive data structure), we can achieve almost arbitrarily small space overheads: <1% is no problem for the fast configurations, and <0.1% overhead with around 50% extra runtime cost. This compares to around 10% for XOR filters and ≥ 44% for Bloom filters.
This made my day, thank you so much. :) Your explanation makes sense and it sounds brilliant/clever yet obvious. (like many good ideas are)
I'm reading the paper and looking at your github now, and look forward to "github/academia" stalking you in the future. Skimming your list of repositories and seeing a lot of stuff I understand and could possibly use. ;-)
(I find it to be a useful strategy to, when I find a clever concept in a paper, or in code on github, then look at all the other things done by the same person, or the works of people they co-author with. "collaborative filtering" for ideas.)
Indeed! Funny enough, I rewrote that article a few years ago, it previously contained an approximation of something like Algorithm L that some person with a blog came up with, having no idea that an even simpler and provably correct algorithm was published as early as 1994 :) Though others have improved the article a lot since then, adding explanations for how/why it works. Couldn't be happier to see it cited in this list!
The App Store page says "Simply take photos of an object from all angles and upload them to our service, and we will create and send you a 3D model ready for 3D printing, Augmented Reality and our web app r3Dent." so not it appears to use some kind of server-side processing. So it's not even on-device.
Now, AirDrop support is a completely different beast. But it requires hardware support (promiscuous mode, iirc) that many common chipsets simply lack.