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.
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.)
It might be a Verizon S4... VZW takes bootloader-locking 'evil' to creative new heights (lows?).
Apparently, when the Note 4 came out, Verizon actually paid extra to Samsung for them to protect the Sprint version's bootloader the same way (Sprint itself was indifferent) just to make sure there wouldn't be another CDMA model with easy-to-unlock bootloader. From what I recall, the Verizon model of one of Samsung's earlier phones could be cracked by flashing a Sprint bootloader to the Verizon phone... it temporarily bricked the phone (or at least disabled the radio modem), but then you could unlock the easy-to-unlock Sprint-version bootloader & reflash it with a second bootloader that was basically a Sprint Android bootloader w/ripped Verizon radio modem firmware to give you a working, bootloader-unlocked Verizon phone. Verizon was determined to keep it from happening again.
We were well on our way towards getting it until Microsoft decided to kill off Windows Mobile for a replacement that was inferior to, and 2+ years behind, every other mobile platform at the time (instead of 5+ years ahead).
If "Windows Phone" (a/k/a Danger Sidekick OS, ported to C# & dotnet compact framework) had never existed & Samsung's latest & greatest phone today ran Hypothetical Windows Mobile 14 instead, upgrading your old Hypothetical WinMo 12 device to WinMo 14 would be like upgrading an older PC or laptop to a newer version of Windows... some new driver.dll files copied from a newer phone (or generic reference drivers downloaded from Qualcomm or Nvidia), and you'd be set.
WinMo 5 & 6 were ugly as sin out of the box, but the core OS itself was generally good, and had capabilities that were YEARS ahead of anything about to be released by Apple or Google. That's a big part of the reason why Microsoft makes about ~$14 in royalties for every new Android & Apple device sold... Android might have made the technology pretty, and Apple might have made it usable by nontechnical people, but MICROSOFT was the one who first delivered it as a working product to YEARS before an iPhone or Android was even a "thing".
Exactly. Imagine taking a snapshot of an Android device's RAM & using it to attempt reverse-engineering a running app without access to the.apk file used to install it... by reading the bare ARM assembly language of ART executing JIT-compiled.dex code from compiled Java bytecode. Without assistance from an app like Ida Pro (which is somewhere between "AI" and "black magic" to begin with), it's basically impossible. Computers can grok 700 levels of recursion & dereferencing. Humans max out after a dozen or two (usually more like 6-9 levels).
The best point of PC joysticks was when they moved the reading logic into a microcontroller running inside, but used the old SB joystick port as a MIDI-speed serial port. Near-instant response, without soaking up 5-10% of the CPU just to repeatedly poll the goddamn USB port to ask the gamepad, "do you have anything to tell me?" hundreds of times per second.
A pox on the bastards at Intel who decided USB should be 100% PIO. In theory, USB 3.0 added an IRQ line, but AFAIK, it's still generally ignored & unused by HID drivers & devices.
Another double-whammy with modern documentation: extraordinarily poor use of screen space, and no real "editing" to speak of. Like Google's Android docs, with oceans of empty whitespace around maybe 12-16 lines of actual text content, half the screen's width consumed by sidebars, and hyperlinks to hyperlinks to still-more hyperlinks (ok for reference, but awful for learning how to do something for the first time when what you *really* need is a coherent & complete start-to-finish explanation of the topic.
Believe it or not, for a brief period circa 1997, installing ActivePerl on a Windows PC enabled Perlscript as a first-class IE4 scripting language equal to Javascript & vbScript. Except its sandbox was shockingly broken, so ActiveState disabled Perlscript a few months later (though, for a few years, you could STILL enable it by inserting a key into the registry like, "I_AM_TRULY_INSANE" = 1)
I remember how unbearably slow Commodore's Macro Assembler was on a c64 prior to Epyx Fastload. It took SEVERAL MINUTES just to assemble & link about 3 screens' worth of sourcecode. I remember being in total *awe* by how much it was sped up by Epyx Fastload. With Fastload, 4 minutes of build time turned into ~10-20 seconds.
Totally agree about problem #2 (lack of info). I remember my year of frustration (circa 1991) trying to learn how to use 32-bit protected-mode assembly language on a 486DX. With the information resources I had available to me at the time, it was pretty much hopeless.
* Finding an affordable assembler that could use linear addressing and orthogonal registers? Hard.
* Finding a book that coherently explained 32-bit x86 protected mode assembly langugage? Harder.
* Finding a book that explained how to do useful things (read the keyboard, read a joystick, use VGA, etc) without having the BIOS available? Utterly and completely fucking hopeless. I now know that books about the topic DID (sort of) exist... but finding them back when it meant special-ordering expensive books sight-unseen based on nothing besides the title, author, and page count (and waiting weeks for them to arrive) was almost impossible.
Making matters worse, all the books about programming for OS/2 (which, in theory, COULD have supported things like disk i/o from protected-mode assembly) didn't even HINT that it was possible to call system routines from assembly... in stark contrast to the Amiga realm, where most books documented the register conventions alongside the C syntax). OS/2 (or at least, books about it) had such a total fetish for object-oriented programming, if you didn't understand OO, you were pretty much dead in the water and couldn't even make it to "hello world".
1. The Amiga 1000 would have shipped with a 68010 from day one. It only cost a few dollars more than a 68000, and would have ensured that 98% of all the good games that came out for the next 5 years wouldn't crash, burn, and die a horrible death on anything with a 68020+ due to the copy protection using MOVE SR, <ea>.
2. I would have BEGGED Jay Miner for a "semi-chunky" 4-bit graphics mode that used a byte per pixel, but read either the high or low nybble (set by a register bit). So you could write the low nybbles, display them, update the high nybbles, switch to them, update the low nybbles, switch to them, etc. And had a graceful update path for ECS to make it a true 8-bit mode.
3. I would have tied up the CEO of Gravis and beat him with a rubber hose until he agreed to let the engineers add a SB-compatible FM and DAC to it (for perfect compatibility with SB-only software, instead of endless fucking misery with SBOS that never really worked right). Or at least, could take a daughterboard with SB-compatible chips (so they could keep the lower price point without permanently gimping it). Or even just had a fucking 1/8" stereo jack for input from a second soundcard that got mixed 50/50 with the GUS's native audio (enabled with a jumper), so you could have both a GUS and a SBpro without having to switch cables or spend a hundred bucks on an external mixer.
4. I would have leaked the whole story of HP's CD-R design debacle to the media before they had a chance to ship (ie, HP's engineers *knew* beyond doubt that shipping a CD writer without a dedicated RAM buffer was GUARANTEED to turn at least 1 in 4 discs into a coaster, but HP's management ignored their protests).
5. I would have made an equally made a big stink in the media about PC-CHIPS's fake "WRITE-BACK cache" circa 1993 (literally, bars of plastic with metal pins soldered to the motherboard, and a BIOS that flat-out LIED about it).
Except, OS/2 needed 16mb to *really* run every winapp in its own instance of WinOS2 without slowing everything to a crawl... which, circa 1993, meant chucking the 8x1mb SIMMs you had, and spending about $700 on 4x4mb SIMMs. Been there, did it.:-(
I don't know about iOS, but using an Android app to open my garage door would drive me nuts:
* touch fingerprint sensor to unlock. 2-5 seconds.
* wait for OS to stabilize after unlock: 2-6 seconds
* launch app: 2-3 seconds if it's already running, 3-5 if the icon is on the screen you got after unlocking, 5-20+ if you have to open the app drawer and navigate to it.
* add another second or three if the phone can't make up its mind between LTE and wifi. Because, for some inane reason, Android can't deal with having multiple routes to the internet, even though Linux has been able to handle at least 253 simultaneous network connections since... well... forever. So if you catch Android in a moment of network metastability... you're going to wait.
I got a Ring doorbell for Christmas. It takes SO LONG to unlock the phone, launch Ring's app, and begin the video stream, half the time you'll be lucky to launch it in time to see whomever rang the bell walking away. And that's when I'm on the same LAN as the doorbell. If someone rings it when I'm NOT home, I'll be lucky to launch the video stream in time to see whomever rang it DRIVING AWAY. It's not totally Ring's fault... I'd argue that pretty much ANY IoT product that depends upon an Android phone that might be asleep, locked, and semi-offline the moment it gets triggered is going to have serious usability problems due to lag.
If there's an urban land shortage, what's stopping Australia from building a new freeway a kilometer or two inland along the entire east coast from Carins to Sydney, opening up tens of thousands of square kilometers of land for new development in the process?
Except, sauropod dinosaurs were probably warm-blooded, just like an ostrich, penguin, chicken, pigeon, owl, or hawk is now.
T-Rex was basically the biggest, most bad-ass ostrich the world has ever known(*). And make no mistake... an angry ostrich can fuck you up quite badly.
(*) In terms of genetic distance, T-Rex had more in common with a modern sparrow than it did with any modern reptile or amphibian.
A domain-validated cert guarantees *nothing* besides, "this cert was issued to a likely admin at $host.$domain.$tld."
The expectation is that clients (ie, web browsers) will compare the tail end of the hostname to the CN on the cert, and take appropriate action if they don't match.
They guarantee *nothing* about the identity of the site's owner, the legitimacy of their domain's ownership, or anything else.
DV certs exist because sometimes, all you care about is preventing MITM attacks to web users. Period. The onus is still on *you* to verify that login.chase.com.lucky7domainpark69.com is, in fact, the login page for your bank, and not a phisher's site. All a DV cert for that domain guarantees is that someone running a fake/compromised wifi access point can't intercept, read, or tamper with the request or response.
This is why banks pay thousands of dollars for "EV" certs. A CA issuing an EV cert IS expected to have "boots on the ground" physically verifying that the cert's applicant is who they say they are, has an office where they say they do, etc. They themselves STILL guarantee nothing about how data is secured or used after decryption.
TL/DR:
DV cert: the other party is whomever controls $(some-specific-domain).
EV cert: same as DV, but adds guarantee that they're ALSO whom they claim to be. They might STILL be evil & crooked, but at least you might conceivably hunt them down in the real world if they do something bad.
...made worse by the fact that modern graphics subsystems are basically the descendant of a 3dfx card integrated onto the most minimal dumb hardware frame buffer possible.
It's why Android tablets (even fast ones) take at least a half second to render pdf pages using a 2.5GHz 4+ core SoC, but even a ghetto $150 mid-90s video card could do it instantly on a computer running at 100MHz... the old video cards had hardware spline acceleration. Now, they use the CPU to lay out 400 million triangles, then pump them through the GPU to render them. One step forward, one step diagonally-backwards to the left.
If DHS ever expanded this to include American citizens who travel abroad and need to re-enter the US, I'd never be able to leave the country without risking prison for omitting hundreds of email addresses and website logins from the disclosure form. Why? I've used SO MANY email addresses and website logins over the years, I couldn't accurately disclose 90% of them EVEN IF I TRIED. And frankly, it would be a cold day in hell before I ever did it voluntarily, because even IF I trusted the government to act with 100% professionalism and good faith, there's always the risk some future activist hacker group might get a hold of it and ruin the lives of a few hundred million people for shits & giggles by posting it all online.
As it stands, I'm effectively trapped in the US -- unable to even visit Canada, Mexico, or the Bahamas -- because a fucking 3-day vacation would derail my life for weeks before and after the trip. At the VERY LEAST, I'd have to buy a throwaway phone and laptop, spend days configuring both, and dump them at a loss on eBay afterwards (on the likelihood that Customs & Border Control installed advanced persistent malware on one or both capable of surviving anything I could realistically do to remove them, and neither would ever be trustworthy again).
Ironically, the one website account I'd have few qualms about disclosing to them is Facebook, mainly because I use it so infrequently, and disclose so little, they'd probably think it was a throw-away burner account even though it's actually my real one.
The OTA channels generally look better than they did on DirecTV, except when there's lightning. I'm pretty sure our local CW, Fox, and ABC affiliates are broadcasting GOPs that are *way* longer than 15 frames (IBBPBBPBBPBBPBB), because noise bursts (like nearby lightning) seem to derail them and make the picture & audio fall apart for at *least* a second or two.
What ATSC *should* do is keep the same 8vsb transport layer, but allow broadcasters to use their 19.2mbps link budget to send a primary MPEG-2 stream (compatible with current standards), but use their remaining bits for one or more h.265 streams (with faster error-recovery than we have now). That way, they could launch it with a single SD h.265 stream at the tail end of each data chunk, then drop the primary stream's bitrate to 6-8mbps (using the balance for the new h.265 stream), then move the subchannels from MPEG-2 to h.265, and finally drop the legacy MPEG-2 primary stream down to SD bitrate & reallocate the bits to the primary h.265 stream (enabling 1080p60, 1536p30, 2160p24, etc... maybe even native 24, 25, 48, 50, 72, or even 100fps streams, if they can get TVs to handle on-the-fly mode changes like ATSC was *supposed* to (but apparently doesn't, since NO OTA station I'm aware of changes modes on the fly today). It would be kind of nice to be able to watch British TV shows at 720p50 or 1080p25 without telecine judder like we have now, and 720p100 is a *visible* step up from 720p60(*) (at least, when viewed side by side, 720p100 is clearly smoother).
(*) 120fps is visually indistinguishable from 100fps... the next visible step up from 100fps requires 150fps for high-contrast motion, and 200-300fps to see a difference with lower-contrast content. Since 100fps is as good as 120, we might as well go with 100 & make everyone's lives easier going forward).
I don't know about Houston, but in Miami/Ft. Lauderdale, the subchannels are all so compressed and blocky, watching them will make your eyes feel like they're going to bleed. And most of them are religious channels, Spanish channels, or shopping/infomercial channels. As of a few days ago, we only have EIGHT English-language OTA HD channels... and *maybe* 5-8 unwatchably-pixelated subchannels that aren't religious, Spanish, or home shopping.
Technically, they can. Licensing rights aren't recursive. If I buy some product that uses a licensed, patented part, then use that part to make something else, I could still be sued for infringement. Arguing that someone else already licensed it would get me nowhere.
Courts have ruled that it's not necessarily infringement to repair a broken item, but IS infringement if the repair improves it beyond its original design. I think the key case involved a knife whose handle was prone to breakage long before the blade itself. Someone bought broken knives (and eventually, brand new ones), replaced the handles, resold them, and got sued for infringement because the new handles were substantially better than the original ones.
Why aren't tractors from China that aren't encumbered by Deere IP available? What does "Deere Do" that Chinese tractors don't? Have tractors really come SO FAR in ~18 years that there's no viable US market for tractors that are built entirely from designs whose patents all expired?
I mean, do Deere tractors have some kind of semi-autonomous operation, so they can run in perfectly straight lines at precise distances and do something in 300 minutes and 40 passes that might otherwise have taken 500 minutes and 60 overlapping passes? Does their holy software provide some kind of real value to users (besides "allowing them to operate"), or is it literally just DRM?
> Microsoft and manufacturers deliberately refuse to make drivers work with windows
The problem wasn't that they deliberately broke drivers. The problem was that Microsoft didn't follow the NT HAL paradigm with TWAIN.
When NT4 came out, Microsoft had a SERIOUS problem with lack of driver support for anything that resembled an imaging device. If you wanted imaging hardware that supported NT, you were stuck paying enterprise-level prices for it. The mainstream industry basically told Microsoft, "find a way to make TWAIN work on NT, or we aren't going to support NT."
Microsoft knew manufacturers would eventually come around if they abolished non-NT Windows... but they also knew there was a chance the strategy could fail if Win2k had an imaging-driver problem as bad as NT4's, and consumers were to dig in and refuse to adopt XP. And in fact, much of the early "stuff doesn't work on Win2k" was a lingering artifact of that problem.
So, Microsoft wrapped Twain in a shell of duct tape, and made it (sort of) able to limp along under NT architecture. Basically, they made it so the vendor could re-wrap their old source in a new binary wrapper specific to a version of Windows whenever a new version of Windows came out. The problem was, only someone with the original sourcecode could do it... and lots of manufacturers either went tits-up during the first dotcom crash, or were acquired by other companies with zero interest in making even the slightest effort to support older hardware.
As a result, lots of scanners that initially didn't support NT4 or Win2k AT ALL eventually DID support Win2k. A few even got later drivers to support XP.
WDM (since Vista) has slowly brought a degree of sanity to Windows imaging drivers, but once again broke backwards compatibility as badly as before. Many scanner drivers ignored WDM (or released really, really buggy WDM drivers) and supported only TWAIN. Those are the scanners that worked under Vista, but broke under Windows 7 (which made TWAIN strictly a front-end for back-end drivers)
Now, we (finally) have vendor-supplied miniport drivers that work kind of like a SANE back-end. We're still (mostly) stuck with TWAIN as a version-specific front end, the key difference is that NOW, Microsoft releases THEIR OWN generic TWAIN driver that uses the miniport-implemented scanner driver, so old scanner drivers can at least continue to work (albeit, often with reduced functionality) under newer versions of Windows.
If the laser does its damage in a fraction of a second, 58kW is within the capability of about 30-50 car batteries. If it needs up to 5 seconds, about 100 (200, if you don't want to destroy the batteries after one or two uses. 10-20 seconds is within the capabilities of a small generator with lots of big supercapacitors in parallel (but you might need 30-90+ seconds between shots). Assuming 58kW is the INPUT power, and not the OUTPUT power.
For comparison, a good car stereo draws 500-1000 watts (RMS), which is why good car stereo == the biggest mixed/deep-cycle battery you can physically fit + upgraded alternator.
Qualcomm ships SoCs with the silicon necessary to use mobile phone networks, but charges substantial licensing fees for the radio modem FIRMWARE. And probably wouldn't allow a small company to license it anyway. Wifi, in contrast, can be implemented with a pre-certified module. The FCC test requirements for part A or B compliance are fairly tame... their requirements for "intentional generators" (like WiFi subsystems and cellular radio modems) are quite a bit more stringent & expensive to satisfy. Using a pre-certified module for a radio modem would make it too expensive AND probably too large to fit in the case.
Slashdot Mirror
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.
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.)
It might be a Verizon S4... VZW takes bootloader-locking 'evil' to creative new heights (lows?).
Apparently, when the Note 4 came out, Verizon actually paid extra to Samsung for them to protect the Sprint version's bootloader the same way (Sprint itself was indifferent) just to make sure there wouldn't be another CDMA model with easy-to-unlock bootloader. From what I recall, the Verizon model of one of Samsung's earlier phones could be cracked by flashing a Sprint bootloader to the Verizon phone... it temporarily bricked the phone (or at least disabled the radio modem), but then you could unlock the easy-to-unlock Sprint-version bootloader & reflash it with a second bootloader that was basically a Sprint Android bootloader w/ripped Verizon radio modem firmware to give you a working, bootloader-unlocked Verizon phone. Verizon was determined to keep it from happening again.
We were well on our way towards getting it until Microsoft decided to kill off Windows Mobile for a replacement that was inferior to, and 2+ years behind, every other mobile platform at the time (instead of 5+ years ahead).
If "Windows Phone" (a/k/a Danger Sidekick OS, ported to C# & dotnet compact framework) had never existed & Samsung's latest & greatest phone today ran Hypothetical Windows Mobile 14 instead, upgrading your old Hypothetical WinMo 12 device to WinMo 14 would be like upgrading an older PC or laptop to a newer version of Windows... some new driver .dll files copied from a newer phone (or generic reference drivers downloaded from Qualcomm or Nvidia), and you'd be set.
WinMo 5 & 6 were ugly as sin out of the box, but the core OS itself was generally good, and had capabilities that were YEARS ahead of anything about to be released by Apple or Google. That's a big part of the reason why Microsoft makes about ~$14 in royalties for every new Android & Apple device sold... Android might have made the technology pretty, and Apple might have made it usable by nontechnical people, but MICROSOFT was the one who first delivered it as a working product to YEARS before an iPhone or Android was even a "thing".
RIP Windows Mobile.
Exactly. Imagine taking a snapshot of an Android device's RAM & using it to attempt reverse-engineering a running app without access to the .apk file used to install it... by reading the bare ARM assembly language of ART executing JIT-compiled .dex code from compiled Java bytecode. Without assistance from an app like Ida Pro (which is somewhere between "AI" and "black magic" to begin with), it's basically impossible. Computers can grok 700 levels of recursion & dereferencing. Humans max out after a dozen or two (usually more like 6-9 levels).
The best point of PC joysticks was when they moved the reading logic into a microcontroller running inside, but used the old SB joystick port as a MIDI-speed serial port. Near-instant response, without soaking up 5-10% of the CPU just to repeatedly poll the goddamn USB port to ask the gamepad, "do you have anything to tell me?" hundreds of times per second.
A pox on the bastards at Intel who decided USB should be 100% PIO. In theory, USB 3.0 added an IRQ line, but AFAIK, it's still generally ignored & unused by HID drivers & devices.
Another double-whammy with modern documentation: extraordinarily poor use of screen space, and no real "editing" to speak of. Like Google's Android docs, with oceans of empty whitespace around maybe 12-16 lines of actual text content, half the screen's width consumed by sidebars, and hyperlinks to hyperlinks to still-more hyperlinks (ok for reference, but awful for learning how to do something for the first time when what you *really* need is a coherent & complete start-to-finish explanation of the topic.
Believe it or not, for a brief period circa 1997, installing ActivePerl on a Windows PC enabled Perlscript as a first-class IE4 scripting language equal to Javascript & vbScript. Except its sandbox was shockingly broken, so ActiveState disabled Perlscript a few months later (though, for a few years, you could STILL enable it by inserting a key into the registry like, "I_AM_TRULY_INSANE" = 1)
I remember how unbearably slow Commodore's Macro Assembler was on a c64 prior to Epyx Fastload. It took SEVERAL MINUTES just to assemble & link about 3 screens' worth of sourcecode. I remember being in total *awe* by how much it was sped up by Epyx Fastload. With Fastload, 4 minutes of build time turned into ~10-20 seconds.
Totally agree about problem #2 (lack of info). I remember my year of frustration (circa 1991) trying to learn how to use 32-bit protected-mode assembly language on a 486DX. With the information resources I had available to me at the time, it was pretty much hopeless.
* Finding an affordable assembler that could use linear addressing and orthogonal registers? Hard.
* Finding a book that coherently explained 32-bit x86 protected mode assembly langugage? Harder.
* Finding a book that explained how to do useful things (read the keyboard, read a joystick, use VGA, etc) without having the BIOS available? Utterly and completely fucking hopeless. I now know that books about the topic DID (sort of) exist... but finding them back when it meant special-ordering expensive books sight-unseen based on nothing besides the title, author, and page count (and waiting weeks for them to arrive) was almost impossible.
Making matters worse, all the books about programming for OS/2 (which, in theory, COULD have supported things like disk i/o from protected-mode assembly) didn't even HINT that it was possible to call system routines from assembly... in stark contrast to the Amiga realm, where most books documented the register conventions alongside the C syntax). OS/2 (or at least, books about it) had such a total fetish for object-oriented programming, if you didn't understand OO, you were pretty much dead in the water and couldn't even make it to "hello world".
1. The Amiga 1000 would have shipped with a 68010 from day one. It only cost a few dollars more than a 68000, and would have ensured that 98% of all the good games that came out for the next 5 years wouldn't crash, burn, and die a horrible death on anything with a 68020+ due to the copy protection using MOVE SR, <ea>.
2. I would have BEGGED Jay Miner for a "semi-chunky" 4-bit graphics mode that used a byte per pixel, but read either the high or low nybble (set by a register bit). So you could write the low nybbles, display them, update the high nybbles, switch to them, update the low nybbles, switch to them, etc. And had a graceful update path for ECS to make it a true 8-bit mode.
3. I would have tied up the CEO of Gravis and beat him with a rubber hose until he agreed to let the engineers add a SB-compatible FM and DAC to it (for perfect compatibility with SB-only software, instead of endless fucking misery with SBOS that never really worked right). Or at least, could take a daughterboard with SB-compatible chips (so they could keep the lower price point without permanently gimping it). Or even just had a fucking 1/8" stereo jack for input from a second soundcard that got mixed 50/50 with the GUS's native audio (enabled with a jumper), so you could have both a GUS and a SBpro without having to switch cables or spend a hundred bucks on an external mixer.
4. I would have leaked the whole story of HP's CD-R design debacle to the media before they had a chance to ship (ie, HP's engineers *knew* beyond doubt that shipping a CD writer without a dedicated RAM buffer was GUARANTEED to turn at least 1 in 4 discs into a coaster, but HP's management ignored their protests).
5. I would have made an equally made a big stink in the media about PC-CHIPS's fake "WRITE-BACK cache" circa 1993 (literally, bars of plastic with metal pins soldered to the motherboard, and a BIOS that flat-out LIED about it).
Except, OS/2 needed 16mb to *really* run every winapp in its own instance of WinOS2 without slowing everything to a crawl... which, circa 1993, meant chucking the 8x1mb SIMMs you had, and spending about $700 on 4x4mb SIMMs. Been there, did it. :-(
I don't know about iOS, but using an Android app to open my garage door would drive me nuts:
* touch fingerprint sensor to unlock. 2-5 seconds.
* wait for OS to stabilize after unlock: 2-6 seconds
* launch app: 2-3 seconds if it's already running, 3-5 if the icon is on the screen you got after unlocking, 5-20+ if you have to open the app drawer and navigate to it.
* add another second or three if the phone can't make up its mind between LTE and wifi. Because, for some inane reason, Android can't deal with having multiple routes to the internet, even though Linux has been able to handle at least 253 simultaneous network connections since... well... forever. So if you catch Android in a moment of network metastability... you're going to wait.
I got a Ring doorbell for Christmas. It takes SO LONG to unlock the phone, launch Ring's app, and begin the video stream, half the time you'll be lucky to launch it in time to see whomever rang the bell walking away. And that's when I'm on the same LAN as the doorbell. If someone rings it when I'm NOT home, I'll be lucky to launch the video stream in time to see whomever rang it DRIVING AWAY. It's not totally Ring's fault... I'd argue that pretty much ANY IoT product that depends upon an Android phone that might be asleep, locked, and semi-offline the moment it gets triggered is going to have serious usability problems due to lag.
If there's an urban land shortage, what's stopping Australia from building a new freeway a kilometer or two inland along the entire east coast from Carins to Sydney, opening up tens of thousands of square kilometers of land for new development in the process?
Except, sauropod dinosaurs were probably warm-blooded, just like an ostrich, penguin, chicken, pigeon, owl, or hawk is now.
T-Rex was basically the biggest, most bad-ass ostrich the world has ever known(*). And make no mistake... an angry ostrich can fuck you up quite badly.
(*) In terms of genetic distance, T-Rex had more in common with a modern sparrow than it did with any modern reptile or amphibian.
A domain-validated cert guarantees *nothing* besides, "this cert was issued to a likely admin at $host.$domain.$tld."
The expectation is that clients (ie, web browsers) will compare the tail end of the hostname to the CN on the cert, and take appropriate action if they don't match.
They guarantee *nothing* about the identity of the site's owner, the legitimacy of their domain's ownership, or anything else.
DV certs exist because sometimes, all you care about is preventing MITM attacks to web users. Period. The onus is still on *you* to verify that login.chase.com.lucky7domainpark69.com is, in fact, the login page for your bank, and not a phisher's site. All a DV cert for that domain guarantees is that someone running a fake/compromised wifi access point can't intercept, read, or tamper with the request or response.
This is why banks pay thousands of dollars for "EV" certs. A CA issuing an EV cert IS expected to have "boots on the ground" physically verifying that the cert's applicant is who they say they are, has an office where they say they do, etc. They themselves STILL guarantee nothing about how data is secured or used after decryption.
TL/DR:
DV cert: the other party is whomever controls $(some-specific-domain).
EV cert: same as DV, but adds guarantee that they're ALSO whom they claim to be. They might STILL be evil & crooked, but at least you might conceivably hunt them down in the real world if they do something bad.
...made worse by the fact that modern graphics subsystems are basically the descendant of a 3dfx card integrated onto the most minimal dumb hardware frame buffer possible.
It's why Android tablets (even fast ones) take at least a half second to render pdf pages using a 2.5GHz 4+ core SoC, but even a ghetto $150 mid-90s video card could do it instantly on a computer running at 100MHz... the old video cards had hardware spline acceleration. Now, they use the CPU to lay out 400 million triangles, then pump them through the GPU to render them. One step forward, one step diagonally-backwards to the left.
If DHS ever expanded this to include American citizens who travel abroad and need to re-enter the US, I'd never be able to leave the country without risking prison for omitting hundreds of email addresses and website logins from the disclosure form. Why? I've used SO MANY email addresses and website logins over the years, I couldn't accurately disclose 90% of them EVEN IF I TRIED. And frankly, it would be a cold day in hell before I ever did it voluntarily, because even IF I trusted the government to act with 100% professionalism and good faith, there's always the risk some future activist hacker group might get a hold of it and ruin the lives of a few hundred million people for shits & giggles by posting it all online.
As it stands, I'm effectively trapped in the US -- unable to even visit Canada, Mexico, or the Bahamas -- because a fucking 3-day vacation would derail my life for weeks before and after the trip. At the VERY LEAST, I'd have to buy a throwaway phone and laptop, spend days configuring both, and dump them at a loss on eBay afterwards (on the likelihood that Customs & Border Control installed advanced persistent malware on one or both capable of surviving anything I could realistically do to remove them, and neither would ever be trustworthy again).
Ironically, the one website account I'd have few qualms about disclosing to them is Facebook, mainly because I use it so infrequently, and disclose so little, they'd probably think it was a throw-away burner account even though it's actually my real one.
The OTA channels generally look better than they did on DirecTV, except when there's lightning. I'm pretty sure our local CW, Fox, and ABC affiliates are broadcasting GOPs that are *way* longer than 15 frames (IBBPBBPBBPBBPBB), because noise bursts (like nearby lightning) seem to derail them and make the picture & audio fall apart for at *least* a second or two.
What ATSC *should* do is keep the same 8vsb transport layer, but allow broadcasters to use their 19.2mbps link budget to send a primary MPEG-2 stream (compatible with current standards), but use their remaining bits for one or more h.265 streams (with faster error-recovery than we have now). That way, they could launch it with a single SD h.265 stream at the tail end of each data chunk, then drop the primary stream's bitrate to 6-8mbps (using the balance for the new h.265 stream), then move the subchannels from MPEG-2 to h.265, and finally drop the legacy MPEG-2 primary stream down to SD bitrate & reallocate the bits to the primary h.265 stream (enabling 1080p60, 1536p30, 2160p24, etc... maybe even native 24, 25, 48, 50, 72, or even 100fps streams, if they can get TVs to handle on-the-fly mode changes like ATSC was *supposed* to (but apparently doesn't, since NO OTA station I'm aware of changes modes on the fly today). It would be kind of nice to be able to watch British TV shows at 720p50 or 1080p25 without telecine judder like we have now, and 720p100 is a *visible* step up from 720p60(*) (at least, when viewed side by side, 720p100 is clearly smoother).
(*) 120fps is visually indistinguishable from 100fps... the next visible step up from 100fps requires 150fps for high-contrast motion, and 200-300fps to see a difference with lower-contrast content. Since 100fps is as good as 120, we might as well go with 100 & make everyone's lives easier going forward).
I don't know about Houston, but in Miami/Ft. Lauderdale, the subchannels are all so compressed and blocky, watching them will make your eyes feel like they're going to bleed. And most of them are religious channels, Spanish channels, or shopping/infomercial channels. As of a few days ago, we only have EIGHT English-language OTA HD channels... and *maybe* 5-8 unwatchably-pixelated subchannels that aren't religious, Spanish, or home shopping.
Technically, they can. Licensing rights aren't recursive. If I buy some product that uses a licensed, patented part, then use that part to make something else, I could still be sued for infringement. Arguing that someone else already licensed it would get me nowhere.
Courts have ruled that it's not necessarily infringement to repair a broken item, but IS infringement if the repair improves it beyond its original design. I think the key case involved a knife whose handle was prone to breakage long before the blade itself. Someone bought broken knives (and eventually, brand new ones), replaced the handles, resold them, and got sued for infringement because the new handles were substantially better than the original ones.
Why aren't tractors from China that aren't encumbered by Deere IP available? What does "Deere Do" that Chinese tractors don't? Have tractors really come SO FAR in ~18 years that there's no viable US market for tractors that are built entirely from designs whose patents all expired?
I mean, do Deere tractors have some kind of semi-autonomous operation, so they can run in perfectly straight lines at precise distances and do something in 300 minutes and 40 passes that might otherwise have taken 500 minutes and 60 overlapping passes? Does their holy software provide some kind of real value to users (besides "allowing them to operate"), or is it literally just DRM?
> Microsoft and manufacturers deliberately refuse to make drivers work with windows
The problem wasn't that they deliberately broke drivers. The problem was that Microsoft didn't follow the NT HAL paradigm with TWAIN.
When NT4 came out, Microsoft had a SERIOUS problem with lack of driver support for anything that resembled an imaging device. If you wanted imaging hardware that supported NT, you were stuck paying enterprise-level prices for it. The mainstream industry basically told Microsoft, "find a way to make TWAIN work on NT, or we aren't going to support NT."
Microsoft knew manufacturers would eventually come around if they abolished non-NT Windows... but they also knew there was a chance the strategy could fail if Win2k had an imaging-driver problem as bad as NT4's, and consumers were to dig in and refuse to adopt XP. And in fact, much of the early "stuff doesn't work on Win2k" was a lingering artifact of that problem.
So, Microsoft wrapped Twain in a shell of duct tape, and made it (sort of) able to limp along under NT architecture. Basically, they made it so the vendor could re-wrap their old source in a new binary wrapper specific to a version of Windows whenever a new version of Windows came out. The problem was, only someone with the original sourcecode could do it... and lots of manufacturers either went tits-up during the first dotcom crash, or were acquired by other companies with zero interest in making even the slightest effort to support older hardware.
As a result, lots of scanners that initially didn't support NT4 or Win2k AT ALL eventually DID support Win2k. A few even got later drivers to support XP.
WDM (since Vista) has slowly brought a degree of sanity to Windows imaging drivers, but once again broke backwards compatibility as badly as before. Many scanner drivers ignored WDM (or released really, really buggy WDM drivers) and supported only TWAIN. Those are the scanners that worked under Vista, but broke under Windows 7 (which made TWAIN strictly a front-end for back-end drivers)
Now, we (finally) have vendor-supplied miniport drivers that work kind of like a SANE back-end. We're still (mostly) stuck with TWAIN as a version-specific front end, the key difference is that NOW, Microsoft releases THEIR OWN generic TWAIN driver that uses the miniport-implemented scanner driver, so old scanner drivers can at least continue to work (albeit, often with reduced functionality) under newer versions of Windows.
If the laser does its damage in a fraction of a second, 58kW is within the capability of about 30-50 car batteries. If it needs up to 5 seconds, about 100 (200, if you don't want to destroy the batteries after one or two uses. 10-20 seconds is within the capabilities of a small generator with lots of big supercapacitors in parallel (but you might need 30-90+ seconds between shots). Assuming 58kW is the INPUT power, and not the OUTPUT power.
For comparison, a good car stereo draws 500-1000 watts (RMS), which is why good car stereo == the biggest mixed/deep-cycle battery you can physically fit + upgraded alternator.
Qualcomm ships SoCs with the silicon necessary to use mobile phone networks, but charges substantial licensing fees for the radio modem FIRMWARE. And probably wouldn't allow a small company to license it anyway. Wifi, in contrast, can be implemented with a pre-certified module. The FCC test requirements for part A or B compliance are fairly tame... their requirements for "intentional generators" (like WiFi subsystems and cellular radio modems) are quite a bit more stringent & expensive to satisfy. Using a pre-certified module for a radio modem would make it too expensive AND probably too large to fit in the case.