Previously on Show HN, I made a native Mac music player app called Radiccio, which works with local files, Apple Music, Navidrome*, OpenSubsonic*, Plex, and Jellyfin. (* = new since launch)As of today, the same app also has a built-in OpenSubsonic server. Enable in settings and your local files are now streamable on the LAN. If you have Tailscale (or another mesh VPN), you can access from...
It was somewhat unexpected to find section headings such as "Is IPv6 a failure?" in the product support documentation, but I thought it was interesting and informative nonetheless.
This is a result of trying to retrofit a series of tighter security measures on top of a system that was not originally designed for them, in a way that is both understandable to users but also doesn't break back-compat with APIs (and therefore a lot of existing third-party apps that are seldom updated) too badly. I'm not saying Apple did a perfect job here, but it's a hard problem.
Yes, the problem could probably be "solved" by adding more UI, but "more UI" is not always a good solution. The more UI that exists, the less likely the user is to successfully navigate it. On the other hand, adding additional complexity to an existing UI is also fraught with potential for new bugs and edge cases. Again, not defending the status quo, but I can see how it might have ended up like this.
This is worth spending more time on trying to improve, and perhaps it is reasonable to expect better from an almost-$4tn company. But at the same time, a potential solution is far from easy or obvious, and there is a risk of making things worse if not done with an extreme level of thought and consideration.
(Alternate pessimistic take: A large number of users don't care or read anything, they just click "allow" on anything that gets in their way. A smaller set of users are terrified and disgusted by repeated invasions of the privacy and click "deny" on everything. None of these implementations are doing any good for either group. The allow/deny design pattern is badly broken and in need of rethinking.)
TLDR: Check out my Mac music player app, download the beta, and I’d love any feedback! Comment here or email [email protected] I’ve been unsatisfied with available options for music players on the Mac. Everyone focuses on mobile (I know, that’s where the money is) and it feels like there’s not as much good stuff for Mac as there used to be. Well, I’ve been using the Mac for a long...
Note that it works as either a prefix or a suffix - it might be easier to put the insertion point at the end of the text box.
If you're using Safari, you can use my Safari extension to do this with a toolbar button or keyboard shortcut: http://horizon-nigh.org/re-search/
People often look at me like I'm crazy when I tell them this. I haven't quite figured out why.
If I need to look up some personal thing in the middle of the day, I reach for my phone. If I find I've been reaching for my phone too much that day, I get up and put it on the other side of the room. Now every would-be distraction requires me to physically move my entire body.
As far as I can tell, Final is not really about reducing fraud, which, as you correctly state, is mostly a non-problem for customers. Instead, its value is in increasing my personal convenience, by reducing the annoyances the credit card companies force me to deal with as a direct result of their absurdly outdated technology.
Open it up though, and the deception ends immediately. Just your usual tacky, glossy printed brochure.
This is been public knowledge for as long as the App Store has existed: http://www.macrumors.com/2008/08/11/30-million-in-app-store-...
Jailbreakers found it almost immediately: http://forums.macrumors.com/showthread.php?t=549203
Technically, the third-party could simply make up a list of random (but valid) numbers, send them to the carrier to subscribe, and the carrier would do it. There is no technical means in place to stop this. The only thing that (in theory) stops it is the carrier noticing the high number of customer complaints and deciding not to do business with the third-party any more - a clear conflict of interest, since deciding to ignore the problem benefits the carrier financially.
What many of these services do is toe the line, by enticing a customer to give up their phone number for some completely unrelated reason, and bury somewhere in the fine print that they are signing up for a recurring charge on their phone bill. The customer has absolutely no idea that this is happening unless they read through pages of legalese. This way, the charges are technically opt-in, even though no reasonable person would describe it as such.
https://en.wikipedia.org/wiki/Cramming_(fraud)
The brain-dead simple technical solution for this is for the carrier to check with the customer before adding a charge to the bill. There is no reason not to do this.
Or maybe just get rid of for-pay SMS services altogether. In the age of smartphones they are useless.
Many of the possible actions resulting from tapping that icon (on iOS) may be unrelated social sharing (e.g., copy, save to photo library, assign to contact, etc.).
[1]: UIBarButtonSystemItemAction; https://developer.apple.com/library/ios/documentation/uikit/...
If it's stored in the same place as the encrypted password, then you have gained no security over storing it in plain text.
If it's stored in a separate system, then you have substantially increased the complexity of the system, and in general, a more complex system is harder to implement securely.
Also, an agreement Verizon signed when buying their LTE spectrum from the FCC says that all Verizon LTE devices must be carrier-unlocked out of the box[2].
However, Verizon will refuse to activate any device that was not originally sold for use on its network (they use a unique device hardware ID for this). AT&T and T-Mobile don't do this.
Therefore, for maximum flexibility, buy Verizon versions of recent Apple devices. You can then switch to AT&T or T-Mobile (not Sprint), or back again to Verizon, at any time, as many times as you wish. This is what the author did[3].
[1]: http://www.apple.com/iphone/LTE/
[2]: https://en.wikipedia.org/wiki/United_States_2008_wireless_sp...
I don't know why he lumps in AWS with Heroku. At least when I read AWS, I think of EC2, which is very similar to Linode or Digital Ocean (which he is complimentary of). I suppose there's also Elastic Beanstalk, which is more similar to Heroku, but I doubt that's what most people think of when they read 'AWS'.
> Ideally, your servers should be disposable and easily recreated. The only backups you should need are your source code (which should include any required server-setup scripts) and your database’s data.
Ugh, please don't mix server-specific setup scripts in with your app source code. Now when you want to switch from CentOS to Ubuntu, you're hosed. The server environment should be able to host your app without any modifications to the app itself, and the code that makes this environment ready to host an app should be separate from the app code, so that you can drop it into a different kind of environment at any time. This is one of the main ideas behind http://12factor.net.
Answering my own hypothetical: Mac keyboards (including the full-size 108-key models) don't have an 'insert' key, nor any key that does what you describe.
And sensible languages don't have buffer overflows, either...
> Chromebox, plus everything you need for video meetings. Starting at $999.
> includes first year's $250 management & support fee
source: https://www.google.com/intl/en/chrome/business/solutions/for...
Most large companies simply have no way to escalate a real bug report.
Unfortunately, NFSN's technology stack is so far behind the times that it's hard to use them for much of anything these days. I'm not affiliated with them, just a long time customer.