Win98/SE was the first version to support USB in general, but later updates to 95 & 98 added support for USB mice.
I believe that in theory, a highly-motivated vendor with lots of resources *could* have independently released their own drivers for Win95OSR2 & non-SE Win98, but the miniport.dll files almost everyone depends upon only came with 98SE. It's hard enough to do when you HAVE them, and damn-near impossible to do without them. I remember Linux struggled with USB performance for *years* (lots of things "worked" without needing drivers, but few devices worked really *well* compared to their non-USB variants).
And bring Android's management of short-term heap space up to at least where Java was 15 years ago.
Seriously. Android DOES NOT deal well with apps that promiscuously create lots of transient objects that fall out of scope almost immediately after creation. Java itself has, since at least 1.4 (circa 2001).
With Android, you basically have to create your OWN pseudo-heap using object pools (and write your classes so they can be restored to 'new' condition). Otherwise, Android's braindead "stop the world" GC will repeatedly halt the entire phone (UI included) until it finishes with garbage collection.
In Java, object pools are (rightfully) used for objects that are time-consuming to CREATE (like Oracle SQL connections). Android ends up forcing you to use them for objects that simply need lots of transient ram. It's a major reason why OpenGL can't easily be wrapped with "nice" Java classes to make it behave in a more OO manner... the GC penalty would *destroy* the app's performance.
They don't even need to do full-blown a-la-carte... they could just offer their mid & top-tier packages for $20-25/month less without losing a cent by making ESPN, the regional sports networks, and local OTA channels optional & passing along their actual savings to customers who exclude them. I have a perfectly good antenna & HDHomeRun (and would get a Cablecard-compatible HDHR-Prime if I got cable) with Windows Media Center as my DVR, so there's no reason I should have to pay an extra $5-10/month just so I can get my local channels from the same coax cable as CNN & Comedy Central.
Wow, you probably remember the area when it was still fairly undeveloped. You'd be shocked by how built-up the area around Pembroke Lakes Mall is now. I remember driving there sometime around 1994 & thinking I'd gotten off at the wrong exit, because there was *literal* wilderness on both sides of Pines Blvd for the first mile east of I-75. Let's just say it looks very, very different now.;-)
Why, exactly, should the user of a company laptop who travels for business *not* be allowed to boot Linux from his own USB drive when he's in his hotel room at night? Almost all companies encrypt their drives with Bitlocker, so it's not like there's a real risk of company data being compromised by malware... without the key, it's *impossible* for malware running under an externally-booted OS to read the decrypted data or write subtle changes to the company's boot drive (at worst, it might render it unbootable until the OS gets reinstalled).
Back when I traveled a lot for business trips, I just bought a drive & drive caddy on ebay for my company-issued Dell D600, and swapped in *my* drive when I was in the hotel room or on the plane. IMHO, it was win-win for everyone... for all intents and purposes, I was traveling with two de-facto different computers whose OSes never directly crossed paths, because they were never in the computer simultaneously. My stuff never went anywhere near the company's HD, or endangered the sanctity of its data. If I'd been forced to take my own laptop too, you can *bet* the company's laptop would have been the one at risk of theft/breakage in my checked baggage...
Is dual-booting even *viable* anymore? I did it for years, but sometime around Windows 7, Windows just became too damn hostile to dual-boot... as in, every time I booted into Windows after running Linux, Windows insisted on taking a sidetrip to analyze/fix its ACLs that could take anywhere between 30 seconds and 3 days to complete (usually, 2-7 minutes).
The sad truth is, if you have files larger than 4 gigs, there really *isn't* a filesystem anymore that's natively and robustly supported by both Windows and Linux that both can safely share and use directly. Using ext2/3 with Windows is almost data-suicidal, Linux pretends exFAT doesn't exist, and Windows throws a tantrum if some other OS touches a NTFS partition it regards as its own (not to mention, Windows imposes requirements on NTFS that NTFS *itself* doesn't... it's *really* easy to accidentally get a NTFS filesystem into a state that works fine in Linux, but causes Windows to throw a tantrum (max path length, allowable characters in filenames, etc.).
For a quick & easy example, dual-boot into Linux, and back up your Windows c: drive to a tarball. Now untar it into a path like '/oldWinC', boot into Windows, and try to access those files. Windows will bitch about path length, because its IE cache files max out the allowable path, and restoring them to a subdirectory instead of '/' causes the limit to be exceeded.
And here in South Florida, our malls are generally doing quite well. There are several reasons why:
* The weather sucks outside. Our seasons are Summer, Sauna, Raintorrent, and January. Open-air "lifestyle centers" might do well in California (where it's moderately warm and relatively dry most of the time), but they aren't nearly as appealing in Florida. Sure, high school students on dates might still prefer lifestyle centers on Friday night, but on a hot, steamy, thunderstorm-soaked Saturday afternoon, people who are actually going to shop & spend money want an indoor mall with air conditioning. And when it's raining, a garage (so they can get inside without getting soaked).
* There isn't much true greenfield LEFT in South Florida for sprawling new malls. As of today, there's basically one significant greenfield site suitable for a regional mall remaining in the entirety of urban Dade & Broward County (by I-75 at the Turnpike Extension, which is kind of a weird donut hole surrounded by wall-to-wall development on 3 sides, and limestone mines on the fourth).
* Cities will concede almost ANYTHING to developers to protect their sales-tax cash cow from newer, bigger malls in some nearby municipality... especially if that municipality is on the other side of the county line. I have no doubt that the cities of Sunrise & Pembroke Pines, plus Broward County, will grant just about any request made by the owners of Sawgrass Mills and Pembroke Lakes Mall in the name of protecting their sales tax revenue from American Dream Mall (a few hundred feet on the wrong side of the county line).
* The developers of the last real wave of "big, new regional malls in previously-undeveloped greenfields" in the 80s and 90s were smart enough to leave themselves plenty of room to radically grow in the future (mostly, by replacing their original sprawling parking lots with multi-story garages and new wings).
* There's a certain point where a mall can actually become TOO BIG to be appealing to anyone besides tourists. Malls like Galleria (Fort Lauderdale) and Dadeland (Miami) do well because they have lots of wealthy people living nearby and are relatively convenient to shop at. Malls like International Mall (Doral), Pembroke Lakes Mall (Pembroke Pines), and Broward Mall (Plantation) fall into the niche of "big enough to have what you want, but small enough to be reasonably efficient to shop at if you already know what you want & just need to get to the store and buy it. In contrast, I *might* go to Aventura or Sawgrass Mills once or twice a year, because it's normally just too much of a time-consuming pain in the ass to shop at those two malls (in fact, the last time I went to either mall was SPECIFICALLY because I wanted some game at Gamestop that was only in stock at those two malls).
Exactly. We now have 240ppi+ displays, but it's still basically impossible to buy a tablet with 14-16" 3840x2580 3:2 that weighs less than a pound (more than a pound, and it just becomes too heavily to hold open for extended periods of time) AND is fast enough to complete a pageflip in 150ms or less, or flip to some arbitrary page-pair in 250ms or less.
Tech books NEED 2-up layout, because they frequently have a diagram on one page, with explanatory text on the facing page. Attempting to read a book like that one page at a time is a miserable use experience.
IMHO, the MINIMUM specs for a tolerable ebook reader for tech books is something like the Chuwi Hi12... and it's *barely* fast enough to be tolerable. Anything less is just plain unacceptable. And tech support for Chuwi is a bit... difficult... unless you're fluent in Mandarin. A Surface Pro w/largest display would be better... but they're too expensive to use for JUST ebook-reading, and not quite good enough to use as your "real, one & only" computer.
If you can meaningfully compact *anything* that's encrypted, the encryption was improperly implemented. You *always* want to compact files prior to encryption, and a well-encrypted compressed file should be statistically indistinguishable from random noise.
Plus, a transplanted *head* might end up paralyzed from the neck down in its donor body, but at least the patient might have working eyesight & facial muscles. Transplant a brain alone, and the patient doesn't even get to have *that* as a 'Plan B' consolation.
Another possibility is that at best, you'd be resurrecting a zombie whose brain effectively had its programming erased when it died (or, perhaps, would be like a Sandforce SSD that loses power during a write operation & leaves the storage in a state that it can't make sense of later).
As difficult as it might be to transplant a donor cadaver's body onto another patient's head, at least there *is* a chance that it might work well enough to keep the recipient alive with some quality of life. IMHO, a brain-only transplant at this time is several steps *beyond* the realm of anything that even *pretends* to resemble sanity.
China has at least one HUGE advantage over the US: 3-4 times the number of taxpayers. As China becomes increasingly wealthy, it'll be easier for China to raise the funds for ambitious space-exploration projects.
If China prioritizes Moon-colonization over travel to Mars, it means only one thing: its leaders aren't confident that they can get to Mars with current technology & survive long enough to plant a flag.
The moon isn't a "stepping stone" to anything... even after you launch a rocket from the moon, you're STILL almost as deep inside Earth's gravity well as you'd have been after launching from Earth.
A colony on the moon itself is about as valuable as a house built (off-grid) in the Nevada desert 100 miles from Las Vegas... yeah, you could technically do it, and the land itself would probably be "almost free"... but the construction cost & ongoing supply costs would eat you alive, to the point where you could have paid less for a mansion in Henderson than you'd have ended up spending for a shack (with trucked-in water & electricity from a generator) in the desert.
The fundamental problem with auto-translating COBOL into something like C(++) or Java is the fact that the resulting code might be semantically-valid C(++) or Java that successfully compiles & runs, but it would probably be almost impossible for humans to make sense of, let alone safely modify in the future.
You're right about AT&T mis-appropriating funds meant for fiber... but let's be honest. If the best you can get is 3mbps, you probably aren't in an area that would have gotten fiber even if they'd faithfully observed their obligations. At best, you'd be like cable internet customers in farm country (where cable internet is available, but you'll have to spend thousands of dollars up front to get that service from the road all the way back to your house).
There is one (albeit expensive) option that might work. I believe some satellite providers will let you set up "split" service using IDSL, ISDN, or LTE as your low-latency uplink, while using the satellite for JUST your downlink (kind of like the way one-way cable internet used to work in the late 90s).
And *you're* missing the fact that you aren't going to get 50-100mbps over more than about a half-mile of copper with any current technology.
Uverse runs fiber to the node because it's the only practical way to *PUT* a VRAD with enough backhaul capacity to handle thousands of users streaming HD Netflix within ~2000 feet of those customers.
It's not a question of statutory law... it's a matter of PHYSICS. The fact that ADSL2 can achieve 12mbps up/1.5mbps down is borderline-miraculous, considering that 20 years ago, most RBOCs wouldn't even let you sign up for 1.5mbps/256kbps ADSL if you were more than a mile or two from the nearest CO.
There's no organized lobbying to force RBOCs (and their direct delegates, like AT&t Uverse & CenturyLink Prism) to let independent ISPs use existing copper from neighborhood nodes because there's nobody for whom it would actually be a viable business model.
If ${ISP} had to pay U-verse $60/month wholesale-rate to VPN traffic from one of ${ISP}'s customers to ${ISP}, and Uverse ITSELF charged $70 to directly provide the same level of Internet access, how many independent ISPs could genuinely provide comparably-fast Internet access without going broke with only $5-10/month?
Remember: Antitrust law exists to protect consumers, not competitors or business models. Within the constraints imposed by VDSL2, it's hard to argue that consumers with 25-100+mbps service are being harmed by the lack of competition... any viable alternative involving access to RBOC assets and comparable high speeds would cost more than anyone would willingly pay.
The only consumers who *might* benefit are those who'd be content with cheap, slow (say, G.Lite-speed) internet access (who are currently told, "our cheapest service is $50/month for 12/1.5", but for only a few dollars more, you can get 2-8x that speed). Frankly, I'm glad my senior-citizen and poor neighbors are forced to buy expensive service that's faster than they "need", because it subsidizes the infrastructure required to let *me* have fast internet access at semi-affordable prices. If I could get gigabit fiber for $100/month by forcing everyone to pay $50/month in 'fiber fees' (regardless of whether or not they actually USED, or even WANTED to use, their fiber), I'd do it in a heartbeat.
Exactly. An Android developer might know something is 'easy', but forget that it's only easy due to a new API that came out 3 years ago, but is STILL 1 or 2 versions ahead of the minimum version of Android for which the customer demands compatibility. Sometimes, it might be merely 'hard' to achieve something with an older version (ex: pdf-rendering, which didn't exist as an Android API until Lollipop). In other cases, it might be borderline-impossible to achieve with older versions... for example, low-latency audio (Marshmallow... on *some* devices... kind of...), or programmatically manipulating the appearance & location of the arrow pointer that appears when you attach a bluetooth or USB mouse (impossible without a custom ROM prior to Nougat!).
In the Android realm, estimation is even harder because "mainstream" Android devices are usually 2-3 entire releases behind the "current" one (and developers tend to have devices at the newer end of the spectrum), in which case we're talking about the loss of API functionality that's been present in newer versions for 3 or 4 YEARS. To Android developers, that's a *major* and frustrating mindfuck... it would be like being asked to estimate a Java project (in 2017) where you weren't allowed to use anything newer than JDK 1.5 (1.5 is ancient history, but the gulf between Java 5 and Java 8 is probably *less* than the gap between Kitkat and Nougat is today. I've been writing Android software since 2009, and I *still* get caught off guard by discovering that some core functionality that's been part of Android seemingly *forever* is *actually* post-Kitkat.
ADSL has a range of a few miles, but as you observed, it maxes out around 13mbps. VDSL2 is another matter entirely.
ADSL was viable for CLECs to lease wires, because they could rent rack space in the RBOC's CO and serve thousands of customers. VDSL2 blows that whole business model out the window... the only practical way CLECs could be accommodated with VDSL2 (due to short distance limits) is if the RBOC provided the VDSL2 network connectivity to the customer, then routed that customer's traffic over to the CLEC... and there's no way a CLEC (besides *maybe* Verizon, operating outside its home market) could actually make money doing that. And with U-verse, it would be largely pointless... the RBOC's customers would be paying more, and getting slower internet connectivity in return.
With ADSL, you can upgrade one CO and spread the costs among rich AND poor areas. With VDSL2, your meaningful service area is about 1,000 feet... and deploying a new VRAD in an area without existing fiber within a mile or so isn't cheap. Unless they can find enough rich people within a thousand feet who can't get service through an existing VRAD, those poor areas aren't going to get faster service.
God, it hurts defending AT&T... but even if they were actively benevolent, VDSL2's short range makes it really hard to cost-effectively serve poor areas UNLESS those poor areas have lots of people willing and able to buy premium internet service.
Going back to the rural electrification argument, yes, you can force the power company to provide you with power almost anywhere adjacent to a public road or right-of-way... but if you decide to build an Aluminum-smelting plant in the middle of nowhere (Aluminum-smelting uses a STAGGERING amount of power), you can't legally (or reasonably) expect the power company to upgrade 100+ miles of wiring for free, even if they WOULD provide you with up to 500A service for free.
The best way California can get Uverse into poor neighborhoods? Find all the properties in the area owned by the city/county/state due to unpaid liens, and offer one per ~2,000 feet to AT&T for free (waiving those liens) as a neighborhood VRAD site. Most poor areas have vacant properties that can't be sold, because the liens exceed its value. Making some of them available to AT&T as VRAD sites would make it easier for AT&T to justify the cost of deploying 50mbps+ VDSL2 into those areas.
Insecurity isn't a necessary component of corporate data-harvesting... it's quite possible to make a device with robust, impenetrable security that encrypts & transports vast quantities harvested data to its corporate masters.
These are the REAL problems with most IoT devices:
1. Devices with 8-bit MCUs that treat the internet like a UDP-implemented serial port & have no meaningful security of their own.
2. Linux's (intentional) lack of a stable kernel ABI, which makes it all-but-impossible for end users to take control of their own destiny and upgrade devices long after they've been abandoned by their manufacturers.
3. The lack of meaningful public documentation of the underlying SoC. If MediaTek, Qualcomm, etc. doesn't make proper datasheets available to the public, reverse-engineering some generic nameless webcam is going to be *really* hard unless you have access to the hardware & software tools usually owned only by companies or universities.
If somebody can name a sub-$60 IP camera with official open-source firmware, I'd *love* to be proven wrong, but the fact is, sub-$60 IP cameras are practically large-scale integrated circuits *themselves*. Seven times out of eight, not even the nominal *manufacturer* of the camera has access to the full sourcecode to its firmware... they buy some SoC, assemble it into a camera based on some generic reference design, and get all the firmware & drivers verbatim from the SoC's manufacturer (like the thousands of knock-off "Foscam-type" IP webcams).
plus, "JTAG" is very implementation-dependent. AFAIK, for example, you can't use an Atmel JTAG-Ice200 to reflash anything besides specific Atmel MCUs. Want to reflash a PIC? You need to buy yet another proprietary JTAG programmer. And so on, for every common microcontroller family. And if some third-party (Keil?) DOES make a multi-platform JTAG, it will be (a) mind-blowingly expensive (like almost every 'pro-grade' tool for non-hobby embedded development), (b) suck, or (c) both.
If you consumed 24 cans of Diet Mtn Dew or Diet Pepsi per day, you'd spend the NEXT day with horrific, explosive diarrhea and a pounding caffeine-withdrawal headache... assuming you didn't die from cardiac arrest first. At the VERY least, the cardiac arrhythmia would be pretty unpleasant. 24 cans has about 1.2 KILOGRAMS of caffeine (24 cans * 50mg/can).
Though they weren't really relevant to PCs or Windows, the Coldfire chips are a good example of this kind of design change. Though they were marketed as having a m68k heritage, they basically took away most of the instructions and addressing modes that made the original 680x0 so incredibly convenient to program in assembly language.
RISC processors were developed to be efficient and cheap. The m68k was developed to be convenient for assembly-language programmers. The 680x0 family indulged programmers in ways that would be almost *inconceivable* today (it even had a instructions for manipulating binary-coded decimal... they weren't terribly useful on computers like an Amiga, ST, or Mac, but apparently were a Very Big Deal(tm) back when programmers had to routinely deal with legacy BCD-encoded data from mainframes. Being able to directly manipulate BCD values meant not having to go through the trouble of converting them to and from 8/16/32-bit values first.
Examples of things Coldfire took away:
* the "decrement and branch conditionally" instructions. Sure, behind the scenes, they were basically two simpler instructions automatically glued together and executed back to back from a single opcode... but damn, they were nice to have.
* most of the immediate addressing modes not involving a register as the source or destination. On a 680x0, you could stuff a specific byte value into an arbitrary memory location by doing something like, "MOVE.B #$69, $dff000" (storing hex 0x69 in address 0xdff000 in a single gulp). On a Coldfire, you have to load-then-store (load $69 into a data register, then store that register's value at the desired target address).
* and of course, all the BCD-related instructions (ok, losing THEM didn't really bother me much, as you probably guessed... but I probably would have loved them if I'd been born about 10 years earlier).
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.
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.
Actually, I developed software for Windows Mobile for work back around 2006-2008.;-)
One feature I really, really miss from dotnetCF -- it didn't force you to bend over backwards and write explicitly-asynchronous code when you were trying to implement some blatantly-linear activity (like "display a form on the screen", "submit its contents to a server and wait for the response", "deal with its response", "display the next form", "submit its contents to a server and wait for the response", and so on). You could literally just wrap it in a dotnetCF class that allowed you to write it as a faux single-threaded sequential task, and let dotnetCF itself do the UI thread-juggling for you. It wasn't the OPTIMAL way to write an app like that, but it made implementing a simple sequence of submitted forms absurdly easy to do. I wrote my first server-submitting dotnetCF app in about 3 hours (most of which was spent reading a few chapters of a book)... I think my first Android app that did something comparable took the better part of a week to write. It amazed me how complicated Android managed to make things that were absolutely TRIVIAL to do with Windows Mobile.
The biggest single weakness of WinMo was the fact that it was LITERALLY impossible to develop a custom WinMo 5 or 6 "phone/dialer app" using dotnet compact framework... you could only do it in C, using (semi-)private APIs with minimal documentation and no example code to speak of. But from what I recall, that was actually one of the new features that were supposed to be in Windows Mobile 7.0 (before Microsoft abandoned it).
Slashdot Mirror
Win98/SE was the first version to support USB in general, but later updates to 95 & 98 added support for USB mice.
I believe that in theory, a highly-motivated vendor with lots of resources *could* have independently released their own drivers for Win95OSR2 & non-SE Win98, but the miniport .dll files almost everyone depends upon only came with 98SE. It's hard enough to do when you HAVE them, and damn-near impossible to do without them. I remember Linux struggled with USB performance for *years* (lots of things "worked" without needing drivers, but few devices worked really *well* compared to their non-USB variants).
And bring Android's management of short-term heap space up to at least where Java was 15 years ago.
Seriously. Android DOES NOT deal well with apps that promiscuously create lots of transient objects that fall out of scope almost immediately after creation. Java itself has, since at least 1.4 (circa 2001).
With Android, you basically have to create your OWN pseudo-heap using object pools (and write your classes so they can be restored to 'new' condition). Otherwise, Android's braindead "stop the world" GC will repeatedly halt the entire phone (UI included) until it finishes with garbage collection.
In Java, object pools are (rightfully) used for objects that are time-consuming to CREATE (like Oracle SQL connections). Android ends up forcing you to use them for objects that simply need lots of transient ram. It's a major reason why OpenGL can't easily be wrapped with "nice" Java classes to make it behave in a more OO manner... the GC penalty would *destroy* the app's performance.
They don't even need to do full-blown a-la-carte... they could just offer their mid & top-tier packages for $20-25/month less without losing a cent by making ESPN, the regional sports networks, and local OTA channels optional & passing along their actual savings to customers who exclude them. I have a perfectly good antenna & HDHomeRun (and would get a Cablecard-compatible HDHR-Prime if I got cable) with Windows Media Center as my DVR, so there's no reason I should have to pay an extra $5-10/month just so I can get my local channels from the same coax cable as CNN & Comedy Central.
Wow, you probably remember the area when it was still fairly undeveloped. You'd be shocked by how built-up the area around Pembroke Lakes Mall is now. I remember driving there sometime around 1994 & thinking I'd gotten off at the wrong exit, because there was *literal* wilderness on both sides of Pines Blvd for the first mile east of I-75. Let's just say it looks very, very different now. ;-)
Why, exactly, should the user of a company laptop who travels for business *not* be allowed to boot Linux from his own USB drive when he's in his hotel room at night? Almost all companies encrypt their drives with Bitlocker, so it's not like there's a real risk of company data being compromised by malware... without the key, it's *impossible* for malware running under an externally-booted OS to read the decrypted data or write subtle changes to the company's boot drive (at worst, it might render it unbootable until the OS gets reinstalled).
Back when I traveled a lot for business trips, I just bought a drive & drive caddy on ebay for my company-issued Dell D600, and swapped in *my* drive when I was in the hotel room or on the plane. IMHO, it was win-win for everyone... for all intents and purposes, I was traveling with two de-facto different computers whose OSes never directly crossed paths, because they were never in the computer simultaneously. My stuff never went anywhere near the company's HD, or endangered the sanctity of its data. If I'd been forced to take my own laptop too, you can *bet* the company's laptop would have been the one at risk of theft/breakage in my checked baggage...
Is dual-booting even *viable* anymore? I did it for years, but sometime around Windows 7, Windows just became too damn hostile to dual-boot... as in, every time I booted into Windows after running Linux, Windows insisted on taking a sidetrip to analyze/fix its ACLs that could take anywhere between 30 seconds and 3 days to complete (usually, 2-7 minutes).
The sad truth is, if you have files larger than 4 gigs, there really *isn't* a filesystem anymore that's natively and robustly supported by both Windows and Linux that both can safely share and use directly. Using ext2/3 with Windows is almost data-suicidal, Linux pretends exFAT doesn't exist, and Windows throws a tantrum if some other OS touches a NTFS partition it regards as its own (not to mention, Windows imposes requirements on NTFS that NTFS *itself* doesn't... it's *really* easy to accidentally get a NTFS filesystem into a state that works fine in Linux, but causes Windows to throw a tantrum (max path length, allowable characters in filenames, etc.).
For a quick & easy example, dual-boot into Linux, and back up your Windows c: drive to a tarball. Now untar it into a path like '/oldWinC', boot into Windows, and try to access those files. Windows will bitch about path length, because its IE cache files max out the allowable path, and restoring them to a subdirectory instead of '/' causes the limit to be exceeded.
And here in South Florida, our malls are generally doing quite well. There are several reasons why:
* The weather sucks outside. Our seasons are Summer, Sauna, Raintorrent, and January. Open-air "lifestyle centers" might do well in California (where it's moderately warm and relatively dry most of the time), but they aren't nearly as appealing in Florida. Sure, high school students on dates might still prefer lifestyle centers on Friday night, but on a hot, steamy, thunderstorm-soaked Saturday afternoon, people who are actually going to shop & spend money want an indoor mall with air conditioning. And when it's raining, a garage (so they can get inside without getting soaked).
* There isn't much true greenfield LEFT in South Florida for sprawling new malls. As of today, there's basically one significant greenfield site suitable for a regional mall remaining in the entirety of urban Dade & Broward County (by I-75 at the Turnpike Extension, which is kind of a weird donut hole surrounded by wall-to-wall development on 3 sides, and limestone mines on the fourth).
* Cities will concede almost ANYTHING to developers to protect their sales-tax cash cow from newer, bigger malls in some nearby municipality... especially if that municipality is on the other side of the county line. I have no doubt that the cities of Sunrise & Pembroke Pines, plus Broward County, will grant just about any request made by the owners of Sawgrass Mills and Pembroke Lakes Mall in the name of protecting their sales tax revenue from American Dream Mall (a few hundred feet on the wrong side of the county line).
* The developers of the last real wave of "big, new regional malls in previously-undeveloped greenfields" in the 80s and 90s were smart enough to leave themselves plenty of room to radically grow in the future (mostly, by replacing their original sprawling parking lots with multi-story garages and new wings).
* There's a certain point where a mall can actually become TOO BIG to be appealing to anyone besides tourists. Malls like Galleria (Fort Lauderdale) and Dadeland (Miami) do well because they have lots of wealthy people living nearby and are relatively convenient to shop at. Malls like International Mall (Doral), Pembroke Lakes Mall (Pembroke Pines), and Broward Mall (Plantation) fall into the niche of "big enough to have what you want, but small enough to be reasonably efficient to shop at if you already know what you want & just need to get to the store and buy it. In contrast, I *might* go to Aventura or Sawgrass Mills once or twice a year, because it's normally just too much of a time-consuming pain in the ass to shop at those two malls (in fact, the last time I went to either mall was SPECIFICALLY because I wanted some game at Gamestop that was only in stock at those two malls).
Exactly. We now have 240ppi+ displays, but it's still basically impossible to buy a tablet with 14-16" 3840x2580 3:2 that weighs less than a pound (more than a pound, and it just becomes too heavily to hold open for extended periods of time) AND is fast enough to complete a pageflip in 150ms or less, or flip to some arbitrary page-pair in 250ms or less.
Tech books NEED 2-up layout, because they frequently have a diagram on one page, with explanatory text on the facing page. Attempting to read a book like that one page at a time is a miserable use experience.
IMHO, the MINIMUM specs for a tolerable ebook reader for tech books is something like the Chuwi Hi12... and it's *barely* fast enough to be tolerable. Anything less is just plain unacceptable. And tech support for Chuwi is a bit... difficult... unless you're fluent in Mandarin. A Surface Pro w/largest display would be better... but they're too expensive to use for JUST ebook-reading, and not quite good enough to use as your "real, one & only" computer.
If you can meaningfully compact *anything* that's encrypted, the encryption was improperly implemented. You *always* want to compact files prior to encryption, and a well-encrypted compressed file should be statistically indistinguishable from random noise.
Plus, a transplanted *head* might end up paralyzed from the neck down in its donor body, but at least the patient might have working eyesight & facial muscles. Transplant a brain alone, and the patient doesn't even get to have *that* as a 'Plan B' consolation.
Another possibility is that at best, you'd be resurrecting a zombie whose brain effectively had its programming erased when it died (or, perhaps, would be like a Sandforce SSD that loses power during a write operation & leaves the storage in a state that it can't make sense of later).
As difficult as it might be to transplant a donor cadaver's body onto another patient's head, at least there *is* a chance that it might work well enough to keep the recipient alive with some quality of life. IMHO, a brain-only transplant at this time is several steps *beyond* the realm of anything that even *pretends* to resemble sanity.
China has at least one HUGE advantage over the US: 3-4 times the number of taxpayers. As China becomes increasingly wealthy, it'll be easier for China to raise the funds for ambitious space-exploration projects.
If China prioritizes Moon-colonization over travel to Mars, it means only one thing: its leaders aren't confident that they can get to Mars with current technology & survive long enough to plant a flag.
The moon isn't a "stepping stone" to anything... even after you launch a rocket from the moon, you're STILL almost as deep inside Earth's gravity well as you'd have been after launching from Earth.
A colony on the moon itself is about as valuable as a house built (off-grid) in the Nevada desert 100 miles from Las Vegas... yeah, you could technically do it, and the land itself would probably be "almost free"... but the construction cost & ongoing supply costs would eat you alive, to the point where you could have paid less for a mansion in Henderson than you'd have ended up spending for a shack (with trucked-in water & electricity from a generator) in the desert.
The fundamental problem with auto-translating COBOL into something like C(++) or Java is the fact that the resulting code might be semantically-valid C(++) or Java that successfully compiles & runs, but it would probably be almost impossible for humans to make sense of, let alone safely modify in the future.
You're right about AT&T mis-appropriating funds meant for fiber... but let's be honest. If the best you can get is 3mbps, you probably aren't in an area that would have gotten fiber even if they'd faithfully observed their obligations. At best, you'd be like cable internet customers in farm country (where cable internet is available, but you'll have to spend thousands of dollars up front to get that service from the road all the way back to your house).
There is one (albeit expensive) option that might work. I believe some satellite providers will let you set up "split" service using IDSL, ISDN, or LTE as your low-latency uplink, while using the satellite for JUST your downlink (kind of like the way one-way cable internet used to work in the late 90s).
And *you're* missing the fact that you aren't going to get 50-100mbps over more than about a half-mile of copper with any current technology.
Uverse runs fiber to the node because it's the only practical way to *PUT* a VRAD with enough backhaul capacity to handle thousands of users streaming HD Netflix within ~2000 feet of those customers.
It's not a question of statutory law... it's a matter of PHYSICS. The fact that ADSL2 can achieve 12mbps up/1.5mbps down is borderline-miraculous, considering that 20 years ago, most RBOCs wouldn't even let you sign up for 1.5mbps/256kbps ADSL if you were more than a mile or two from the nearest CO.
There's no organized lobbying to force RBOCs (and their direct delegates, like AT&t Uverse & CenturyLink Prism) to let independent ISPs use existing copper from neighborhood nodes because there's nobody for whom it would actually be a viable business model.
If ${ISP} had to pay U-verse $60/month wholesale-rate to VPN traffic from one of ${ISP}'s customers to ${ISP}, and Uverse ITSELF charged $70 to directly provide the same level of Internet access, how many independent ISPs could genuinely provide comparably-fast Internet access without going broke with only $5-10/month?
Remember: Antitrust law exists to protect consumers, not competitors or business models. Within the constraints imposed by VDSL2, it's hard to argue that consumers with 25-100+mbps service are being harmed by the lack of competition... any viable alternative involving access to RBOC assets and comparable high speeds would cost more than anyone would willingly pay.
The only consumers who *might* benefit are those who'd be content with cheap, slow (say, G.Lite-speed) internet access (who are currently told, "our cheapest service is $50/month for 12/1.5", but for only a few dollars more, you can get 2-8x that speed). Frankly, I'm glad my senior-citizen and poor neighbors are forced to buy expensive service that's faster than they "need", because it subsidizes the infrastructure required to let *me* have fast internet access at semi-affordable prices. If I could get gigabit fiber for $100/month by forcing everyone to pay $50/month in 'fiber fees' (regardless of whether or not they actually USED, or even WANTED to use, their fiber), I'd do it in a heartbeat.
Exactly. An Android developer might know something is 'easy', but forget that it's only easy due to a new API that came out 3 years ago, but is STILL 1 or 2 versions ahead of the minimum version of Android for which the customer demands compatibility. Sometimes, it might be merely 'hard' to achieve something with an older version (ex: pdf-rendering, which didn't exist as an Android API until Lollipop). In other cases, it might be borderline-impossible to achieve with older versions... for example, low-latency audio (Marshmallow... on *some* devices... kind of...), or programmatically manipulating the appearance & location of the arrow pointer that appears when you attach a bluetooth or USB mouse (impossible without a custom ROM prior to Nougat!).
In the Android realm, estimation is even harder because "mainstream" Android devices are usually 2-3 entire releases behind the "current" one (and developers tend to have devices at the newer end of the spectrum), in which case we're talking about the loss of API functionality that's been present in newer versions for 3 or 4 YEARS. To Android developers, that's a *major* and frustrating mindfuck... it would be like being asked to estimate a Java project (in 2017) where you weren't allowed to use anything newer than JDK 1.5 (1.5 is ancient history, but the gulf between Java 5 and Java 8 is probably *less* than the gap between Kitkat and Nougat is today. I've been writing Android software since 2009, and I *still* get caught off guard by discovering that some core functionality that's been part of Android seemingly *forever* is *actually* post-Kitkat.
ADSL has a range of a few miles, but as you observed, it maxes out around 13mbps. VDSL2 is another matter entirely.
ADSL was viable for CLECs to lease wires, because they could rent rack space in the RBOC's CO and serve thousands of customers. VDSL2 blows that whole business model out the window... the only practical way CLECs could be accommodated with VDSL2 (due to short distance limits) is if the RBOC provided the VDSL2 network connectivity to the customer, then routed that customer's traffic over to the CLEC... and there's no way a CLEC (besides *maybe* Verizon, operating outside its home market) could actually make money doing that. And with U-verse, it would be largely pointless... the RBOC's customers would be paying more, and getting slower internet connectivity in return.
With ADSL, you can upgrade one CO and spread the costs among rich AND poor areas. With VDSL2, your meaningful service area is about 1,000 feet... and deploying a new VRAD in an area without existing fiber within a mile or so isn't cheap. Unless they can find enough rich people within a thousand feet who can't get service through an existing VRAD, those poor areas aren't going to get faster service.
God, it hurts defending AT&T... but even if they were actively benevolent, VDSL2's short range makes it really hard to cost-effectively serve poor areas UNLESS those poor areas have lots of people willing and able to buy premium internet service.
Going back to the rural electrification argument, yes, you can force the power company to provide you with power almost anywhere adjacent to a public road or right-of-way... but if you decide to build an Aluminum-smelting plant in the middle of nowhere (Aluminum-smelting uses a STAGGERING amount of power), you can't legally (or reasonably) expect the power company to upgrade 100+ miles of wiring for free, even if they WOULD provide you with up to 500A service for free.
The best way California can get Uverse into poor neighborhoods? Find all the properties in the area owned by the city/county/state due to unpaid liens, and offer one per ~2,000 feet to AT&T for free (waiving those liens) as a neighborhood VRAD site. Most poor areas have vacant properties that can't be sold, because the liens exceed its value. Making some of them available to AT&T as VRAD sites would make it easier for AT&T to justify the cost of deploying 50mbps+ VDSL2 into those areas.
Insecurity isn't a necessary component of corporate data-harvesting... it's quite possible to make a device with robust, impenetrable security that encrypts & transports vast quantities harvested data to its corporate masters.
These are the REAL problems with most IoT devices:
1. Devices with 8-bit MCUs that treat the internet like a UDP-implemented serial port & have no meaningful security of their own.
2. Linux's (intentional) lack of a stable kernel ABI, which makes it all-but-impossible for end users to take control of their own destiny and upgrade devices long after they've been abandoned by their manufacturers.
3. The lack of meaningful public documentation of the underlying SoC. If MediaTek, Qualcomm, etc. doesn't make proper datasheets available to the public, reverse-engineering some generic nameless webcam is going to be *really* hard unless you have access to the hardware & software tools usually owned only by companies or universities.
If somebody can name a sub-$60 IP camera with official open-source firmware, I'd *love* to be proven wrong, but the fact is, sub-$60 IP cameras are practically large-scale integrated circuits *themselves*. Seven times out of eight, not even the nominal *manufacturer* of the camera has access to the full sourcecode to its firmware... they buy some SoC, assemble it into a camera based on some generic reference design, and get all the firmware & drivers verbatim from the SoC's manufacturer (like the thousands of knock-off "Foscam-type" IP webcams).
plus, "JTAG" is very implementation-dependent. AFAIK, for example, you can't use an Atmel JTAG-Ice200 to reflash anything besides specific Atmel MCUs. Want to reflash a PIC? You need to buy yet another proprietary JTAG programmer. And so on, for every common microcontroller family. And if some third-party (Keil?) DOES make a multi-platform JTAG, it will be (a) mind-blowingly expensive (like almost every 'pro-grade' tool for non-hobby embedded development), (b) suck, or (c) both.
Or they use something like WizNet's serial/SPI/I2C-to-UDP boards, whose 'security' can be bruteforced by anyone within a few hours.
If you consumed 24 cans of Diet Mtn Dew or Diet Pepsi per day, you'd spend the NEXT day with horrific, explosive diarrhea and a pounding caffeine-withdrawal headache... assuming you didn't die from cardiac arrest first. At the VERY least, the cardiac arrhythmia would be pretty unpleasant. 24 cans has about 1.2 KILOGRAMS of caffeine (24 cans * 50mg/can).
Though they weren't really relevant to PCs or Windows, the Coldfire chips are a good example of this kind of design change. Though they were marketed as having a m68k heritage, they basically took away most of the instructions and addressing modes that made the original 680x0 so incredibly convenient to program in assembly language.
RISC processors were developed to be efficient and cheap. The m68k was developed to be convenient for assembly-language programmers. The 680x0 family indulged programmers in ways that would be almost *inconceivable* today (it even had a instructions for manipulating binary-coded decimal... they weren't terribly useful on computers like an Amiga, ST, or Mac, but apparently were a Very Big Deal(tm) back when programmers had to routinely deal with legacy BCD-encoded data from mainframes. Being able to directly manipulate BCD values meant not having to go through the trouble of converting them to and from 8/16/32-bit values first.
Examples of things Coldfire took away:
* the "decrement and branch conditionally" instructions. Sure, behind the scenes, they were basically two simpler instructions automatically glued together and executed back to back from a single opcode... but damn, they were nice to have.
* most of the immediate addressing modes not involving a register as the source or destination. On a 680x0, you could stuff a specific byte value into an arbitrary memory location by doing something like, "MOVE.B #$69, $dff000" (storing hex 0x69 in address 0xdff000 in a single gulp). On a Coldfire, you have to load-then-store (load $69 into a data register, then store that register's value at the desired target address).
* and of course, all the BCD-related instructions (ok, losing THEM didn't really bother me much, as you probably guessed... but I probably would have loved them if I'd been born about 10 years earlier).
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.
> 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.
Actually, I developed software for Windows Mobile for work back around 2006-2008. ;-)
One feature I really, really miss from dotnetCF -- it didn't force you to bend over backwards and write explicitly-asynchronous code when you were trying to implement some blatantly-linear activity (like "display a form on the screen", "submit its contents to a server and wait for the response", "deal with its response", "display the next form", "submit its contents to a server and wait for the response", and so on). You could literally just wrap it in a dotnetCF class that allowed you to write it as a faux single-threaded sequential task, and let dotnetCF itself do the UI thread-juggling for you. It wasn't the OPTIMAL way to write an app like that, but it made implementing a simple sequence of submitted forms absurdly easy to do. I wrote my first server-submitting dotnetCF app in about 3 hours (most of which was spent reading a few chapters of a book)... I think my first Android app that did something comparable took the better part of a week to write. It amazed me how complicated Android managed to make things that were absolutely TRIVIAL to do with Windows Mobile.
The biggest single weakness of WinMo was the fact that it was LITERALLY impossible to develop a custom WinMo 5 or 6 "phone/dialer app" using dotnet compact framework... you could only do it in C, using (semi-)private APIs with minimal documentation and no example code to speak of. But from what I recall, that was actually one of the new features that were supposed to be in Windows Mobile 7.0 (before Microsoft abandoned it).