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?
I'm upgrading soon from an S5 - I wonder if I should get a 7 while I still can and then wait to see what they do next instead of getting the 8.
A thousand pounds of wood moving at 300 feet per minute. Don't get in the way.
No reason to ever buy a Galaxy S8, then.
Fuck that shit.
You can tell how powerful someone is by the magnitude of the crime they can commit and be able to get away with.
...and their comment was certainly snarky; but...
WHAT IS UP WITH YOU PEOPLE?!?!?
Do you whine that you can't reprogram the Play and Stop buttons on your DVD Player?
Do you whine that you can't make the Stop button on you microwave oven launch Spotify?
Just because something has a microcontroller doesn't make it a general purpose computer.
It's an EMBEDDED DEVICE, get the fuck over it.
So just flash another ROM into the phone and do what you want with it. How hard is that?
slashdot: A failed experiment.
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
Perhaps that's why they disabled the Bixby button.
if you can find a ROM that supports the S8's radio. WiFi, hardware accelerated graphics, GPS, etc, etc. Difficultly: The S8 Just launched.
Phones aren't like windows PCs. You can't just go to Samsung's website and pull drivers down. For a flagship like the S8 you probably will be able to find a ROM before long though. Try that with a cheaper phone like an LG D415 or Blu R1 HD...
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Not only has it always required binary blobs and Android, but Google routinely dragged its feet in releasing the latest updates to the Open Source "community".
Requiring binary blobs is pretty much the status quo in the PC market too, there are very few fully open source PCs and of course there are also very few fully open source phones. That isn't to say many people haven't tried but it's hard to develop and fund something that nobody wants.
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.)
Guess someone was able to remap the Bixby button on demo S8 unit in Best Buy. So it isn't that Samsung blocked it from the beginning , they explicitly removed right before launch which is d-bag move.
http://www.androidauthority.co...
Do they have approval from the Bixby family to use that designation?
Also the Hulk reference to the Bixby button is closer than you may first guess, Bill Bixby was one actor in the TV series The Incredible Hulk.
Push the Bixby button - get Lou Ferrigno to show up in green.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
You are mistaken. The monthly payments are necessary in order to keep your legs nice and healthy. The corporations can't be held responsible if you stop paying and something just happens to occur...
Sleep your way to a whiter smile...date a dentist!
/wankery
I agree with you on the way the instability of the kernel ABI has an effect on binary drivers but even then there is a solution in the form of compiling a kernel module to load the binary driver - which is what nVidia (and others) do with their binary drivers. Of course doing that requires a compiler and kernel headers which Android may not provide and it might not be practical to do so.
Google could enforce all of this through their licensing of Android in the way they enforce having their apps installed with Google Play Services...but they don't and it's in the interest of OEMs to get people to buy a new device rather than maintain older ones especially when the margins aren't particularly large.
My point was only that the binary blob requirement has, for the most part, always been there whether it's Linux on the PC or Linux on the smartphone.
Another major annoyance: no Android phones -- not even NEXUS phones -- allow you to use the stock rom as a STARTING POINT for further modifications (by furnishing a build script with complete source and any binary blobs required to build the stock ROM). Instead, you're forced to throw the baby out with the bathwater, and reimplement the phone's functionality in its entirety (since AOSP itself usually has major stock features missing, even for a Nexus).
For YEARS, I've been wanting to make a slightly-modified kernel that acts like you have the display orientation set to "manual", BUT reads the accelerometer and sets the orientation ONE TIME immediately after the user toggles the display off and on by pressing the power button twice. Basically, offering a compromise between "auto" and "manual" -- "semi-automatic". Toggling the power button twice is a quick & easy gesture, and IMHO setting the orientation immediately (but ONLY) after turning on the display is just common sense. It blows my mind that anyone at Google thinks the way auto-orientation has worked ever since we lost slide-out keyboards is actually acceptable. At the very least, Google's auto-orientation-setting routine should have enough logic to notice the user violently rotating the phone (and maybe listen for an angry "God DAMN it!") in the immediate aftermath of an auto-orientation change... especially when the phone's display is angled downwards (ie, the user is lying in bed holding the phone above his face).
I'd also love to implement what I call "CrashCam Mode" -- Crash, as in "you see a jet about to crash (or some other newsworthy event, like a police officer beating the crap out of a 95 year old woman in a wheelchair) and only have a second or two before it'll be too late to film the million-dollar video for CNN". Basically, if the user presses the power button four+ times within 400ms, instantly disable autofocus, set focus it to infinity, and start capturing video at the maximum resolution and framerate while launching the camera app itself. For good measure, if the camera supported 120fps, you could have the odd frames be set to some exposure suitable for either indoor lighting or morning/late-afternoon daylight, then alternate the even frames between under-exposed and over-exposed (to ensure that you'd end up with at least 30fps of usable video if the lighting were really dark or bright).
Oh... and I'd also remove the 911 emergency-dialer-without-unlock that seems to be the new norm, and make it impossible for the dialer screen to activate unless I've either fingerprint-unlocked the phone, or done a complex gesture like the Donut/Eclair/Froyo-era "deliberately slide the dot along a precise arc to unlock". Frankly, I'm more likely to die from an aneurysm in a moment of rage after hearing DTMF tones coming from my pocket (when the phone is SUPPOSED to be locked) than I am to die because some random onlooker couldn't use my phone (instead of their own) to call 911.
We will see soon.
Oh, I was aware that Bill Bixby played David Banner on that show. Thanks for getting it.
> Seemed to contradict yourself there, son.
Not really. There's no contradiction between, "they have the institutional knowledge and resources to do it" and "Google's management isn't interested in dedicating their best senior developers for several months to take leadership of Android's binary kernel-driver problem".
The fact is, if it weren't for Android, Linux's device driver issues would be mostly irrelevant, because they'd meaningfully affect *maybe* a few thousand actual users. Google is the entire reason why roughly 97% of the Linux-running devices on earth actually RUN Linux, and it's high time they took responsibility and assumed leadership for fixing its driver and bootloading mess for the sake of Android's own users. Because god knows, there just about the only ones in a position to actually DO it. Gnu would rather have everyone rot in Tivo-ized hardware hell for all eternity than concede defeat to Qualcomm for the sake of empowering end users to make the best of a situation with only bad and worse alternatives.
The biggest single problem with Android phones and tablets is the fact that, with the POSSIBLE exception of Intel-based Chinese devices capable of dual-booting Windows and Android, there's no direct equivalent to a PC BIOS (and even with dual-boot devices, it's iffy). On a PC, there are well-defined universal standards for making an operating system bootable from fixed and removable storage media that have evolved in compatible ways since the 1980s. Everyone agrees upon where the boot sector goes, where in RAM it should be loaded, and how it should be interpreted during the first moments after powering on the device. With Android devices, there's no such thing... every single vendor does it differently, and most of them take advantage of the opportunity to lock down the device and exercise control the owner's experience long after its purchase by the end user.
OK, fine. Try this: name one real phone available for purchase today by end users with the following features:
* full-speed compatibility with at least one American phone network. This is a hard one, because thanks to bastardized American LTE, even our nominally-GSM carriers have become as de-facto proprietary as Sprint & Verizon.
* 2GHz+ CPU, 3+ gigs of RAM, and 64+ gigs of fast flash. Bonus points for microSD, removable battery, and/or the ability to charge quickly.
* 2160x1440 or better display.
* Released with all the sourcecode, build scripts, and documentation necessary for knowledgeable end users to independently implement support for later releases of Android, even without the active blessing or cooperation of the vendor.
The problem isn't that Linux EVER breaks binary compatibility... it's the fact that it routinely and casually breaks binary compatibility up, down, left, right, diagonally, and with "three snaps in 'Z' formation" with every single new build (let alone version).
The fact is, end users are powerless to exert any kind of meaningful market influence or economic pressure over Qualcomm, because they have a de-facto monopoly over American LTE. If you want full-speed LTE on an American network, it's basically "Qualcomm or nothing". At least if we had some degree of meaningful binary kernel module compatibility, we could limp along with the original binary drivers when a new version of Android gets released and the phone's manufacturer has abandoned it because it's no longer a current model.
Nice legs you have. You wouldn't want something bad to happen to them, right?