> the HTML specification document neglected to mention which CSS should be used to get eg
From what I remember, there were quite a few things you could do with table/row/cell going all the way back to IE3, but COULDN'T do at all with CSS1, and couldn't reliably do with CSS2 in a way that was cross-browser compatible without implementing multiple variants that were more trouble than they were worth, and either serving different HTML based on the browser-sniffed user agent string, or using conditional comments and doctype to tell IE what your precise expectations were and hide whatever you did from Firefox & Opera -- and getting it to work with Firefox & Opera required major DOM-manipulation via Javascript in onLoad().
I distinctly remember that we didn't start seeing articles saying, "There's now nothing you could do with tables that you can't do with CSS" until CSS3 became commonplace. The CSS1-era articles all basically said, "Sorry, can't do it", and the CSS2-era articles basically said, "You can sort of do it if you're feeling incredibly masochistic, but it's almost pointless to bother").
The biggest roadblock to metric adoption in the US was the insane idea that anything expressed in metric units had to be some whole multiple of 10 or 100. We weren't allowed to have 5mL and 15mL measuring spoons... they had to be 1mL and 10mL, bundled with an equally-useless 100mL measuring cup. Or at least, that was what you'd think if you saw the useless set of baking utensils my mom & grandmother got for Christmas at some point in the late 70s. It was like there was some unwritten rule banning 250mL measuring cups, because it wasn't a "proper" metric size.
The sole exception to the "whole multiple of 10" rule was speed limits. Without exception, the speed limit in km/h was always less than the speed limit in miles per hour -- sometimes, a lot. Hence, signs that listed metric speed limits for 55mph and 30mph as 88km/h and 40km/h. I specifically remember the news reports on TV about how the 30mph/40km/h signs were vandalized at an abnormally-high rate (in rural areas, they were usually shot full of bullet holes). Had the government given drivers a freebie, and listed the metric speed limits for 55 and 30mph as 90km/h and 50km/h respectively, I *guarantee* American drivers would have LOVED the metric system. At least, in that specific context.
DST is an anachronism. Only old people (esp. those in congress) oppose getting rid of it.
I know plenty of people -- young AND old -- who'll happily support a proposal to abolish DST, as long as "abolish DST" means "stay in summer time all year".
40 years from now, DST will begin in early February, end the weekend after Thanksgiving, people will bitch about the stupidity of changing clocks for just 9 or 10 weeks, and the DST-abolitionists will be trying to abolish summer time and turn 9 weeks of winter time into 52, and wondering why everybody opposes them.
> why the hell would you connect your house to the internet or any appliance on the Internet anyway.
So you can check up on your cats during the day while you're at work, and reassure yourself that the house hasn't gotten broken into in a way that somehow managed to avoid setting off the alarm. And dispense treats for them from the Magic Invisible Food God if you start to feel guilty about leaving them home alone all day. And drive the Roomba-platform-mounted webcam around to their favorite hiding spot (still working on *that* one).
There's also the fact that more traditional means of remote home control (via phone) rarely work well with VoIP and voicemail. My alarm, for example, DOES have a telephone interface module... but it depends upon having an answering machine pick up the call so it can eavesdrop and listen for the triggering code. If the call rings until it goes to voicemail, the alarm never gets a chance to listen in and grab the call away from the answering machine. If the alarm answers the phone, and it was somebody calling, all it can do is play back a ~5-second.wav file apologizing and hang up on them. Did I mention yet that the way Android phones implement keyboard DMTF (playing a short pre-generated sample, as opposed to generating the tones on the fly in realtime), coupled with the way most VoIP codecs and mobile phone networks mangle DMTF, causes roughly 1 or 2 digits per dozen or so to fail to get recognized?
As a practical matter, thanks to VoIP, voicemail, and mobile phones, you almost *have* to implement your controls via IP rather than dial-in unless you want to pay AT&T $35/month for a landline phone that you almost never actually use.
That said, most internet-interfaced home automation controls are HORRIFICALLY insecure. If their interface consists of a Wiznet serial-to-IP module, and actually depends upon Wiznet's own password-based security, you should probably just assume it's been pwn3d several times over. ESPECIALLY if whatever's connected to the serial port end of the Wiznet module was designed to be physically connected to a real RS-232 serial port inside a locked cabinet, and all they did was strap the Wiznet module onto it. A security-free serial port isn't a great idea, but if it's inside a locked cabinet inside your house, it's pretty low on the list of concerns unless you have servants spending time unsupervised inside your home. That same security-free serial port strapped onto a Wiznet module with 8-character password (and with no rate-limit or lockout policy) can literally be bruteforced via UDP in a matter of days if the password is purely alphanumeric.
ARM-based modules aren't a whole lot better, because manufacturers try to shave 17c from the manufacturing costs and cram everything into a few megs of flash. Of course, the first thing that gets cut when the compiled code is a little too big is the security. To manufacturers, security isn't a quantifiable selling point compared to features, and strong security raises tech support costs anyway by making the device more likely to NOT work for some non-obvious reason.
IMHO, the only secure way to connect embedded hardware with minimal security to the internet is through a gateway appliance that shields them from direct contact with the internet, and acts as a proxy server/firewall/application level gateway. Preferably, running over a different physical network, and at the very least (if wire-sharing is inevitable), segregating the insecure devices into a different IP range that can communicate ONLY with that gateway.
Note that if 100mbit ethernet is fast enough, you can actually wire two electrically-independent 10/100 ethernet jacks with a single cat5e cable (use green & orange for one, blue & brown for the other). If you pull two cat5e cables from every room to the wiring closet, you can use one for gigabit ethernet (possibly using a pair of layer VLAN-capable switches that support layer 2 IGMP snooping to isolate the "TV multicast network" from the "hom
On the other hand, the Find 7 has two things the Nexus 5 will never have:
* removable battery
* microSD card
And as a practical matter, it's about as open as the Nexus 5. I think I even read that it has open-source drivers for one or two chips that are proprietary binary blobs in the Nexus 5.
A Nexus 5 can run Cyanogenmod with minimal difficulty. A Find 7 gets to have Cyanogenmod as its official operating system right out of the box.
Over at XDA, the Find 7 is a popular choice for "next phone" among Nexus 5 owners, and became the #1 choice of users who WERE looking at the Galaxy S5 almost overnight, once news leaked that even the T-Mobile S5 would have a locked bootloader.
Zero latency is impossible due to both the speed of sound in air and the speed of light (which indirectly governs the speed of information-conveyance by electrons over a wire. For the sake of being pedantic, the actual electrons travel along the wire at a relatively slow speed).
Imperceptible latency is impossible with anything besides analog modulation schemes like FM, or uncompressed PCM. By the very definition of stream and block compression, you have to buffer SOMETHING.
That doesn't mean there's no room for improvement... but what you're asking for basically at odds with data compression.
It's the same reason why hearing aids are still overwhelmingly analog devices. Digital technologies -- especially cheap ones -- introduce unacceptable latency.
> I doubt that this would fit comfortably in a pocket.
Think again. The Find 7 was explicitly designed to minimize horizontal bezel. Its width is less than most phones that have screens a full centimeter smaller.
I havne't personally laid my hands on a Find 7 yet, so I can't guarantee it will fit in a back pocket... but I'll be shocked if it's really too big to fit in the back pocket of an average, non-obese male wearing relaxed-fit jeans.
Mobile games don't suck because the displays are too high resolution... they suck because it's nearly impossible to buy a phone with proper analog & digital gamepads and buttons.
Touchscreens are unfit controls for anything that requires hair-trigger muscle memory responses, and accelerometers/gyros would only be suitable in some scenarios if the display you're looking at weren't part of the same slab being tilted. And the few devices that DO have gamepads make too many compromises for the sake of having a thin profile, and destroy most of the advantages of having a real gamepad in the first place. It's like manufacturers think that things like tactile snap and accuracy cease to matter the moment you add a radio modem to your pocket videogame system.
> Seems most manufacturers (and users?) forgot the "phone" bit.
What's this "phone" thing people keep talking about? You mean that old legacy "voice" mode that nobody uses anymore? Ew... Voice calls just seem so rude and intrusive.
> My Samsung Galaxy S3 Mini gets around three days stand-by with light to medium use..
ROFLMAO. How the other half lives...
I've managed to wring my Galaxy S3's stock battery dry in about 2 hours, and would estimate that my ~3,000mAH Seidio extended battery is good for about 5 hours of really hardcore use (though it usually doesn't fall below 10% until an hour or two before I'm ready to go to bed).
Admittedly, part of the reason my battery life is so bad is because I have zero tolerance for touch-latency or lag. I have my kernel tweaked to keep the CPU running full-bore if I've turned on the display within the past 5 seconds, or touched the screen within the past 10 seconds. The basic strategy is "ramp up to max speed at the slightest hint of upcoming interactive use, but allow it to slowly reduce the speed if I go for more than 5 seconds without touching the screen, or allow it to rapidly slow down & go to sleep if I actually turn off the display. It's spoiled me. Using a S3 with a stock ROM and normal CPU governor feels like I'm slogging through wet concrete. The truth is, 99% of the lag people complain about with Android phones is due to CPU-throttling. Force it to run at full-bore, and the lag magically goes away.
> Unfortunately, not for a phone with this kind of a screen.
Fortunately, Oppo listened to the feedback from people who saw the Find 5, and wisely gave it a removable battery (as well as LTE and microSD). So, you'll be able to buy a nice, big, beefy 6,000-8000mAH+ aftermarket battery for it. Or buy a half-dozen spare regular batteries from someone on eBay, and swap them out as needed throughout the day and night.
Because modern webapps depend on Javascript for everything, and Javascript completely sucks on most current mobile platforms. Like it or not, a webapp that uses Javascript to render itself into an empty [body/] tag's DOM needs a metric shit ton of ram and a fast, multi-core CPU. Unfortunately, that description now includes a large plurality of the web sites that we use today.
The solution isn't to make our phones slow and laggy to maximize battery life. The solution is to give our phones bigger batteries so they can keep chugging along at full speed all day, remain alive overnight, and have enough power left to get you through breakfast online.
10-15 years ago, nobody bitched about the size or weight of a Palm Pilot or PocketPC. Our phones have now grown to the approximate length and width of a turn of the century PDA, but there's still an industry-wide unhealthy obsession with being thin and light at all costs. I'd LOVE a phone with the approximate dimensions of a 2001 iPaq that fills most of its interior with 12,000mAH or more of lithium ion goodness.
I only wish it were that simple. On my computer at work, I have at least one Java app that literally dies on launch unless you have BOTH 32-bit AND 64-bit Java installed. It exhibits this behavior on everybody's computer, and not just mine. Nobody, including its author, really knows why.
That oddball app notwithstanding, installing only a 64-bit JRE on a computer running 64-bit Windows 7 is NOT the universal solution. Google finally fixed it, but for the longest time, you literally couldn't do Android software development under Eclipse on a computer with ONLY a 64-bit JRE. It would randomly forget how to find the SDK, fail compilation due to bugs in your code that didn't actually exist (if you cut the class into the clipboard, saved the now-empty class, then pasted it back, all the errors would go away), completely mangle R.java, and would do a phantom cursor-left whenever you typed a semicolon at the end of a line, so that when you pressed return a quarter-second later, it moved the semicolon down to the next line and caused an error.
There a other examples of vehemently-32bit apps, but it's late and Android-Eclipse is the huge one that drove me nuts for about 2 years. Note that I'm not conflating Android and Java... Eclipse itself is what was screwing up when run on a 64-bit VM.
It's not nearly as bad as the situation with C(++), but the way Java's classloader refuses to allow jars-in-jars is still pretty stupid. We should be able to create an executable jarfile with a virtual/libs directory that contains all the thirdparty jarfiles our own app needs.
It's 2014. Nobody *cares* how much space the compiled bytecode takes anymore, because it's insignificant compared to the amount of RAM needed at runtime for the various heaps. And when there's an exception to that rule, it's usually with some app that's so utterly niche, the likelihood of having some other app on the same system that uses the same meaningfully-huge library is almost nonexistent anyway.
Ten years ago, we could cheat & copy the thirdparty jarfiles we used all the time to the JRE's/ext directory. That doesn't work anymore, because Java's near-weekly auto-updates mean it's now a moving target. The/ext subdirectory of today's JRE will be an orphaned wasteland by the middle of next week, and every app that depends upon automagically finding Log4j, HttpComponents, JSAP, and everything else in that directory will break unless we give our app its own copy anyway.
Far BETTER would be if Java could be aware of how much ram the computer has, and enlarge its heaps as necessary & possible. Few things piss me off more than getting OutOfMemoryException on a computer with 16 gigs because I forgot to manually specify a larger heap size when I launched some executable jarfile from the commandline.
I mean, seriously. Would it really be *that* hard for the JVM to handle TWO sets of memory pools instead of just one, so that if the Eden space (for example) gets exhausted and is due for GC, the JVM would check with Windows to see how much physical RAM is free, and if there's a lot of it, just allocate a new chunk that's roughly double the size of the old one, start sticking new data into the new one immediately, and consolidate data from the old one into the new one as a very, very low-priority non-blocking background thread that eventually returns the first chunk of RAM to Windows once everything in it has been either moved or freed. For longer-lived services where memory leaks are a real issue, you could tell it, "expand by doubling up to [max megs or percent free], then fall back to conventional garbage collection -- possibly, grabbing a new chunk of ram that's the same size as the old one if possible so the time-consuming object-copy can be deferred and done in the background"
Did they finally straighten out the 64-bit mess?
on
Java 8 Officially Released
·
· Score: 3, Interesting
The biggest problem with Java is the fact that it makes dealing with 32-vs-64-bit and user-vs-admin in shell and script environments needlessly painful under Windows.
I mean, seriously. Why, in 2014, do we STILL have bullshit like:
java -jar foo.jar arg1 arg2 arg3
(silent crash), or [*very public crash*], or "This application requires a 64-bit JVM"
then, have to screw around figuring out what the path is THIS WEEK to the right java.exe, because every goddamn semi-daily update changes the installation path, so you end up having to do something like:
{swear violently and with frustrated rage} dir "c:\program files\java" (see what the installation dir is this week) "c:\program files\java\jdk1.7.0.69\bin\java.exe" foo.jar arg1 arg2 arg3
I mean, would it really kill them to give us an installer that installs BOTH the 32 and 64-bit JDKs, then creates a bunch of symlinks to a file named java.exe that -- when launched -- looks at the jarfile, determines whether it needs a 32- or 64-bit JVM, finds the latest 32- or 64-bit JVM as appropriate, and launches it -- passing the path to itself and the rest of the args as args?
This is an endless source of pain to me. Java is my main language & I end up using it for almost everything, and its awful handling of commandline launches has driven me crazy for years. When I write some tool I use a lot, I'll go to the trouble of setting it up to build with JSmooth so it can wrap the whole thing in a.exe file... but that's a royal pain in itself, and I'm dreading the day when I have to figure out how to use it to wrap a 64-bit Java app (I'm not even sure it can).
Java also needs to seriously improve the way it deals with UAC... like maybe install a privileged Java background service (that's normally asleep and idle) so we can launch apps as regular users under Windows 7, and programatically auto-elevate via UAC by having Java delegate sensitive tasks to that background service when necessary under Windows 7 or later. Or at least, create something like WindowsUACException that's a subclass of IOException (so Windows-aware apps can catch it explicitly and deal with it gracefully, without breaking Windows-unaware apps that are oblivious to UAC) that gets thrown when something fails due to UAC, instead of throwing some misleading Exception that makes it look like the filesystem is missing.
Regardless, Java's handling of Windows commandline launches of executable Jarfiles *sucks* under Java 7, and we can only hope they've had mercy on us and made it less dysfunctional under Java 8.
No sane airline would *allow* the President to fly commercially. It would be like painting a red target across its metaphorical face and daring terrorists to attack them, in return for less money and staggeringly-higher security expenses than it would otherwise have if normal people bought the tickets. And when the inevitable attack *did* happen, they'd get hit by lawsuits from everyone who ended up being "collateral damage". The amount of money they'd have to charge to guarantee that the service would be revenue-neutral for them (taking into account things like attacks) would probably be four times the amount we currently pay for the Secret Service and military to handle the logistics.
One bit of info that *might* be of interest... cell phone towers beacon to announce their presence to phones, but individual phones actually *poll* towers every few seconds. The reply from the tower lets them know when there's an incoming call, deliver SMS & voicemail notifications, etc. In theory, at least, if the mobile phone of any passenger came within range of a cell tower it was allowed to poll, there's probably a log of it somewhere.
That said, if the jet was at cruising altitude, the likelihood of a phone on board *doing* that is almost nil, because tower antennas are generally aimed downwards... partly, to minimize interference from airborne mobile phones that could otherwise splatter noise over a 40-100 mile radius (the line of sight when your transmitter is 5+ miles up in the air).
And how many atoms thick does the insulating layer between adjacent photosensitive or photoemitting structures need to be to prevent light emitted by one pair's LED from unduly influencing the state of an adjacent photodiode/phototransistor?
What, exactly, is the benefit of building a chip whose internal connections are basically all optoisolators?
Of course, there's also ARM. It's not new, of course, but programming ARM in assembly language is kind of a recent developmen (though I'd conservatively estimate that at least 20% of assembly-language ARM code is probably malware).
In theory, you can even do JVM assembly. It's kind of pointless and masochistic, but people have done it just to say they have.;-)
For anybody who knows... could a radar system partly or completely side-step the Doppler Dilemma ( http://en.wikipedia.org/wiki/W... ) by doing DSS or FHSS and cycling through a sequence of different carrier frequencies from pulse to pulse?
The problem is, there's no way to safely STORE large numbers of Bitcoins. Banks can store a trillion dollars with zero risk by depositing it at the Fed. The Fed notes the deposit, backs up the record in multiple places with enormous amounts of redundancy, then shreds any actual currency that was part of the deposit because it doesn't NEED it. It can always print new bills to replace the deposited ones should the need arise.
With Bitcoin, a bank can't do that. If a bank stores a thousand Bitcoins somewhere in exactly one super-secure location, and the medium on which they're stored gets physically destroyed, those Bitcoins are as gone as the money from depositors at a Wild West bank that just got robbed & had its vault emptied. Or boxes of British Pounds on a sunken ship resting in the middle of the Atlantic Ocean circa 1880.
With virtual Dollars that exist only as bookkeeping entries at the Fed, geographically-dispersed redundancy increases robustness and security. With Bitcoins, it increases their likelihood of loss by malware or theft. The only way to protect Bitcoins is to store them in a non-networked environment... but if you're burning a thousand bitcoins to BD-R discs and transporting them to vaults around the country, you'd better have armed security guards watching the discs, because a single stolen disc could be worth literally millions. If you're encrypting them and transporting them over a network, you're gambling on the encryption key not being compromised. If you're printing the base64 hashes to exactly one -piece of paper per Bitcoin and storing them in a vault, you're gambling on the vault not getting stolen or destroyed. And ultimately, you have to transfer that Bitcoin back to a networked computer in order to spend it... and all it takes is one bit of malware at that instant to completely negate everything you did up to that point to store it safely.
There's a reason why businesses don't like to handle large amounts of cash -- it's dangerous. And the danger increases exponentially with the amount. With Bitcoins, everything is effectively a cash transaction, with all the real-world risks that entails.
Or if you want to be cute, and you can hack your router's firmware a bit to auto-map internal ipv4 to external ipv6, you can ignore the fact that the underlying representations are fundamentally different and do something like:
internal device #1 = 192.168.100.101
external ipv6 prefix = 2001:44b8:6116:5aff::
internal device #1's public ipv6 address: 2001:44b8:6116:5aff:192:168:100:101
There's no law that says the lower bytes of your ipv6 address HAVE to be some god-awful value. As the parent noted, you could quite legitimately assign ip addresses to devices on your local network as 2001:44b8:6116:51ff::1, 2001:44b8:6116:51ff::2, 2001:44b8:6116:51ff::3, etc.
You can even make up addresses that spell cute things, like:
2001:44b8:6116:51ff:B16:B00:B5:1 ("Big Boobs 1"), 2001:44b8:6116:51ff:f00d:f00d:dead:beef, etc.
If you can deal with remembering a public ipv4 address and a dozen 10.x.x.x or 192.168.x.x addresses with inbound port-mapping rules, you can translate the whole thing to a scheme for assigning internal addresses that you can still remember.
AFAIK, no mobile network in existence will even route inbound TCP/IP. At one time in the distant past, Sprint would relay up to a few bytes per second sent as UDP to the public IPv4 address of a phone connected via 1xRTT, but they pulled the plug on THAT sometime around 2006.
I know that today, T-Mobile (and probably others) have begun to use the US DoD class A (or at least a hefty chunk of it) as a de-facto private address space for non-routable ipv4 addresses assigned to phones.
Slashdot Mirror
> the HTML specification document neglected to mention which CSS should be used to get eg
From what I remember, there were quite a few things you could do with table/row/cell going all the way back to IE3, but COULDN'T do at all with CSS1, and couldn't reliably do with CSS2 in a way that was cross-browser compatible without implementing multiple variants that were more trouble than they were worth, and either serving different HTML based on the browser-sniffed user agent string, or using conditional comments and doctype to tell IE what your precise expectations were and hide whatever you did from Firefox & Opera -- and getting it to work with Firefox & Opera required major DOM-manipulation via Javascript in onLoad().
I distinctly remember that we didn't start seeing articles saying, "There's now nothing you could do with tables that you can't do with CSS" until CSS3 became commonplace. The CSS1-era articles all basically said, "Sorry, can't do it", and the CSS2-era articles basically said, "You can sort of do it if you're feeling incredibly masochistic, but it's almost pointless to bother").
The biggest roadblock to metric adoption in the US was the insane idea that anything expressed in metric units had to be some whole multiple of 10 or 100. We weren't allowed to have 5mL and 15mL measuring spoons... they had to be 1mL and 10mL, bundled with an equally-useless 100mL measuring cup. Or at least, that was what you'd think if you saw the useless set of baking utensils my mom & grandmother got for Christmas at some point in the late 70s. It was like there was some unwritten rule banning 250mL measuring cups, because it wasn't a "proper" metric size.
The sole exception to the "whole multiple of 10" rule was speed limits. Without exception, the speed limit in km/h was always less than the speed limit in miles per hour -- sometimes, a lot. Hence, signs that listed metric speed limits for 55mph and 30mph as 88km/h and 40km/h. I specifically remember the news reports on TV about how the 30mph/40km/h signs were vandalized at an abnormally-high rate (in rural areas, they were usually shot full of bullet holes). Had the government given drivers a freebie, and listed the metric speed limits for 55 and 30mph as 90km/h and 50km/h respectively, I *guarantee* American drivers would have LOVED the metric system. At least, in that specific context.
DST is an anachronism. Only old people (esp. those in congress) oppose getting rid of it.
I know plenty of people -- young AND old -- who'll happily support a proposal to abolish DST, as long as "abolish DST" means "stay in summer time all year".
40 years from now, DST will begin in early February, end the weekend after Thanksgiving, people will bitch about the stupidity of changing clocks for just 9 or 10 weeks, and the DST-abolitionists will be trying to abolish summer time and turn 9 weeks of winter time into 52, and wondering why everybody opposes them.
> why the hell would you connect your house to the internet or any appliance on the Internet anyway.
So you can check up on your cats during the day while you're at work, and reassure yourself that the house hasn't gotten broken into in a way that somehow managed to avoid setting off the alarm. And dispense treats for them from the Magic Invisible Food God if you start to feel guilty about leaving them home alone all day. And drive the Roomba-platform-mounted webcam around to their favorite hiding spot (still working on *that* one).
There's also the fact that more traditional means of remote home control (via phone) rarely work well with VoIP and voicemail. My alarm, for example, DOES have a telephone interface module... but it depends upon having an answering machine pick up the call so it can eavesdrop and listen for the triggering code. If the call rings until it goes to voicemail, the alarm never gets a chance to listen in and grab the call away from the answering machine. If the alarm answers the phone, and it was somebody calling, all it can do is play back a ~5-second .wav file apologizing and hang up on them. Did I mention yet that the way Android phones implement keyboard DMTF (playing a short pre-generated sample, as opposed to generating the tones on the fly in realtime), coupled with the way most VoIP codecs and mobile phone networks mangle DMTF, causes roughly 1 or 2 digits per dozen or so to fail to get recognized?
As a practical matter, thanks to VoIP, voicemail, and mobile phones, you almost *have* to implement your controls via IP rather than dial-in unless you want to pay AT&T $35/month for a landline phone that you almost never actually use.
That said, most internet-interfaced home automation controls are HORRIFICALLY insecure. If their interface consists of a Wiznet serial-to-IP module, and actually depends upon Wiznet's own password-based security, you should probably just assume it's been pwn3d several times over. ESPECIALLY if whatever's connected to the serial port end of the Wiznet module was designed to be physically connected to a real RS-232 serial port inside a locked cabinet, and all they did was strap the Wiznet module onto it. A security-free serial port isn't a great idea, but if it's inside a locked cabinet inside your house, it's pretty low on the list of concerns unless you have servants spending time unsupervised inside your home. That same security-free serial port strapped onto a Wiznet module with 8-character password (and with no rate-limit or lockout policy) can literally be bruteforced via UDP in a matter of days if the password is purely alphanumeric.
ARM-based modules aren't a whole lot better, because manufacturers try to shave 17c from the manufacturing costs and cram everything into a few megs of flash. Of course, the first thing that gets cut when the compiled code is a little too big is the security. To manufacturers, security isn't a quantifiable selling point compared to features, and strong security raises tech support costs anyway by making the device more likely to NOT work for some non-obvious reason.
IMHO, the only secure way to connect embedded hardware with minimal security to the internet is through a gateway appliance that shields them from direct contact with the internet, and acts as a proxy server/firewall/application level gateway. Preferably, running over a different physical network, and at the very least (if wire-sharing is inevitable), segregating the insecure devices into a different IP range that can communicate ONLY with that gateway.
Note that if 100mbit ethernet is fast enough, you can actually wire two electrically-independent 10/100 ethernet jacks with a single cat5e cable (use green & orange for one, blue & brown for the other). If you pull two cat5e cables from every room to the wiring closet, you can use one for gigabit ethernet (possibly using a pair of layer VLAN-capable switches that support layer 2 IGMP snooping to isolate the "TV multicast network" from the "hom
Don't forget... the new G7 ALSO spent the afternoon writing a stern letter telling Putin how angry they are.
On the other hand, the Find 7 has two things the Nexus 5 will never have:
* removable battery
* microSD card
And as a practical matter, it's about as open as the Nexus 5. I think I even read that it has open-source drivers for one or two chips that are proprietary binary blobs in the Nexus 5.
A Nexus 5 can run Cyanogenmod with minimal difficulty. A Find 7 gets to have Cyanogenmod as its official operating system right out of the box.
Over at XDA, the Find 7 is a popular choice for "next phone" among Nexus 5 owners, and became the #1 choice of users who WERE looking at the Galaxy S5 almost overnight, once news leaked that even the T-Mobile S5 would have a locked bootloader.
Zero latency is impossible due to both the speed of sound in air and the speed of light (which indirectly governs the speed of information-conveyance by electrons over a wire. For the sake of being pedantic, the actual electrons travel along the wire at a relatively slow speed).
Imperceptible latency is impossible with anything besides analog modulation schemes like FM, or uncompressed PCM. By the very definition of stream and block compression, you have to buffer SOMETHING.
That doesn't mean there's no room for improvement... but what you're asking for basically at odds with data compression.
It's the same reason why hearing aids are still overwhelmingly analog devices. Digital technologies -- especially cheap ones -- introduce unacceptable latency.
> I doubt that this would fit comfortably in a pocket.
Think again. The Find 7 was explicitly designed to minimize horizontal bezel. Its width is less than most phones that have screens a full centimeter smaller.
I havne't personally laid my hands on a Find 7 yet, so I can't guarantee it will fit in a back pocket... but I'll be shocked if it's really too big to fit in the back pocket of an average, non-obese male wearing relaxed-fit jeans.
Mobile games don't suck because the displays are too high resolution... they suck because it's nearly impossible to buy a phone with proper analog & digital gamepads and buttons.
Touchscreens are unfit controls for anything that requires hair-trigger muscle memory responses, and accelerometers/gyros would only be suitable in some scenarios if the display you're looking at weren't part of the same slab being tilted. And the few devices that DO have gamepads make too many compromises for the sake of having a thin profile, and destroy most of the advantages of having a real gamepad in the first place. It's like manufacturers think that things like tactile snap and accuracy cease to matter the moment you add a radio modem to your pocket videogame system.
> Seems most manufacturers (and users?) forgot the "phone" bit.
What's this "phone" thing people keep talking about? You mean that old legacy "voice" mode that nobody uses anymore? Ew... Voice calls just seem so rude and intrusive.
> My Samsung Galaxy S3 Mini gets around three days stand-by with light to medium use..
ROFLMAO. How the other half lives...
I've managed to wring my Galaxy S3's stock battery dry in about 2 hours, and would estimate that my ~3,000mAH Seidio extended battery is good for about 5 hours of really hardcore use (though it usually doesn't fall below 10% until an hour or two before I'm ready to go to bed).
Admittedly, part of the reason my battery life is so bad is because I have zero tolerance for touch-latency or lag. I have my kernel tweaked to keep the CPU running full-bore if I've turned on the display within the past 5 seconds, or touched the screen within the past 10 seconds. The basic strategy is "ramp up to max speed at the slightest hint of upcoming interactive use, but allow it to slowly reduce the speed if I go for more than 5 seconds without touching the screen, or allow it to rapidly slow down & go to sleep if I actually turn off the display. It's spoiled me. Using a S3 with a stock ROM and normal CPU governor feels like I'm slogging through wet concrete. The truth is, 99% of the lag people complain about with Android phones is due to CPU-throttling. Force it to run at full-bore, and the lag magically goes away.
> Unfortunately, not for a phone with this kind of a screen.
Fortunately, Oppo listened to the feedback from people who saw the Find 5, and wisely gave it a removable battery (as well as LTE and microSD). So, you'll be able to buy a nice, big, beefy 6,000-8000mAH+ aftermarket battery for it. Or buy a half-dozen spare regular batteries from someone on eBay, and swap them out as needed throughout the day and night.
> Why this incessant focus on processing power?
Because modern webapps depend on Javascript for everything, and Javascript completely sucks on most current mobile platforms. Like it or not, a webapp that uses Javascript to render itself into an empty [body/] tag's DOM needs a metric shit ton of ram and a fast, multi-core CPU. Unfortunately, that description now includes a large plurality of the web sites that we use today.
The solution isn't to make our phones slow and laggy to maximize battery life. The solution is to give our phones bigger batteries so they can keep chugging along at full speed all day, remain alive overnight, and have enough power left to get you through breakfast online.
10-15 years ago, nobody bitched about the size or weight of a Palm Pilot or PocketPC. Our phones have now grown to the approximate length and width of a turn of the century PDA, but there's still an industry-wide unhealthy obsession with being thin and light at all costs. I'd LOVE a phone with the approximate dimensions of a 2001 iPaq that fills most of its interior with 12,000mAH or more of lithium ion goodness.
I only wish it were that simple. On my computer at work, I have at least one Java app that literally dies on launch unless you have BOTH 32-bit AND 64-bit Java installed. It exhibits this behavior on everybody's computer, and not just mine. Nobody, including its author, really knows why.
That oddball app notwithstanding, installing only a 64-bit JRE on a computer running 64-bit Windows 7 is NOT the universal solution. Google finally fixed it, but for the longest time, you literally couldn't do Android software development under Eclipse on a computer with ONLY a 64-bit JRE. It would randomly forget how to find the SDK, fail compilation due to bugs in your code that didn't actually exist (if you cut the class into the clipboard, saved the now-empty class, then pasted it back, all the errors would go away), completely mangle R.java, and would do a phantom cursor-left whenever you typed a semicolon at the end of a line, so that when you pressed return a quarter-second later, it moved the semicolon down to the next line and caused an error.
There a other examples of vehemently-32bit apps, but it's late and Android-Eclipse is the huge one that drove me nuts for about 2 years. Note that I'm not conflating Android and Java... Eclipse itself is what was screwing up when run on a 64-bit VM.
It's not nearly as bad as the situation with C(++), but the way Java's classloader refuses to allow jars-in-jars is still pretty stupid. We should be able to create an executable jarfile with a virtual /libs directory that contains all the thirdparty jarfiles our own app needs.
It's 2014. Nobody *cares* how much space the compiled bytecode takes anymore, because it's insignificant compared to the amount of RAM needed at runtime for the various heaps. And when there's an exception to that rule, it's usually with some app that's so utterly niche, the likelihood of having some other app on the same system that uses the same meaningfully-huge library is almost nonexistent anyway.
Ten years ago, we could cheat & copy the thirdparty jarfiles we used all the time to the JRE's /ext directory. That doesn't work anymore, because Java's near-weekly auto-updates mean it's now a moving target. The /ext subdirectory of today's JRE will be an orphaned wasteland by the middle of next week, and every app that depends upon automagically finding Log4j, HttpComponents, JSAP, and everything else in that directory will break unless we give our app its own copy anyway.
Far BETTER would be if Java could be aware of how much ram the computer has, and enlarge its heaps as necessary & possible. Few things piss me off more than getting OutOfMemoryException on a computer with 16 gigs because I forgot to manually specify a larger heap size when I launched some executable jarfile from the commandline.
I mean, seriously. Would it really be *that* hard for the JVM to handle TWO sets of memory pools instead of just one, so that if the Eden space (for example) gets exhausted and is due for GC, the JVM would check with Windows to see how much physical RAM is free, and if there's a lot of it, just allocate a new chunk that's roughly double the size of the old one, start sticking new data into the new one immediately, and consolidate data from the old one into the new one as a very, very low-priority non-blocking background thread that eventually returns the first chunk of RAM to Windows once everything in it has been either moved or freed. For longer-lived services where memory leaks are a real issue, you could tell it, "expand by doubling up to [max megs or percent free], then fall back to conventional garbage collection -- possibly, grabbing a new chunk of ram that's the same size as the old one if possible so the time-consuming object-copy can be deferred and done in the background"
The biggest problem with Java is the fact that it makes dealing with 32-vs-64-bit and user-vs-admin in shell and script environments needlessly painful under Windows.
I mean, seriously. Why, in 2014, do we STILL have bullshit like:
java -jar foo.jar arg1 arg2 arg3
(silent crash), or
[*very public crash*], or
"This application requires a 64-bit JVM"
then, have to screw around figuring out what the path is THIS WEEK to the right java.exe, because every goddamn semi-daily update changes the installation path, so you end up having to do something like:
{swear violently and with frustrated rage}
dir "c:\program files\java"
(see what the installation dir is this week)
"c:\program files\java\jdk1.7.0.69\bin\java.exe" foo.jar arg1 arg2 arg3
I mean, would it really kill them to give us an installer that installs BOTH the 32 and 64-bit JDKs, then creates a bunch of symlinks to a file named java.exe that -- when launched -- looks at the jarfile, determines whether it needs a 32- or 64-bit JVM, finds the latest 32- or 64-bit JVM as appropriate, and launches it -- passing the path to itself and the rest of the args as args?
This is an endless source of pain to me. Java is my main language & I end up using it for almost everything, and its awful handling of commandline launches has driven me crazy for years. When I write some tool I use a lot, I'll go to the trouble of setting it up to build with JSmooth so it can wrap the whole thing in a .exe file... but that's a royal pain in itself, and I'm dreading the day when I have to figure out how to use it to wrap a 64-bit Java app (I'm not even sure it can).
Java also needs to seriously improve the way it deals with UAC... like maybe install a privileged Java background service (that's normally asleep and idle) so we can launch apps as regular users under Windows 7, and programatically auto-elevate via UAC by having Java delegate sensitive tasks to that background service when necessary under Windows 7 or later. Or at least, create something like WindowsUACException that's a subclass of IOException (so Windows-aware apps can catch it explicitly and deal with it gracefully, without breaking Windows-unaware apps that are oblivious to UAC) that gets thrown when something fails due to UAC, instead of throwing some misleading Exception that makes it look like the filesystem is missing.
Regardless, Java's handling of Windows commandline launches of executable Jarfiles *sucks* under Java 7, and we can only hope they've had mercy on us and made it less dysfunctional under Java 8.
No sane airline would *allow* the President to fly commercially. It would be like painting a red target across its metaphorical face and daring terrorists to attack them, in return for less money and staggeringly-higher security expenses than it would otherwise have if normal people bought the tickets. And when the inevitable attack *did* happen, they'd get hit by lawsuits from everyone who ended up being "collateral damage". The amount of money they'd have to charge to guarantee that the service would be revenue-neutral for them (taking into account things like attacks) would probably be four times the amount we currently pay for the Secret Service and military to handle the logistics.
One bit of info that *might* be of interest... cell phone towers beacon to announce their presence to phones, but individual phones actually *poll* towers every few seconds. The reply from the tower lets them know when there's an incoming call, deliver SMS & voicemail notifications, etc. In theory, at least, if the mobile phone of any passenger came within range of a cell tower it was allowed to poll, there's probably a log of it somewhere.
That said, if the jet was at cruising altitude, the likelihood of a phone on board *doing* that is almost nil, because tower antennas are generally aimed downwards... partly, to minimize interference from airborne mobile phones that could otherwise splatter noise over a 40-100 mile radius (the line of sight when your transmitter is 5+ miles up in the air).
And how many atoms thick does the insulating layer between adjacent photosensitive or photoemitting structures need to be to prevent light emitted by one pair's LED from unduly influencing the state of an adjacent photodiode/phototransistor?
What, exactly, is the benefit of building a chip whose internal connections are basically all optoisolators?
Do the new AMD64-architecture assembly-language opcodes to do AES encryption and decryption count?
http://en.wikipedia.org/wiki/A...
http://www.intel.com/content/w...
Of course, there's also ARM. It's not new, of course, but programming ARM in assembly language is kind of a recent developmen (though I'd conservatively estimate that at least 20% of assembly-language ARM code is probably malware).
In theory, you can even do JVM assembly. It's kind of pointless and masochistic, but people have done it just to say they have. ;-)
For anybody who knows... could a radar system partly or completely side-step the Doppler Dilemma ( http://en.wikipedia.org/wiki/W... ) by doing DSS or FHSS and cycling through a sequence of different carrier frequencies from pulse to pulse?
The problem is, there's no way to safely STORE large numbers of Bitcoins. Banks can store a trillion dollars with zero risk by depositing it at the Fed. The Fed notes the deposit, backs up the record in multiple places with enormous amounts of redundancy, then shreds any actual currency that was part of the deposit because it doesn't NEED it. It can always print new bills to replace the deposited ones should the need arise.
With Bitcoin, a bank can't do that. If a bank stores a thousand Bitcoins somewhere in exactly one super-secure location, and the medium on which they're stored gets physically destroyed, those Bitcoins are as gone as the money from depositors at a Wild West bank that just got robbed & had its vault emptied. Or boxes of British Pounds on a sunken ship resting in the middle of the Atlantic Ocean circa 1880.
With virtual Dollars that exist only as bookkeeping entries at the Fed, geographically-dispersed redundancy increases robustness and security. With Bitcoins, it increases their likelihood of loss by malware or theft. The only way to protect Bitcoins is to store them in a non-networked environment... but if you're burning a thousand bitcoins to BD-R discs and transporting them to vaults around the country, you'd better have armed security guards watching the discs, because a single stolen disc could be worth literally millions. If you're encrypting them and transporting them over a network, you're gambling on the encryption key not being compromised. If you're printing the base64 hashes to exactly one -piece of paper per Bitcoin and storing them in a vault, you're gambling on the vault not getting stolen or destroyed. And ultimately, you have to transfer that Bitcoin back to a networked computer in order to spend it... and all it takes is one bit of malware at that instant to completely negate everything you did up to that point to store it safely.
There's a reason why businesses don't like to handle large amounts of cash -- it's dangerous. And the danger increases exponentially with the amount. With Bitcoins, everything is effectively a cash transaction, with all the real-world risks that entails.
Or if you want to be cute, and you can hack your router's firmware a bit to auto-map internal ipv4 to external ipv6, you can ignore the fact that the underlying representations are fundamentally different and do something like:
internal device #1 = 192.168.100.101
external ipv6 prefix = 2001:44b8:6116:5aff::
internal device #1's public ipv6 address: 2001:44b8:6116:5aff:192:168:100:101
There's no law that says the lower bytes of your ipv6 address HAVE to be some god-awful value. As the parent noted, you could quite legitimately assign ip addresses to devices on your local network as 2001:44b8:6116:51ff::1, 2001:44b8:6116:51ff::2, 2001:44b8:6116:51ff::3, etc.
You can even make up addresses that spell cute things, like:
2001:44b8:6116:51ff:B16:B00:B5:1 ("Big Boobs 1"), 2001:44b8:6116:51ff:f00d:f00d:dead:beef, etc.
If you can deal with remembering a public ipv4 address and a dozen 10.x.x.x or 192.168.x.x addresses with inbound port-mapping rules, you can translate the whole thing to a scheme for assigning internal addresses that you can still remember.
AFAIK, no mobile network in existence will even route inbound TCP/IP. At one time in the distant past, Sprint would relay up to a few bytes per second sent as UDP to the public IPv4 address of a phone connected via 1xRTT, but they pulled the plug on THAT sometime around 2006.
I know that today, T-Mobile (and probably others) have begun to use the US DoD class A (or at least a hefty chunk of it) as a de-facto private address space for non-routable ipv4 addresses assigned to phones.