Slashdot Mirror
Samsung Blocks Ability To Remap Galaxy S8's Bixby Button (zdnet.com)
A Samsung representative confirmed today via Twitter that the company has blocked the ability for users to remap the Bixby hardware button on the Galaxy S8. For soon-to-be Galaxy S8 owners, the news will come as a disappointment, especially since the Bixby voice assistant in English has been delayed and will not be fully functional when units starting shipping later this week. ZDNet reports: XDA Developers first reported a Galaxy S8 firmware update blocked the ability to remap the button to perform a variety of tasks. Before, the button could even be remapped to launch Google Assistant. It's not clear if Samsung will ever support remapping the button. A representative for Samsung tweeted: "Can't say it will never happen, but we won't officially support."
These things are computers; where is the PC of mobile computing?
We need the freedom to program these things as we, the users, see fit. When will we finally have our freedom again?
>"Why is Samsung scared of the possibility? It's annoying."
Power corrupts and absolute power corrupts absolutely. It is almost irresistible for companies to gain the power to force their agenda on people and then NOT use that power. The only thing that keeps it in check is severe customer backlash (which rarely happens) and hacking (which the companies try to fight endlessly). Samsung is probably no worse than any other typical company. Google is certainly not immune to it- they have all kinds of artificial limitations in Android that favor their own agendas, too. Crap, even their web search page is full of it ("Oh, I see you are not using us as your default search engine." "Oh, I see you are not using Chrome..." dismiss it as much as you like, it will come right back next time or perhaps next week). As does Apple, Microsoft, Adobe, etc, etc.
So just flash another ROM into the phone and do what you want with it. How hard is that?
slashdot: A failed experiment.
The problem was they could reprogram it but the devs BLOCKED it just to be asses.
This is why i won't buy a locked-down smartphone running Android anymore. These are designed to obey their creators, not their masters, which should rightfully be the users.
The quickening pace at which we are losing control over our own devices that we presumably own is frightening
Fuck that shit.
Seconded. But this blunder is easy to undo, and Samsung has a history of responding correctly to criticism. In their own interest obviously, but just a little less arrogant than a couple of Silicon Valley operations I could mention. An example: correctly chose not to follow (courageously!) in Apple's footsteps re the stereo jack. Another example: the sdcard slot stayed. Well, we never got the removable battery back, but I understand why... just so long as it stays repairable as opposed to glued in so insanely that replacing the battery amounts to refurbishing. I will predict that, with widespread condemnation of this stupid, arrogant infringement of the right to use the thing you bought, Samsung will back down and do the right thing.
Should they wisely see the light and do the right thing, I would say that on the whole Samsung will gain trust compared to this incident never having happened. On the other hand, if they stick to their guns on this, that that's enough to flip me. In that case, fuck that shit, there are lots of good Android phones out there, and I will pick one that does not wave an attractive feature in my face then take it away.
When all you have is a hammer, every problem starts to look like a thumb.
The difference is, "desktop" Windows has historically given us compatibility with drivers written for older versions (sometimes, as old as NT4) -- imaging drivers being the one notable exception due to TWAIN's brain-dead pre-WDM architecture).
In contrast, Linux only abstracts its ABI for *applications*, not the kernel itself. For example, suppose I have a 4.10.10 kernel compiled for AMD64 using gcc, and a loadable kernel module built for that kernel. Now, suppose I have an identical computer running a 4.10.10 AMD64 kernel compiled with Visual Studio (just to give another widely-used compiler as an example). In most cases, the .ko file built for the "gcc" kernel will die a horrible death on the "Visual Studio" kernel... or possibly, even another 4.10.10 kernel compiled with gcc using slightly different options.
Basically, Linux doesn't even *try* to maintain driver binary compatibility, even within THE SAME KERNEL VERSION, while Windows bends over backwards to maintain driver compatibility more or less "forever". AFAIK, it's an ideological decision... Linux's developers *want* to punish users of binary drivers & inflict the maximum possible pain, totally ignoring the reality that end users (or at least, users of cell phones capable of doing LTE on American mobile phone networks) have ZERO influence on Qualcomm or Nvidia's licensing policies... ironically, empowering VENDORS over end users in the process.
Riddle me this: why could Linux use binary wifi drivers built for fsck'ng WINDOWS (via NDISwrapper), but can't even maintain binary compatibility between two sequential kernel releases with only minor differences? It's insane. I don't even blame Linus... I blame Google. Google has some of the best Linux kernel experts on planet earth. They could EASILY add an abstraction layer that preserved binary .ko compatibility across at least a few releases (think: a stable, open-source thunking layer that Android-certified drivers were required to use instead of directly referencing kernel structures... new release of Android? Just compile a new thunking layer for old binary drivers to use instead.)