538 karma · joined May 3, 2024
There's an exception for banking apps
> Apps that have a verifiable core purpose facilitating financial-transactions involving financially regulated instruments (for example, dedicated banking, dedicated digital wallets) may obtain broad visibility into installed apps solely for security-based purposes.
But HSBC app declares "<uses-permission android:name="android.permission.QUERY_ALL_PACKAGES"/>" permission, which requires an explicit approval (https://support.google.com/googleplay/android-developer/answ...) but
> Apps that have a verifiable core purpose facilitating financial-transactions involving financially regulated instruments (for example, dedicated banking, dedicated digital wallets) may obtain broad visibility into installed apps solely for security-based purposes.
The other way around — make it clear that the devices are capable of showing ads, and provide instructions on how to opt-in to them (and no cookie-like prompts either)
- there's no touch feedback (ripple) on many of clickable components. Some that do have it look non-native, inconsistent and sometimes gets stuck
- the search bar on top app bar in `search` tab looks very non-native and non-standard (it's elevated on top of elevated app bar already)
- the lists look iOS-y, especially settings
- the settings list item has weird glitch where it loses background after touching (but not clicking)
- collapsing comments is pretty choppy (on a Samsung S25 so a pretty powerful phone)
- can't swipe down a bottom sheet (with post options/actions)
- it's just not android-y — the navigation is weird, the design is all over the place,
It's not unusable and it's a good tradeoff for a small team I guess. But this is nowhere near the experience a native app can provide, and has lots of small papercuts that would make for at least a slightly frustrating experience. It is a decent app don't get me wrong, but it's clearly not native
There's some jump from _a property exists_ to _it must be used_, but a massive one from _a property exists_ to _Apple uses it everywhere and we never notice it because they are done well_.
On mobile the webview app experience is crap and it's immediately obvious that an app is not native. Simply nobody asks customers how they like it. The management assumes that as long as nobody complains and the users don't leave in droves, the experience must be impeccable.
> We've been continuing to backport bugfixs to the 1.7.x series just for Heroku, but unless Heroku joins Ruby Together I don't have enough time available to make sure that continues to happen.
but OP claims it
> was interpreted as leveraging his control over Bundler as a pay-to-play scheme
I'm sorry but not supporting outdated versions of an open-source tool for a business is perfectly reasonable.
Similarly, [2] was again is described as "was interpreted at the time as indicating the feature would be withheld from Bundler because Heroku had failed to pay Ruby Together.". This is not at all how I read it — the comment just says that the open source project has priorities and not all of them can be implemented given the level of funding it has.
These are just two examples, but the article is riddled with wording like "blatant copying", "brazenly hypocritical", "was interpreted as [a bad thing]" etc.
I just feel like reading a clearly lopsided political piece intended to incite negative emotions towards something/someone. There are just enough facts to make it sound fact-based, but enough of author's own feelings and interpretation that I'm not at all convinced.
In fact, towards the end the author even states that there's been ~6 years where nothing of note happened, before the current drama. That seems like a relatively healthy situation?
[1] https://github.com/heroku/heroku-buildpack-ruby/pull/385/com... [2] https://github.com/rubygems/rubygems/issues/1811#issuecommen...
Do you mean "right now" as in _now that they hijacked the Github repositories and locked out the previous owners_, or "right now" as in _for some time now, since they've been funding some Ruby work_?
Port tests, run them against unported code. Port code, run it against unported tests? That way you also verify that the public api hasn't changed
I think this supports precisely my point — in EU all the fees are presented such that you can get the service without any hidden costs
Sure you will have upsells but if a price for a service is presented, that should be a final price. You can't tack on "resort fees", the price presented must be inclusive of all the required charges. For example as much as I dislike Booking.com, the price they show for a room includes everything — tax, mandatory cleaning fee and city tax if applicable.
I guess words don't don't have meaning anymore, how can you claim to have an open system in an announcement about closing it down?
It's also telling that the big supporters of this are apparently corporations and governments. Admittedly I don't know what "Developer's Alliance" is but they don't seem to care about developers very much, and I wouldn't surprised if they were just a "pay us to say what you're doing is good for devs" kind of thing
``` val arr = ... val result = arr .let { column(it, "tags") .let { merge(it) } .let { unique(it) } .let { values(it) } ```
You add function references for single-argument functions too:
``` arr.let(::unique) // or (List<>::unique), depends on the function ```
all without adding a special language construct.
I've used Msty but it seems like LM studio is moving faster, which is kind of important in this space. For example Msty still doesn't support MCP
> we plan to end the year with a global workforce of about 75,000 employees as a result of workforce reductions and attrition
so it looks like the explicit reduction might be lower, but accounting for people leaving on their own, the final amount of employees should be ~75k
- the wifi module and temperature sensor are right next to each other, which was causing the unit to read temperature 2-3 celcius higher than actual due to wifi sensor heat (measured by another temperature sensor on the other side of the unit). This was fixed in a software update, but seems like poor design
- it looks like the original wifi module uses a lot of power, at least according to the app readings. Didn't verify this one, but it tracks with how much it heats up even if the unit is completely off
- no way to connect an external temperature sensor, so even with a software fix to the temperature sensor reading, my room is consistently 2-3 degree celcius colder than the set temperature
- there are no release notes for the official firmware updates so you never know what can break if you update (but an update did fix the wifi module heating issue)
- the (new) app had power usage data for the past couple of years. Now they decided to only store a year? Or maybe just deleted the old data. Either way, now it's lost without any notice or way to archive it
---
That said, how likely is it that Faikin causes a hardware failure in an indoor or outdoor unit in case of a software bug? I'll definitely try it but I'm a bit uneasy with an open source software designed for what seems like a massive range of devices, and no way for the maintainers to accurately test against each one
It's important to note that pretty much nobody used the visual designer though. The resulting xml was pretty terrible, writing the UIs manually (in xmls, while looking at preview) was infinitely better